Date. 2026-08-15 From. The E0128 walk arc, 2026-08-11 to 2026-08-15. To. The next Claude.ai session. Operator. Marvin Percival.
Read, in this order:
session-handoffs/session-close-2026-08-15-e0128-arc-v0_1.md — the arc's own close, written by Claude Code.standing-notes/dunin7-build-list-v0_87.md — the current build list.Nothing is mid-flight. No unpushed commits, no halted change requests, no pending gates. Both services are deployed on their landed commits.
The Operator signed into the product and used it. Every defect in this arc was found that way — not by scoping, not by code reading. Several were invisible to both.
The first one set the pattern: pressing "Make it official" on a project said "Couldn't commit — try your passkey again." Two days went into the passkey. The server had been saying the real cause all along — an open seed finding — and a catch block on the surface had replaced it with a message about passkeys.
Nine change requests shipped from that thread. Seven items closed. The engagement at the centre of it, E0128, is now committed, readable, and its own history contains the Companion admitting it couldn't see the finding that was blocking it — three CRs before the fix that made it visible.
Both are design questions. Neither is answerable by reading code, which is why they sat.
The concrete symptom. When a draft project (a "candidate") is discarded, its induction findings survive. They sit in the administrative log, pointing at a seed that no longer exists. Nothing breaks — they block nothing, nobody sees them — but every discarded candidate that went through induction leaves one behind.
Why it's a real question rather than a cleanup task. It depends on what a finding is about.
The two answers produce different work. The first is a delete query. The second says the schema records findings against the wrong object, and fixing that touches how induction is stored.
What tips it either way. Ask whether a finding could ever be interesting after its seed is gone. If someone would ever want to know "this engagement was reviewed and had gaps" — for provenance, for a pattern across engagements, for the record's own sake — the finding is about the engagement. If a finding only ever means "this document is incomplete," it's about the seed and dies with it.
Adjacent, worth knowing. The Operator has a standing item (B-69) on seed mutability — what happens to derived work when a seed changes underneath it. That question and this one are neighbours: both are about what a seed's identity governs.
Also worth knowing about how this was found. An FK census enumerated 27 foreign keys pointing at engagements, to work out what a discard must handle. The orphaned findings were structurally invisible to it — they point at the administrative engagement, not the candidate — so they never blocked a discard and never appeared in the enumeration. It took discarding a real object to surface them. The lesson filed: an enumeration answers the question it enumerates and is silent on the rest.
The context. A draft project can be blocked by an induction finding — the system reviewed the seed and something is missing. Until recently the Companion couldn't see those findings at all, and the project page showed only a count. Two of the three fixes shipped: the Companion can now see findings, and the project page shows the finding text with a box to answer it. That path works end to end; the Operator used it to commit E0128.
What's left. Answering a finding by typing to the Companion in conversation is not wired. Right now, doing that captures your words as an ordinary note in Memory — it doesn't touch the finding. The Operator hit this exactly: he answered in the composer, and it landed as a held note while the finding stayed open.
Whether to wire it is the question, and four sub-questions have to be settled first. They were enumerated during scoping so they wouldn't have to be discovered:
(a) What does an answer do? Two shapes. It could amend the seed directly — you say it, the seed changes, the finding is re-reviewed. Or it could hold pending confirmation — your answer sits as a proposal until you confirm it, matching how Memory contributions already work. The second is more consistent with the rest of the product and slower; the first is faster and skips a gate.
(b) What closes a finding? If an answer closes it, who closed it — the person who spoke, the Companion that captured it, or the re-review cycle that judged it satisfied? This isn't bookkeeping. The seed's governing principle is that the machine surfaces and signals and the Operator approves. If the Companion's capture of your sentence closes a gate, something needs to say plainly whose act that was.
(c) Whose hands are on the amendment? Amending a seed is an event in the record with an author. If the Companion writes it on your behalf, the record needs to show that accurately — not as though you edited the seed directly, and not as though the Companion decided anything.
(d) How does this sit with seed mutability (B-69)? Conversational seed writes land squarely on the open question of what a seed changing means for everything derived from it. This may not be decidable before B-69 is.
A defensible answer is "not yet." The panel path works. The conversational path is a convenience, and it's the one that touches the seed. Deferring it is a legitimate ruling, and if that's the answer it should be recorded as chosen rather than left open.
| Item | What | |---|---| | B-100 | The finding-answer box sits above the header bar, visually separated from the working surface — the Operator pasted into the composer twice before finding it | | B-94 / B-97 | Two splicing defects: a surface template swallowing a name mid-clause, and an engine clip cutting text mid-word | | B-91 | The message-order ruling (newest-first, composer at top) is unapplied on mobile | | B-92 | A one-time layout jump on load for accounts with a stored non-default order | | B-102 | A disambiguation prompt prints display numbers its own answer path can't consume — the speakable-number vocabulary has existed in-house since CR-127, unimported | | B-103 | Duplicate personal facts accepted at capture — the write that makes B-102's trap | | B-104 | A recall count that is honest at 8 and silently false at 501 |
The gate string is exact. GATE A APPROVED — PROCEED for CR-XXXX, and it belongs at Checkpoint A — after the build, before tag and push. Permission to start a CR is a separate, ordinary approval. The Operator has typed the wrong one at the wrong gate three times; Claude Code holds him to it, which is correct.
Approvals are never standing. One approval, one CR, given after seeing that CR's numbers.
Claude Code asks rather than infers. A loose phrase like "ready whenever you are" is a question to ask back, not an approval to read through.
Every artefact carries a version in its filename. No in-place edits to committed documents — supersede with a new version and keep the prior one intact.
Two roles. Claude.ai scopes, drafts change requests, and rules. Claude Code reads the live tree, builds, tests, and reports. Claude.ai does not assert facts about the code it hasn't read — this arc produced four wrong premises that way, each caught at Step 1.
Plus a meta-pattern, four instances: a ruling that says "think here" becomes a guarantee only when the thinking leaves evidence.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Claude.ai session handoff — v0.1 — 2026-08-15