c1dbf9d64e
+6 bodies (worker A claims 23-26, worker B2 claims 8-9). Candidate gate MATCH
before every promotion.
FULL CLEAN AUDIT GREEN at the milestone:
make clean && make all exit 0
cmp exit 0
SHA-1 both files e173426c157384ebf1b6caf8c6fea18a85a14af9
registry 489 rows, 0 overlap, 0 unsorted, 0 bad extents,
0 missing sources, 480 distinct sources
firewall 0 tracked paths under any prohibited root (583 files)
suite 237 tests OK
The phase goal (475 from the 400 baseline) is met with 5 bodies to spare.
Per the plan, phase close requires the developer's explicit confirmation of the
milestone; this commit records the state, not the close.
SIZE-BAND FINDING now confirmed a third time, within-worker: worker B2's nine
matches cost 1, 4, 6, 4, 1, 2, 2, 1, 1 attempts -- the three <=120 B frameless leaves
all cost exactly ONE attempt, while the two >200 B P1 rows it opened with cost 6 and
4 attempts and produced ZERO matches.
Two more levers recorded from the closing rows:
- RECORD IDENTITY FROM WIDTHS (0x80041610): the two arms read three shorts at
+264/+266/+268 versus three ints at +20/+24/+28 through one extra indirection,
so they are TWO record types; declaring one shared type would have been wrong.
- a1[1] = -a1[1] RELOADS FROM MEMORY and its source order matters: the negation
reloads 4(a1) because the intervening store to 8(a1) may alias it.
- A 2-D ARRAY'S ROW STRIDE IS BYTE-LOAD-BEARING (0x800AC7A0): D[a3][a4] emits
sll a3,4 + sll a4,2 + add (correct length); D[a3*4 + a4] folds the outer *4 into
a second sll and comes out 4 bytes SHORT. When a scaled index is one sll short,
the source is a 2-D array, not a flattened index -- a LENGTH-class lever.