Developer confirmation of the 600-body milestone was requested and given before this record was
written, per the plan. The phase closes at 602 distinct matched bodies / 611 registered regions, from
the Phase 10 close state of 484 / 493 (+118 / +118).
Closing gate set, all green from a clean tree:
make clean && make all exit 0
cmp exit 0
SHA-1 (both files) e173426c157384ebf1b6caf8c6fea18a85a14af9 (UNCHANGED from Phase 10)
make test 253 tests, OK (from 237)
make extents-verify regions=611 disagreements=0 result=AGREE
make gate c_regions=611 differing_bytes=0 result=MATCH
The SHA-1 being identical to the Phase 10 close is the point: all +118 bodies are additions to a
binary that still reproduces exactly.
Records written:
phase-ends/PhaseEnd_Phase11.md the close record
docs/PHASE11_VERIFICATION.md the verification record
phase-ends/DIGEST.md Phase 11 section
phase-ends/CURRENT_PHASE.md rewritten: NO PHASE ACTIVE, roster-restart warning
phase-ends/logs/Phase11.md Cycle 3 close, corrections, ledger reconciliation
docs/MATCHING_COOKBOOK.md 187
docs/ORCHESTRATOR_WORKFLOW.md section 4.0 roster rule, section 10 close steps, section 11
Three corrections made during the close, each to something already reported:
1. The negatives index was reported as "200 rows, 82 with a mechanism". Measured: 194 data rows
(200 LINES, 6 of them header), 101 with a named class, 86 with a substantive note, 92 with no
class at all. The 700-body route is LARGER than reported. wc -l on a file with header comments is
not a row count -- and the same error was then made again with the symbol count (413 lines, 400
rows) inside this very record.
2. One in-flight ledger row was STALE-TAKEN and invisible. 0x800298C0 (392 B) traced
C wip -> C released -> A wip -> C wip, so last-row-wins read it TAKEN while NEITHER holder was
working it -- both were out of context and would never append a release. It is a live worklist
row and is NOT in the negatives index, so nothing else would have surfaced it. Released with
coordinator as the worker field; tools/sf3_free now reports FREE. This is cookbook 179's failure
mode in its OTHER half: the copied script blocked rows that HAD been released, while this row
shows the ledger cannot express "the holder no longer exists" at all. Now a standing close step
(cookbook 187).
3. Worker A's "32 first-attempt" claims are not reconcilable from its artefact -- only 27 of its 46
report rows carry an explicit first-attempt note. 27 is recorded as the verifiable figure and 32
is flagged unverified, because a first-attempt rate is a COST claim and cost claims drive
dispatch.
Ledger reconciliation at close: 275 rows over 135 addresses; last row released for 113, claimed for
21, wip for 1. The 21 claimed rows are all already registered, so they need no action -- claimed is a
legitimate resting state.
The roster does NOT survive this close. All six worker sessions are retired and their herdr panes
closed, so Phase 12 MUST spawn a fresh roster; there is nothing to reconnect to. This is a change
from Phase 10, which left three retired sessions listed in `intercom list` -- and a roster that is
retired but still listed is indistinguishable from one that is live. Both halves are now standing
rules in ORCHESTRATOR_WORKFLOW section 4.0.
No changes to AGENTS.md.
Christopher Williams
ec7e2c6242