Gate exit 0 (693 regions, MATCH), 344 tests OK, make check exit 0, tracked patch regenerated so
pristine + patch reproduces the working tree.
+4 this commit (worker D): 0x80100334, 0x800FBDC0, 0x800F88F0 (all maspsx=epilogue), 0x80042DD4.
Phase: 602 -> 684 = +82. Milestone 750 was not reached; +66 remains.
TWO TOOL INCIDENTS OF MINE, both reported by workers before I saw them, both repaired:
1. I edited tools/sf3_match in place while four workers verified against it. The new add_argument
block landed between `--fill-epilogue` and its help=, raising IndentationError at line 1129 --
EVERY worker's verification failed for the duration. A verified with a probe copy and re-verified
with the official tool once it parsed; D reported it independently.
2. Reverting an untested transform, my scripted edit DELETED `_LOAD_RA`, the load-delay regex
fill_epilogue needs, breaking maspsx=epilogue for all 21 regions carrying the token. The
whole-binary gate caught it immediately (exit 2, no result line) and it is repaired at the point
of damage.
Guard adopted for every future tool edit: ast.parse immediately after saving, and one atomic write
rather than a scripted multi-step edit. A worker cannot tell a transient tool break from a broken row,
and the cost lands in their context.
ONE DEFERRED ITEM COSTS A BODY: `gp=-` is SINGLE-VALUED per region. D's 0x80102F58 (60 B) needs
D_801221A8/AA/AC registered with gp markers (proven: 60/0 with, 72 without), but A's merged 0x800FFF60
needs those same three ABSENT from the registry because it uses them as SYMBOLS with per-site macro
expansion. Measured: adding the rows breaks A's 140 -> 124; adding them AND giving A three gp=- overrides
restores A to 140/0 -- but the parser refuses with `duplicate override key 'gp'`. The resolution is
proven; only the option key's multiplicity blocks it. Cheapest remaining body in the phase.
The la SYM+N harness transform the developer directed was implemented and REVERTED, because it did not
close its target and an untested transform in the shipped tool is worse than a documented design. Its
mechanism, its guard, where it belongs in the pipeline, and the open question about WHICH STAGE's text
it must rewrite are all in the ledger so it can be resumed without re-deriving.
Also recorded: the gp-rewrite bug worker A found and I fixed (a stale %hi from an unrecorded register
redefinition); the compiler-boundary class (3 rows no vendored cc1 can build); the per-region codegen
flag policy; D's measured tier finding (4/4 with a call or a frame, 0/4 on leaves); and the reading
rules discovered this session, each with at least two instances.
**670 bodies / 680 regions. Phase: 602 -> 670 = +68.**
**+3 bodies, all verified by me from fresh --work dirs at their REAL extents:**
0x80107CCC (76 B, cc1bin=gcc-2.8.1-psx) -- A's row, unlocked by the tool fix below
0x8002D060 (72 B, D) 0x8006FAEC (88 B, D)
And +2 earlier this round: 0x8004D7C8 (220 B, B), 0x8003A9C8 (240 B, B).
**WORKER A FOUND A REAL BUG IN tools/sf3_match AND I FIXED IT.** `rewrite_gp_accesses`'s `_GP_LO`
branch rewrote `lw $2,%lo(SYM)($R)` to `lw $2,%gp_rel(SYM)($gp)` and then `continue`d WITHOUT recording
that the rewrite redefines its destination register. `carrying` kept the stale `%hi`, the register's
next use was scored as an unrewritten use, and the `%hi` was deliberately kept -- so the region came
out exactly 4 bytes long, one instruction.
I reproduced the evidence independently before touching the code, in 0x80107CCC's pre-fix output:
lui $2,%hi(D_801221CC) # high
lw $2,%gp_rel(D_801221CC)($gp)
The same failure the docstring says was fixed for the adjacent-lines case, still live for the
load-whose-result-is-used-later case. One-line fix, A's reasoning and name in the comment, plus why it
stayed invisible: nothing breaks until a gp-marked LOAD feeds something.
Measured: 80/LENGTH-MISMATCH -> 76/0/MATCH. **The tool change was GATED, not trusted**: the pass
touches every gp region, so the full gate was re-run -- c_regions=678, differing_bytes=0, MATCH. That
also answers A, which asked whether the four merged cc1bin rows needed re-verification; the gate is
what proves it and it was green.
**AND WORKER D FOUND THE SAME PASS FROM THE OPPOSITE DIRECTION** on 0x800FFBBC: cc1 2.8.1 puts a safe
`lui $2,%hi(...)` in a branch delay slot, the rewrite folds the hi/lo pair to gp-relative, the lui
DISAPPEARS and the store slides into the delay slot (48 -> 44). So A's case is the rewrite failing to
fire and D's is the rewrite firing and changing a schedule -- two faces of one pass, on two rows, found
by two workers who could not see each other's row. D's framing is the open item: a maspsx mode that
re-derives the delay slot after the gp-relative rewrite would likely close a class.
**cc1bin's measured boundary, and a correction to my own guidance.** B swept the compilers: 2.5.7 /
2.6.0 / 2.6.3 / 2.7.2 / 2.7.2-cdk / 2.7.2-psx give a MERGED epilogue; 2.8.0-psx / 2.8.1-psx give
SEPARATE jr $31 per return. So return merging is a 2.7.2-family behaviour. BUT 2.8.x also changes the
GLOBAL ACCESS FORM (explicit lui %hi / lw %lo pair instead of the symbolic load maspsx turns into
lw v0,2080(gp)). **The lever moves two axes at once and is not free** -- which corrects what I told A,
B and D when routing the multi-exit rows.
**0x80107D7C sits BETWEEN the compilers and is a genuine open question.** B: default 112, 2.8.1 104,
target 108. I swept all TEN vendored builds because B's table listed eight: only 2.7.2-cdk produces 108
bytes, and it is 30 bytes off in content. 2.91.66 and 2.95.2 give 100. So the length is reachable and
the content is not, on any vendored compiler.
**Two corrections of record, both mine:** I guessed extents instead of reading
config/function_extents.tsv (testing A's 76-byte row against an 80-byte extent and reporting
LENGTH-MISMATCH from a correct candidate); and I told three workers cc1bin was a clean lever for the
multi-exit rows when B's sweep shows it moves two axes.
**Ruling on A's per-region codegen flag request (0x800AB504): (b) class-bound, with the diagnosis
kept** -- because `-fno-strength-reduce` gives 152 against a 148 target. A flag that closes a row is a
lever; one that moves a row 16 bytes closer to a different number is a diagnosis. But the PRINCIPLE is
recorded for the next such row: a codegen flag is admissible on the same terms as cc1bin, i.e. a named
mechanism in the bytes, and A has one (address normalisation creating a second loop-carried pointer).
**D: the indexed and pointer loop forms COEXIST and neither carries across rows.** 0x8002D060 matches
only as an INDEXED loop; 0x80107B40 wants the pointer form. A direct refutation of pattern-carrying
from the worker with the most reason to trust a pattern. Also: the both-sides-volatile rule TRANSFERS
(0x8006FAEC), with the narrowing measured (only interleaved accesses need it); and READ the displacement
and compute the symbol rather than inferring it from an adjacent symbol's name (gp+0xBA4 -> 0x801224DC).
**Charter note: `--cc1-flag=X` REPLACES the default `-quiet -O2 -G0` set**, so a diagnosis run must
pass all four explicitly. A's first -fthread-jumps probe read 200 B purely because -O2 was dropped.
MERGE 23: +2 bodies from worker D's un-attempted band, both re-verified from fresh --work dirs:
0x800582AC (64 B) and 0x800A82D0 (64 B). Gate c_regions=676, differing_bytes=0, MATCH.
DISPATCH CORRECTION, and it came from checking a claim rather than forwarding it. D reported three
multi-exit rows as unclosable because 'my multi-return probes share ONE exit under all ten cc1 builds'.
Measured from the binary: ALL SEVEN unregistered multi-exit rows are >=2 jr $31, which is the gate's
precondition for naming an alternative cc1 -- so the restriction PERMITS the lever on every one, with
four merged rows as precedent.
And C's measured row refutes the probe conclusion directly: 0x801008DC is 3 exits and the default gives
the correct 88 bytes with 58 DIFFERING bytes because it merges all three returns, while
cc1bin=gcc-2.8.1-psx gives 88/0/MATCH. The merge is SHAPE-dependent, and a synthetic probe speaks only
for the shape it probes. I made exactly this error earlier in the phase with a probe-dependent
mechanism written into tools/sf3_match.
Rows routed: A gets 0x80107CCC (3 exits, A has the diagnosis), B gets 0x800FF6DC / 0x80100998 /
0x80107D7C, D gets 0x800FFBBC.
Also recorded: D's self-caught harness hazard -- its run helper leaves the LAST variant on disk, so its
first verification of 0x800A82D0 ran against the wrong variant and report.tsv's md5 described it. D
re-verified from a fresh directory and made the re-write explicit in its procedure. This is the failure
mode that would produce a FALSE MATCH CLAIM rather than a missed one, and it is invisible from outside
because the report's own md5 agrees with the wrong file.
MERGE 22: +2 bodies, both from worker D's un-attempted band. 0x801092C0 (52 B) and 0x80085B44 (60 B),
both re-verified by me from fresh --work dirs first. Gate: c_regions=674, differing_bytes=0, MATCH.
POOL FILTER, SECOND LEAK, MY ERROR CORRECTED. D found 0x80012D54 -- the charter-blocked 0x80012xxx
primitive-init family, with class , so the address-parsing rule I installed after the FIRST leak
(0x80012A98) had no text to match on. D read its bytes and confirmed the family.
I had explicitly DECLINED band-blocking the first time, arguing it 'would silently discard
unclassified rows on an inference the charter does not make'. That was backwards: the charter names
the family as 'the 0x80012xxx primitive-init family', i.e. BY ADDRESS BAND, and earlier phases already
acted on it -- 0x80012A10/AE0/B20/CFC, all class '-', are excluded BY NAME in the Makefile. Two rows
leaked by label phrasing and the second had no label at all. The band is the predicate. Blocked 8 -> 15,
pools 70 -> 54.
Also applying my own corrected commit idiom: this commit names the two claim sources rather than
using 'git add -A src/', which swept three of D's in-flight rows into an earlier commit.
New levers recorded: LOAD/STORE INTERLEAVING NEEDS BOTH SIDES VOLATILE (a volatile load can still
hoist above a plain store and vice versa; cc1 orders volatile only against volatile) -- and from
0x801092C0, unsigned-parameter signedness read from the instruction AFTER the test, volatile on a
table pointer for an alias reason, cookbook 19 generalising to a forward loop, and
`p += i + start; p->p0 = 0;` over the subscript form.
My per-merge command used `git add -A $(git status --porcelain src/)`, which adds EVERY modified or
untracked file under src/ -- and four workers write there concurrently. One merge commit therefore
carried three files I had not verified: an edit to src/func_80013114.c, a new src/func_80085B44.c, and
a 20-line DELETION from src/func_800FBF5C.c.
Measured, not assumed: all three are UNREGISTERED, so no region references them and the full gate
re-run on the committed tree is c_regions=672 / differing_bytes=0 / MATCH. Also committed here: the
deletion of src/func_80013114.c, which a worker made after I had committed the file, so that HEAD and
the working tree agree again.
The dangerous variant is one edit away and did not happen: if a worker edits a REGISTERED region's
source mid-merge, that edit is committed and the gate verdict from moments earlier no longer describes
the committed tree. Rule from here: a merge adds the named claim sources plus config/docs/tools, never
src/ wholesale.
Merge 7: worker D's 0x8006AD5C (84 B, a GOAL B row, first spelling) and 0x8006D1C4 (140 B).
Merge 8: worker C's GTE pair 0x80010810 / 0x8009C69C (60 B each, on the DEFAULT toolchain, via
the inline-asm hatch). Every row verified from a fresh --work dir against the exact md5, merged to
a candidate, gated whole-binary, promoted only on result=MATCH.
sf3_match gate c_regions=634 differing_bytes=0 result=MATCH
sha1 e173426c157384ebf1b6caf8c6fea18a85a14af9 (unchanged)
make check exit 0 extents-verify regions=634 disagreements=0 AGREE
registry audit 634 rows ordered, non-overlapping, 625 distinct sources, 0 missing
INTEGRITY CHECK THAT PASSED, ON A REAL HAZARD. Worker C edited the headers of the three
ALREADY-MERGED cc1bin sources after I merged them, changing their md5s (6afb89a7 / 51ab9083 /
c30c5bfa). The registry points at those paths, so a content change would have made it stale. I
re-ran the full gate on the current registry: MATCH. Comments only. This is exactly what the
md5-in-claim-row guard exists for, and here the whole-binary gate is what settled it.
C'S INLINE-ASM HATCH WAS JUSTIFIED TWICE, AND THE SECOND REASON IS A NEW FINDING.
The GTE pair is the d=0/15 identical pair, so one solve meant two bodies. The hatch was needed
because (1) ~20 spellings and ALL TEN vendored cc1 builds fold the dead `move t0,a1` into the
negation, and `((y ^ -1) + 1)` is the only spelling reaching the right LENGTH while lowering to
nor+addiu -- so length alone was never evidence; and (2) THE ORIGINAL'S NEGATION IS THE TRAPPING
`sub` (funct 0x22), not `subu` (0x23). objdump prints `neg` for the original and `negu` for the
candidate, so a mnemonic comparison cannot see it: a one-byte funct-field difference, cookbook 6's
class. With the copy fixed but the C negation kept, the row sits at differing_bytes=1.
AND C CLOSED THE ALT-CC1 QUESTION AGAINST ITS OWN INTEREST. On the 0x80050674 pair the residual is
differing_bytes=1 on the default cc1 and differing_bytes=22 on BOTH 2.8.1 and 2.91.66-psx, so it is
not a compiler-revision artifact. C then declined to spend the inline-asm hatch on it, on the
grounds that the residual is a mundane operand order inside an otherwise all-C body and the hatch
would be doing COSMETIC work. Ruling: endorsed. The hatch is for shapes plain C provably cannot
express; pinning three registers to win one operand order is not that. The row is classified with
its mechanism and an exhausted dimension instead.
OPEN, RECORDED WITH THE EXPERIMENTS RATHER THAN A GUESS: the workflow's checklist item
`excluded_already_registered == registry size` held exactly through merges 5, 6 and 7 and diverges
at merge 8 (634 registry rows, counter 632). Two hypotheses were tested and BOTH REFUTED: the two
new rows are not extent-graded non-exact (both are `exact`/`term=jr_ra`), and it is not "negatives
rows are counted under the negatives filter instead" (11 registry rows have negatives addresses,
but removing only the 2 newest from the registry reproduces the count exactly). Two failed
root-cause attempts, so per AGENTS.md rule 10 it is recorded with the evidence instead of a third
guess. No correctness risk, and that is measured: the whole-binary gate proves all 634 rows
byte-exact simultaneously, the registry audit is clean, and extents-verify agrees. It is a
diagnostic, not a gate. To be reconciled at the close, where the negatives-index reconciliation
happens anyway and is probably the same question.
Worker A's third claim, verified from a fresh --work dir against the exact md5 in the claim,
merged to a candidate, gated whole-binary, promoted only on result=MATCH. It is the largest body
any worker has taken this phase (572 B).
sf3_match gate c_regions=630 differing_bytes=0 result=MATCH
sha1 e173426c157384ebf1b6caf8c6fea18a85a14af9 (unchanged)
make check exit 0 make extents-verify regions=630 disagreements=0 AGREE
make worklist listed=989, excluded_already_registered=630
registry audit 630 rows, 621 distinct sources, 0 missing, 3 carry cc1bin
**ADJACENCY IS NOW 3-FOR-3 FOR WORKER A, ACROSS THREE BANDS.** 0x800297F4 (204 B, band 0) ->
0x800298C0 (392 B, band 1) -> 0x80029A48 (572 B, band 2): three CONSECUTIVE bodies, 1168 bytes,
four spellings total, with the density ranker not involved in any of the three picks. The chain
ends where no row starts at the next boundary. That is the strongest single piece of dispatch
evidence in the phase, and it is why the fresh-band files were re-cut to put adjacency above
density inside a band.
Worker A's lever, recorded because it is an operator RECOVERY rule rather than a spelling tip: the
original is `if ((x1 < 0 && x2 > 0) || (x1 > 0 && x2 < 0))`, and the truth-table-equivalent
if/else ladder is EXACTLY ONE INSTRUCTION SHORT. The emitted stream is `bgez x1` / `bgtz x2` /
`blez x1` / `bgez x2` -- each term's first test branches over its own second test -- and the ladder
has no `bgez x1` to emit. So the four BRANCH SENSES let you write the operator down without
guessing; cookbook 83's "branch direction distinguishes && from ||" turned into a recovery rule.
And `(x1 ^ x2) < 0` is the same predicate with the wrong codegen: the original compares.
**0x800C3490 IS EXCLUDED FROM THE WORKLIST.** Cookbook 114 (worker A, Phase 10) records it as a
FRAGMENT: it starts mid-expression, its body is a SHARED TAIL (`addiu sp,sp,48; jr ra`) that also
appears at 0x800C3470-0x800C348C, and it cannot be matched standalone. The extents table still
grades it `exact` with `term=jr_ra` because the boundary walk sees a well-formed terminal, so the
tool cannot catch it -- which is exactly why it needs a recorded exclusion rather than a tool rule.
Worker A recognised it for the SECOND time in Phase 12 and skipped it instead of spending reading
budget, which is the signal that the exclusion belongs in the Makefile: a row that has to be
re-identified by hand every phase is a row the dispatch should not be offering.
Added with its provenance in the Makefile comment, the same mechanism Phase 10 used for
0x8010080C's false extent start. excluded_named_exclusion 8 -> 9.
Ledger updated with merges 2-5, the cc1bin lever and its gate, the mechanism correction, the gp
pair rewrite and both of my failures in it, the dispatch measurement (369 of 993 rows abut SOME
region = noise; only 5 abut a PHASE-12 match = the signal), and the partition-membership fix.
The phase's FIRST merge was rejected: "expected three or four fields", while all four workers
were already staging files in the format my charter had given them.
charter said: range<TAB>source<TAB>md5<TAB>differing_bytes<TAB>result<TAB>options
with range written 0xSTART..0xEND
tool reads: start<TAB>end<TAB>source[<TAB>overrides]
Finding 179 says a rule every worker must follow belongs in a TRACKED tool, not in a file each
worker copies, because a copied artefact cannot be fixed for the people who already copied it.
Phase 11 earned that from a worker's free.sh. **A charter IS a file each worker copies**, so
writing a FORMAT into prose recreates the defect one level up — and this time the unfixable
copied artefact was the coordinator's.
AND THE TOOL HAD ALREADY LEARNED IT. validate_overrides exists because a Phase 11 worker put
md5= in the 4th column, and its error message says in terms: "Per-claim metadata such as a
source md5 belongs in report.tsv, not in the registry row." The convention was documented
INSIDE THE TOOL, I did not read it, and I wrote prose contradicting it — including renaming
the evidence file to evidence.tsv when report.tsv is the established name in the tool's own
error string and in every Phase 8/9/11 worker's staging directory.
Standing rule: before writing a staging format, an interface, or an exit-code contract into a
charter, READ THE TOOL THAT ENFORCES IT. "The tool is the contract" is not advice for workers
only. Workers compute addresses rather than eyeballing them; the coordinator must derive
formats rather than inventing them.
FIXED AS A COMMAND, NOT AS CORRECTED PROSE. New `sf3_merge check-claims --claims F [--regions R]`
validates the format, flags a duplicate start, a missing source file and an already-registered
row, so a worker answers "is my staging mergeable?" itself before reporting. 11 tests, one of
which asserts THE CHARTER'S OWN WRONG FORMAT IS REJECTED, so the message stays honest for the
next coordinator — who will also write prose.
Charter §10 rewritten to specify the tool's format by READING THE TOOL, to separate claims.tsv
(the merge input) from report.tsv (the evidence, where the md5 lives), and to name
check-claims as a required pre-report step; §5 gained rule 17.
What worked: fail-fast validation caught it in under a second at the merge, not as a confusing
failure at the gate. Phase 11's override-key guard paid off again. A staging format a tool can
CHECK is worth more than one that is documented well.
Cost: one rejected merge, four correction messages, ~10 minutes. Cheap because the tool refuses
to guess.
make test 301 tests, OK (from 290)
T0's defect was proven three ways (the patch rejects, the guard tests fail, the transform emits
an extra nop). This adds the end-to-end one, and its arithmetic closes exactly.
Gating the CURRENT 611-region registry with the SUPERSEDED transform:
rebuilt_bytes=1886260 original_bytes=1886208 -> 52 bytes LONG
rebuilt_sha1=24c4c2a9c99cc7f5daf88c0a30107bda2d16340f
original_sha1=e173426c157384ebf1b6caf8c6fea18a85a14af9
result=DIFF
52 bytes is 13 instructions, and 13 was derived INDEPENDENTLY from the original payload: the 15
maspsx=epilogue regions split 2 shapes A / 13 shapes B, classified by asking whether the word
before the `jr $31` is a nop (A) or a real instruction (B), with the frame release after the jump
in both cases. Each shape-B region gets one extra nop, so 4 x 13 = 52.
A count taken from the bytes and a count taken from the failing gate AGREE. That is what makes
this a measurement rather than an argument, and it is why the T0 record does not rest on a single
line of tool output.
ALSO RECORDED, because it is the trap this phase's own documentation warns about: my demonstration
command piped the gate through `tail` and then printed `$?`, so the `>>> gate exit=0` line in that
log is MEANINGLESS -- `$status` is a fish variable and the pipeline masked the gate's real status.
`result=DIFF` is the authoritative field and the byte arithmetic is the independent check. Workflow
section 6's rule is "use the gate's EXIT CODE as the gate"; I broke it while quoting it. Standing
note for every future gate call: capture the exit code directly, never through a pipeline.
Roster (fresh, spawned by the orchestrator; tab w1:t5, 2x2 grid):
A w1:pC 01a0d529 A1 lever-a.tsv 334 rows
B w1:pE 01a0d52a-2c40 A1 lever-b.tsv 334 rows
C w1:pD 01a0d52a-55d3 A2 negatives-c.tsv the 101 NAMED negatives
D w1:pF 01a0d52a-6198 A1+B lever-d.tsv 333 + negatives-d.tsv the 92 UNCLASSIFIED
Four agent_pane_not_found errors on first start, all cleared on retry after a few seconds --
the documented transient, not a bad id.
PARTITIONS ARE PROVEN, NOT ASSERTED (.run/p12/partition-proof.txt):
worklist rows 1001; a=334 b=334 d=333; sum 1001; distinct union 1001; overlaps 0;
union == worklist True; negatives 193 (c=101 d=92); negatives overlap worklist 0;
negatives c/d overlap 0.
The phase's structural premise was verified by set comparison: 0 of the 193 negatives rows
appear in the 1001-row worklist, because sf3_triage plan --negatives excludes them. The
negatives are an INDEX, not a queue, and worker C is the first worker in this project whose
partition is that index.
THE MEASURED RANKING, and it produced a real number. Band first, density second, with the
density statistic IMPORTED from the tracked tools/sf3_rank (which declares itself the reference
implementation and warns scores are not comparable across implementations -- reimplementing it
would silently break that guarantee):
band rows median density max size range
0 (<=244 B) 410 0.359 0.912 4-244 B
1 (245-400 B) 225 0.491 0.920 248-400 B
2 (401-800 B) 221 0.604 0.896 404-796 B
3 (>800 B) 145 0.720 0.940 804-11516 B
Median density rises MONOTONICALLY with band. That is worker D's warning ("density is
correlated with size, which biases the top of the list") measured on this corpus, and it is
exactly why a pure density ranking is wrong when the milestone counts BODIES rather than bytes:
one body at 80 B and one at 8000 B are worth the same. Band-first suppresses the bias; density
then orders within the band, where it is the measured cost signal.
MEASURED NEGATIVE, recorded so three workers do not each rediscover it: tools/sf3_family
--top 25 returns candidates=0 against the fresh band at ratio 1.000. The family lever is
EXHAUSTED for the worklist (Phase 11's 7 rows were all of it). It has NEVER been run against
the 193 negatives -- sf3_family reads the worklist, which excludes them -- so that is a named,
UNTRIED lever handed to workers C and D, who were both told to report who runs it.
Baseline revalidated from clean before dispatch: make clean/all exit 0; cmp exit 0; SHA-1
e173426c157384ebf1b6caf8c6fea18a85a14af9 unchanged; make test 290 OK (253 -> 281 -> 290);
extents-verify regions=611 disagreements=0 AGREE; gate c_regions=611 differing_bytes=0 MATCH.
CURRENT_PHASE.md rewritten for the phase, with the milestone warning stated plainly (+148 is
larger than any phase so far) and the cycle-1 requirement that at least 8 bodies must come from
the negatives pool -- so a low overturn rate is measured in cycle 1, not discovered at the close.
Approved by the developer 2026-09-24: milestone 750, stretch 800; both harness repairs
authorised; Goal B (the 92-unclassified negatives) in scope and bounded; 4 workers —
two on the fresh band, one on the 101 named negatives, one on the third fresh slice plus
the 92 unclassified as the Goal B worker; compaction-first.
THE ONE STRUCTURAL FACT THIS PLAN IS BUILT ON, measured at the open:
0 of the 193 near_match_negatives rows appear in the 1001-row worklist.
The negatives index is held OUT of the worklist (sf3_triage plan --negatives) and is not a
queue — it is an index, and a worker dispatched only from the worklist can never reach it.
So the negatives pool becomes a first-class partition with its own worker, and the phase's
structural change is that it stops being an appendix.
Two pools, measured: 1001 fresh rows (410 of them <=244 B) plus 193 attempted-but-unresolved
negatives, of which 101 carry a NAMED mechanism and are overturnable by cookbook 182's rule,
and 92 carry no class at all and cannot be attempted until someone re-reads them. That is
what Goal B is for.
The plan states plainly that +148 is LARGER THAN ANY PHASE SO FAR (Phase 11 closed +118) and
that it cannot be reached from the fresh worklist alone — it depends on the negatives-overturn
programme working at scale, which is a measured route but only a ONE-ROW demonstration so far
(worker F's 0x8002622C). Two safeguards are built in rather than discovered late: the cycle-1
checkpoint must include at least 8 bodies from the negatives pool, so a low overturn rate is
measured in cycle 1 and not at the close; and the leading-indicator rule stands unchanged —
report the projection and ask, never redefine or self-certify the milestone.
Also recorded: the fresh-band size distribution, the negatives class distribution, and the
baseline revalidation table including the failed precondition that T0 repaired.
The firewall line in all four close records said 720 tracked files. That figure was measured BEFORE the
two close records themselves were added, so the true post-close count is 722
(phase-ends/PhaseEnd_Phase11.md and docs/PHASE11_VERIFICATION.md). Corrected in the PhaseEnd, the digest
entry, the verification record and the ledger.
Same class of error as the two the close already records: a number measured at one moment, then quoted
in a document that itself changes the thing being measured. The firewall RESULT is unaffected --
0 tracked paths under any prohibited root either way.
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.
b29963e promoted worker F's staging tools, and in the same commit I copied F's
staging `diff.py` over `tools/sf3_diff` WITHOUT READING IT FIRST -- a direct
violation of AGENTS.md rule 3, 'Never overwrite blind.'
`tools/sf3_diff` was a 364-line Phase 9 tool: two subcommands (diff, resolve), a
PS-X-EXE header parser that reads the text address rather than hardcoding it, a
symbol-registry loader, and a lui/addiu + gp-relative address resolver. It had
17 tests of its own. Replacing it with a 97-line staging script dropped
`make check` from 253 tests to 237 and failed it with exit 2.
Restored from b29963e^ and verified byte-identical to it (cmp exit 0).
make check exit 0, 253 tests OK
extents-verify regions=611 disagreements=0 result=AGREE
gate rebuilt 1886208 B, differing_bytes=0, result=MATCH
sha1 e173426c157384ebf1b6caf8c6fea18a85a14af9
Documentation corrected, because the overwrite also left the record wrong:
* cookbook 185 documented the interface of F's STAGING script
(`sf3_diff 0xSTART 0xEND <workdir>`), which is NOT the interface of the
tracked tool and never was. Replaced with the real one, and the reason the
Phase 9 tool is worth more is now stated: its `notes` column resolves
lui/addiu pairs against the symbol registry and gp offsets against the gp
base, so a residual row can name WHICH GLOBAL an address is.
* cookbook 186 records the defect. The question to ask before promoting into
tools/ is not 'is the new one better?' but 'what does the old one already do
that the new one does not?'
* ORCHESTRATOR_WORKFLOW.md section 11 gains both as standing prohibitions, with
the diagnostic: a SHRINKING TEST COUNT means a tool that had tests no longer
satisfies them, and it fires before the failure itself is explained.
* phase-ends/logs/Phase11.md: 'seven defects' -> nine, recording the free-check
defect (cookbook 179) and this one.
Records worker output (104 claims total), the GTE class moving from BLOCKED to OPEN (worker D's
0x800F3E18 is the first GTE row matched in the project), the epilogue post-pass and its two
corrections, seven defects in coordinator-written rules, the central finding restated with worker
D's seven-finder breakdown, and the ranker's known blind spot with both failed proxies.
Records the cycle: five defects in coordinator-written rules (all found by workers following
them), the merge-flow defect the coordinator inflicted on itself, four new tools, the central
finding confirmed from both directions, the ranker's known blind spot with two failed proxies,
adjacency at 9-for-9, and the open items (GTE token, the post-pass, the solved 0x82082083).
Records the full cycle: the 244 B ceiling was a dispatch artefact, ASPSX does not fill delay
slots (so the post-pass shrank from a modelling project to five lines), and the central finding
that cost is tie-break density rather than size -- measured independently by two workers from
opposite directions and now shared tooling.
Also records the four defects in coordinator work that workers found, the coordination defect
the best heuristic created, the new classes and levers (58-106), and two orchestrator notes:
the milestone counts BODIES not bytes, and a diagnostic should be routed to the row shape it
matches rather than broadcast.
Records worker B's oracle result overturning the post-pass framing (ASPSX does not
fill delay slots; maspsx is faithful to it; the fills come from GNU as reorder mode and
the only gap is one mnemonic), the new `maspsx=moves` mode, worker C's correction of a
too-broad Phase 10 coordinator fix (now opt-in `maspsx=nopmarker`), the per-worker cost
tables that show SHAPE not band is the variable, and the new findings 63-66 plus the
named-locals family's fourth mechanism and the char[4] block-move recipe.
Committed at the orchestrator's 70% context cap; compaction follows, safe because the
ledger and CURRENT_PHASE are current.
494 bodies / 503 regions. Three bodies above the old 244 B ceiling from two workers
(248/248/264 B). Cookbook 59 extended with the unreferenced-array-local mechanism
(cc1 gives unreferenced scalars no home but does allocate for unreferenced arrays),
the amended three-direction rule, the per-band cost table, the sf3_merge fail-fast
fixes, and the rank-instability broadcast.
Records: the "244-byte ceiling" is a DISPATCH ARTEFACT not a measured wall (5 of 427
rows ever attempted, 1.2%; three in an excluded class; both non-excluded attempts
near-matched; 84% unclassified ordinary code), so worker C is re-assigned above the
ceiling onto a 619-row dispatch file with 258 known-callee rows.
The new division_check exclusion class (break and div always co-occur; 0 of 493
registered regions contains either; worklist 1193 -> 1118).
Worker B's localisation of the maspsx/GNU-as mutual exclusion (ASPSX does both the
move->addu conversion and the fill; maspsx the first only, as the second only, and they
cannot be combined) with a 42-row/14% census in its partition, and the developer's
authorization of a tracked post-pass modelled on ASPSX's behaviour via oracle
characterisation -- ASPSX itself is a diagnostic oracle only, never a build stage,
because it is proprietary and git-ignored and a build depending on it could not be
reproduced.
Baseline revalidated at the Phase 10 close state: tracked maspsx patch applied,
make check exit 0, extents regions=493 AGREEE, gate differing_bytes=0 MATCH, 237
tests OK, 484 bodies / 493 regions, worklist 1193 with excluded_already_registered=493.
Roster spawned by the orchestrator via herdr (tab w1:t4, 2x2 at ~115x31); all four
probed clean and all four confirmed context_info + compact_context, which is the
basis for the compaction-first policy. Worker D is assigned GOAL B (the 244-byte
ceiling) with a bounded four-step investigation and a running GOALB.md deliverable;
A, B and C are on Goal A with 12-claim cycle targets.
Partitions: 4-way rank-interleaved, 299/298/298/298, disjoint, union == worklist,
near-identical tier/size mixes. Lever files rank size-band-first (cookbook 41):
P2 (<=200B, no lever) at 359 rows is the main target across the four partitions.
Charters carry the Phase 10 process rules as hard requirements: md5 per claim,
verify the staged path, cleanup audit before reporting, read ranges from the worklist
row, one attempt on a named lever then classify, fold region options into the claim row.
Plan approved by the developer with all four recommended decisions: milestone 600
(stretch 700), Goal B (the bounded 244-byte-ceiling investigation) in scope, a
4-worker roster spawned by the orchestrator with discretion to scale or retire, and
a compaction-first context policy.
Roster spawned by the orchestrator via herdr in a verified 2x2 grid (tab w1:t4,
~115x31 per pane):
w1:p5 worker-a 01a0d36a-be1f
w1:p6 worker-b 01a0d36b-1dc6
w1:p7 worker-c 01a0d36b-f346
w1:p8 worker-d 01a0d36c-02f4
All four probed; worker A confirmed context_info works (1.4% at spawn) and that
compact_context is available, which is the mechanical basis for the compaction-first
policy.
phase-ends/CURRENT_PHASE.md rewritten for Phase 11 with the planning finding (the
matched corpus median is 52 B, p90 108 B, max 244 B, and nothing larger has ever
matched), the roster table with herdr pane and intercom ids, the context policy, and
the carried machinery.
Prepared immediately after Phase 10 closure (484 bodies / 493 regions).
THE PLANNING FINDING THAT DEFINES THE PHASE: the matched corpus is n=493 with a
median of 52 bytes, p90 108 bytes and MAX 244 bytes -- NOT ONE BODY LARGER THAN 244
BYTES HAS EVER MATCHED. Against a remaining worklist of 1193 rows:
<=120 B 115 rows proven-matchable band
121-200 B 284 rows proven-matchable band
201-400 B 367 rows partially proven (up to 244 B)
401-800 B 245 rows UNPROVEN -- nothing has ever matched here
>800 B 182 rows UNPROVEN
So the ~400-450 rows at <=244 B are the finite proven band, and +116 bodies means
matching a quarter to a third of it. The 244-byte ceiling is therefore the real
subject, and the plan states TWO goals: A consume the proven band (the milestone
path), B break the 244-byte ceiling (a bounded investigation with a measured
deliverable, where a result that adds zero bodies is still a met goal).
Structural change: the orchestrator spawns and retires its own workers via herdr
(4 agent panes per tab, 2x2 verified at 115x31 each); the developer spawns only the
orchestrator. Context management changes too: pi-context-tools is installed
globally, so every session has context_info and compact_context -- measurement is
exact and self-service, and COMPACTION replaces rotation as the first response to a
full context, with rotation second. That is only safe because the state lives in
files, so keeping the ledger current becomes a hard requirement.
Four decisions requested: the milestone number; whether Goal B is in scope this
phase; the 4-worker default with orchestrator discretion to add a fifth; and
confirmation of the compaction-first policy.
MILESTONE MET AND EXCEEDED: 484 distinct matched bodies / 493 registered regions
(target 475, from the 400 baseline) — +84 bodies. Developer confirmation of the
milestone was requested and given before any close record was written.
Closing checklist all green from clean:
make clean && make all exit 0
cmp exit 0
SHA-1 both files e173426c157384ebf1b6caf8c6fea18a85a14af9
make test 237 tests, OK
make extents-verify regions=493 disagreements=0 AGREE
make gate c_regions=493 differing_bytes=0 MATCH
registry audit 493 rows, 0 overlaps, 0 unsorted, 0 bad extents,
0 missing sources, 484 distinct sources
worklist listed=1193, excluded_already_registered=493
negatives index 194 rows, address-ordered, 0 registered
git status --short src/ empty (0 untracked files)
firewall 0 prohibited-root paths (591 tracked files)
New records:
phase-ends/PhaseEnd_Phase10.md the phase record
docs/PHASE10_VERIFICATION.md the verification record
docs/MATCHING_COOKBOOK.md findings 41-57 (57 total)
phase-ends/CURRENT_PHASE.md CLOSED, with the checklist itemised
phase-ends/DIGEST.md the Phase 10 digest entry
The headline finding is methodological (finding 41, THE SIZE-BAND LAW): the matched
corpus median is 48 bytes with 454/459 at <=200 B while the remaining levered rows
had a median of 456 B, and two independent measurements — one controlled — put the
small band at 1-2 attempts per row against 1-in-12 for 200-800 B.
The phase's character: five of the coordinator's own generalisations were bounded by
workers (rare-epilogue class, register-field diagnostic, polarity lever, goto
trigger, load-delay consumer form). The rules that survived are the ones that were
bounded.
Five incidents recorded rather than smoothed over; the candidate gate rejected three
batches and the tracked registry was never corrupted. Scope held: the blocked classes
stay excluded, no scheduler-changing flag was granted, and inline asm was extended
only to shapes C provably cannot express.
STOPPING HERE. Phase 11 does not begin in this session.
Records the 0x800A9C24 collision (coordinator double-assignment: the row was
redistributed to B2 and then chartered to C2), B2's diagnosis that "verify the file
at the path you claim" is necessary but not sufficient because the gap is between
verify and merge, the adopted md5-in-claim-row guard, and worker A's 4 first-attempt
bodies including the second byte-exact stack-switch row that isolates the variable
to an argument move at the call site.
Records: worker A's 8 first-attempt bodies and two general levers (two-arm polarity
byte-required; named boolean local forces the branchless compare); worker B2's
limitation of the coordinator's polarity broadcast (both ordinary spellings give the
mirrored branch, so the guard must be a goto); the staging slip the candidate gate
caught (verified finding, wrong file staged) and the standing rule it produces
(verify the file you stage, not a scratch variant); and the dead-store-elimination
class from 0x80016F80.
Third coordinator over-generalisation a worker has caught this phase.
Christopher Williams