The §53 carve path banked only 4 of 137 siblings, ALL of them SC07 — the exact signature
func_80177DA8 showed before its §99 fix, so the same lever applies.
- jtbl_family_bank func_80135260: 4 BANKED / 133 gate-fail. The 4 are SC07 overlays.
- conform_decls dry run confirmed the class: byte-true def is
`s32 func_80135260(s32, s32, s16 *, s16 *)` but 3,744 declaration sites say
`(s32, s32, s32, s32)` — params 3 and 4 declared s32 where the byte truth is s16 *.
Return type agrees, so the §85 return-axis precondition does not fire.
- Applied: 3,744 sites rewritten across 2,021 files; the tool's R32 assertion reports
"non-canonical declarations remaining: 0 OK (axis complete)". It correctly SKIPPED the 5
DEFINING TUs (the 4 SC07 banks + ov_SC01_077) — a defining TU owns its own declarations, since
per-overlay byte-true signatures legitimately differ under §16 loose typing.
- This touches src/shared/engine_core.h, so it is FLEET-SHARED and R22 was mandatory (§61/§63):
R22 clean-fleet 140 passed, 0 failed of 140.
Also recorded: jtbl_family_bank's [gather_externs] warning named func_80135D20 as an undeclared
referenced symbol, but that symbol appears ONLY in the draft's header COMMENTS (lines 3 and 29) —
a comment-scanning false positive, same class as the Phase-19 gen_harvest_targets garbled-hint bug.
It was not the cause of the 133 failures.
Next: re-run the carve path for the remaining 133 siblings now that the decl axis is conformed.
The T45 probe re-filed this as a crack target; it turned out to be a SCOPE problem, and the fix is a
new reusable lever.
DIAGNOSIS. The draft MATCHes standalone (136 ins) with block-scope `extern u16 *D_801870AC/B0/B8`,
which are byte-TRUE (they produce the target's 4-byte pointer loads). The TU carries FILE-scope
`extern u8 D_801870B0/AC/B8; extern s16 *D_801870B4;` at lines 3433-3436 — the preamble of the
already-banked func_80135168 — and a file-scope decl constrains EVERY LATER function in the TU, so
the draft's pointer decls became "conflicting types". Ordering is what makes this asymmetric: the
TU's own block-scope `extern u16 *D_801870B0;` at L2829 precedes the file-scope u8 decl and only
WARNS; a block-scope decl AFTER it is an ERROR.
TWO WORKAROUNDS MEASURED AND REJECTED, both +3 instructions with a rotated callee-saved bank:
reconcile_tu (conform to the TU) -> 139 ins vs 136, 123 mismatched
cast-at-use (*(u16 **)&D_x) -> 139 ins vs 136, 123 mismatched
So the byte-true code genuinely REQUIRES the pointer-typed declaration; the decls had to move.
THE FIX (move the decls, never the draft — §85 applied to DATA): scoped those four file-scope externs
into their only two consumers (func_80135168 and func_80135480, both of which already use the
cast-at-use idiom). Verified in two steps: (1) the decl move ALONE rebuilds ov_SC01_077 byte-identical
d19c9580 — declaration-only, no codegen change; (2) the original byte-true draft then banks clean,
verified 1 / failed 0. R22 clean-fleet 140 passed, 0 failed of 140.
THE REUSABLE LEVER: a FILE-scope extern in a shared overlay TU is a global constraint on every later
function in that TU. When a byte-true draft needs an incompatible type for the same symbol, scope the
existing decl to its consumers rather than bending the draft — bending it cost +3 here, twice.
Family sweep is NEXT and needs the §53 carve path (has_mid_jr: true, 137 siblings, PURE) —
family_sweep correctly refused it.
137/137 banked via jtbl_family_bank (jr family, carve-aware path). R22 clean-fleet 140 passed /
0 failed of 140. MEASURED: fn-count 319,412 -> 319,549 (+137); instr-weighted 84.7 -> 84.8%
(+9,590 ins); distinct-code 74.5 -> 74.7% (+130 unique fns).
WAVE22 COMPLETE: 18 targets drafted (12 MATCH / 6 NEAR / 0 FAIL, 2.59M subagent tokens) ->
5 exemplars banked -> 685 members swept -> 690 functions total.
This commit stages config/ EXPLICITLY. Twice today I omitted it and left a carve uncommitted, both
times caught by jtbl_family_bank's dirty-tree precondition rather than by me or any gate.
Same error as commit commit:1103 this morning, which I recorded as a lesson and then repeated: I scoped
`git add` to src/ and docs and omitted config/, leaving the jtbl carve that func_80171B4C's bank
depends on (its `- [0x499f4, c, …]` split + `.rodata` carve + the JTBL_INTERLEAVE order) uncommitted.
harvest_verify KEEPS a carve on success, so it is part of the banked state, and the R22 140/140 I
reported was verified WITH these files present.
Caught by jtbl_family_bank's dirty-tree precondition again — not by me, not by any gate. That is now
twice in one session that a tool's precondition was the only thing standing between a partial commit
and a broken HEAD.
THE REAL LESSON, and it is not "be more careful": a scoped `git add` is an UNVERIFIED ASSERTION about
a change set's boundary, and nothing in this project checks it. R32 says a claim like that needs an
assertion. The concrete guard: before committing banked work, `git status --porcelain config/` must be
empty or its contents must be part of the same commit. Recorded for the next session rather than
bolted on at the end of a long one.
137/137 banked, 0 failed via jtbl_family_bank. R22 clean-fleet 140 passed / 0 failed of 140; report
fail-closed green (dedup 1886/0, C1 coverage 239604/239604, 0 NON_MATCHING).
MEASURED: fn-count 318,447 -> 318,585 (+138); instr-weighted 83.9 -> 84.0% (+12,558 ins);
distinct-code 73.2 -> 73.4% (+131 unique fns — byte-VARIANT members, so unlike func_801330E0's
byte-identical family this one moves the distinct number too).
Closes the function REFUSED since SESSION-21 — correctly refused, since conforming its 660
declarations without first casting its 138 zero-arg call sites would have broken 138 binaries.
Also logged (T21): the sweep-throughput measurement. Drew was right that parallelism was proven and
adopted (Makefile JOBS=16; sweep_parallel.py -j12 built SESSION-20 after measuring an 8-16x loss),
but NEITHER sweep tool calls it — the adapter is reachable only via a manual --stage-only two-step,
so three sweeps today ran serially for no reason. The -j theory was wrong and measurement said so:
make is ~5s of the 16s per sibling (the loop runs up to FOUR builds per sibling), so -j16 is a 12%
win, kept but minor. The real 8-16x lever is blocked on revert() restoring the SHARED
config/overlays.mk from git — designed, not built. An attempt to wire family_sweep's parallel default
broke it twice and was reverted rather than committed.
MY ERROR: the previous commit scoped `git add` to src/ and tools/ and omitted config/, leaving the
jtbl carve's config (overlays.mk + splat.ov_SC01_077.yaml) uncommitted. harvest_verify KEEPS a carve
on success, so that config is part of the banked state — HEAD was an incomplete change set, and the
R22 140/140 I reported was verified WITH these files present, not without them.
CAUGHT BY jtbl_family_bank's precondition check ("config/ or src/ has uncommitted changes"), not by
me and not by any gate. A build without them appeared byte-identical, but that was an INCREMENTAL
build reusing objects — the same trap that produced a false all-clear earlier today — so it is not
evidence either way. Committing what R22 actually verified removes the ambiguity rather than
reasoning about it.
Lesson, same shape as R32 pointed at commit hygiene: a scoped `git add` is an assertion about the
change set's boundary, and nothing checks it. The tool preconditions are the only thing standing
between a partial commit and a broken HEAD.
The largest single family on the census: 137 siblings x 289 ins. Per sibling — jtbl_carve -> make
extract -> remap_hseq + canon_sig_reconcile -> whole-binary gate, revert-on-fail. 137/137 BANKED,
0 failed. R22 clean-fleet 140 passed / 0 failed of 140; report fail-closed green (dedup 1886/0,
C1 coverage 239604/239604, 0 NON_MATCHING).
MEASURED: fn-count 318,171 -> 318,309 (+138); instr-weighted 83.4 -> 83.8% (+39,882 ins);
distinct-code 72.5 -> 73.2% (+131 unique fns).
TWO TOOL REFUSALS MADE THIS BANK POSSIBLE, and both deserve recording:
- family_sweep REFUSED the family (has_mid_jr): §53's carve law says a carve-less sweep there returns
"a 0% that is a TOOL artifact, not a wall". Overriding with --allow-jr would have yielded 0/137 and
plausibly filed the highest-value family on the board as a wall.
- jtbl_family_bank REFUSED a dirty tree: its per-sibling revert restores from HEAD, so the
uncommitted 414-file decl axis would have been destroyed. H4 enforced in code.
This is the inverse of the session's earlier failures, which all came from tools that ANSWERED
instead of refusing.
SESSION-22 TOTAL: 5 exemplars + 543 members = 548 functions.
Fleet: 82.9 -> 83.8% instr, 71.5 -> 73.2% distinct-code.
The largest target on the T14 census: 138 members x 289 ins = 39,882 templated instructions at stake.
conform_decls --check showed 418 sites in 3 forms, pointer-type-only with NO narrowing warning and no
return-type change — the func_80179B74 shape that banked 137/137. Applied (418 sites / 414 files),
gated (jtbl carve succeeded first try), R22 clean-fleet 140 passed / 0 failed of 140.
Committed BEFORE the family bank because jtbl_family_bank refuses to run on a dirty tree — its
per-sibling revert restores from HEAD, so an uncommitted axis would be destroyed. The tool enforcing
H4 in code, correctly.
Also recorded: family_sweep REFUSED this family rather than returning 0/137 — func_80135EB0 is
has_mid_jr, and §53's carve law says a carve-less sweep there yields "a 0% that is a TOOL artifact,
not a wall". That refusal is the good version of today's pattern: every false wall untangled this
session (func_8016B6BC 0/137, the 4 fabricated CC1-FAILs, Phase-28's B2 0/8) came from a tool that
ANSWERED instead of refusing.
134/134 BANKED on the remainder after 3/3 on the probe — the FOURTH full-family sweep this session,
all four unblocked by the --like role guard, three of them 100%.
R22 clean-fleet: extract-all 139/139, check-all 140 passed / 0 failed.
1,600 decl sites across 523 files, in THREE different forms (s16 *a0 / short * / short *p),
conformed to the byte-true 'void func_80179B74(u16 *p)'. conform_decls ALLOWED this one: the arity
is unchanged, so no 0-arg call site can break, and the return is unchanged, so §85's precondition
does not apply. Gated BYTE-IDENTICAL; R22 clean-fleet 140/140.
The tool has now refused one axis (func_8015B950, correctly — it would have broken 138 binaries)
and cleared another (this one, correctly). Both verdicts held under R22.
133/134 BANKED on the remainder after 3/3 on the probe. ONE sibling refused (ov_SC03_108,
gate-fail) and is left as a stub rather than forced — a 136/137 recorded honestly beats a 137/137
that needed a shortcut. Third full-family sweep this session, all three unblocked by the --like
role guard.
R22 clean-fleet: extract-all 139/139, check-all 140 passed / 0 failed.
134/134 BANKED on the remainder after 3/3 on the probe — the second clean full-family sweep this
session, both unblocked by the --like role guard. func_8015B950 is stubbed in NO overlay.
R22 clean-fleet: extract-all 139/139, check-all 140 passed / 0 failed.
At 271 ins x 137 members this is the session's largest single family by instruction weight.
The same axis that broke 138 of 140 binaries an hour ago now lands clean, because conform_decls'
NEW arity guard located the actual obstruction instead of leaving me to absorb it by hand.
THE OBSTRUCTION WAS ONE LINE. Conforming `extern s32 func_8015B950(void)` -> `(s32 arg0)` turns
every 0-arg CALL SITE into `too few arguments`. My hand attempt assumed those were spread across the
926 TUs and would need 926 casts (the func_8012AAAC precedent, where it really was 137 separate
sites). They are not: there is exactly ONE call, in `src/shared/engine_core.h`'s
`DEFINE_func_8015BEE4()` macro body — expanded into all 926 TUs by the preprocessor.
func_8015BEE4 is a THUNK: `return func_8015B950();` with $a0 passing straight through from its own
caller. So the 0-arg call shape is byte-CORRECT and must be preserved, not fixed —
`return ((s32 (*)(void))func_8015B950)();` keeps it exactly (§17a-1; gcc folds the cast of a known
symbol to a direct jal, and the s32 return is unchanged so the thunk's value still flows).
Sequence: 1 cast -> conform_decls --apply (925 sites, R32 completion assertion: 0 remaining) ->
gate BANKED byte-identical -> R22 clean-fleet extract-all 139/139, check-all 140 passed / 0 failed.
The draft's 2 callee-decl conflicts (func_801725A4, func_80147078) dissolved with the axis.
Worth 37,398 templatable ins; the ×137 family sweep is next.
BANKED: func_8016AE5C (85 ins ×138). R22 clean-fleet 140/140.
⚠️ I BROKE 138 OF 140 BINARIES AND R22 CAUGHT IT — the per-binary gate could not.
Conforming func_8015B950's decl from `(void)` to its byte-true `(s32 arg0)` across 926 sites gated
BYTE-IDENTICAL on ov_SC01_077 and broke 138 other binaries with Error 33. §63/§85 exactly: a T2
write set is provable only by R22, and the binary the gate authorises is not the binary that breaks.
MECHANISM: conforming a decl to a signature that TAKES parameters makes every existing 0-ARG CALL
SITE a hard `too few arguments` error once a prototype is in scope. Not a declaration-only change.
PROCESS NOTE (mine): a first R22 reported 138 failures, an individual rebuild of a "failing" binary
said BYTE-IDENTICAL, and I nearly filed it as a flake. The second clean R22 reproduced it exactly —
the individual build passed only by reusing objects the clean run rebuilds. An incremental pass does
not refute a clean-tree failure; that is R22's whole premise, pointed at me. Reverted to a known-good
baseline (a stray jr_isolate region file was also in the tree) and redid the one good bank cleanly.
NEW tools/conform_decls.py — because applying this axis by hand three times in one session is how a
half-axis happens. Derives the byte-true signature from the DRAFT's definition (§58b), rewrites EVERY
site, asserts completion (R32). Encodes both preconditions: the §85 return axis (refuse if any caller
consumes the return) and a NEW arity precondition (refuse if 0-arg call sites exist, naming the cost).
The guard immediately gave a better diagnosis than my hand-fix had: func_8015B950's 0-arg call is in
ONE place — src/shared/engine_core.h, a DEFINE macro body — expanded into all 926 TUs. That fix is a
SINGLE cast, not 926 edits. Named as the next step rather than run on tired context.
Also lands cookbook §91 (the --like role trap) from the previous step.
- 134/134 BANKED on the remainder (after 3/3 on the probe) => the family is 137/137, ZERO failures.
func_8012AAAC is now stubbed in NO overlay. R22 clean-fleet: extract-all 139/139, check-all
140 passed / 0 failed.
- FLEET 81.9 -> 82.0% instr · 89.60 -> 89.64% fn-count · distinct-code 69.3 -> 69.5%.
- THE METRIC POINT, reproduced twice in one session and in BOTH directions: this jtbl family is
byte-VARIANT (each overlay's table holds its own addresses), so every member is a genuinely new
unique function and distinct-code MOVED. The h_seq PURE families swept earlier added 274 members
and moved distinct-code by +0.0, because those members were already counted via their shared
exemplar. SESSION-20's routing rule, now byte-demonstrated: target byte-VARIANT families to move
RE-completeness; high-reach h_exact families move only the display number.
- cookbook §91 — "a structure-TRANSFER is only valid where the structure corresponds": the --like
role trap, plus the three-hypothesis trail (two wrong, and instructive: the sibling call-site casts
were a real defect that fixed nothing, and my own carve-alone test was a false lead that departed
from the tool's real sequence). The law: any "same family => same structure" transfer must state
which structural fact it assumes and CHECK it on both sides — and a tool that drops an error class
it cannot act on should still SURFACE it, because a bare `gate-fail` repeated 137 times cost far
more than printing one line would have.
ROOT CAUSE of the 0/3 (found by reading the tool's ACTUAL invocation, not by guessing):
jtbl_family_bank calls `jtbl_carve <sibling> --func <fn> --like <exemplar_ov>`, and the role-transfer
keys on the SUBSEG ROLE (`ov_SC01_077_a` -> `_a`). Its premise — "same family => same span
structure" — silently breaks when the exemplar and the sibling host the function in subsegs with
DIFFERENT roles, which happens whenever the exemplar has a split the sibling does not.
MEASURED: func_8012AAAC lives in `ov_SC01_077_a` (role `_a`) in the exemplar but in the MAIN subseg
(role ``) in every sibling. The transfer therefore looked up `ov_SC01_077` — an unrelated SEVEN-table
span belonging to entirely different functions — and stamped those starts onto a sibling span holding
one table. jtbl_rodata_pads then refused with `consumed 1 rodata .align(s) but 2 pad spec(s) given —
table-count drift`, and jtbl_family_bank deliberately does NOT treat that error as isolate-fixable,
so all 137 siblings returned a bare `gate-fail` with the cause discarded.
THE FIX: transfer only when the exemplar's subseg for THIS FUNCTION has the sibling's role; otherwise
derive the span from the sibling's own carve (which was already computing it correctly). Fail-open is
not acceptable here — a wrong table set corrupts the image, so the guard defaults to local derivation.
MEASURED RESULT: the 3-member probe goes 0/3 -> 3/3 BANKED. R22 clean-fleet: extract-all 139/139,
check-all 140 passed / 0 failed.
Two earlier hypotheses were tested and are recorded honestly in CURRENT_PHASE.md: the sibling
call-site casts (real conflict, fixed, byte-neutral — but NOT the blocker) and my own carve-alone
test (which fails by construction for this shape, because a stub object does not emit the table its
2-entry spec describes — the tool splices the body BEFORE building, so its path is the valid one).
The first jtbl-routed bank of the session, and it validates the whole chain end-to-end:
1. jtbl_carve SPLIT-TABLE repair (this session): jtbl_801D7FB0 28 -> 50 words (112 -> 200 B),
authorized by func_8012AAAC's own `sltiu 0x32`.
2. NEW FIX — SINGLE-TABLE PREDECESSOR: adding a second table to a subseg whose existing carve was
single-table lost the FIRST table's start entirely (new_offs has only the new one;
overlay_jtbl_addrs cannot see the old one because its owner is banked and extract PRUNED the
stub .s; and single-table carves persist no tables= to rebase). The span then failed its own
validator with "first must equal the span start" — the invariant naming the missing entry.
A single-table carve spans exactly its one table, so ITS SPAN START *IS* THAT TABLE'S START:
inference, not persistence, so it also works for spans carved before tables= existed. This is
the RECOVERABLE half of the documented func_8013F350 lesson (that one was a pre-§8e merged
DOUBLE — two tables, no record, genuinely unrecoverable).
Result: ov_SC01_077_a JTBL_PADS := 0,0 tables=+0x0,+0x14. Carve alone byte-gated BYTE-IDENTICAL
BEFORE the bank was attempted (§81 step 2).
3. ARITY axis, all-or-nothing: 1,244 decl sites / 1,240 files `(void)` -> `()` + an R32 completion
assertion (old-form remaining: 0).
4. ONE call-site cast: the definition lands at line 811 and a 0-arg call sits at 822, so gcc sees
the prototype and rejects it — `((void (*)(void))func_8012AAAC)()` (§17a-1; gcc folds the cast
of a known symbol to a direct jal). Only 1 of the 1,386 fleet-wide 0-arg call sites needed it:
the others see only the `extern ()` decl, which permits a 0-arg call.
DIAGNOSIS NOTE: the failure read CC1-FAIL with only a warning visible under make. Running the
pipeline stage-by-stage (cpp | cc1 | maspsx | jtbl_rodata_pads | as) put it on cc1 rc=33, and cc1's
own stderr named it exactly: "too few arguments to function func_8012AAAC" at line 994. Isolating
the stage was what turned an opaque Error 33 into a one-line fix.
R22 clean-fleet: extract-all 139/139, check-all 140 passed / 0 failed.
family_sweep correctly REFUSED this exemplar (§53: a jr-family must route through
jtbl_family_bank.py; "a 0% from this path would be a TOOL artifact, not a wall") — the ×137 member
sweep is the next step and needs a clean tree, which this commit provides.
Zero functions >1000 ins remain unmatched anywhere in the fleet.
func_80183814 (5,122 ins — the LARGEST function in the game) — round 2 closed it: length 5127->5122
exact, structural residual 36->0, register-sensitive 1201->0, frame -256 -> -0xF8 exact, saves
10 -> .mask 0x807f0000 exact. Verified independently (R14): match_one MATCH (5122 ins).
ROUND 1's DIAGNOSIS WAS WRONG and the agent refuted it properly: the +5 length was a SYMPTOM, not
the lever, and the §83d max_reg/cse.c:8340 story does not hold — a 15-line reproducer reproduced the
case-0/3 CSE exactly (so it cannot be max_reg-gated), max_qty only gates extension ACROSS blocks,
and the target leaves $s7/$fp unused (no pressure story). Confirmed from a second direction: C01 has
the identical two groups over the identical symbols with ZERO residual, because a `break` puts a
CODE_LABEL between them. The two biggest levers were pure DECLARATION SCOPE (§45/§76), not pins.
func_8017DC1C (1,518) — MATCH first round, pin-free, zero __asm__ dials. NOT a jr fn (0 mid-fn jr).
func_8017D2DC (1,586) — MATCH first round (banked in the previous commit).
BANKING ORDER MATTERS — a new failure mode found and worked around: banking func_8017DC1C BEFORE the
carve chain broke the build. Its draft establishes the canon for 39 previously-undeclared externs;
jr_isolate_all's re-partition (overlay_src_split) then DROPPED ALL 39 across the new split boundary
(`D_801C1EB0 undeclared`), leaving them in NEITHER file. The §77 preamble-drop class, in a third tool.
FIX = ordering, not patching: run the §81 carve chain FIRST on a clean tree (gated BYTE-IDENTICAL),
then bank. Reverted, re-sequenced, both banked clean.
R22 clean-fleet 140/140 BYTE-IDENTICAL; tools-health OK; dedup 1886/0; 0 NON_MATCHING (G4).
Fleet: instr 81.6 -> 81.7% · distinct-code 69.1 -> 69.3% · fn-count 89.52%.
T0.7 — the §86 one-member probe applied to the remaining FREE families: 9 LIVE / 6 DEAD / 5 unstaged.
The three highest-value families by raw size (18,084 / 11,234 / 10,880 ins) all probed DEAD — the
probe skipped them instead of burning ~400 gate cycles rediscovering it. Swept the 9 live: 104 banked,
8 of 9 families fully cleared (func_8017BEF8 has 8 stragglers).
BEHEMOTH 2 of 3: func_8017D2DC (1,586 ins, ov_SC01_001) MATCHED and BANKED — closed in ONE agent
round, pin-free. Verified independently (R14): match_one MATCH (1586 ins).
§81 carve chain: the agent predicted step 1 unnecessary; jtbl_carve REFUSED (the subseg already
hosts a .rodata carve and the new table's start != span start). The refusal was RIGHT and is the
instruction to run step 1 — jr_isolate_all --only (2 fns/1 object) -> BYTE-IDENTICAL, then
jtbl_carve -> BYTE-IDENTICAL, then the ladder banked it.
R22 clean-fleet 140/140 BYTE-IDENTICAL; tools-health OK; dedup 1886/0; 0 NON_MATCHING (G4).
Fleet: instr 81.5 -> 81.6% · distinct-code 69.0 -> 69.1% · fn-count 89.49 -> 89.52%.
The SESSION-19 handoff's item 1, closed as specified — no drafting, no agent.
- §77 MINIMAL CLOSURE (519 lines, not the 2,993-line whole-file carry): 18 gte_* macros
+ 5 externs + the bandsetup static-inline helper -> match_one MATCH (1061 ins)
- §81 chain, each step byte-gated before the next: jr_isolate_all --only (2 fns/1 object)
-> BYTE-IDENTICAL; jtbl_carve --func (single-table, 44-piece interleave) -> BYTE-IDENTICAL;
harvest_verify --chunk 1 -> verified 1 / failed 0, 7042bc71 BYTE-IDENTICAL
- R22 clean-fleet 140/140 from a genuinely clean tree; tools-health OK; dedup 1886/0;
0 NON_MATCHING (G4). FLEET distinct-code 3,845,161 -> 3,846,222 = 68.3% (+1,061, all
distinct — a behemoth-class bank, not a propagation); instr-weighted 80.6%
- No §75a class spoke: the exemplar's ApplyMatrixSV(void*,void*,void*) canon fix was
already carried, so the declarations were clean and it banked first try
- cookbook §77: the ladder CLOSED with all four rungs measured (-56 -> -34 ->
MATCH-but-uncommittable -> MATCH+BANKED), plus a NEW subsection — the CANDIDATE gate
and the REAL gate need DIFFERENT preambles (match_one compiles standalone, so a
shared-type body's CC1-FAIL is a report about the PROBE, not the draft; the types
header goes in a throwaway probe copy, never in the banked draft)
- FINDING, flagged not acted on (P5d): that shortcut already leaked an ABSOLUTE include
path into 21 git-tracked files / 23 lines. All 21 verified semantically no-op (guarded
engine_types.h via engine_core.h at line 2) => removal is byte-neutral, but cpp must
still find the literal path, so those TUs cannot preprocess on any clone not at
/home/musashi/bfm-decomp. Invisible to every byte-gate (R34's null-oracle shape, aimed
at portability). Proposed as the next task.
- CRACKED at xHigh and VERIFIED INDEPENDENTLY: match_one MATCH (1061 ins); agent re-matched 3x
from clean runs (100% register-masked AND register-kept, all 10 regions, frame 0x270 exact).
§81 carve chain clean first try: jr_isolate_all --only -> byte-identical cacaf7c2 -> jtbl_carve
(43-piece set) -> byte-identical -> bank -> R22 clean-fleet 140/140, tools-health OK.
instr 80.6%; distinct-code 3,844,100 -> 3,845,161.
- WHAT IT IS: the matched base func_8017CA80 + camera height-band cull + distance-driven CLUT
fade. func_8004974C (TransposeMatrix) sits in a 36-ins prologue deriving a Y band; the
part-level `lim >= g.otz` cull is GONE; flat arms gain an `sz < lim` near-plane cull. The
base+one-extra-callee fingerprint predicted this exactly.
- §82 ORACLE 1 -- A DUPLICATED `addiu $aN,$sp,K` ACROSS A `jal` MEANS THE BLOCK WAS INLINED.
`&X` on any non-first local always creates a pseudo and CSE always merges two of them
(expr.c:6260 ADDR_EXPR -> force_operand(..., NULL); exception: virtual-stack-vars offset 0).
So the same stack address re-materialised at two sites separated by a jal means CSE was
PREVENTED from merging => not the same function body. 17 non-inline spellings failed; a
`static inline` helper reproduced the prologue BYTE-FOR-BYTE first try. Reusable probe: scan
the ~1,200 built objects for that signature in NON-INCLUDE_ASM functions.
- §82 ORACLE 2 -- SCALAR vs AGGREGATE DECIDES *WHEN* A STACK SLOT IS ALLOCATED: lazily at first
`&` for a scalar, AT DECLARATION for an aggregate. Six GTE result words had to be six separate
longs, not a struct, or they don't land after the inlined helper's temps and the frame isn't
0x270. Second-order: it also flips MEM_IN_STRUCT_P (§30's /s) -- with one word a fixed-address
scalar, ((PolyF3*)pkt)->rgbc stops aliasing it, so a store needed respelling to keep the
target's nop. A scalar-vs-struct choice is simultaneously a frame-layout AND an aliasing
decision.
- BANKING FOOTNOTE (§75a class A): first bank rejected `conflicting types for ApplyMatrixSV` --
draft (MATRIX2*, SVECTOR2*, SVECTOR2*) vs the TU/fleet canon (void*, void*, void*), 2,286 of
2,835 sites. Conforming the decl is byte-neutral and banked first try. On a jr function expect
BOTH gates to speak: the carve chain answers the jump table, §75a answers the declarations.
- Also reproduced: §78 (reuse a busy variable), §80(i) (a lever went -8 -> exactly neutral as the
base moved), §72 (a register pin made it worse).
- AGENT'S OWN CAVEAT, recorded not hidden: one zero-byte __asm__ keeps a vestigial `mnc = hmid`
alive that flow.c would delete (costing 10 ins + the 0x130 spill slot). Emits nothing, compile
is 1061 exact, but it is a documented stand-in -- 12 natural spellings measured, all DCE'd.
- BANKED (1,194 ins, ×1 distinct-code). Chain cleared, each step byte-gated before the next was
built on it: one-line fix to jr_isolate_all._engine_types() -> jr_isolate_all --only
func_8017C954 (2 fns / 1 object, NOT the bare 47-fn / 21-object resegment) -> BYTE-IDENTICAL
b7b0d4ae -> jtbl_carve --func func_8017C954 (44-piece carve set + interleave order) ->
BYTE-IDENTICAL -> harvest_verify VERIFIED BYTE-IDENTICAL -> R22 clean-fleet 140/140,
tools-health OK. instr 80.5 -> 80.6%; distinct-code 3,842,906 -> 3,844,100.
- THE DEFECT (tools/jr_isolate_all.py): _engine_types() harvested shared type names with four
patterns -- `typedef ... X;`, `} X;`, forward-decl `struct X;`, fn-ptr typedef -- and a TAGGED
DEFINITION WITH A BODY matches NONE of them. So `struct PW8017E6D8 { int w; }
__attribute__((packed));` at engine_types.h:658 was present in the shared header yet invisible
to the carried-type check, and `extern struct PW8017E6D8 D_801E1EC4;` could not be placed.
MEASURED BLAST RADIUS: 77 such tags in engine_types.h were invisible. One added pattern fixes
all 77.
- WHY THIS COST 20 MINUTES INSTEAD OF A MYSTERY BYTE-DIFF THREE PHASES LATER: the Phase-26 audit
had already turned this predicate's SILENT DROP into a LOUD REFUSAL. The original bug dropped
4,040 col-0 decls, 683 of them function PROTOTYPES -- and a dropped prototype is a SILENT
BYTE-CHANGER (C89 implicit `int f()`; return type drives delay-slot fill in this codebase). The
refusal named the exact symbols and the exact remedy. A loud "I cannot place this" is worth far
more than a green build -- the audit paying for itself, live.
- §81: the 3-step jr-carve chain + why match_one CANNOT see the problem (it masks jal/HI16/LO16,
so a jump-table function reports MATCH while the whole-binary gate reports DIFF, correctly).
Detect with `grep -cE 'jr \$(v0|v1|a0|t[0-9])'` on the target .s + a jtbl_ in asm/<ov>/data/.
ALWAYS use --only: bare would have resegmented 47 jr-functions across 21 objects.
- dedup_extend banked 132 / 179 planned across 135 binaries: func_80174CB0 VERIFIED in 132,
FAILED in exactly 3. 123 ins × 132 = 16,236 ins.
- THE PREDICTION HELD TO THE OVERLAY. The blocker breakdown across the original 134-binary sweep
was 131 class-B (func_8012F14C arity split) / 3 class-A (func_80012ABC, census 73 s32 vs 7
s16). Fixing class B alone banked 132 and left 3 -- precisely the class-A set. A diagnosis that
predicts WHICH members will still fail, and is right, is much stronger evidence than one that
explains failures after the fact; same shape as §75b predicting that the 3 stuck members would
be exactly the 3 files carrying the __volatile__ spelling of SHB.
- FLEET: instr-weighted 80.2% -> 80.3% (10,539,723 -> 10,555,959); fn-count 89.14% -> 89.18%;
distinct-code 67.7% UNCHANGED (propagation moves coverage, not distinct-RE -- fresh cracks are
the only lever there). dedup 1886 validated / 0 failed, C1 coverage 239,604/239,604.
0 NON_MATCHING (G4).
- R22 clean-fleet: make clean && extract-all && check-all -> 140 passed, 0 failed of 140.
- cookbook §75c committed with this batch. The 3 residual overlays need the 7 `s16` func_80012ABC
decls normalized -- worth 3 overlays only, so do it only if trivially cheap.
- dedup_extend banked 157 / 478 planned across 135 binaries: func_80165CA0 (99 ins) ×135
(~+0.10pp) + 22 other functions ×1 picked up in the 3 overlays the first sweep excluded.
- FLEET: instr-weighted 80.1% -> 80.2% (10,525,534 -> 10,539,723, +14,189 ins); fn-count
89.09% -> 89.14%; distinct-code 67.7% (unchanged — propagation moves coverage, not distinct-RE).
dedup 1886 validated / 0 failed, C1 coverage 239,472/239,472. 0 NON_MATCHING (G4).
- R22 clean-fleet: make clean && extract-all && check-all -> 140 passed, 0 failed of 140.
- §75b — extraction lifts `extern`s but NOT file-scope `#define`s, so a body matched with a macro
in its preamble compiles only where that overlay's define is in scope ABOVE the splice point.
Signature is a LINK error (`undefined reference`), never `conflicting types`: an unexpanded
SHB(x) parses as a call to an undeclared function. The diagnosis PREDICTED the membership —
the 3 stuck members are exactly the 3 files carrying the __volatile__ spelling of SHB, i.e. the
function's own preamble still sitting above its own instantiation.
- R14/R35 IN ACTION: the full-sweep census REVERSED the ranking I had just committed. I put the
class-A normalization first at "~+0.13pp if it reaches ×138"; measured across all 134 it is
worth 3 overlays (func_80012ABC 3, func_8012F14C 131). The cheap win was the one I ranked
third. §75a's "collect across the whole sweep before scoping" earned itself immediately.
- NEXT (specified, not guessed): func_80174CB0 is class B on func_8012F14C (1944 `(s32)` vs 968
`(s32,s32,s32)`). The macro carries the 3-param prototype; the failing TU declares the 1-param
one FIRST (ov_SC01_001: TU@328 vs instantiation@2616) -> two prototypes, different arity ->
reject. Per cdecl.compatible's MEASURED rule a K&R `extern void func_8012F14C();` is accepted
BOTH ways round here (prototype-first + `()`-second always; `()`-first + prototype-second when
no param default-promotes, and s32 does not) -> it should satisfy both populations in either
order. One-line probe on the carried decl, byte-gate the 3 members, then extend.
- THE NORMALIZATION PAID: one `dedup_extend --binaries <the 134 excluded>` banked 134/400
planned -- func_8014F3E8 VERIFIED in ALL 134 -> ×138 total (+4,288 ins), no drafting at all.
A 4-overlay island became full fleet reach because the carried extern finally agreed.
- FLEET: instr-weighted 80.0% -> 80.1% (10,509,526 -> 10,525,534 = +16,008 ins, exactly the
projected 84×138 + 32×138); fn-count 89.02% -> 89.09%; distinct-code 67.7% (unchanged, as
expected -- propagation moves coverage, not distinct-RE). dedup 1884 -> 1886 validated / 0
failed, C1 coverage 239,315/239,315. 0 NON_MATCHING (G4).
- R22 clean-fleet: make clean && extract-all && check-all -> 140 passed, 0 failed of 140.
- §75a — "PROPAGATION-CAPPED" IS AT LEAST THREE CLASSES, and the classifier names which:
A minority spelling `conflicting types` + a lopsided census (1710 vs 4) -> normalize, cheap
B genuine arity split same message, TWO real populations (func_8012F14C: 1944 `(s32)` vs
968 `(s32,s32,s32)`) -> the §29 loose-typing wall; a K&R `()` MAY satisfy
both but is order-dependent -> PROBE, do not normalize on a guess
C missing extern `undefined reference to 'SHB'` -- a LINK error, unrelated to types
The discriminator is one grep (census the symbol cc1 named) and it decides the remedy.
- R14 self-correction recorded: I predicted func_80174CB0 was "the identical class". It is class
A in KIND but on DIFFERENT symbols, and different ones per overlay (func_80012ABC at
ov_SC01_000 where the minority is on the TARGET side; func_8012F14C at ov_SC01_001 = class B).
One member's error names one blocker, not the blocker set -- collect the classifier's line
across the whole sweep before scoping a fix.
- func_80174CB0 (×3) and func_80165CA0 stay capped, each now with a named cause and a named next
probe -- not a wall verdict.
- func_8014D4C0 (84 ins) PROPAGATED ×138: all 138 overlays rebuilt byte-identical, group
E_func_8014D4C0 registered. 84×138 = 11,592 ins.
- func_8014F3E8 (32 ins) propagated ×4 only (the ov_SC07_{006,007,010,011} island), 134
overlays excluded one at a time.
- TWO FINDINGS, both measured:
(1) THE FIRST RUN'S "drop" WAS A FLAG OMISSION, NOT A WALL. Without --recover,
dedup_propagate takes the historical all-or-nothing path on the first culprit overlay,
so ONE divergent member cost the whole group (×0). With --recover, Part A excludes just
the culprit -> ×4 instead of dropped. Always pass --recover on a targeted --addr run.
(2) THE EXCLUSION CAUSE IS A MINORITY-SPELLING SOURCE OVERLAY, not byte divergence. The
sigs prove all 138 members share ONE h_exact (2ccf344d), so nothing diverges in bytes.
The macro carries the source overlay's `extern void func_8014F468(void);` while the
fleet census is 1,710 `extern s32` + 134 `s32` definitions vs 20 `extern void` + 4
`void` definitions -- and all 4 `void` definitions are ov_SC07_{006,007,010,011}, i.e.
the source overlay I banked from is the OUTLIER. The macro inherited the minority
spelling and silently capped its own reach at that island.
- => the fix is NORMALIZATION (24 occurrences), not a reconciliation engine; the follow-up
commit flips the SC07 minority to the fleet-canonical s32 and re-propagates.
- R22 clean-fleet: make clean && extract-all && check-all -> 140 passed, 0 failed of 140.
- MATCH (59 ins), real-TU verified by the agent before handing back (cc1 rc=0, 59/59, 0 diffs).
- Propagated x138 with ZERO exclusions -> confirms the ×3 cap on func_80174CB0 was purely the
carried-extern collision: a body with no externs propagates clean.
- R22 clean-fleet 140/140, 0 failed. dedup-check 1884 validated / 0 failed, C1 coverage complete.
- FLEET CROSSES 80.0% instr-weighted (10,509,526 / 13,141,652); fn-count 89.02%; distinct 67.7%.
- THE LEVER (cookbook §70): residual was ONE instruction, addiu $t0,$t1,0xC vs $t0,$a0,0xC -- a giv
based on a copy of the param. Reading gcc-2.7.2 loop.c/cse.c proved the natural form can never
emit the target: cse.c:make_regs_eqv makes the copy canonical (it out-lives a0) and
loop.c:update_reg_last_use won't extend a0's last-use (giv-init UID >= max_uid_for_loop). Fix:
walk the PARAMETER itself, so record_initial sees the biv init as hard reg (reg:SI 4),
valid_initial_value_p accepts it (precondition: no calls), and emit_iv_add_mult bases the giv on
$a0 -- yielding both required instructions free.
- META: this compiler-source reasoning was done by an ORDINARY Opus 5 drafting agent, unprompted --
the tier Phase 23 reserved for Fable5. One data point, recorded as such; the cheap action is to
give routine drafting agents the gcc source path.
TWO mislabels in one tool, both found by making it print what the compiler actually said.
1) compiles_standalone() returned a bare False and the caller filed EVERY failure under
"overlay-local TYPE (the real cap)". The dominant real cause is undeclared FILE-SCOPE EXTERNS.
Now returns (ok, stderr) and the skip is classified by actual cc1 output.
2) find_site()'s backward walk over "preceding contiguous externs" skipped BLANK lines but not
COMMENT-ONLY lines, so a full-line /* ---- */ between two extern groups dropped every extern
above it. Comment lines are now skipped like blanks and filtered out of the emitted body so
make_macro never meets a `//`.
RESULT, measured honestly: func_80174CB0 went from "not self-contained" to a 138-member PLAN, but
--recover banked only x3 (ov_SC07_006/007/011); 135 overlays excluded. Those exclusions are NOT
byte divergence (all 138 share h_exact) -- they are the CARRIED EXTERNS colliding with each target
overlay's own decls. The carry is necessary but not sufficient: it must reconcile per-target-TU
(cdecl.compatible(), the shape reconcile_tu already uses). Spec updated in CURRENT_PHASE.md.
- R22 clean-fleet 140/140, 0 failed. dedup-check 1883 validated / 0 failed, C1 coverage complete.
- fleet instr 79.9% (10,501,384 / 13,141,652); +246 ins from the x3.
- WHY THIS MATTERS beyond the numbers: the Phase-21 backlog already prescribed "macro-extern-
injection frees them x134 (~+0.3%)" and it was never built, because the mislabel told every later
session these were the known-hard type wall. A wrong diagnostic label cost ~4 phases.
- cookbook §68. NOTE the exclusion message is ALSO mislabelled ("byte-diverge / irreconcilable"
conflates differing bytes with a non-compiling instantiation) -- logged to fix.
- func_8012B4B8 (84) + func_80169228 (105) propagated via targeted --addr (--check-only first,
never --auto-from): 138 overlays byte-identical, 2 new dedup groups, ~+26,082 ins.
- R22 clean-fleet: check-all 140 passed, 0 failed of 140. Fleet fn-count 88.90 -> 88.98%.
- The 3 non-banks are diagnosed, not guessed (blocker_probe, both oracles agree): func_801463A0 is
a real-cc1 MATCH in its own TU that the gate still rejects (§65c rtu-vs-gate divergence, link-level);
func_80156670/func_80174CB0 carry "drop when banking" typedefs textually identical to the canonical
ones. Blockers STACK — stripping the cc1-named typedef exposed the next (S8->B8; MATRIX->a callee
conflict). Remedy named: strip ALL shared-provided typedefs, then run the DRIVER's ladder.
- Targeted `dedup_propagate --addr 0x80177940 --recover` (NEVER --auto-from; --check-only first
confirmed the plan held exactly this one address, so the de-macroize hazard could not apply).
- 138 overlays rebuilt byte-identical; 0 stubs remain for the address; 1 new dedup group registered.
- R22 clean-fleet: check-all 140 passed, 0 failed of 140.
- Fleet: fn-count 88.86 -> 88.90%, instr-weighted 79.6 -> 79.7% (+13,938 ins = 101 x 138),
distinct-code 64,874 -> 64,875 unique fns.
- 5 of the 6 s15 fresh cores propagated ×138 (func_801483E8/8014680C/8017129C/80177AD4/801759D8;
func_8014A51C §20-capped). R22 clean-fleet 140/140. fn-count 88.66->88.86%, instr 79.4->79.6%,
distinct-code count 64854->64860, dedup 1879/0.
- EFFICIENCY AUDIT (decision-log): the 2 LLM waves ran 92% match_one MATCH but only ~27% whole-binary
bank; 6 spot-checked non-banks are ALL match_one MATCH (byte-correct bodies). NOT a missing idiom —
an INTEGRATION wall (def-side sig / data-extern / unshared struct). We strand ~16 paid-for correct
functions per wave; a fleet-safe integration-recovery pass would ~3.7× yield for 0 new drafting
tokens. Next investment = integration tooling, not more drafting. Waves held per Drew.
The grinder ran the targeted permuter sweep to EXHAUSTION (all 75 permuter-shaped candidates;
correctly skipped 1575 redraft/structural/integration). It banked 29 distinct functions autonomously
(gate_stage commit=True, byte-gated, fail-closed, §55b un-propagated), 39% conversion.
- All 29 are LOW-REACH (1-5) overlay-unique code in the 0x8017-0x8018 range — confirming the map's
finding that the permuter-admissible set is the low-leverage tail (the high-reach near-misses like
func_8014F3E8 close=1 reach=134 are redraft/structural, NOT permuter-shaped).
- Propagation of the 22 reach>1 banks filled only 1 (0x80180710 ×2); the rest are genuinely
overlay-unique (siblings byte-diverge) — as predicted.
- R22 clean-fleet 140/140 (the 27 overnight per-binary-gated commits verified fleet-wide, §61).
- distinct-code 64837 -> 64854 (+17 unique fns); session total +22 unique (wave +5, permuter +17) —
the first real distinct-code progress in many sessions. instr 79.4%, fn-count 88.66%, dedup 1874/0.
Of the 6 s14 fresh cracks, func_80136F3C propagated ×138 (func_801749C8 dropped as an
ov_SC07_006 straggler; 4 are §20 local-type-capped — future uniquify fodder, low-value
de-duplication per the SESSION-14 finding).
THE POINT (byte-verified): distinct-code UNIQUE count rose 64832 -> 64837 (+5) — the FIRST
distinct-code movement all session. Every other lever today (154-type lift, 6 uniquify cores,
MATRIX rename) was de-duplication and moved distinct-code by 0. These 6 are genuinely UNMATCHED
cores, so banking them ×1 is real new coverage. Percentage is flat (67.6%, denom 87459) but the
direction and the count are the validation the pivot to fresh cracks was correct.
Fleet: instr 79.3 -> 79.4% | fn-count 88.61 -> 88.65% | distinct-code count +5 | dedup 1873/0.
R22 clean-fleet 140/140 BYTE-IDENTICAL.
- Propagated 0x8012A464 / 0x8014FFDC / 0x801502EC -> 138/138 byte-identical, 0 stragglers, 3 new
groups. R22 clean-fleet 140/140; dedup 1872/0; C1 237654/237654.
- FINDING (R14/R31): the §20 propagation cap was gating source-level DE-DUPLICATION, not coverage.
The whole uniquify campaign (Buf+MATRIX+Vec8, 223 files renamed, ~1559 copies stripped, 5
propagations, 4 R22 cycles) moved the fleet by +6 functions / +558 ins / -6 stubs and 0.00pp on
all three headline metrics. The freed cores' members were ALREADY matched individually;
propagation just consolidated them into shared macros. "Unblocked" != "unmatched".
- SESSION ATTRIBUTION: of -837 stubs / +0.3pp instr / +0.23pp fn-count, -831 stubs came from the
FIRST batch (broad lift -> 13 cores). The uniquify campaign contributed -6.
- Roadmap B4 re-labelled: a maintainability item, not a coverage lever. Remaining camps
(Handler/Blk8/V8/Prim/Prim_8016E7C8) are small and now known low-yield — opportunistic only.
- distinct-code sat at EXACTLY 3811442/5634875 = 67.6% at open and close. Fresh cracks are the sole
mover of that number; point the next session there.
Two units, committed together because they touch overlapping overlay .c files.
- PROPAGATE: 0x8012E778 (freed by the MATRIX uniquify) -> 138/138 byte-identical, 0 stragglers,
1 new dedup group.
- Vec8 UNIQUIFY+LIFT: camp1 {s16 unk0,unk2,unk4,unk6} (8 bytes) x139 files -> Vec8_c1; the 180-file
{s32 w[8]} (32 bytes) majority keeps the name. These are two genuinely DIFFERENT types that had
been sharing one identifier across TUs of the same overlay — the case §64a exists for; reconciling
them to one layout would have merged a 32-byte and an 8-byte struct. Both camps lifted, 319 local
copies stripped.
- Pre-filtered on an overlay from each camp, then R22 clean-fleet 140/140 BYTE-IDENTICAL.
- Blocked core queue 10 -> 7 (0x8012a464, 0x8014ffdc, 0x801502ec freed). Session arc 13 -> 7 via
uniquify (Buf -> MATRIX -> Vec8). Remaining camps all small: Handler, Blk8, V8, Prim, Prim_8016E7C8.
MEASUREMENT CORRECTED THE PLAN. The checkpoint called for a "per-camp field-access reconcile";
measuring the camps refutes that: Vec8 = {s32 w[8]} (32B) in 180 files AND {s16 unk0..} (8B) in
139 files; MATRIX 48B/32B/32B; Buf 16B / 0x20+ / DrawEnv. These are DIFFERENT types sharing an
identifier across TUs of the same overlay — reconciling to a canonical layout MERGES them, the
same failure that broke 103 binaries on Prim. The right op is UNIQUIFY: rename the non-majority
camp (byte-neutral — a type name emits no code; TU-local by construction), which makes every camp
single-def and liftable by the existing lift_types rules.
- NEW tools/uniquify_type.py: deterministic camp ordering (file-count desc, then normalized text,
so re-runs assign the same suffixes); majority keeps the name, camp n -> <T>_c<n>; rewrites ONLY
files that DEFINE that camp (a file that merely USES the name gets it elsewhere and is untouched);
\bT\b word boundaries so `Buf` never matches `Buf80153978`.
- VALIDATED on Buf (578/6/1 files): 11 identifiers across 7 files -> 3 camps LIFTABLE -> lifted
(585 local copies stripped) -> R22 140/140 -> blocked core queue 13 -> 11 (0x8012ea90, 0x801749c8
freed). Propagated 0x8012EA90 ×138; 0x801749C8 dropped (straggler in ov_SC07_006).
- YIELD, HONESTLY (P9): ZERO new matched functions. fn-count 88.61% / instr 79.3% / stubs 40281 all
UNCHANGED; dedup 1867->1868, C1 +138. 0x8012EA90's members were ALREADY matched in all 138
overlays — the propagation consolidated duplication into one shared macro (DRY), not coverage.
The value is the PROVEN RECIPE + the queue moving 13->11, not the numbers.
- dedup_propagate (R32): the skip line printed a COUNT and no names, and aggregated three unrelated
causes into n_local — a body skipped merely for a `//` comment (macro-unsafe, 1-line fix) read
identically to one genuinely using an overlay-local type. Now named and split by cause.
- cookbook §64a (uniquify-vs-reconcile + the validated recipe + remaining camps by cost).
With the §20 local-type cap lifted (commit:0863), dedup_propagate --auto-from planned 17
self-contained cores that were previously skipped "not self-contained (local types)".
- BANKED: 12 cores via --auto-from + func_80175308 (propagated separately, 138/138) = 13 ×138.
func_80175308 is the PROVABLE unblock — the core the SESSION-13 checkpoint named as
local-type-blocked. No claim is made that all 17 were unblocked by the lift; measuring that
needs a pre-lift re-scan I did not run (P9).
- 5 correctly DROPPED as cross-overlay stragglers (0x8012A018, 0x80172C50, 0x80173A60,
0x80144090 in ov_SC01_000; 0x801495C4 in ov_SC07_006): h_exact sharing is all-or-nothing and
those overlays' bytes diverge. --recover NOT used (the documented quadratic thrash hazard).
- GATES: R22 clean-fleet 140/140 BYTE-IDENTICAL (2nd full cycle this session); make report green;
dedup-check 1854 -> 1867 validated / 0 failed, C1 236964/236964; 0 NON_MATCHING (G4).
- FLEET: instr 79.0 -> 79.3% | fn-count 88.38 -> 88.61% | INCLUDE_ASM stubs 41112 -> 40281 (-831).
distinct-code stays 67.6% — correct: propagation replicates already-distinct-matched code;
only a fresh crack moves that number.
- STILL BLOCKED: 13 cores "not self-contained (local types)", blocked by exactly the 8 deferred
VARIANT entities (MATRIX 3-def, Buf 3-def, Vec8, Prim, Handler, Blk8, V8, Prim_8016E7C8).
Next lever = a per-camp FIELD-ACCESS RECONCILE, not a lift (lifting them blindly is what broke
103 overlays earlier this session).
Propagation of the 7 fresh-138 cores banked in commit:0855. Only the 2 self-contained
ones cleared all three integration walls:
- func_80130C08 x138, func_80137178 x138 (+274 stubs). R22 clean-fleet 140/140.
The other 5 are blocked, each by a different integration wall (drafting was solved —
all 7 bodies byte-matched; INTEGRATION is the bottleneck):
- func_8012B4B8/func_80175308/func_8012E138/func_8012A1BC: §20 local-type
propagation cap ("not self-contained") — need build_engine_types type-lift to
propagate x138 (roadmap B4; ~+552 stubs when unblocked). Stay x1.
- func_80169228: per-member divergence (whole SC03 cluster byte-diverges) — a
genuine partial family; --recover thrashes it (killed + reverted). Stays x1.
decision-log: fix_header_decl fragility correction (shared multi-caller decls break;
gate_stage's call-site-cast is the integration spine, not header-decl rewriting).
Bounded probe (SESSION-13, token-free) that REVERSED the same-session "fresh
reach-138 well is spent" verdict. Target func_8014CD80: 138 live, 0 matched, NO
DEFINE macro, a universal body (only universal callees + param offsets, zero
overlay-local D_* refs), clean MATCH draft from batch-1.
- Blocker was a def-side header decl: engine_core.h DEFINE_func_8014CD0C()
forward-declares it `void func_8014CD80(s32,void*,void*)` while the byte-true
def is `int func_8014CD80(s32,u16*,u16*)`. gate_stage's arity pre-pass is
param-COUNT-only (misses return/ptr-type); §54 reconcile_def_sig fixes the
wrong direction.
- One byte-neutral header edit (void->int, void*->u16*; call site passes u16[3]
arrays + ignores the return -> codegen unchanged) -> harvest_verify banked x1
BYTE-IDENTICAL -> dedup_propagate --addr propagated 138/138 overlays
byte-identical (live 138->0) -> R22 clean-fleet 140/140.
- Fleet 78.7->78.8% instr, 88.22->88.26% fn-count from this one family;
tools-health green (dedup 1851/0).
Quantified market (decision-log 2026-07-23): of the 75 fresh (>=100-live)
families, 46 carry an engine_core.h caller forward-decl, 38 SIMPLIFIED = the
func_8014CD80 pattern -> each a candidate x138 (~+1.5-2.8pp instr). NEXT: build
tools/fix_header_decl.py + a fresh-family wave. func_80165CA0's 0/135 was a
non-universal BODY (different failure mode), not this blocker.
Propagation of the 6 batch-1 x1 banks (§55b: banks committed first in commit:0848,
then targeted propagate as a standalone step):
- dedup_propagate --addr: func_801325B8 -> +3 onboarded-tail siblings
(ov_SC07_007/010/011). func_8014A048/func_801678F0 byte-diverge in the SC07
cluster (kept x1); func_8014FE60/func_80167540 local-type-blocked §20 (x1).
- func_80165CA0: consolidated its h_exact subgroup (dedup group registered, +0
new), then family_sweep --hseq 0/135 — a PER-MEMBER WALL (cf func_80133AB0
0/136). The x135 "fresh family" prize does not exist here.
- Net batch-1 yield ~9 newly-matched functions; fleet 78.6->78.7% instr, distinct
flat; ov_SC07_006 84.6->84.8%. R22 clean-fleet 140/140; tools-health 1850/0.
The finding (R14/R35, decision-log 2026-07-23): nins*reach leverage over-counts —
rank by LIVE-siblings. build_wave_args.py --rank live now ranks by the true lever
and reports the fresh(76)/onboarded-tail(44) split. The reach-138 family well is
largely SPENT via wave+gate; the fresh families are the hard tail (def-side
plumbing/DIFF/per-member walls), not free x138 fuel.
THE BUG (tools/gate_stage.py main(), introduced commit:0181, 2026-06-21, Phase 21 T3):
good_sha=a.good_sha or DEF_SHA, # DEF_SHA = ov_SC01_077's locked hash
DEF_SHA is TRUTHY, so it beat run_gate's per-binary lookup
(`good_sha or _check_sha(binary) or DEF_SHA`) and made that lookup DEAD CODE on
every CLI invocation. gate_stage therefore BUILT one binary and compared it to a
DIFFERENT binary's hash: it can never match, every draft reports as "near", and
NOTHING COULD EVER BANK outside ov_SC01_077 from the CLI. A "near" is
indistinguishable from a genuine codegen residual, so the failure looked like a
compiler wall for a month.
WHY IT HID: the programmatic callers take a different path and were all correct —
grinder/idiom_hunt pass good_sha=None (per-binary lookup), lora_grind/bulk_harvest
pass an explicit per-binary sha, orchestrator is 077-only where DEF_SHA is right.
That is exactly why the grinder banked func_80181F78 in ov_SC03_014 (Task 13B)
while my CLI ladder banked 0/10 on the same tree. Two paths disagreed for a month
and nothing compared them (R34's lesson, from the inside).
BLAST RADIUS, MEASURED (not assumed): 0 of 6,708 backlog records come from the
affected path — by source: worker 2724 / bulk-harvest 2275 / lora-grind 766 /
grinder 522, all correct. THE BACKLOG NEEDS NO RE-RUN. The void verdicts are the
manual CLI gates on non-077 binaries, i.e. exactly the Task-5 wave's "the gate
banked ZERO" on 12 preserved cracks — never a codegen finding at all.
FIXED: pass a.good_sha through; run_gate reads config/check.<bin>.sha (R33).
VALIDATED end-to-end: the raw draft that produced {banked:0, near:1} now gives
{banked:1}.
RE-RUN RESULT — 7 of the 12 preserved t5wave cracks are now banked:
func_8018F694 (478) · func_8019059C (673) · func_80135A4C (181) ·
func_80135888 (113) · func_80135D20 (100) · func_801749C8 (105) ·
func_801299C8 (158, was filed "PLUMBING: prototype declaration")
STILL BLOCKED (5, believed genuine): func_8012AAAC, func_80135260, func_801365B8,
func_80165CA0, func_80191C50.
⚠️ SUPERSEDES the earlier retraction: the "0/10 ladder" was not vague interference
— it was the gate comparing against the wrong binary's hash. Task 14 stages 2-3
were priced against a number that could only ever have been zero.
- R22 clean-fleet 140/140 BYTE-IDENTICAL; all 6 verified stub-free
Drew T