B-98 scoping — is it really one CR? — v0.1

Date. 2026-08-14 · Item. [B-98] (build list v0.80) — the Companion findings-blindness, one item, three faces. Mode. READ-ONLY. Report, not draft. Engine f011c80, surface a1deb86 (clean). The Operator's read under test: faces 1+3 are plumbing (no design decisions) and ship as one CR; face 2 (what answering a finding in conversation DOES) is a design question, scoped separately — unless face 2 is smaller than it looks, or 1+3 can't be built without deciding it.

A correction first: the inspection brief wrote the amend route as POST …/seed/amend. It is POST /engagements/{id}/seed (engagements.py:330). Folded in here rather than left standing.

Verdict: the read HOLDS. 1+3 is one CR of plumbing with two named wrinkles (both precedented); face 2 is genuinely a design question, not smaller than it looks; and 1+3 requires deciding none of it.

Face 3 — everything exists engine-side, and yes, the amend shape is reusable

• The findings read: GET /engagements/{id}/seed/findings → FindingSchema[] — finding_id, requirement_identifier, location_in_seed, suggestion, state, cycle_number. Already scoped and auth-hardened (the F3 fix: creator-gated via assert_engagement_creator, filtered to this engagement's own seed lineage). Everything a findings panel needs to render, including the suggestion text the Operator never saw on E0128.
• The amend route needs nothing the candidate page doesn't already have. Auth is assert_engagement_creator — the same dependency the page's instantiate ceremony already satisfies, and the page already knows viewer_is_creator (CR-207's wire). The body is partial (null fields carry forward) — "answer one field" is its native shape. The surface adapter already exists and is surface-agnostic: amendCandidateSeed(engagementId, changes) in lib/api/door3.ts — nothing door-3-specific in it; sharing it is an import, not a port.
• Wrinkle A — the sequence (a flow fact, not a decision): amend does NOT close findings. Each amendment writes a new seed version; the close comes from POST /engagements/{id}/seed/induct, the cycle that re-reviews and closes what the amendment satisfied. Door 3's adjust flow calls amend only (its induction happened at extract). So face 3's "answer" button is amend → induct, two calls; induct spends one LLM cycle (existing route, existing deps — and its engagement_id Path dependency is satisfied here, unlike the unmountable create-from-conversation handler). The panel then refetches findings and the banner state.

Face 1 — mechanical, with one precedented wrinkle

Adding a findings block for candidate-state engagements is a state check plus the same read the GET route already does, formatted into the prompt (the tier system is content-based — a fresh candidate sits in seed_only; the block belongs to candidate STATE, orthogonal to tier).

• Wrinkle B — the cache: findings live on the ADMINISTRATIVE log, keyed by seed_id in the payload (creation.py::_load_induction_state — Fault A's own comment). Raising or closing a finding does NOT bump the candidate's current_engagement_version, so the context cache would not invalidate on finding changes. Exact in-house precedent: B-77/CR-2026-202 ("the prompt cache asks the seed's own log") — the same shape, one log over: on cache hit for a candidate, also check finding freshness (max object_version/count for the seed_id), or simply skip caching candidate-state contexts (candidates are low-traffic by construction). Mechanical either way.
• A drafting note for the 1+3 CR, from the standing note (offers gate on capability): the findings block's prompt instruction must be capability-honest — with findings visible, the Companion must not OFFER to close them (face 2 is unbuilt). The right composed posture is "here is the open finding; the panel above can answer it" — which face 3 makes true the moment it ships. Faces 1 and 3 make each other honest, which is itself an argument they are one CR.

Face 2 — the design question is real, and it is NOT smaller than it looks

Nothing exists: no intent (31 routed, none seed-touching), no assertion↔finding linkage anywhere in schema or code, no answer path. Building it requires deciding, at minimum:

1. What an answer DOES — amend the seed directly from conversation (a seed write with a conversational actor), or hold-pending-confirm (then Confirm needs a new linkage from the held assertion to the finding, plus a commit-side effect that runs amend + induct).
2. What closed the finding — the person (their confirm), the Companion (its extraction of the answer), or re-induction (the machine's re-check)? A provenance question with governance weight: the seed's operator-authority principle says the machine surfaces findings and the Operator decides — a conversational close must not blur who decided.
3. The actor on the amend event — each amendment is a new seed version with attribution; a conversation-driven amend writes the seed with whose hands?
4. B-69 adjacency confirmed: conversational seed writes land squarely on the seed-mutability standing question (what follows a moved seed). Not to be settled as a side effect of an answer path.

And 1+3 requires deciding none of the above. No shared code forces the choice; the panel's amend→induct is the existing HTTP ceremony with existing attribution (the creator, via assert_engagement_creator), and the context block only reads.

The test the Operator named, applied

"1+3 alone would have unstuck me today — I'd have seen the finding text and had a button." Confirmed against the code: the finding's suggestion field contains exactly the sentence the walk needed ("The success_conditions assertion is present but empty. Add observable criteria…"), the GET route serves it to the creator, and amend→induct with one field filled closes it. Face 2's absence, with 1+3 shipped, degrades to an honest limitation the Companion can state — not a trap.

What awaits ruling

The 1+3 CR draft (findings into candidate context with the B-77-shaped cache check + capability-honest prompt posture; the candidate page's findings panel with the amend→induct affordance), and a separate face-2 scoping when it ranks — its four design questions are enumerated above so that scoping starts from decisions, not discovery.

DUNIN7 — Done In Seven LLC — Miami, Florida — B-98 split scoping — v0.1 — 2026-08-14 The split holds: two faces of plumbing that make each other honest, one design question that deserves its own room. Amend, then induct — the close belongs to the cycle.