The phase's first two bodies, and both are recorded negatives rather than worklist rows.
Worker C found them with the NAMED UNTRIED LEVER I handed it: tools/sf3_family driven over the
101 negative rows against the 611 registered regions. I measured candidates=0 for the fresh
band and told C that said nothing about its own pool. It didn't:
score >= 1.000 : 3 rows (NOT 0)
score >= 0.99 : 4 rows
score >= 0.95 : 15 rows
-> 0x800518BC (88 B) -> 0x80051864 MATCHED (this merge)
-> 0x800B34A4 (88 B) -> 0x800B34FC MATCHED (this merge)
-> 0x8010804C (16 B) -> 0x80085B80 blocked class (gp-thunk), correctly not attempted
Transfer rate 2/2 on the unblocked score-1.000 rows, against finding 166's 7/7.
I re-verified BOTH claims from fresh --work directories before merging (differing_bytes=0,
result=MATCH, exit 0 each), merged to a candidate, gated the whole binary, and promoted only on
result=MATCH.
./tools/sf3_merge apply ... exit 0, added_regions=2
./tools/sf3_match gate --expect-sha1 e173... exit 0, c_regions=613
differing_bytes=0, result=MATCH
sha1 e173426c157384ebf1b6caf8c6fea18a85a14af9
make check exit 0
make extents-verify regions=613 disagreements=0 result=AGREE
registry audit 613 rows, ordered, non-overlapping,
604 distinct sources, 0 missing files
Worklist regenerated. It still lists 1001 rows, and the reason is worth recording because it
looks like nothing happened:
excluded_already_registered 611 -> 613 (+2)
excluded_recorded_negative 169 -> 167 (-2)
The two rows were NEVER in the worklist -- they were excluded as recorded negatives. Registering
them MOVES each row from the negatives-exclusion bucket to the registered bucket, so `listed`
is unchanged while both counts shift by exactly 2. excluded_already_registered == the registry
size, as required. No partition refilter is needed: both rows were in C's negatives partition,
not in any fresh partition.
WORKER C'S FINDING, which is worth more than the two bodies and is a Goal-B-grade result: BOTH
rows' recorded class strings were WRONG ABOUT THEIR OWN MECHANISM.
0x800518BC was classed "return-merge/sltiu", with a note that three spellings all came out
80 B and sltiu fixed the compare byte but not the 8-byte layout. RAW WORDS: 21 of 22 words
are IDENTICAL to matched 0x80051864. The sole difference is the forward `j` to the shared
return, and its target differs only because `j` encodes an ABSOLUTE address and the two
bases are 0x58 apart. The body is a literal twin; no re-spelling was ever needed.
0x800B34A4 was classed "alloc-tiebreak" (bit-index/base register pair a0/a1 vs cc1 a0/v1).
RAW WORDS: 20 of 22 identical to matched 0x800B34FC; both differences are the OFFSET
CONSTANT (`li a0,3` vs `li a0,20`). The register pair the note asked for was already there.
The lever is the constant, not the allocator.
Both rows abut their matched twin, so the negatives index contains whole RUNS of repeated
bodies -- and C's operational conclusion is that the cheapest finder is a raw-word HAMMING scan
against the 611 registered regions, which the histogram tool only half-finds. C is running that
scan across all 101 rows now. That map, not the bodies, is likely the largest thing this phase
produces.
Note the discipline this vindicates: an unclassified negative is not overturnable (finding 182),
but these two WERE classified -- wrongly, in the same dimension, by earlier sessions that then
wrote off the row. Cookbook 182's rule needs its other half: a recorded mechanism is a HYPOTHESIS,
and a WRONG named mechanism is as unattemptable as no mechanism at all until someone reads the
raw words.
Christopher Williams
b3e3ec3ea7