Uncommitted src/ changes found at gate entry. These are banked functions from a lane that gates with commit=False, not residue — preserved, not reverted. Top-level src/*.c (main TUs) are excluded by construction (S59).
commit:2863 ("ox wave dk overlays — 2 banked") committed config/overlays.mk as a ZERO-LINE
file, deleting the registry that defines all 141 overlay binaries: EXE paths, VRAM bases,
ASM_DIR/SRC_DIR roots, symbol files, and every JTBL_PADS spec.
BLAST RADIUS while it was empty:
* main could not build AT ALL. Its object glob prunes sibling binaries via
$($(b)_ASM_DIR); with no binaries registered, every overlay's asm/<ov>/nonmatchings/*.s
fell into MAIN's OBJS and was assembled standalone, where glabel/endlabel/nonmatching
are undefined ("unrecognized opcode `glabel func_801831C8'").
* the main lane found its committed baseline RED and REFUSED to draft or gate (correctly,
R43) — 1,288 open main stubs idle behind it.
* overlay gates collapsed: GATE do banked 0 of 236 gated, GATE dk 2 of 445 drafts.
* every overlay left BINARIES, so check-all's fleet scope collapsed with it.
HOW IT HAPPENED — two failures, neither sufficient alone:
1. A NON-ATOMIC WRITE. The version at commit:2863^ was ALREADY damaged: it ends with a stray
partial line ("uto.txt") after the proper final line — one writer's tail landing after
another's. This file is rewritten in place with no tmp+rename while lanes edit it
concurrently (jtbl carves, o0 subsplits, pad specs).
2. A BLANKET COMMITTER. "tree dirty at gate entry — committing it rather than reverting"
swept the truncated file into a commit. R42 says commit rather than revert and that
stands for src/ — but a tool cannot tell a truncated config from an intended one, and
this is the second time that reasoning has destroyed a registry (P28's yaml.safe_dump,
H5: never silently drop content on a rewrite).
Restored from commit:2863^ with the stray fragment removed; make parses it again. Atomic
writes and a sanity guard on the committer come next.
Uncommitted src/ changes found at gate entry. These are banked functions from a lane that gates with commit=False, not residue — preserved, not reverted. Top-level src/*.c (main TUs) are excluded by construction (S59).
ov_SC02_005 and ov_SC07_006 both failed to assemble with "jtbl_rodata_pads: consumed 1
rodata .align(s) but 2 pad spec(s) given", both from wave dd (commit:2847).
CAUSE, not guessed: dd banked a function CARRYING A SWITCH into each object
(func_8018A150 / func_80183524). A switch changes how many .rdata jump tables the object
emits, and JTBL_PADS is a static per-object spec written by jtbl_carve at CARVE time — it
describes the table population as it was, and nothing re-derives it when banking changes it.
Verified rather than assumed, the same experiment both times: set the spec to the count now
emitted and rebuild. Both are BYTE-IDENTICAL, so the banks are correct and the spec was
stale — the opposite of ov_SC04_018 this morning, where the identical symptom came from a
LOST bank and the spec was right. The symptom does not tell you which; the byte gate does.
ov_SC02_005 9c233988b061... GREEN with 0
ov_SC07_006 7ca772be5656... GREEN with 0
Both binaries were RED from 11:00 (dd's commit) until now — every draft gated against them
in that window was rejected for a reason that had nothing to do with the draft.
The 16-fn -O0 cluster (0x8013B568..0x8013C964), remapped from the ov_SC01_077 exemplars
(16/16 matched there) into all three freshly carved -O0 objects:
ov_SC02_037 16/16 ov_MAIN_012 16/16 ov_SC03_107 16/16
All three BYTE-IDENTICAL against config/check.<ov>.sha after the batch, and corpus.stubs
reports zero of the 16 addresses still open in any of them. 48 functions for zero model
tokens — the entire cost was a partitioning fix.
R14 NOTE ON THE INSTRUMENT: sweep_parallel summarised "banked=44 notbanked=4" while the
byte gate and corpus.stubs both say 48/48. The bytes win; its counter undercounts (drafts
banked in a later chunk after a bisect appear not to be credited). Worth a look before that
number is ever quoted as a rate.
Three drafts per overlay came with a gather_externs warning — a sibling callee with no
file-scope decl in ov077 (func_8013B83C, func_8013BD74). They banked anyway: C89 implicit
declaration covers a same-TU sibling whose stub sits in the same object. The gate decided,
not the warning.
With U2's 4, this closes the -O0 U2/U3 thread: 52 functions / ~6,730 instructions banked
tonight from the stranded -O0 population without drafting a line.
ov_SC02_037, ov_MAIN_012 and ov_SC03_107 never received the P30 _o0c carve, so the 16-fn
-O0 cluster at 0x8013B568..0x8013C98C sat inside their -O2 `jr_801380E0` object. Opt level
is a property of the FILE (§116), so every remap into it was correctly rejected by the gate
— 16 functions x 3 overlays unreachable for a partitioning reason, not a matching one.
o0_subsplit at [0x8013B568, 0x8013C98C) per overlay. All three BYTE-IDENTICAL after
`make extract && make build`, which is the whole claim of a carve — it moves nothing:
ov_SC02_037 b0c5394ae23cd5f0cbb32687f61bca669151bf5f
ov_MAIN_012 d6b3e8b971cdd6c53aea8c4f265afb82b363283c
ov_SC03_107 87d02b578a27a947f1da381255a1faa3f05cedfd
A LOCKING RULE THIS EARNED. ov_MAIN_012's dry run planned 5 regions around an "-O2 island"
at func_8013C0F8 [def]; the real run planned 3, and the function is an INCLUDE_ASM stub in
both HEAD and the carved tree — nothing was lost. The dry run had read a MID-GATE
SUBSTITUTION: a lane had a candidate body in that TU, the gate rejected it, and the stub
came back. o0_subsplit derives its plan from which functions are matched, so a plan derived
outside the per-binary lock can be a plan about a tree state that never existed. Derive the
plan INSIDE `.run/auto/gate.<bin>.lock`, carve under the same lock — which is what the real
runs did, and why they saw the truth.
Next: populate the 3x16 from the ov_SC01_077 exemplars (16/16 matched there), then gate.
The binary has been RED since wave bp (commit:2687), where the gate-time jtbl carve
wrote 'JTBL_PADS := 0,0 # tables=+0x0,+0x20' for ov_SC07_002_jr_8017C8D0.o. The
object emits ONE rodata .align, so jtbl_rodata_pads refused every build:
consumed 1 rodata .align(s) but 2 pad spec(s) given — table-count drift vs the carve
make: *** [build/src/ov_SC07_002/ov_SC07_002_jr_8017C8D0.o] Error 1
The carve itself is legitimate — jr_isolate_all's jr_inventory resolves every
committed .rodata carve in this binary to exactly one banked owner (R32/R33), so this
was never an orphaned carve. Only the pad SPEC was wrong, and §8e's own rule is that a
single-table span gets no line at all (its pipeline stays byte-identical to pre-§8e).
Removing the line restores it:
sha1 fad71342019704d1dd6ec25f2f3934c97e322624 == config/check.ov_SC07_002.sha
Found by the A-prop agent's scoped R22 (141 binaries affected, 96 SHA-checked), which
also fixed ov_SC07_010 — a binary whose committed tree state had provably never been
built. Two RED binaries had been sitting in the fleet while every lane gated against
them; neither was noticed because no lane checks a binary it is not currently touching.
The whole split is ONE inserted config line plus jr_isolate_all --only, exactly as
the adversarial review concluded (no _pre piece, no ld_interleave change, the
- [0x0, .rodata, md_SC03_076] island piece untouched):
- [0x268, .rodata, md_SC03_076_jr_801F218C]
- [0x2d24, c, md_SC03_076_jr_801F218C]
FRESH negative control, measured now rather than inherited (the study's +8/0x144
baseline was measured on func_801F0F28 and misattributed):
baseline whole-binary sha1 9a165e368009a79bcc2ebb06bcb13e6da20d460e (green)
md_SC03_076.o .rodata sh_size 0x27c (the whole island)
after whole-binary sha1 9a165e368009a79bcc2ebb06bcb13e6da20d460e (green)
md_SC03_076.o .rodata sh_size 0x268
md_SC03_076_jr_801F218C.o .rodata sh_size 0x14 (the 5-entry table)
So the SHA is unchanged AND the object-level discriminator proves the split really
happened — the pair rules out the no-op reading of a green build.
Island census for the record (file offsets): D_801EF468 0x000-0x0D8, D_801EF540
0x0D8-0x144, then the migrated tables of func_801EFBB4 0x144, func_801F0210 0x1B4,
func_801F0734 0x1EC, func_801F0A9C 0x214, func_801F0F28 0x23C, func_801F218C 0x268
-> 0x27C = the island end. The island is a STACK: only the end-adjacent table carves
cheaply, and each isolation exposes the next one, so the module peels from the end.
Drew T