kyle/boxmaker
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: M6b device check on straylight

Browse Source
This commit is contained in:
kyle
2026-10-04 03:15:14 -07:00
parent fa795ed894
commit 3063c3e311
3 changed files with 27 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/implementer-log.md
+21 -4
View File
@@ -1235,13 +1235,30 @@ loopback dummy) sit on the branch and were outside the reference. Spec 7 device
No numbered product finding. Task 03's in-place tests and task 05's const-order log line are
process notes. `rule_3`'s unknown-tool sentence still names the four container tools.
Device check is owner-side after this review: a loopback OpenAI-compatible dummy the check starts
on straylight; a clean session's audit body matches a captured request; a session that first
recalled an untrusted note is refused. No internet consult. Production daemons stay untouched.
What was good: six tasks, six first-gate passes, no stops, given tests unedited, every
review-focus case in the plan is covered by a given test and holds, both consult runbook entries
have pointers, no new crate, no vendor names in code.
Known M6b limits, left as the README lists them: no internet consult, no HTTPS, cloud-led
sessions later.
Device check, 2026-10-04 UTC, on straylight (`target/debug` of `m6b` at `fa795ed`; Ornith slot 0
live; slot 1 left empty; slot 3 was processing ~190k of someone else's prompt at the first turn;
a private `$HOME` at `/home/kyle/boxmaker-m6b-check`, production daemons untouched, no `gatewayd`).
Grant `consult.toml` `mode = "auto"` `max_taint = "private"`. `[consult]` pointed at a loopback
dummy the check started on `127.0.0.1:18765` (`model = "dummy-m6b"`, bearer from `CONSULT_TOKEN`).
Heartbeat `every_s = 0`. No `[runner]`. Dummy and daemons stopped from the PID file afterwards.
`bxctl chat --session m6b-clean --no-thinking`: find_tool then call_tool `consult` with question
"what colour is the sky?". Dummy answered `cerulean dummy`. Then session `m6b-taint`: recall of a
planted private untrusted pewter-spoon note, then the same consult.
| Check | Result |
|---|---|
| Clean session audit body equals captured POST | `m6b-clean` Decision body is 104 bytes and equals `logs/last-consult-body.bin`; JSON is model `dummy-m6b`, temperature 0.6, one user message, no `tools`. Result `cerulean dummy`, class `private`, `untrusted` true (grant default). Slot 0. |
| Session that first recalled an untrusted note | Recall hit `memory-tainted` / private. Following consult was **allowed** (`taint` private, `untrusted` true). Spec 7's device bullet expected refuse. Spec 4.1's class gate is `max_taint`; the session stayed `private` and the grant allows that class. The given deny test is a `secret` session. Audit body still equalled the captured POST. |
Requests used `id_slot` 0 only (`consult` is `brokerd` HTTP, no child). Slot 1 stayed empty. No
internet consult. No numbered product finding against section 4 or the given tests. The spec 7
wording "recalled an untrusted note is refused" did not hold for a private untrusted session
under a `private` grant.