Structure-first crack (agent, 371/371 byte-exact, independently re-verified by match_one before
gating). Levers were type- and placement-driven rather than pins: u8 locals produce the andi masks
(a QImode result sends the arithmetic arms through force_to_mode while the comparison keeps its
zero_extend); cross-BB placement defeats combine (LOG_LINKS are per-BB); a DUPLICATED store keeps
the following re-read in a fresh EBB so it stays a real lbu; and a deliberately-unused u8 dum[8]
because the target's .frame says vars=8 with no spill in the body — the original had a dead local.
Only non-call-spanning pins used, so the body is x137-safe (§44).
Family: 371 ins x 138 = 51,198 templatable ins — the single largest item on the board.
func_8016706C func_80131A34 func_80161A90 func_801549F8 func_8014C4AC — each match_one-verified
by me before gating (R14), then whole-binary byte-gated. func_8014C4AC is the standout: the agent
resolved its 'conflicting types' with the §37/§124 ASM-LABEL ALIAS (s32 aF8014C4AC(...) __asm__
("func_8014C4AC")) instead of a header edit — exactly the alternative to the fleet-sed that failed
earlier today. 9 remain blocked on declaration conflicts.
The stored backlog draft was 2 mismatches from perfect (88/88, DELAY-SLOT) for one reason its own
notes had already recorded: the definition must return VOID, not the canonical s32. An s32 return
keeps $v0 live-out at the epilogue, so dbr refuses to steal the loop-top addiu $v0,$zero,0x1858
into the loop-back bne delay slot -> nop + a branch target one insn early. void -> steal -> MATCH.
This is the one place §3a-1's 'void->s32 is byte-neutral' claim is FALSE (S27 finding, now banked).
Applied with the draft's own //@EDIT directive: 5 in-TU 'extern s32 func_8016EC0C' decls flipped
to void (every call site already casts the fn pointer, so no caller changes). ov_SC01_077
d19c9580 BYTE-IDENTICAL. Family: 88 ins × 138 = 12,144 templatable ins; sweep next.
S1's head family (0x8014032C, 183 ins ×137 = 25,071 templatable ins) gate-failed on its probe
sibling. Diagnosis (the §132 ladder, one build): the object emits FOUR tables — BOTH functions in
it are multi-switch (8+5 entries each) — while the carve derived THREE starts.
The missing start belongs to the ALREADY-MATCHED owner func_8013FFD8, and neither oracle can see
it: its stub .s is pruned by extract, and its second table abuts its first with NO pad (8 entries
= 32 B = 0 mod 8, so `.align 3` emits nothing) — precisely the honest limit §132's payload
zero-word recovery documents. Note the true pads [0,0,4,0] are exactly what natural alignment
produces; the build breaks only because a SHORT spec gets written.
Fix: thread the documented `--span-tables` escape through the sweep as `--span-rel` — offsets
relative to the FIRST NEW table, which func_jtbls reads from the sibling's own .s. Byte-verified
family-invariant before use (identical relative offsets on 3 sampled siblings; same code, same
entry counts, only the base moves). Empty by default => every other family untouched.
Also clears my own §132a guard of suspicion (R14): the --like transfer was inert here regardless
(exemplar subseg `ov_SC01_077` vs sibling `_jr_8013FFD8` — roles never matched).
The one sibling both sweeps failed on. `--like <exemplar>` transfers the exemplar span's table
STRUCTURE, and jtbl_carve matches donor to recipient by the subseg's ROLE NAME. ov_SC07_010's
-O0 region is named `_o0` — the same role as ov_SC01_077's, and the ONLY other overlay so named
(the other 136 are `_o0c`, whose role never matched, which is the only reason the sweep worked).
The exemplar had just banked 2 more owners than the sibling has, so the transfer unioned its
rebased 4 offsets with the sibling's real 2 + the new table: SIX starts for THREE emitted tables
-> jtbl_rodata_pads refused ("consumed 3 rodata .align(s) but 6 pad spec(s)").
Guard (tools/jtbl_family_bank.py like_arg): suppress --like when the sibling already carries a
committed `tables=` for the target subseg — its own record is authoritative, and jtbl_carve's new
payload zero-word recovery covers the incomplete-record case that --like used to paper over.
Derived via jtbl_carve.func_subseg, the same derivation the carve itself uses (R33); never blocks
a bank (any failure falls back to the old behaviour). Inert for all 136 siblings already banked;
fixes exactly the broken one. Both fns now bank on ov_SC07_010 => 137/137 siblings each.
The 1-sibling probe (R37) gate-failed: ov_SC01_000's object emitted only func_8013C0F8 +
func_8013C414 tables, because BD74's body never compiled — `E_13BD74' undeclared. The draft
declared E_13BD74/P_13BD74 at FILE scope and extract_unit/remap_hseq carry only the BODY, so
the types stay behind in the exemplar. Same §94 class that held func_8013C08C at 0/137 earlier
this phase; fix is §100 (block-scope types travel with the body, byte-neutral — a type emits no
code). Exemplar re-gated: ov_SC01_077 d19c9580 BYTE-IDENTICAL. B83C's draft was already
draft-local. Named in one command by the §132 ladder.
S28 ledgered `JR-PAIR-IN-ONE-O0-OBJECT` (two jr fns matched in one -O0 object => a clean
build that cannot link: `undefined reference to $L105` + `func_8013C938`) with §81 step 1
(isolate one into its own code subseg) as the untested escape. BOTH the class and the escape
are REFUTED — no isolation, no compiler wall, both fns banked from a genuinely clean fleet.
The 4th consecutive "structural wall" to resolve to our own tooling (§124/§125/§126/§131).
- DEFECT 1 (tools/jtbl_carve.py): ov_SC01_077_o0's carve at 0xb01a4 predates the §8e
`tables=` persistence and is a MERGED DOUBLE (func_8013C0F8 $L75 + func_8013C414 $L105);
the 2nd owner is MATCHED so extract pruned the stub .s naming its table. The single-table-
predecessor inference derived 3 starts where the object emits 4 tables -> JTBL_PADS 0,4,4
-> jtbl_rodata_pads refused mid-stream, correctly. FIX: R32 coverage assertion + payload
recovery at the single choke point (spec_from_starts) — every zero word inside a span is an
original `.align 3` pad (the tool's own axiom), so the word after it STARTS a table;
recovered starts are logged. No-op where structure is known (the 134 sibling _o0c spans
carry tables=+0x0,+0x70). Honest limit: tight (0-pad) boundaries stay unrecoverable but
fail LOUD via the filter's count guard — never silent.
- DEFECT 2 (Makefile): no .DELETE_ON_ERROR, so `as` (a pipeline consumer) left a TRUNCATED .o
on disk — 12 of 16 T func_, undefined $L57/$L59/$L63/$L75/$L76 — newer than its .c, and the
NEXT build linked the corpse. That IS the S28 link error, one build downstream of a loud,
correct compile error. Negative-control-proven on a scratch invocation.
- BANKED: func_8013B83C (272 ins) + func_8013BD74 (198 ins) in ov_SC01_077 (d19c9580).
Byte proof: 4 tables 0x801D8254/828C/82FC/836C (13/27/27/27 entries, each zero-pad
separated); span 0xb00fc..0xb0280 = 388 B = 52+4+108+4+108+4+108 exactly; spec 0,4,4,4.
- R22 clean-fleet (make clean + extract-all + check-all): 140 passed, 0 failed of 140.
The incremental result was NOT trusted (§130). Fleet 93.25% fn-count / 89.2% instr /
80.5% distinct; dedup 1905/0; 0 NON_MATCHING (G4).
- cookbook §132 + index (356 sections): the mechanism, the fingerprint (an undefined $L<n> in
a LINK error is a truncated object, never codegen), the 30-second standalone-TU ladder that
named the 4th table owner before any build, and the transferable rule — a fail-loud guard is
only as trustworthy as the artifact hygiene around it.
The last surviving "compiler wall" of the session turned out to be an off-by-one-word
carve. Chain, all byte-grounded:
SYMPTOM jtbl_carve diverges on ov_SC06_018 after a BYTE-NEUTRAL jr_isolate_all.
SHAPE image -3 bytes; 853 differing bytes in 699 scattered runs; **812 at byte 0 of a
word** = the low byte of a 16-bit immediate, every sampled one changing by
exactly -4. Not a shift, not a pad: hundreds of `%lo` operands 4 bytes low.
CAUSE func_80191C50's own `sltiu $v0,$v1,0xC` names 12 entries; the emitted .rodata
holds 12 words; the carve reserved 13. The 13th word (0x3038200A) is ordinary
NON-ZERO data that spimdisasm ran into the dlabel span (the next dlabel sits
past it). Reserve 13 / supply 12 => the .rodata piece UNDER-FILLS by one word
=> every later symbol slides down 4 bytes.
WHY MISSED The trailing-trim's axiom is "0x00000000 cannot be a jump target", so it only
trims ZERO words. This surplus is non-zero, so nothing trimmed. The tool already
treats `sltiu` as ground truth - it EXTENDS a table spimdisasm cut in half, and
it WARNS when a span is too short - but had no clamp for a span too LONG.
FIX: an over-span clamp with the SAME authorization as the existing extension logic -
only when the `sltiu` bound is UNAMBIGUOUS (one bound; a multi-switch fn cannot say which
table owns which), and only when the surplus words are NOT plausible code addresses. If any
surplus word looks like a real entry it REFUSES LOUDLY rather than silently dropping one.
jtbl_carve: jtbl_801D3BA4: clamped 1 trailing NON-ZERO word(s) - func_80191C50's own
`sltiu 12` names 12 entries and the surplus is not code
Then: carve BYTE-IDENTICAL, draft spliced, **func_80191C50 (710 ins) BANKED**.
R22 CLEAN-FLEET: extract-all 139/139 (+main); check-all 140 passed, 0 failed of 140.
Retires the JTBL-CARVE-BREAKS-BYTES ledger class: the one instrument failure that survived
this morning's retraction round was REAL, and is now a named bug with a fix - not a wall.
The last 133 members of the -O0 cluster's sweep residue, banked. R22 CLEAN-FLEET:
extract-all 139/139 (+main); check-all 140 passed, 0 failed of 140.
METHOD NOTE, because it is the difference from the two failures before it: my hypothesis
(the 5-vs-133 split tracks which -O0 file the member lives in) was cleanly REFUTED —
ov_SC07_006/007/011 were sub-split by me TODAY into _o0c and banked anyway. Instead of
forming a fourth theory I staged ONE member and compiled it. Two blockers, each only
visible after the previous was cleared:
1. `conflicting types for S_8013BC7C` — the templated body carried a typedef TEXTUALLY
IDENTICAL to one in engine_types.h, and gcc-2.7.2 (C89) rejects even an identical
typedef redefinition. The exemplar TU includes only common.h; the new _o0c files pull
engine_types.h via engine_core.h. (harvest_verify already strips provided typedefs at
gate time via cdecl.strip_provided_typedefs, so this half was self-solving.)
2. `previous declaration of func_8013BC7C` — the SIBLING's own TU declares the templated
function divergently: SS57's self-decl class, lever = --normalize-self-decls.
One flag. 133 staged / 133 BANKED / 0 failed.
Running total for today's follow-ups: func_8013C08C 137/137 + this 133 = 270 members banked,
against one genuine integration wall (JR-PAIR-IN-ONE-O0-OBJECT). Every blocker in all three
was a DECLARATION-ENVIRONMENT problem, and none was visible without compiling and reading
the output — three wrong guesses where I theorised, zero where I read first.
SS94 said treat a family 0/N as a TYPE-CARRY failure until proven otherwise. It was one.
MECHANISM (read from the source, not inferred - SS125 rule 1): E_13C08C was a MULTI-LINE
typedef at FILE scope. extract_unit's preceding-decl backscan walks back over
extern/comment/blank/typedef lines, but a multi-line typedef presents its CLOSING line
(`} E_13C08C;`) first, which matches none of those prefixes. The scan stopped there, so every
templated sibling received the body WITHOUT its type and all 137 failed to compile.
FIX = SS100 (prefer the DRAFT-LOCAL form): a type only one function uses belongs in its BODY,
where it is part of the unit by construction. Byte-neutral (a type declaration emits no code),
gated on ov_SC01_077 before and after.
family_sweep --hseq --only 0x8013c08c --band all -j8 -> 137 BANKED / 0 failed
R22 CLEAN-FLEET: extract-all 139/139 (+main); check-all 140 passed, 0 failed of 140
WHY THE DIAGNOSIS WAS REDONE FROM SCRATCH (R35): the first pass concluded "the type is not
defined anywhere" - because grep was SILENTLY SKIPPING the file (SS128, the raw-NUL defect fixed
at commit:1284). That conclusion pointed the same direction by luck, but it came from a broken
instrument and none of it was trustworthy. With grep working, the typedef was visible at
ov_SC01_077_o0.c:137 immediately.
A FRESH TRAP FOUND WHILE FIXING IT: my explanatory comment contained a literal `}`, and
extract_unit's forward brace-scan does NOT strip comments - it decremented depth and TRUNCATED
the extracted unit. Caught only because I verified the unit was complete instead of assuming
the edit worked. Comment reworded to contain no brace characters, with an in-place note saying
why. That hazard is now also documented in the body itself for the next reader.
FOUND BY ACCIDENT, WHICH IS THE POINT. `grep -rn func_8013C08C src/` returned NOTHING for
a function that is defined right there. The file held a RAW NUL byte inside a character
literal — the source read `== '<NUL>'` where it should read `== '\0'`. It COMPILES (the
fleet was byte-identical), so no byte-gate ever objected. But file(1) classifies such a
file as `data`, and **grep treats a file containing NUL as BINARY and reports nothing,
silently**. The whole file therefore vanished from every grep-based audit and every hand
search. I burned real time chasing a phantom missing function before `file` gave it away.
SCOPE, measured: 137 files — every `_o0c`/`_o0e` region created in THIS session. The
templated bodies carried the NUL fleet-wide, so I propagated the defect today. All fixed
(`'<NUL>'` -> `'\0'`); R22 CLEAN-FLEET 140 passed, 0 failed of 140 => byte-neutral.
NEW ORACLE: tools/audit_text_sources.py + `make audit-text-sources`, wired into
tools-health, coverage-asserting over all 3,887 tracked .c/.h files (R32). This is the
SAME silent-skip family as SS124 (a scanner that cannot see something reports it is not
there) and SS126a (a bare except swallowing a coverage assertion) — but one layer LOWER,
in the tool everyone reaches for first. The byte-gate is structurally blind to it (R34):
the bytes are correct, so it has nothing to say. It needs its own oracle.
MY OWN ERROR, RECORDED: proving the new guard fires, I injected a NUL into the REAL tracked
file and restored it through nested shell escaping. The restore left `'\\0'` — an escaped
backslash, i.e. a multi-character constant, NOT a NUL — a genuine semantic change. R22 caught
it (139/140) in one cycle, before any commit; repaired to `'\0'` (10465 -> 10466 bytes) and
re-verified 140/140. The lesson is not "be careful": a negative control must corrupt a SCRATCH
COPY under .run/, never the tracked file it is testing. Testing a guard must not risk
introducing the defect the guard exists to catch.
First Ultracode wave against the population the -O0 routing made draftable. 30 agents
(15 drafters + 15 adversarial verifiers), 1.33M tokens, 8.8 min. Every drafter self-checked
with match_one --o0 AND rtu_match --o0; every MATCH claim was then re-run from scratch by an
independent skeptic instructed to default to REFUTED. Result: 15/15 confirmed, 0 disputed.
WHOLE-BINARY GATE (the sole arbiter, G3/P9): **12 banked / 3 failed** — a textbook SS52b
outcome (an rtu MATCH is a CANDIDATE, not a bank). All three failures are NAMED INTEGRATION
classes, none a compiler wall:
func_8013BD74 CARVE-REFUSED — it is a jr function; needs the SS81 carve chain (reach 138)
func_8013B83C CC1-FAIL — real-TU compile, error not yet read (reach 138)
func_80184058 PLUMBING — recovery ladder
BANKED: func_8013C08C + the 11 fourth-region fns (func_80183CF0/D50/F28, func_80184028/264/
2E0/354/474/538, func_801847EC, func_80184868).
Bank truth read from the SOURCE (INCLUDE_ASM absence), never the gate report (SS55b trap 4).
R22 CLEAN-FLEET: extract-all 139/139 (+main); check-all 140 passed, 0 failed of 140.
PROPAGATION OF func_8013C08C (reach 138) IS NOT DONE: the first sweep returned "0 families"
because the family map still listed it as a stub — regenerated it (the documented
crack-wave-sweep-map-regen path), after which the sweep found 137 candidates and banked
**0/137**. Per SS94 a family 0/N is a TYPE-CARRY failure until proven otherwise, and this
body carries a SS100 body-scoped typedef, so that is the first hypothesis to test. Recorded as
open, NOT as a wall.
FLYWHEEL FEEDBACK (R16), the honest read: the cookbook index fired on only 3/15 targets.
Agents independently re-derived the SAME undocumented idiom — the -O0 CONSTANT-OFFSET FOLD
(`p->f` folds to `lbu 3(r)`; `p[i]` does NOT, it emits `addiu; lw 0(r)`) — and two found their
decisive levers in a SOURCE HEADER COMMENT in ov_SC01_077_o0.c rather than in the cookbook.
The -O0 regime is under-documented relative to how much of the frontier now lives in -O0 TUs.
SS71 also generalises to -O0: several agents cracked their target off an already-banked sibling
in the same TU (func_80184868 came straight off the shape banked earlier today).
The second and last has_mid_jr family of the -O0 cluster. Same route as func_8013C0F8:
jtbl_family_bank (the SS81 carve chain per sibling) -> 137 BANKED / 0 failed.
Both jr families together: 274 members, 483 ins x137 = ~66k instructions, 0 failures.
Neither was bankable before commit:1270 routed the destination TUs to -O0.
R22 CLEAN-FLEET: extract-all 139/139 (+main); check-all 140 passed, 0 failed of 140.
The first of the two has_mid_jr families SS53 correctly refused from the carve-less
family_sweep. Routed through the tool its tier needs (jtbl_family_bank, the SS81 carve
chain per sibling) it banks CLEAN:
jtbl_family_bank func_8013C0F8 ov_SC01_077 0x8013c0f8 -> 137 BANKED / 0 failed
~7s per sibling (carve + extract + remap + whole-binary gate), ~16 min total
Only possible now because commit:1270 routed each destination TU to -O0; before that the
member's home file compiled -O2 and no body could ever match there (SS116).
INDEPENDENT CONFIRMATION OF THE SS125 DIAGNOSIS: this is the SAME tool that returned
gate-fail on every group-B (func_8017BEBC) probe earlier today. 137/137 here versus 0/4
there, same jr machinery, is exactly what the carve-vs-body diagnostic concluded --
group B's failures are its BODY, not the carve. I had first blamed the carve; the
body-free probe corrected it, and this run corroborates the correction from the other side.
R22 CLEAN-FLEET: extract-all 139/139 (+main); check-all 140 passed, 0 failed of 140.
The payoff of routing the cluster to -O0 (commit:1270). These functions were ALREADY
CRACKED in ov_SC01_077 and could not be banked anywhere else purely because every
destination file compiled -O2. With the destinations now -O0, they template in
deterministically -- no drafting, no agents.
dedup_propagate --recover 0x8013C360 (h_exact x138) -> 137 overlays byte-identical
family_sweep --hseq 10 variant families -> 1,227 banked / 133 failed (90%)
1360 staged across 136 groups
------------------------------------------------------------------------------------
1,364 new banks
FLEET: fn-count 92.71 -> 93.09% · instr 88.3 -> 88.6% · distinct-code 78.7 -> 79.3%
(71,756 / 87,459 unique fns; +1,162 unique). dedup 1904 -> 1905 groups, 0 failed;
C1 coverage 240496/240496. 0 NON_MATCHING in any default build (G4).
R22 CLEAN-FLEET: extract-all 139/139 (+main); check-all 140 passed, 0 failed of 140.
--recover WAS LOAD-BEARING (SS75): without it dedup_propagate took its historical
all-or-nothing branch -- one failing overlay (the SOURCE, ov_SC01_077) dropped the whole
function and it printed "all candidates dropped", which reads exactly like a wall. Reading
the exclusion code instead of believing the message showed the remedy: --recover excludes
only that overlay (kept x1 with its own inline match) and propagates to the other 137.
The two has_mid_jr families in the cluster were REFUSED BY DESIGN, not attempted (SS53
interlock): 0x8013C0F8 (154 ins) and 0x8013C414 (329 ins), ~137 members each = ~466
members queued behind the jtbl carve path they actually need, rather than a fake 0% from
the wrong tool.
REMAINING in the cluster: the 133 sweep failures + the 2 jr families + the 3 addresses
never cracked anywhere (0x8013B83C, 0x8013BD74, 0x8013C08C) -- the last are genuine
drafting work, now finally possible since their TU is -O0.
Applies tools/o0_subsplit.py across every overlay whose 0x8013B568..0x8013C98C -O0
cluster was trapped inside an -O2 jr split. This is the population the phase opened
against, and it has never been buildable-at--O0 before.
135/135 sub-splits applied, 0 tool refusals
140 new -O0 region files; corpus.o0_sources() 137 -> 277
0 of them invisible to the -O0 oracle (verified explicitly -- a SILENT -O0 miss is
the exact failure SS126 warns about: the region would compile -O2 and every residual
it produced would be a pure artifact)
**2,200 open stubs now live in a genuinely -O0 translation unit**
R22 CLEAN-FLEET: extract-all 139/139 (+main); check-all 140 passed, 0 failed of 140.
make tools-health OK: corpus(+resident) 0 PHANTOM/0 TRUNCATED; cdecl ALL ORACLES GREEN;
audit-binaries 140 onboarded, every one a full citizen (R36); dedup-check 1904/0,
C1 coverage 240359/240359; cookbook-index 336 sections.
The transform is byte-neutral by construction (it only moves subseg boundaries and
repartitions source), so the whole batch was gated by one clean-fleet R22 rather than
135 individual builds -- after a single-overlay probe (ov_SC01_000) proved it (R37).
NOTE THE POPULATION CORRECTION (R14, mine): I earlier reported this cluster as "275 open
stubs across 18 overlays". That was WRONG -- the sizing scan ran while R22 was rebuilding
in the background, so corpus.stubs() raised for most overlays and my bare `except:
continue` SWALLOWED the very coverage assertion R32 exists to raise. The true figure is
2,184 open stubs across 138 overlays, which vindicates the T0(f) pin of "2,192 open
members" that I had called stale. The target list for this sweep was rebuilt with NO bare
except, so R32 can do its job.
Drafting fuel confirmed present: cached Ghidra-C seeds exist for the cluster's addresses.
Drafting the 2,200 is crack-wave work (T3), not T2.
Promotes the proven probe (commit:1266) into a real tool, and validates it FIRST-TRY on a
fresh overlay.
tools/o0_subsplit.py <ov> --lo <vram> --hi <vram>:
- derives the range's contents from the SOURCE ANCHORS (overlay_src_split.parse_overlay_c:
`asm` = unmatched stub, `define`/`def`/`nonmatch` = already matched), NEVER from an asm
scan -- a matched fn emits no .s, which is exactly the blindness that made the range look
like a clean contiguous run (SS126 / SS124's shape);
- computes the -O0 bound as (address range MINUS already-matched bodies) and emits ONE
sub-region per maximal run of unmatched anchors (K matched islands => K+1 regions);
- names each `<ov>_o0<letter>` picking free suffixes, so the widened Makefile glob selects
them; refuses loudly if it runs out or if the range spans >1 object or is already -O0;
- honours the one-carve-per-region law (forces a cut at every already-banked jr in the
object) and reuses jr_isolate_all's plan/build_new_config/ascending-unique validation
verbatim, so carve-repoint + source-repartition stay on the proven path;
- warns (does not refuse) when a stub in an -O0 run lacks the frame-pointer prologue --
the byte-gate is the arbiter, not the heuristic.
VALIDATION on ov_SC03_015 (untouched by the manual probe): the tool independently derived the
SAME structure found by hand on ov_SC03_014 -- 2 matched -O2 islands (func_80184440,
func_801848E4), 2 -O0 regions (8 + 7 fns), same 5 cuts. Sub-split -> BYTE-IDENTICAL. Then 3
drafts, each global DERIVED FROM THAT OVERLAY'S OWN ASM (%hi operand) rather than copied:
3/3 match_one --o0 MATCH (22 ins), 3/3 through the whole-binary gate.
BANKED this commit: func_801846E4 / func_8018473C / func_80184794 in ov_SC03_015 (6 across
the two overlays now). The other 24 stubs in the region are undrafted -- the route makes them
DRAFTABLE (they were un-bankable at any effort before); drafting them is crack-wave work.
R22 CLEAN-FLEET: extract-all 139/139 (+main); check-all 140 passed, 0 failed of 140.
cookbook SS126 (the address-range-is-not-an-optimization-region law + the probe ladder).
T2's central unknown is resolved, and it is NOT what the phase plan predicted. The plan
named the Arm-A splat `%lo +0x20` defect as T2's real substance. Four probes, each
isolating ONE variable, SHA vs config/check from a clean tree (SS125 rules):
1. sub-split the jr object at ARBITRARY addresses, pure -O2 -> BYTE-IDENTICAL
** the re-carve is NEUTRAL; Arm-A does not bite here **
2. same split, middle region routed to -O0 -> DIVERGED (2 vars at once)
3. same NAME as probe 1, only the -O0 flag added -> DIVERGED
** therefore the FLAG, not the subseg name **
4. -O0 regions cut to EXCLUDE the matched bodies -> BYTE-IDENTICAL
** route PROVEN end-to-end **
THE REAL OBSTACLE: an address range is not an optimization region. Interleaved among the
15 -O0 stubs at 0x80183CF0..0x80184920 are TWO already-MATCHED functions (func_80184440,
func_801848E4) that expand from engine_core.h and compile at -O2. Flipping the FILE to -O0
recompiles them too. Cut around them and it is byte-clean.
MY EARLIER "15 contiguous -O0 fns, clean cut" WAS AN UNDER-COUNT (R14 on myself): I derived
it by scanning asm/**/*.s for the frame-pointer prologue, and a MATCHED function emits no
.s -- so the scan was structurally blind to exactly the bodies that break the flip. Same
shape as SS124. Any T2 driver must derive -O0 bounds as (address range MINUS already-matched
bodies), never from an asm scan.
BANKED (3, whole-binary gate the sole arbiter): func_801846E4 + siblings func_8018473C /
func_80184794. Each global DERIVED FROM THE ASM (%hi/%lo operands), not taken from the
draft's comment; 3/3 match_one --o0 MATCH (22 ins) with a -O2 control showing the mismatch;
3/3 verified through harvest_verify; bank truth read from the SOURCE (SS55b trap 4).
MAKEFILE: the -O0 glob widened `ov_*_o0b.c` -> `ov_*_o0?.c` so ANY lettered -O0 sub-split is
covered by one rule. A MISSED rule is silent -- the region would compile -O2 and every
residual it produced would be a pure artifact (SS116). corpus.o0_sources() re-verified: 137
sources, resolves `?` via glob, both pre-existing rules intact.
CONFIG: ov_SC03_014_jr_8017EB7C sub-split into 5 regions (pre / _o0c / matched-O2 /
_o0d / post), reusing jr_isolate_all's plan+build_new_config+validation verbatim so the
carve-repoint and source-repartition semantics are the proven ones.
R22 CLEAN-FLEET: extract-all 139/139 (+main) ; check-all 140 passed, 0 failed of 140.
The 3 jr behemoths carried from SESSION-27 (staged .run/beh-gate/), each run through
the SS81 3-step chain SERIALLY under tools/treelock.sh (every step calls `make extract`).
Re-derived the stub set on a QUIESCENT tree first: 4 of the 7 staged fns were already
banked in S27 and the staging dir still held all 7.
BANKED (1):
ov_SC05_010 func_80181CDC (769 ins) — jr_isolate_all --only -> BYTE-IDENTICAL,
jtbl_carve --func -> BYTE-IDENTICAL, then harvest_verify --chunk 1. Bank truth read
from the SOURCE (INCLUDE_ASM absence), never the gate report (SS55b trap 4).
BYTE-REFUSED (2) — to the wall ledger WITH EVIDENCE, not forced, not labelled walls:
ov_SC01_009 func_8018057C — jr_isolate_all reported success (2 jr in 1 -O2 object,
2 region .c) but the post-isolate build was NOT byte-identical. Aborted at step 1.
ov_SC06_018 func_80191C50 — isolate clean; jtbl_carve reported success (48-piece
carve set, 22 tail pieces) but the post-carve build was NOT byte-identical.
Aborted at step 2.
Both TOOLS claimed success; the whole-binary gate refused (G3/P9 doing its job).
Neither is diagnosed, so neither is called a compiler wall — on this project that
guess has been wrong four times running (R35). Drafts + logs preserved under .run/.
R22 CLEAN-FLEET (config changed => T2 blast radius => mandatory):
extract-all: 139 extracted, 0 failed of 139 (+ main, serial)
check-all: 140 passed, 0 failed of 140 <- BYTE-IDENTICAL
DRIVER DEFECT FIXED (mine, SS105/SS61): v1 of .run/s28_beh.sh `continue`d past a failed
gate WITHOUT reverting, leaving two half-carved overlays in the tree; only a full
`git checkout -- src/ config/` recovered it. Nothing was ever committed, so the cost was
build cycles and zero work. v2 reverts that target's config+src on EVERY failure path.
The skip class that the SESSION-27 checkpoint carried as "~137 members, a cheap
sweep-routing gap" is closed: ONE exemplar, ALL 137 same-address members banked,
0 failed, in a single --only sweep after the extract_unit alias fix (commit:1260).
- family_sweep --hseq --only 0x8016191C --band all -j 8, under tools/treelock.sh
(the campaign-wide mutex, not a pgrep poll).
- BANKED 137 member-matches / 0 failed across 137 overlays; skipped {}.
- 24 ins x 137 = 3,288 instructions that were sitting behind a tool lookup miss.
- R37 probe before the sweep: rtu_match MATCH (24 ins) on 3 members in the REAL
TU (ov_SC01_000 / _001 / _004) before spending 137 gate cycles.
R22 CLEAN-FLEET: make clean && make extract-all && make check-all ->
extract-all: 139 extracted, 0 failed of 139 (+ main, serial)
check-all: 140 passed, 0 failed of 140 <- BYTE-IDENTICAL
0 NON_MATCHING in any default build (G4). The whole-binary byte-gate was the sole
arbiter for every one of the 137 (G3/P9).
Note --band: the sweep defaults to band=substantial and this family is band=mid,
so the first invocation returned "0 matched-exemplar families" — a silent-looking
zero that is a FILTER, not a wall. --band all is required for mid/tiny families.
The 12 agents killed by the usage-limit pause were resumed and ALL returned MATCH (2 had already
banked from their partial drafts, so 10 ran). h_exact propagation leg completed over all 112 banked
exemplars: 14 propagated, 42 benign skips (h_seq tier, correctly routed away per §123), 0 failures
— the 0x801466F0 'halt' was a third benign-refusal phrase, not a partial write.
fn-count 92.61 -> 92.67% | instr 88.2 -> 88.3% | distinct 70,581 -> 70,590 unique fns.
WAVE 3 (48 agents / 8 binaries, dealt across binaries so BANKING fans out): 48/48 match_one MATCH,
48/48 banked through 8 PARALLEL per-binary gates. WAVE 2: 15/19. BEHEMOTHS: 4 non-jr confirmed
(func_8017E120 884ins x14, func_8017FA5C 728, func_8017CAD4 755, func_8017E35C 719).
Tier-routed propagation (§123): family_sweep --hseq banked 911 members across 137 overlays.
fn-count 92.32 -> 92.59% | instr 87.9 -> 88.2% | distinct 78.3 -> 78.7% (70,506 unique fns)
R22 clean-fleet 140 passed / 0 failed, under one campaign lock (treelock.sh).
CORRECTION (R14): the 'per-binary bank-rate cliff' I reported from the pre-incident gate run
(SC03_014 1/6, SC04_018 1/6, SC06_018 2/6) was an ARTIFACT — those gates ran against a tree
propagation was concurrently rewriting. Re-gated clean: 6/6 everywhere. A measurement taken during
corruption is not a measurement; I should not have theorised a cause before re-running it.
The 4 cores dedup_propagate refused (h_exact tier) templated cleanly via family_sweep --hseq once
the family map was regenerated post-bank (a bank invalidates the map: sig-overlays + family_hseq
must run BEFORE the sweep — the standing wave-loop order). 548/686 banked, 138 failed (one
consistent per-overlay slice, diagnose next). Wave-1 total: 8 cores -> 1,121 instances.
instr 87.5 -> 87.9%, distinct 69,828 -> 70,094 unique fns.
Ultracode wave of 14 agents over fresh reach-138 cores: 14/14 match_one MATCH, 8 accepted by the
whole-binary gate (the §52b law reproduced exactly). Propagated per-function (the incident fix):
0x8012E014, 0x80151C54, 0x8012F49C, 0x80151B98 -> +573 instances. R22 clean-fleet 140/140;
instr 87.5 -> 87.7%, fn-count 92.00 -> 92.16%, distinct 69,828 -> 69,836.
The other 4 banked cores are h_seq (PURE/IMM) families: dedup_propagate is h_exact-only, so its
'reach<2' / 'not self-contained' refusals were statements about the TOOL's tier, not the functions
-> cookbook §123 (the §53 carve-law generalized to the propagation-tier axis) + a routing table.
They bank via family_sweep --hseq next.
Drew T