The new head plumbing class after the symbol-kind fix: `conflicting types for func_80175414` (27
member-rows). Byte-true DEF is `void func_80175414(s32 _arg0)` (its DEFINE_ macro). The fleet
declared it 1,845 times in four spellings, of which three are the SAME TYPE (parameter names do not
participate) — the outlier was 28 sites declaring `(void)`.
conform_decls REFUSED the naive conform and was right to: 29 ZERO-ARG CALL SITES exist across 28
files, so conforming the declaration alone turns each into `too few arguments` — a fleet-wide
COMPILE break the per-binary gate cannot see (the tool cites 138/140 binaries, measured). It named
the count, the consequence, why the cheap check misses it, and the flag that repairs it, then
forced the two-step: --cast-zero-arg-calls (29 sites cast to the 0-arg fn-ptr shape, §17a-1 — gcc
folds the cast of a known symbol to a direct jal, so it is codegen-neutral), then the conform.
Result: 1,845 declaration sites rewritten across 1,061 files, 0 non-canonical remaining (axis
complete, R32). R22 clean-fleet: check-all 213 passed / 0 failed of 213.
WORTH RECORDING AS A TOOLCHAIN STANDARD: this is the instrument that has not wasted a cycle today.
Every other one reported SUCCESS over a defect — a classifier that discarded every gcc-2.7.2 hard
error (no `error:` prefix), a diff that miscounted 116 data-bundled .s files, a --verified-out
truncated to zero bytes over 62 real banks, a --band default that reported "0 families" on a real
135-member family, and a scope stamp describing the filesystem instead of the run. conform_decls
reports FAILURE with a repair path. A guard must state its COVERAGE, not just its verdict; the
in-repo exemplars are this tool and the §53 jr interlock.
scope_data_fix detected conflicts by SCANNING TU TEXT, which cannot see a MACRO-INJECTED
declaration — and that is where these conflicts live: `extern Vec8 D_80114F24;` sits inside a
DEFINE_func_* macro body in engine_core.h while the overlay .c holds only `DEFINE_func_XXXX()`.
That declaration is a genuine file-scope decl of every TU invoking the macro, and it is what the
draft collides with.
Fix: family_sweep builds a per-TU map from cdecl.tu_scope (cpp-derived, cached — 467 data decls in
ov_MAIN_012 vs 0 findable by text scan) and passes it to scope_data_fix, which now takes an
optional tu_types. tu_scope is the repo's stated oracle for "what does this TU declare", and its
own docstring warns that the `above` form answers VISIBILITY, not CONFLICT — C requires
compatibility regardless of order. scope_data_externs was built on that wrong question.
Banked 5 -> 31; failures 730 -> 699. The whole data-symbol class is gone: D_80114F24 (12),
D_800AE620 (10), D_80126B58, D_80078EB4, D_800183E0 all cleared.
R22 clean-fleet: check-all 213 passed / 0 failed of 213.
REGRESSION I CAUSED, AND FIXED: the reclassification showed 9 fresh `conflicting types for
aD800B9A02` — my own alias colliding. The group-level path suffixes the alias per function
precisely to prevent this; scope_data_externs did not, so two drafts aliasing one symbol declared
`aD800B9A02` twice with different types — re-creating the collision one level down. Both paths now
use _alias_name(sym, func). Verified: distinct names, each keeps its own type, both bind the real
symbol via the asm label.
The one-line fix committed ahead of this run (CdFileLoc_80128C98 aliasing CdFileLoc) cleared the
largest remaining propagation-sweep class. Re-sweep: 138 member-matches banked, failures 875 -> 737,
`conflicting types for cdFileLocTable` gone entirely (136 -> 0).
Derived net (138 INCLUDE_ASM removed, 0 re-added) equals the report's 138 — they agree.
R22 clean-fleet: check-all 213 passed / 0 failed of 213.
Fleet 94.2 -> 94.3% instr / 87.9 -> 88.1% distinct / 96.15 -> 96.21% fn-count; stubs 13,780.
Residue reclassified — no symbol dominates any more: 227 PLUMBING-other, 125 DIFF (real byte
divergence, 17%), 93 CC1-FAIL(no-diagnostic), 26 memcpy, then a tail of small data-symbol
conflicts (D_80114F24 12, D_800AE620 11, D_800183E0 9, D_80126B58 6, D_80078EB4 6).
CC1-FAIL rose 77 -> 93 and that is NOT a regression: members that previously died earlier on the
cdFileLocTable conflict now reach a different compile error. Those 93 are hard gcc errors whose
text the sweep's classifier discards because it greps for `error:`, which gcc-2.7.2 never emits on
hard errors. That classifier is now the highest-value instrument fix left — three times today a
no-diagnostic verdict concealed something cheap.
Task B, re-scoped from evidence. The 129 dedup_extend failures are 106 conflicting-types /
21 CC1-FAIL / 4 undefined-ref / 3 DIFF — real byte divergence is 2%, and memcpy is 17 of 106,
not the story. Direction reversed too: the byte-true DEF of func_80128ED8 is what the target
.c files already declare; engine_core.h's macro-local extern was the stub-era guess.
Conformed 8 axes to byte-truth (func_8012F14C 2843, func_8012E5CC 2052, func_8012F038 2214,
func_8014C568 1816, func_80128ED8 1524, func_8012C750 406, func_8012C0EC 50, func_80144A04 25).
R22 clean-fleet: check-all 213 passed / 0 failed of 213. Zero functions banked by design.
Tooling (R33/R35) — three guards that asserted completeness over a narrowed population:
- NEW tools/macro_draft.py: a deduped fn has no definition in any .c (body lives in a DEFINE_
macro), so conform_decls had been refusing the largest class it was built for.
- conform_decls skipped engine_core.h wholesale as "a defining TU": 10 stale externs survived
while 1,514 fleet sites moved, and it still printed "axis complete". Skip now scoped to the
defining macro's span.
- Return-axis compare was literal: typedef int/s32 and a missing `extern` faked a return change.
Now compares normalized types.
- §85 consumer scan under-reported (the dangerous direction): a cast between `=` and the call
hid `s0 = (s32 *)func_80144A04(...)`. Now classified by position, validated both ways.
Corrections to my own predictions (R14): the documented scalar-narrowing hazard was benign
across 2,052 sites; the breaks were arity (6 call sites, fixed with §17a-1 fn-ptr casts) and
the consumer-guard gap. A header-only first probe broke ov_SC01_000 — §85 is literal.
Not done, named: memcpy (builtin codegen), ApplyMatrixSV (no DEF), gte_SetRotMatrix (link bug),
func_80147364 (unparseable macro), D_800AE620/D_80126CC4 (data axis). Cookbook §159.
The S45p9 blocker is closed, and the recovery loop that kept it from finishing is rewritten.
- BANKED: dedup_propagate --auto-from ov_SC02_037 --recover -> 29 functions propagated,
141 overlays byte-identical, dedup 1920 -> 1949 groups, member instances 246,284 ->
249,099 (+2,815). make clean && extract-all && check-all -> 213 passed / 0 failed (R22).
- WHY IT FINISHED THIS TIME: gate_all -> gate_failures returns EVERY failure from the sweep
that already computed them, and the recovery loop resolves them all per round. Converged in
3 rounds; the old one-overlay-per-sweep design needed ~138. That reframes the S45 run — it
was not nearly done when it died, it had barely started.
- Batching did NOT cost capability: per-overlay necessity probes excluded four of the nine
culprits from only the 9 overlays that needed it (not all 138), and ov_SC07_006 was
RECOVERED by the Part-B caller-extern reconcile instead of excluded.
- Plan phase parallelised: 5 min -> 26 s, plan + skip classification byte-identical. Its
compiles_standalone temp file is per-call now — the fixed `t.c` was the same fake-isolation
class as match_one's shared --work dir (P28 T5), latent until something ran it in parallel.
- docs/accelerators.md (NEW, Drew 2026-08-07): the reusable-workflow ledger — what we learned
late that a future decomp should know on day one, each entry with when we found it, when it
WAS findable, what it cost, and the honest prerequisite where one exists.
ROOT CAUSE of the 141/213 breakage earlier this session (correctly derived this time;
my first attribution to F1 was WRONG -- no arity journal ever touched func_80146A6C and
the arity undo reported success):
dedup_propagate --recover's Part B reconciles a conflicting caller extern and
DELIBERATELY leaves the edit on disk when it buys the byte-match ("keep the reconcile
on disk"). Correct while the fn survives -- but a fn can still be dropped by a LATER
iteration against a different overlay, and when the plan finally emptied, the
"all candidates dropped" sys.exit fired with NO restore. Reconciles kept for
ov_SC07_001..009 were orphaned: no-proto'd caller externs for functions that were
never propagated -> ov_SC07_010 "passing arg 2 of func_80146A6C makes pointer from
integer" -> 141 of 213 binaries failed check-all.
The byte-gate never mis-banked (it fails closed). The real cost was VERDICT VOIDING:
every subsequent gate reported "near" against the broken tree, so two whole batches
(4/4 and 20/20) were mis-read as draft failures when they measured the tree (R35).
FIX: a reconcile LEDGER. Every kept reconcile is recorded against its fn, undone the
moment that fn leaves the plan, and ALL outstanding reconciles are restored before the
failure exit -- so a failed propagation leaves the tree exactly as it found it.
HONESTY: the fix is IMPLEMENTED AND REVIEWED BUT NOT YET PROVEN. The negative control
aimed at the exact failing propagation SUCCEEDED instead (different tree state), so the
guarded path never executed. A targeted test of the ledger is still owed.
Also lands the propagation that control performed: func_8015C030 x7 overlays
(func_80168B70 excluded from 4 SC07 overlays, survived elsewhere). check-all 213/213.
The two functions the roadmap has carried as PERMANENT WALLS since Phase 24 are matched in all 138
overlays. Neither needed a siege. Both matched from drafts ALREADY ON DISK.
func_80178004 165 ins x 138 = 22,770 Phase 26: Fable5, ~477k tokens, "intrinsic 3-integer
regalloc wall". THREE stored drafts report match_one
MATCH today; one banked first try, no new work.
func_801412A8 198 ins x 138 = 27,324 close=29/110 since Phase 24. Matched from 1 of 31 stored
drafts + the §37/§124 alias.
WHY func_801412A8 LOOKED INTRINSIC (worth understanding — match_one is structurally blind to it):
the TU declares `extern int func_801412A8(int,int,int,int,int,int)` and its callers USE the return
(`param_1 = func_801412A8(...)`), while the byte-true definition is
`Prim_1412A8 *(Prim_1412A8 *, int, int, int, u16, u16)`. Narrow params cannot agree with an `int`
prototype and the no-prototype escape is illegal once a param promotes, so NEITHER side can move --
and the resulting byte difference is in the CALLERS, which match_one never compiles. The §37/§124
def-side asm-label alias decouples them: the TU decl keeps governing the call sites (codegen
untouched), the definition keeps its byte-true signature.
THEN PROPAGATION RETURNED 0/137 TWICE, both times a missing TYPE, not codegen:
family_remap's `_carry_macros` carries file-scope #defines but (a) NOT typedefs, and (b) is NOT
TRANSITIVE -- it brought addPrim_1412A8 and stopped, though that macro calls setaddr/getaddr and
getaddr casts to PTag_1412A8. Lifted Env_1412A8 / PTag_1412A8 / Prim_1412A8 + OT/getaddr/setaddr
into src/shared/engine_types.h (inside the include guard) -> 137/137, 0 failed.
MY ERROR, CAUGHT BY THE GATE: I lifted the typedefs but did not STRIP them from ov_SC01_077.c, so
they were declared twice and gcc-2.7.2 rejects a repeated typedef even when identical -- the lesson
already recorded at the foot of engine_types.h. R22 came back 139/140 with [FAIL] ov_SC01_077 (the
exemplar's own overlay). Stripped, re-verified, 140/140. A proper lift strips the source;
build_engine_types --strip does both and I did it by hand.
Also a measurement error worth recording: I checked whether the draft defined Prim_1412A8 with a
plain `grep -c` -- which matches inside `addPrim_1412A8` -- and briefly concluded the carry worked.
Substring false positive; the same shape as reading a `return` as a declaration.
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140.
Fleet 12432941 -> 12483035 instr (+50,094 -- EXACTLY the two giants x138); fn-count +276;
instr-weighted 94.5% -> 94.8%. audit-digest OK. 0 NON_MATCHING (G4).
THE RULE THIS BUYS: re-measure a wall before respecting it, and SCAN every stored draft rather than
sampling (my first pass checked 8 of 31 and reported "closeness 40" for a function whose MATCH was
in the 9th). Four minutes of re-measurement was worth 50,094 instructions.
Measured the h_exact free pool from the bytes rather than trusting the frontier report's
numbers (R14 — its whale claim was 3/4 wrong: it said the whale was open in all four SC07
overlays; three were already banked and I closed the fourth earlier this session).
MEASURED: 215 open function-instances / 8,763 instructions are byte-identical (h_exact,
including reloc payloads) to an already-matched function. ONE class is 86% of that pool:
func_801758FC — 55 ins, same address in all 138 overlays, matched in ov_SC01_000 only,
OPEN in the other 137 => 7,535 instructions.
h_exact means identical INCLUDING jal/lui/%lo reloc immediates, so the matched body compiles
byte-identically at every member with NO remap (dedup_extend's correctness argument, §14).
dedup_propagate --addr authored it once as DEFINE_func_801758FC() in engine_core.h and
instantiated it at all 137 open sites in address order.
[ OK ] 138 overlays byte-identical after propagation; 1 new group in config/dedup.us.yaml
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140.
Fleet instr 12411467 -> 12419002 = +7,535 EXACTLY; fn-count +137; instr-weighted crosses to
94.5%. distinct-code unchanged BY DESIGN -- the class was already matched in ov_SC01_000, so
the 137 add fleet instructions but no new DISTINCT function. audit-digest OK. 0 NON_MATCHING.
Note this function had been sitting in the stored-draft backlog for ov_SC06_030 and
ov_SC07_010 and re-gated "no" earlier tonight -- because gating a DRAFT is the wrong move for
an h_exact class. The right move is propagating the already-MATCHED body. Same function, two
routes, and only one of them is free.
Remaining free pool after this: 78 instances / 1,228 ins across 32 classes.
Applied the def-side asm-label alias transform to all 971 staged member drafts (of 997; the rest
had no func_<ADDR> definition head) and gated them: 192 source files changed, ~5,985 insertions.
R22 clean-fleet 140/140 AFTER reverting ov_SC06_030 (below).
METRICS, AS MEASURED — one of them moved the WRONG WAY and I cannot yet explain it:
fn-count 96.32% -> 96.46% (+483 fns)
instr-weighted 94.4% -> 94.4% (+2,990 ins)
distinct-code 89.3% -> 89.2% (78,025 -> 77,952 uniq, -73)
A revert of ONE overlay to HEAD cannot lose 73 distinct functions, so something else is going on.
LEAD (NOT CONFIRMED): progress.py's definition scanner records the identifier immediately before the
paren (SIG at tools/progress.py:423), so an alias definition `void aF80146A6C(...)` is recorded as
`aF80146A6C`, not as func_80146A6C. That same scanner's docstring documents this exact blindness for
K&R defs, where it "silently erased ~190k banked instructions". BUT that lead does not explain why
fn-count ROSE while distinct-code FELL — they should move together under a pure naming artifact.
DO NOT treat the alias harvest's yield as established until this is resolved: the bytes are proven
(R22), the ACCOUNTING is not.
ov_SC06_030 REVERTED: `D_800AF648' undeclared in func_8017E120 — a draft that gated fine broke once
the REST of the harvest landed in the same TU (its declaration presumably displaced by another
banked draft's preamble). SECOND instance today of "per-binary acceptance is not a fleet claim"
(§61), after ov_SC07_010. In a WIDE harvest it is not even a per-TU claim, and only the clean-tree
R22 catches it. The narrow single-family run (138/138) was clean precisely because it was narrow.
Family 0x80146ab4 (18 ins, x138, PURE) had been failing 0/138 with `conflicting types for
func_80146A6C` — 208 of the ~398 conflicts in the sweep residue, its single dominant blocker.
DIAGNOSED BY READING THE DRAFT, after three levers were eliminated by measurement:
draft def : void func_80146A6C(s16 a0, s32 a1, s16 a2, s16 a3, u16 a4, s32 a5, s32 a6)
TU decl : extern s32 func_80146A6C(s32 a0, void *a1, s32 a2, s32 a3, s32 a4, s32 a5, s32 a6);
The NARROW PARAMS are the wall: C's default argument promotion means s16/u16 cannot agree with an
s32 prototype, and the `()` no-prototype escape is ILLEGAL precisely when a param promotes. Neither
declaration side can move.
- cast_call_sites: already on by default; wrong axis (fixes CALLEE decls, not the def's own).
- --normalize-self-decls: 0 banks + non-neutral reverts; wrong axis (the target's decl in callers).
- --fix-def-sig: measured 0/138, error UNCHANGED — it cannot reconcile a promoting param at all.
THE ESCAPE (§37/§124, S33-proven on func_80147364 — definition (u16,u16) vs 4,046 fleet decls,
banked x137 first try; 1,725 in-tree precedents): give the DEFINITION a private C identifier and
bind the emitted symbol with a GNU asm label, so the TU's declaration never meets the definition and
its type becomes irrelevant. Zero blast radius on every caller; byte-neutral by construction.
void aF80146A6C(<byte-true params>) __asm__("func_80146A6C");
void aF80146A6C(<byte-true params>) { ... }
RESULT: 138/138 banked, ~2,484 instructions, ZERO agent tokens. R22 clean-fleet 140/140.
.run/alias_defs.py applies the transform to a staged draft set.
NEXT: this is a CLASS lever, not a one-family fix — generalise it across the remaining sweep residue.
func_80144B9C (770 ins) was matched in 134/138 overlays and open in the four SC07s — 3,080
instructions of code BYTE-IDENTICAL (h_exact, reloc payloads included) to what was already banked,
blocked by a missing file boundary. Now banked in ov_SC07_006 / _007 / _011 for ~0 agent tokens.
R22 clean-fleet 140/140.
THE PLAN'S FRAMING WAS WRONG. This was recorded as "the SC07 carve defect (T2 Arm-A %lo +0x20)".
The carve was never broken: o0_subsplit reported `split byte-neutral` on the FIRST attempt in all
four. The real blocker is that carving the whale out of a jr file makes jr_isolate_all hoist the
parent's file-scope decls into the new region as its `ambient` set — so for the first time the
fleet's loose-typed spellings share a TU with the shared header's (`extern void *D_801274CC` vs
`extern s32 D_801274CC`). In the 134 working overlays the whale sits in a CLEAN -O0 file (common.h +
the header, nothing else) and the two never meet. Fix: drop, in that one file only, the ambient
decls the header already declares — the header being the byte-proven side.
Three iterations, each exposing the next layer of the ambient set, every one a DECLARATION:
1. data symbols (D_80126B58, D_801274CC, D_801274D0)
2. function symbols (func_801336E8, func_8005C324)
3. the alias form terminated by a trailing COMMENT, which an endswith(';') test skipped —
the §134 comment-blindness shape for the THIRD time today.
ov_SC07_010 REVERTED and left open (hence 137/138). Its split landed in an EXISTING _o0c file
rather than a fresh _o0d, producing region _jr_801457A4 whose asm dir splat never generated. It
passed its per-binary build and FAILED the clean-tree R22 — the first R22 failure of the session,
and precisely why a per-binary pass is not a fleet byte claim (§61). Committing on that per-binary
"BANKED" would have shipped a broken overlay.
jtbl_family_bank (the §53 carve path; family_sweep --hseq refuses has_mid_jr families
BY DESIGN — a 0% from the carve-less tool is an artifact, not a wall). Each sibling
individually byte-gated: carve -> extract -> remap -> whole-binary build, kept iff
byte-identical else reverted. Committed per family because jtbl_family_bank requires a
clean tree between families. R22 clean-fleet runs once over the batch.
The free-sweep "wall" was a C parse error: a remapped member body names the EXEMPLAR's TU-local
types, which are undeclared in the sibling's TU, so gcc-2.7.2 parses the declarator as an expression
and dies before ever reaching codegen. extract_unit does carry typedefs, but only ones immediately
preceding the function in the preamble — types declared elsewhere in the exemplar's TU are missed.
Rather than patch the scanner per-family, remove the class: lift every liftable local type into the
shared header once. 895 types lifted, 6,196 local definitions stripped across 1,259 files.
R22 clean-fleet 140/140.
EXCLUDED s8/s16/s32/u8/u16/u32/f32/s64/u64/f64 — lift_types classified those common.h scalars as
liftable and lifting them would have been actively harmful. The tool's own visibility guard kept 8
local defs in src/ov_SC01_077/ov_SC01_077_o0.c, which does not include engine_types.h (stripping a
type out of a TU that cannot see the replacement DELETES it, and the link error that follows names
an unrelated data symbol).
Mechanism proven before scaling: lifting just 3 types took 0x801833f0's family from 0/6 to 6/6.
Fleet 96.21 -> 96.23% fn-count / 93.8 -> 93.9% instr / 88.0 -> 88.3% distinct
(+73 unique fns). R22 clean-fleet: 140 passed, 0 failed of 140. dedup 1910/0.
THE WAVE. Re-ran S10's 17 unbanked targets (26,227 templatable ins) at LOW
concurrency in two batches of ~9 — S10's finding was that 14 of 30 agents were
SERVER-throttled, i.e. the limiter is capacity, not capability. Targets
re-derived against corpus.stubs first (R35): all 17 still live, paths verified.
25 agents, 6.87M tokens, ~2.8h. Claimed 15 MATCH; the whole-binary gate — the
sole arbiter (G3/P9) — banked 13, then family_sweep propagated 65 members across
38 overlays.
HEADLINE: func_8017D174 (793 ins) — the largest single crack of this phase. Its
agent closed two compiler-internal residuals jointly: a §137 allocno-priority tie
between &g.sz0/&g.sz1 (R=7, L=607 vs 606 -> 230/231) that spilled the wrong one
and cost a load-delay nop in BOTH switch arms, and a sched2 rotation in the
outer-loop head block that survived 470+ statement orderings. Fix was four
zero-byte asms: two `"=r"/"0"` re-ties splitting wz's live range, plus two
volatile sliders placed in a DIFFERENT basic block so they lift the live-length
count without perturbing the head schedule.
THE 4 NON-BANKS SPLIT CLEANLY (§136b — none is a wall on one attempt):
- func_8017E2EC (close=20) and func_80186E24 (close=187): honest DIFF verdicts,
real codegen residuals, ledger material.
- func_8017D318 and func_80181EE0: claimed MATCH, gate refused -> the known
match_one->gate gap, which is DECLARATION plumbing (agents cannot run the
gate, so a TU-level conflict is invisible to them). Routed to the reconcile
lane, not retired.
AGENT-REPORTED INDEX GAPS worth acting on (the flywheel closing on itself):
- no symptom key for "schedule rotation at a loop-head block that NO statement
permutation reaches" — the index's nearest line points at §76 regalloc, and
the decisive doc was gcc-2.7.2-map/sched.md, which no scheduling symptom
cross-references.
- §137 is written as a two-compile arithmetic on ONE contender pair; the real
fix here was an N-zero-byte-insn budget that ties only for N in {1,3,4} and
splits the WRONG way for N=2, so a naive "add one slider, add another" walk
silently regresses.
- no key for "gcc hoists a loop-invariant SYMBOL_REF base out of a loop the
target keeps in the `sym(reg)` macro form" (~105 of func_80186E24's 187).
Fleet 96.17 -> 96.21% fn-count / 93.8% instr / 88.0% distinct; dedup 1909 -> 1910
groups, 0 failed, C1 241216/241216. R22 clean-fleet: 140 passed, 0 failed of 140.
The head is now 5/5 classes, 18,545 templatable ins, all banked this session from
a standing start of 0.
func_801466F0 had sat since S6b behind THREE separate blockers, each of which
looked sufficient on its own to explain the failure:
1. Its definition is under a §37/§73 ASM-LABEL ALIAS (`aF801466F0` in C, bound to
the real symbol by `__asm__`), and dedup_propagate.find_site anchored its head
regex on the literal `func_<ADDR>` — structurally blind to the form, returning
None, which every caller reads as "not matched". Now reuses
family_remap._alias_decl_for rather than growing a second matcher (R33).
2. That matcher was itself blind to the WRAPPED (multi-line) declaration — the
§134 shape, third tool. Fixed by matching over the joined text and mapping the
offset back to the decl's FIRST line (extract_unit carries from there).
Regression control: the single-line form still resolves. Fleet census after:
2,768 of 2,768 alias sites resolve, 0 missed.
3. Its record type was a draft-local typedef, so the body failed
compiles_standalone. Lifted Rec801466F0 to src/shared/engine_types.h INSIDE
the include guard (the SESSION-19 double-include note) and switched both the
macro and the exemplar to it — byte-neutral, gate-proven.
Probed on ONE member before the fleet run: byte-identical 9052dc0e first try.
MEASURED, NOT INHERITED (R37): the S6b note frames the alias-regex gap as a CLASS
of missed work. It is ONE function — 91 distinct alias decls fleet-wide, the
per-line matcher resolved 90. Recording it so a future session does not scope a
phase against a class that does not exist.
cookbook §138 extended with the alias-form tool boundary and the three-blocker
story; index regenerated.
Fleet 96.10 -> 96.17% fn-count / 93.7 -> 93.8% instr / 88.0% distinct.
dedup 1908 -> 1909 groups, 0 failed, C1 241078/241078.
R22 clean-fleet: 140 passed, 0 failed of 140.
func_80147364 4,110 x137 definition-side asm-label alias
func_8016BA68 3,886 x134 dedup_extend + the MIRROR decl relax
func_8012F274 3,973 x136 hand-authored macro, source overlay excluded
func_8012A598 3,288 x138 cdecl._mask backscan fix + shared-type switch
func_801466F0 3,288 OPEN the wrapped-alias regex — measured as ONE function
THREE DISTINCT CARRY VARIANTS were hiding in one "CARRY-FIXABLE" bucket, and
only one is a tool bug (-> cookbook §138):
- a MULTI-LINE comment halts the preamble backscan -> fix the tool (cdecl._mask)
- a draft-local `struct Tag {…}` -> switch the exemplar to the SHARED type
- a file-scope `static inline` helper -> hand-author, EXCLUDE the source overlay
The third is the sneakiest: gcc-2.7.2 accepts implicit function declarations, so
the extracted body PASSED compiles_standalone with the helper undeclared and the
miss surfaced only as a whole-binary byte DIFF 137 gates later. Instantiating
that macro in the SOURCE overlay is a duplicate definition (its file-scope helper
is still there), so the shape is `--source-overlay X --binaries <all-but-X>`;
`--binaries` alone removes the source from the scan pool and errors.
TOOL BOUNDARY: once a group's members are DEFINE_func_*() sites, dedup_propagate
cannot extend it (find_site never returns a `def`). dedup_extend is the tool for
an already-macro-ized group — and `dedup_extend --check-only` across ordinary
overlays is a cheap fleet-wide wiring census (measured: exactly 1 group per
overlay, so no hidden backlog).
MEASURED, NOT INHERITED (R37): the S6b note frames _alias_decl_for's single-line
regex as a CLASS of missed work. It is not — 91 asm-label alias decls exist
fleet-wide, the regex matches 90, and the single miss is func_801466F0. Worth
3,288 ins, but a one-function fix. Correcting the expectation so a future session
does not scope against it.
Fleet 96.06 -> 96.10% fn-count / 93.7% instr / 88.0% distinct; dedup 1907 -> 1908
groups, 0 failed, C1 240807/240807. R22 clean-fleet: 140 passed, 0 failed of 140.
func_8012A598 (3,288 templatable ins) was being written off as CARRY-FIXABLE.
It took TWO fixes; either alone leaves it skipped.
1. TOOL (R33) — find_site's preamble backscan. The SESSION-18 fix handled blank,
`//`, and SINGLE-LINE `/* … */` lines, but a MULTI-LINE block comment still
halted the walk: its middle lines start with `*` and its last line ends `*/`
without starting `/*`. So the three externs above the body were dropped and
the body then failed compiles_standalone on now-undeclared data. This is the
§134 multi-line-blindness class — S6b fixed the identical shape three times in
family_remap (D1/D2/D5) and this copy was never reached.
Fixed by deciding skippability on `cdecl._mask` — the project's ONE masking
oracle — instead of on line syntax: it subsumes every comment form at once and
cannot be fooled by a `/*` inside a string, with an R32 assertion on the
length-preservation invariant it rests on. Strictly monotone (it can only
carry MORE preamble), and dedup_propagate is a byte-gate feeder, so a bug here
can fail to bank but never falsely bank.
2. EXEMPLAR — the body also declared a draft-local `struct BigCopy164` tag, which
the tool refuses by design (two macros defining one tag would redefine it in a
single TU). The shared `struct BigCopy` (engine_types.h L312) is the identical
layout and is ALREADY used this exact way at engine_core.h:16158, so switching
the exemplar to it is byte-neutral and drops the alias too.
Probed on ONE member before scaling (R37/S29): byte-identical 9052dc0e first try;
then 138 overlays byte-identical.
PROPAGATE head accounting after this: 7,398 of 18,545 ins banked (func_80147364
4,110 + func_8012A598 3,288). Still open, each with a NAMED cause and none yet
diagnosed against a build: func_8012f274 (3,973, dropped), func_8016ba68 (3,886,
4/138), func_801466f0 (3,288, the S6b D4 wrapped-alias gap).
Continues the S11 lane. Fleet 96.01 -> 96.06% fn-count / 93.6 -> 93.7% instr /
88.0% distinct; dedup 1905 -> 1907 groups, 0 failed, C1 240669/240669.
R22 clean-fleet: 140 passed, 0 failed of 140. 0 NON_MATCHING (G4).
EXTEND (SC07): the 16 volatile-blocked DIFF slots banked on retry after the
data asm-label alias -> lane total 31/36.
PROPAGATE head, measured rather than projected. .run/s8_lag.json re-split: the
checkpoint's "45 classes / 20,837 ins" is really 5 classes carrying 18,545 ins
(89%) and 41 carrying 2,316. Per-class outcome:
func_80147364 30x137 = 4,110 BANKED x137 (definition-side asm-label alias)
func_8012f274 29x137 = 3,973 DROPPED — byte-diverges in ~130 overlays
func_8016ba68 29x134 = 3,886 4 of 138 banked; excluded from ~130
func_8012a598 24x137 = 3,288 SKIPPED, cause NAMED by the tool
func_801466f0 24x137 = 3,288 no source found — the S6b D4 gap, still open
func_80147364's byte-true definition is `(u16, u16)` while 4,046 fleet decls
say `(u16, s32)`. u16 is a default-promotion type, so the `()` no-prototype
escape is ILLEGAL (the documented gcc-2.7.2 dead-end) and conforming the decl
would change caller codegen. The DEFINITION-SIDE asm-label alias gives the def
a distinct C identifier while emitting the real symbol -- zero blast radius on
every caller. Probed on ONE member first (1 build, not 137 -- the S29
discipline): byte-identical 9052dc0e first try; then 137 overlays clean.
In-tree precedent for the form: 1,725 files.
MEASURED NEGATIVE, recorded not buried: `dedup_propagate --recover` banked only
4 of 138 on func_8016ba68 and dropped func_8012f274 entirely (137 [exclude]
lines). The caller-extern reconcile that is 16/16 lifetime ON DRAFTS does NOT
transfer to PROPAGATION of these two. Cause not yet diagnosed -- probe one
excluded overlay's build output before any further attempt (§136a), do not
re-run the lever hoping.
NAMED NEXT (cheapest first): func_8012a598 skips on `missing file-scope extern
(CARRY-FIXABLE): D_801151D4, D_80126DB8_a, D_80127504` -- the SESSION-18
preamble-backscan class. Its body is 2 statements and `struct BigCopy` is
ALREADY in the shared engine_types.h (L312) with the identical statement already
macro-ized at engine_core.h:16158, so a hand-authored macro (the func_80147364
path) should take it x137 for ~0 tokens.
Process errors recorded in CURRENT_PHASE.md, all three one mechanism -- the
signal sampled is not the thing waited for: (1) a `nohup CMD &` wrapper's exit
read as the fleet check finishing (it stood at 63/140); (2) a corpus.stubs probe
mid-rebuild, which R32's coverage assertion refused rather than answer wrongly;
(3) CORRECTION to the S10 checkpoint's own rule -- `pgrep -x make` is right for
one make and WRONG for a campaign of sequential makes (it fired in a gap and
reported a live campaign done), and `pgrep -f <pattern>` SELF-MATCHES so that
waiter can never exit. Wait on the campaign process or `treelock.sh --status`.
Banked 15 h_exact members into the 4 SC07 overlays via dedup_extend, and
diagnosed the class that dedup_extend's own header records as UNDIAGNOSED.
THE 4 DIFFs ARE NOT A CODEGEN WALL. dedup_extend's correctness argument says an
h_exact match guarantees byte-identity including relocs, so a DIFF should be
impossible. Both halves of that tension resolved against the bytes:
1. The contract HOLDS. func_80162FF4's original bytes are sha1-identical in
ov_SC07_006 and ov_SC01_000 (af1aceb2...), so the registry is not lying.
2. The cause is TU CONTEXT. The SC07 host TU (_jr_8015C32C.c:1177) declares
`extern volatile s32 D_80127090/94/98` at FILE scope; none of the 134
working overlays' copy of that TU does. Volatile makes the macro's three
stores a scheduling barrier, so `addu $a0,$s2,$zero` cannot sink into the
`jal func_80146D30` delay slot -- the built body emits it early plus a nop,
one instruction longer. Measured word-for-word against the payload:
built +0x090 addu / lui,sw x3 / jal / NOP
ref +0x090 lui,sw x3 / jal / addu-in-delay-slot
All 4 DIFF macros touch exactly those 3 symbols, which is why all 4 fail in
all 4 binaries and nowhere else.
Fix: the §37/§124 DATA asm-label alias inside the 4 macros
(`extern s32 aD_80127090 __asm__("D_80127090")`) -- a distinct C identifier is
immune to any TU's declaration of the symbol, and is byte-neutral by
construction in the other 134 (same symbol, same type, same non-volatile
semantics). In-tree precedent: ov_SC06_008_jr_80135D20.c:1434.
R22 clean-fleet: make clean && extract-all && check-all -> 140 passed, 0 failed
of 140, with the 15 banks AND the alias edit in.
Remaining in this lane, both named not walled: func_80144B9C x4 (the whale --
its registry `func` field is a bare name, not a DEFINE_ macro, so write_drafts
emits a CALL; it needs the §38 -O0 shared-header route, and dedup_extend should
refuse-and-name it per R32) and func_80149954 x1 (blocked behind func_80147364,
whose u16 params make the `()` no-prototype escape illegal -- the documented
gcc-2.7.2 default-promotion dead-end; needs the alias or a de-macroize).
The dedup_extend SC07 lane banked 0/36. Captured every failure's own compiler
error rather than guessing: 5 PLUMBING (declaration conflicts) + 4 DIFF per
binary, and the PLUMBING set reduces to 4 distinct symbols repeated across all
four binaries.
Fixed at the lowest available blast radius, each byte-neutral BY CONSTRUCTION
and proven by R22:
- func_80146C3C (8 of 36): T2, but 1 token. DEFINE_func_8016A08C /
DEFINE_func_8016A1CC declared it `(void)` while the SC07 TUs declare
`(u8 *a0)`. Both macros already CAST at the call site, so the prototype is
codegen-irrelevant -> relax to `()` (no-prototype). Measured first: all 4,020
fleet decls are (void)/()/(u8*)/(u8 *a0) — no default-promotion param
anywhere, so `()` is compatible with every one of them (the gcc-2.7.2 `()`
dead-end needs a promoting param; there is none).
- func_8014F4C0 (4 of 36, self-axis), D_80126CC4 (3), func_8012E5CC (1): T1
binary-local. Conformed the SC07 decls to the fleet-canonical form. Every one
has ZERO uncast uses in its TU (verified per file), so the decls were pure
splat boilerplate with no codegen effect.
Deliberately NOT touched: engine_core.h beyond those 2 lines. The §29 law is
about BULK header edits (the 2,046-file sed that still didn't build); 2 targeted
macro lines with a measured compatibility argument is not that.
R22 clean-fleet: make clean && extract-all && check-all -> 140 passed, 0 failed
of 140. Enabling change only; no function banked in this commit.
Method note (mine, recorded): I read `corpus.stubs` while `make extract-all` was
mid-flight and got garbage — R32's coverage assertion refused to answer instead
of returning a wrong stub set. A measurement taken during a rebuild is not a
measurement (S27's law, re-earned). Also: `nohup CMD &` inside a backgrounded
Bash call makes the harness signal completion of the WRAPPER, not the campaign —
the R22 "finished" at 63/140. Waited on `pgrep -x make` instead.
- 38 targets / 44,297 templ ins, model-routed (Haiku <=89 + Opus escalation, Opus direct >=90):
52 agents, ~4.1M tokens -> gate 27/38 (71%). All 11 failures captured + classified: 8 declaration/
link plumbing, 3 genuine byte-DIFF. An 8-agent Opus reconcile wave fixed 8/8 (7 banked) ->
wave-3 total 34/38 = 89%. Propagation +639 members / 1 failed / 83 overlays.
R22 clean-fleet 140/140. Fleet 95.42% fn / 92.4% instr / 85.5% distinct.
- DESIGN (S27 law applied BEFORE it bit): six of eight reconcile targets share ONE TU, so this wave
FORBADE agents any build — six concurrent splice-builds would have clobbered a tracked file.
- THE AGENTS OUT-DIAGNOSED MY BLOCKERS:
* func_801848B0 — an agent REJECTED MY PREMISE: I said byte-correct + decl-blocked; it ran
match_one first, found a real 1-ins DIFF, fixed both. R14 aimed back at me, correctly.
* func_8017C5F0 — the "invented symbol" D_801DA0F0 is an INTERIOR ADDRESS: offset 0x6C into
D_801DA084 (0x801DA084..0x801DA103). The lui/addiu pair builds an interior pointer.
* func_8018A860 — the TU declares memcpy THREE times with incompatible signatures, with a latent
byte bug behind it. One symbol declared three ways is a defect awaiting the next draft.
- Carried (4): func_80184A94 (match_one MATCH, gate-refused) + 3 genuine byte-DIFFs
(func_801845B0, func_8017BEBC@ov_SC02_026, func_8018480C).
- POOL (derived from the regenerated map): 36 families / 28,829 templatable ins, kind=modal (no
member matched ANYWHERE so no sweep could reach them), >=20 members, <=60 ins, non-jr, and NOT
ONE exemplar in ov_SC01_077. Hand-calibrated 3/3 one-shot before scaling (Phase-15/18 discipline).
- WAVE (ultracode; Haiku drafters + Opus escalation, 24 targets): 31 agents, 0 errors, ~2.0M tokens,
12.5 min. Agents claimed 24/24 MATCH; the whole-binary gate banked 20/24 (83%); propagation
+524 members / 0 failed / 91 overlays. 17 of 20 banks were HAIKU, 3 Opus — the
cheap-tier-ab-validated call (Haiku == Opus at <=~50 ins, ~4.8x cheaper) held on real work.
- WHAT OPUS BOUGHT: (1) a `sh` of a constant with the stored width's top bit set needs a u16
destination — via s16 gcc folds it sign-extended and li emits addiu, via u16 force_fit_type keeps
it positive and li emits ori; (2) a schedule-reorder closed by STATEMENT ORDER not the permuter
(gcc's list scheduler preserves relative order of disambiguable stores); (3) three loose-typing
fn-ptr casts a cheap drafter had misread as delay-slot/permuter residuals.
- MY ERROR (R37/R14): I generated the manifest to .run/s6f_wave_targets.json then HAND-TRANSCRIBED
the args into the Workflow call, pattern-filling _jr_8017BEBC across overlays where no such split
exists (corpus.stubs says _jr_8017AE2C). Three agents lost time rediscovering real paths. The gate
driver written after (.run/s6f_gate.py) DERIVES every TU/split from corpus.stubs and asserts
nothing. Assert nothing you can derive.
- The 24->20 gap is the known match_one->gate gap (standalone compile cannot see a TU decl conflict;
Phase 19 measured 88-92% -> 60-71%). 4 carried: func_8018584C, func_80180A4C, func_8017CC80,
func_80189B78.
- R22 clean-fleet 140/140. Fleet 95.13% fn-count / 92.0% instr / 84.9% distinct
(phase opened 92.00 / 87.5 / 78.0).
- A: frontier regen at HEAD (sigs + family_hseq) before pricing anything (R35). Also the reason
it was needed: .run/hseq_verified.*.txt has accumulated 22,841 files across every sweep ever
run, so any per-family analysis globbing them over-counts; the regenerated map derives state
from sigs + corpus.stubs (R33), which is the authority.
- B / THE FINDING (third §133-class miss in a row): the S29 checkpoint's structural signal
"after S2 the x138 era ENDS — those are the last two crackable fleet-wide families" — the stated
TRIGGER for the phase close — is wrong. Two fresh-crack families with >=126 members were open:
0x8017cdd8 ov_SC02_039 17 ins x 142 members PURE
0x8017ce7c ov_SC03_114 16 ins x 126 members IMM
Both kind=modal (NO member matched anywhere, so no sweep could reach them) and neither exemplar
in ov_SC01_077 — invisible to exactly the two habits this phase already corrected.
- Both hand-drafted off the .s, match_one MATCH on the FIRST try, ~0 agent tokens. First gate
attempt failed PLUMBING (not DIFF): the draft declared `extern void func_8017CFCC(s32 a0)` while
the TU DEFINES `void func_8017CFCC(void)` — the target passes $a0 only because the caller's
incoming argument still sits in the register (loose typing). Byte-true C calls it with no
argument; re-verified MATCH, gated byte-identical, propagated 266 members / 0 failed / 118 overlays.
- R14 on the seed: the cached Ghidra-C for func_8017CE7C decompiled an entirely DIFFERENT body
(three calls absent from the asm). Reading the .s is what made it one-shot.
- R22 clean-fleet 140/140. Fleet 94.88->94.96% fn-count, 91.9% instr, 84.6->84.7% distinct.
- ONE root cause, four faces (cookbook §134): extract_unit's preamble scanner reads C
one line at a time, so every construct that WRAPS was misread.
D1 the {-guard fired on a documentation comment mentioning a brace -> carry truncated
mid-comment -> `parse error before 'the'`.
D2 _def_head_at's "param list continues -> ANSI definition" fallback accepted a WRAPPED
DECLARATION as a definition head -> a 16-line fragment with no body, closed by a brace
pair inside a comment -> a silent 0/137 that reads exactly like a compiler wall.
D5 the backscan met a multi-line typedef's CLOSING line `} T;` first and stopped -> the
type never travelled -> `T undeclared` across 17 families / 24,332 templatable ins.
(The code comment claimed they "route through the engine_types.h lift"; measured, they
routed nowhere.)
D4 wrapped __asm__("func_...") alias invisible to a single-line regex — MEASURED (1 exemplar,
3,288 ins, second blocker behind it) and deliberately NOT fixed; it now returns None so the
sweep reports a VISIBLE skip instead of 137 silent failures (R32).
- Fixes: _def_head_at(ln, idx, more=()) lookahead (no-lookahead keeps the historical answer);
{-guard exempts comment-only lines + an R32 dangling-comment backstop; forward brace scan
counts over cdecl._mask (R33, one masking oracle); _typedef_block_start carries whole blocks.
- BLAST RADIUS (R14): extract_unit diffed vs the pre-fix tool over all 181 zero-crack exemplars
-> 157 byte-IDENTICAL, 24 changed, all in the intended direction.
- PAYOFF: D1+D2 +323 members from families that banked ZERO; D5 +417 incl. func_8012B77C 139/139
(8,062 ins) and func_80128C98 137/275. S6 total 1,582 members (pre-fix tool scored 842).
- R22 clean-fleet 140/140. Fleet 94.43->94.88% fn-count, 91.4->91.9% instr, 84.0->84.6% distinct.
- TELL worth keeping (§134): bimodal bank rates (57 all / 52 zero / 8 partial) are a TOOLING
signature, not codegen. Probe one member and read one compiler error before writing a family off.
- family_sweep --hseq --band all (no --source override), 117 pre-classified families:
staged 2735 drafts / 1239 groups / 0 skips -> BANKED 842, R22 clean-fleet 140/140.
Fleet 94.43->94.67% fn-count, 91.4->91.6% instr, 84.0->84.5% distinct.
- R37 setup: the 190 zero-crack families decomposed with ZERO builds — 117 sweepable /
17 §94-§100 multi-line-typedef-blocked (24,332 ins incl. the 275-member 0x80128c98) /
9 jr (§53 carve path) / 47 remap-REFUSED.
- R14 PREMISE CORRECTION: the "every sweep passed --source ov_SC01_077" mechanism in the
post-wave checkpoint is wrong (that IS the default and overrides nothing). The real gate
was --band substantial: only 13 of 181 non-jr families are substantial. --band all is it.
- FINDING: the residue is bimodal — 57 families ALL-banked, 52 ZERO, 8 partial — the shape
of a per-family blocker, not per-member codegen. 8 probed via the new generic
.run/s6_diag.py (one build per family, not 137): 7 of 8 are declaration/carry plumbing.
Two proven family_remap defects located at source (D1 comment-line {-guard truncating the
preamble carry; D2 _def_head_at accepting a wrapped multi-line DECLARATION as a def head).
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.
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.
Drew T