Version. 0.1 · Date. 2026-08-10 · Author. Claude Code (read-only scoping). Operator: Marvin Percival.
Fence. Read-only. Nothing built, nothing fixed. Engine at 4ae5509 throughout; diagnostic classifier probes (pure LLM calls, no writes) were the only executions.
Grounding. The CR-2026-197 eye-test observations (checkpoint report §6); code reads cited inline; a full assert-without-confirm sweep of every intent handler, formatter, and template.
Half (1) — the unreachable grant — is a wiring-and-parsing defect. Deterministic, structural, in the delegation pathway.
Half (2) — the save that wasn't — is a truthfulness defect. The reply mechanism hands the microphone to the model on exactly the branches where nothing happened, with weak-to-no constraint against claiming actions. Same class as B-82; different machinery entirely from half (1).
Per the Operator's conditional ruling: the truthfulness half gets its own CR and goes first. The sweep (§4) found it is not one branch but a class with four members, one of them worse than the observed instance.
(1a) Reachability. extract_delegation_grant is wired into exactly one call site: _route_remember_about_me's new-fact branch (router.py:3566). _route_add_knowledge — where an in-engagement sentence lands — has no grant recognition at all. The denial reply's own suggested sentence ("you can draft specifications"), said in a project conversation, classifies as add_knowledge and commits as a plain project note. Observed live in the eye-test; the classifier probe confirms the sentence alone classifies general_conversation (0.85) with no context and add_knowledge in-engagement.
(1b) NEW — the paraphrase defeats the parser even on the personal path. The classifier does not pass the Operator's words through; it extracts personal_fact, and the extraction paraphrases. Probe, context-free: "Remember about me: you can draft specifications." → remember_about_me (0.82) with personal_fact: "Can draft specifications." — the "you can" prefix is gone. extract_delegation_grant("Can draft specifications.") → None (its recognition is prefix-matching: you can|go ahead and|feel free to|i authorize you to|you may). So even a turn that routes correctly and writes successfully can capture the grant as an ordinary personal note carrying no delegation — the authority never comes into being, and the system says "Got it — held" truthfully about the wrong kind of object. With fuller conversation history the probe extracted the fact verbatim (0.92, 3/3 stable), so (1b) is intermittent by paraphrase, which makes it worse: it works in demos and fails quietly.
Design shape for the eventual CR (not designed here): prefix-matching classifier output is the fragile joint. Recognition should run on the Operator's raw message (which the handler has) rather than the extracted paraphrase — or the grant should be its own intent. That is the CR's decision, not this brief's.
Established structurally — it is NOT "composed before the write is confirmed." Every writing branch of the personal path composes its ack server-side after the write call returns (delegated_response built from the write's return value: router.py:3549, 3591, 3613), and the request wraps one transaction committed at dependency teardown before the response is sent (api/deps.py:40-57); a commit failure becomes a 500, not a false ack. The defect is the other one the Operator named: a reply claiming success on a path that returned without writing.
Bounded, not exact — which branch fired live. The candidates are exactly two, and both are non-writing branches whose reply the model composes:
_route_remember_about_me branch no_personal_fact (router.py:3556-3562) → the remember_about_me.md template, whose per-action instructions are correct and prominent, but whose preamble falsely asserts "The substrate has already acted on this turn" — false on precisely this branch, pulling the model toward a success claim. The observed reply's "across all projects" phrasing matches this template's framing.general_conversation fallback → no structural result and no anti-overclaim language at all (general_conversation.md constrains triggering operations, not claiming them).
The exact branch cannot be recovered: the forensic record — the turn's stored classified_intent — was deleted with E0124 in the eye-test teardown. My teardown; the cost is owned here. Reconstruction probes (3/3 at 0.92 with approximated history) produce a classification that would have written, so the live turn's classification or extraction differed from the reconstruction in a way the probes cannot pin. Both candidates are the same defect class and the same CR fixes both.
The larger fear is bounded and answered: the personal path does NOT claim a save whenever it routes there. Its three writing branches are safe by construction (server-composed, gated on the returned write). The exposure is confined to the two non-writing branches — plus the class members below.
Every intent handler, {operation_result} formatter, and instruction template was audited (full A/B/C/D classification held in the session record). The class has four live members, ranked:
add_knowledge's error branches — worse than the observed instance. On no_project or empty extraction (router.py:385-397): no write, no delegated reply — and add_knowledge.md is a single success-voiced line ("You are noting it down… not just that you recorded it") with no {operation_result} placeholder. The corrective formatter _format_add_knowledge_error exists, is correctly written ("Ask which project they mean") — and is computed and thrown away, because the splice only happens when the template contains the placeholder (prompt.py:1134). A well-written failure instruction, structurally unreachable. This is the clearest claims-a-write-that-never-happened path in the codebase.request_draft / request_revision render a FAILED dispatch as a fait accompli. The executed outcome is set unconditionally from execute_pre_authorized (router.py:2054-2076, 2216-2238) — but dispatch_action returns {"status": "failed"} on no-dispatcher/exception, and _format_delegation_action's executed branch never reads execution_result["status"] (prompt.py:874-883): "you produced the {target}… report the outcome briefly as a fait accompli." The neighbouring _format_approve_draft already branches on status correctly — the discipline exists and was simply not applied here. (Currently dormant for the three Tier-1 capabilities because CR-2026-197's per_action_only makes executed unreachable for them — but the code is live for any unflagged dispatcher.)remember_about_me non-writing branches under a preamble that asserts the substrate acted, andgeneral_conversation fallback — no constraint against claiming actions, on the path misclassified action-requests land on. The B-82 "I'm drafting… now" observation is this same member.The root enabler, named by its absence: the persona's truthfulness rules govern state naming (held vs saved, provenance) but contain no rule of the form "never claim to have performed an action the system did not report performing." That absence is what makes members 1, 3, and 4 live rather than latent.
Adjacent but safe (the good pattern, for the CR to copy): save_filter and tune_setting — Action:-first formatters, every failure action enumerated in the template, explicit anti-overclaim rationale. Safe by template. The delegated handlers (commit_assertion, discard_held, open/close_engagement, forget_about_me's confirms) are safe by construction. Two latent smells for the CR's edges: commit_project_draft.md has no failure voice and its {operation_result} renders empty (formatter has no branch — the silent return "" fallthrough at prompt.py:838); forget_about_me.md still carries a dead scripted "Done — I've stopped using that."
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — B-81 Step 0 findings — v0.1 — 2026-08-10 The success branches cannot lie; the branches where nothing happened are the ones holding the microphone.