- 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).
- 9 banked heads propagated: 1,096 non-jr member-matches (family_sweep --hseq --band all, 0 failed)
+ 137 (func_80159A20, jr) + 137 (func_801549F8, jr)
- func_80176734 (371 ins, the largest single item in the frontier) banked + propagated
- FLEET 93.81% fn / 90.9% instr / 83.9% distinct; dedup 1905/0; 0 NON_MATCHING (G4)
- cookbook §132b (--span-rel: the already-matched owner that is ITSELF multi-switch) and §133
(the DEFAULT-FILTER class — three times in one session a tool silently answered a narrower
question than the one asked: my own >=80-ins cut, worklist's h_exact pricing, --band substantial)
- head func_8014032C 137/137 (25,071 ins, --span-rel §132b) + jr tier 46 members incl.
func_8017BEBC 13/13 (12,376), func_8015A3C8 6/6, func_8015AE2C 4/4, func_8017A4AC 4/4,
func_8013FFD8 9/10 + non-jr pass 3.
- MY ROUTING ERROR (recorded): pass 1 ran all 28 families through jtbl_family_bank; 13 are NOT
jr functions, so they carve-failed by construction — §123's own law ('propagate a family with
the tool its TIER needs'), which I had quoted in the task description. Re-routed via
family_sweep --hseq: 3 banked / 38 failed => that residue is the genuine stage-but-DIFF class.
- MEASURED: 13 of 29 zero-crack families have remaining members ONLY in the 4 P27-onboarded SC07
overlays (18,856 ins) — not a stub-count gap; they simply missed every sweep that predates them.
- R22 clean-fleet 140/140. Fleet 93.38% fn / 90.0% instr / 82.4% distinct; dedup 1905/0.
Phase arc: +1.38pp fn / +2.5pp instr / +4.4pp distinct.
- 2 × 138 = 276 function-instances banked (exemplar + 137 siblings each); the -O0 cluster is now
COMPLETE fleet-wide (these were the last open stubs in every overlay's _o0* region)
- §132a: --like matches by subseg ROLE NAME; ov_SC07_010 shares the exemplar's _o0 role (the only
other overlay so named — the other 136 are _o0c, whose role never matched, which is the only
reason the sweep worked at all). Six derived starts for three emitted tables; guard shipped.
- R22 clean-fleet 140/140. Fleet 93.33% fn-count / 89.6% instr / 81.6% distinct (+260 unique fns);
dedup 1905/0; 0 NON_MATCHING (G4). Phase arc: 92.00->93.33 / 87.5->89.6 / 78.0->81.6.
S28 ledgered `JR-PAIR-IN-ONE-O0-OBJECT` (two jr fns matched in one -O0 object => a clean
build that cannot link: `undefined reference to $L105` + `func_8013C938`) with §81 step 1
(isolate one into its own code subseg) as the untested escape. BOTH the class and the escape
are REFUTED — no isolation, no compiler wall, both fns banked from a genuinely clean fleet.
The 4th consecutive "structural wall" to resolve to our own tooling (§124/§125/§126/§131).
- DEFECT 1 (tools/jtbl_carve.py): ov_SC01_077_o0's carve at 0xb01a4 predates the §8e
`tables=` persistence and is a MERGED DOUBLE (func_8013C0F8 $L75 + func_8013C414 $L105);
the 2nd owner is MATCHED so extract pruned the stub .s naming its table. The single-table-
predecessor inference derived 3 starts where the object emits 4 tables -> JTBL_PADS 0,4,4
-> jtbl_rodata_pads refused mid-stream, correctly. FIX: R32 coverage assertion + payload
recovery at the single choke point (spec_from_starts) — every zero word inside a span is an
original `.align 3` pad (the tool's own axiom), so the word after it STARTS a table;
recovered starts are logged. No-op where structure is known (the 134 sibling _o0c spans
carry tables=+0x0,+0x70). Honest limit: tight (0-pad) boundaries stay unrecoverable but
fail LOUD via the filter's count guard — never silent.
- DEFECT 2 (Makefile): no .DELETE_ON_ERROR, so `as` (a pipeline consumer) left a TRUNCATED .o
on disk — 12 of 16 T func_, undefined $L57/$L59/$L63/$L75/$L76 — newer than its .c, and the
NEXT build linked the corpse. That IS the S28 link error, one build downstream of a loud,
correct compile error. Negative-control-proven on a scratch invocation.
- BANKED: func_8013B83C (272 ins) + func_8013BD74 (198 ins) in ov_SC01_077 (d19c9580).
Byte proof: 4 tables 0x801D8254/828C/82FC/836C (13/27/27/27 entries, each zero-pad
separated); span 0xb00fc..0xb0280 = 388 B = 52+4+108+4+108+4+108 exactly; spec 0,4,4,4.
- R22 clean-fleet (make clean + extract-all + check-all): 140 passed, 0 failed of 140.
The incremental result was NOT trusted (§130). Fleet 93.25% fn-count / 89.2% instr /
80.5% distinct; dedup 1905/0; 0 NON_MATCHING (G4).
- cookbook §132 + index (356 sections): the mechanism, the fingerprint (an undefined $L<n> in
a LINK error is a truncated object, never codegen), the 30-second standalone-TU ladder that
named the 4th table owner before any build, and the transferable rule — a fail-loud guard is
only as trustworthy as the artifact hygiene around it.
SS131: `sltiu N` is ground truth in BOTH directions. jtbl_range already EXTENDS a span the
dlabel cut short and WARNS when a span is shorter than the bound, but had no clamp for a
span too LONG for a NON-ZERO reason — and the trailing trim only removes ZERO words, so
ordinary data that spimdisasm ran into the dlabel slipped through and under-filled the piece.
Records the reusable FINGERPRINT of an under-fill, because it does not look like codegen:
hundreds of 1-byte diffs spread over most of the overlay, ~95% at byte 0 (mod 4) = the low
byte of a 16-bit immediate, every one changing by exactly -4. Bucket differing bytes by
offset%4 and decode a few words; uniform small deltas in the immediate field mean LAYOUT,
not codegen. (Measured: 812 of 853 at pos 0 mod 4, all -4.)
The clamp's authorization matches the extension path exactly: unambiguous sltiu bound only,
and REFUSE LOUDLY if any surplus word is a plausible code address.
This was the single instrument failure that survived SS125's retraction round — the one case
where "the tool is broken" was actually true. Now fixed, with the 710-ins behemoth banked.
Fleet 93.25% fn-count / 89.2% instr / 80.5% distinct; R22 140/140 (thirteen runs).
Nothing running, tree clean, lock FREE.
Records for the fresh session: the ordered resume list (T1 + T3 need /effort ultracode and a
WAIT for the toggle; #9 and T5 need Max), the JR-PAIR-IN-ONE-O0-OBJECT wall with its untested
SS81-step-1 escape, and the S28 ROI evidence that a 15-target wave bought 12 banks and +0.00pp
headline — so waves are only worth resuming against HIGH-REACH targets.
Flags the milestone reality plainly rather than leaving it for T5 to discover: 89.2% instr
against a >=95% bar, with the remaining volume in main + the 39 type-1 modules (P31 scope).
P30 realistically closes on the milestone's LEDGER branch, which is an explicit either/or in
the approved milestone — Drew's call, deliberately.
Adds the S28 HONESTY LEDGER: five wrong calls this session, each caught by an oracle, none
committed. The standing consequence is stated once, at the top of the handoff: only a full
clean-fleet R22 counts, and a tool's exit status is never the oracle.
Also removes a duplicated results section left by my own earlier checkpoint edit.
SS129a: post-carve, rtu_match/match_one COUNT THE JUMP TABLE AS INSTRUCTIONS. For
func_8013BD74 it reported `mine=198, target=226, 206 mismatched` — and 226-198=28 is
exactly the table's entry count. A draft that verified cleanly BEFORE the carve reads as a
total mismatch AFTER it, and the number looks like deep codegen trouble. SS81 says a jr fn's
match_one MATCH is not a bank; SS129a says its post-carve DIFF is not a diff either. Let the
whole-binary gate arbitrate.
SS129b: NEVER commit a carve whose owner is still a stub. harvest_verify refuses a dirty
tree (SS97) and the carve dirties config/, so committing the carve to get a clean tree is
tempting — and it STRANDS the carve. jr_inventory refused instantly (R32: "carve ownership
is not 1:1 ... UNOWNED 0x801d828c"), blocking every later jr operation on that overlay.
Reverted; R22 140/140. The route for a jr fn is the INTEGRATED jtbl_family_bank (carve ->
extract -> remap -> gate per sibling in ONE uncommitted transaction). The SS81 hand-chain is
for diagnosis; as a banking path its two constraints contradict each other.
Both were mine, both caught by oracles before any lasting damage, both now documented.
Ledger: JTBL-PAD-SPEC-DRIFT (func_8013BD74, with the exact SS8e error) and CC1-FAIL-UNREAD
(func_8013B83C — the diagnostic is genuinely unread; say so rather than guess).
Fleet 93.21% fn-count / 89.1% instr / 80.4% distinct.
SS127/SS127a/SS127b distil what the wave's agents kept re-deriving, because the index
fired on only 3 of 15 targets:
- the -O0 CONSTANT-OFFSET FOLD: `p->f` folds to `lbu 3(r)`, `p[i]` does NOT (addiu +
0-displacement load). At -O2 these converge, which is why nothing in SS1-SS126 covers it.
- the -O0 regime generally: spill/reload pairs are REAL named locals; load-delay nops and
redundant copies are normal; write plain C, the -O2 steering levers are inert here.
- SS127a: SS71 sibling-first is the STRONGEST -O0 lever — an -O0 TU is a near-uniform code
regime, so a banked sibling's shape transfers far better than at -O2.
- SS127b: two agents' decisive levers came from a SOURCE COMMENT in ov_SC01_077_o0.c, not
from docs/. Promote levers out of source comments or every future agent re-buys them.
Checkpoint records the wave AND its honest ROI: 1.33M tokens for 12 banks and +0.00pp
headline. The value is contingent on three reach-138 functions, and all three are
currently unpropagated (func_8013C08C 0/137, SS94 type-carry) or gate-failed
(func_8013BD74 CARVE-REFUSED, func_8013B83C CC1-FAIL). Fix propagation before wave 2 —
drafting more x2-reach targets is not where the leverage is.
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.
Records the T2 result as the phase's biggest unblock: the carve-within-a-carve is
byte-neutral (Arm-A does NOT bite), the real constraint is that an address range is
not an optimization region (SS126), and tools/o0_subsplit.py implements the correct
bound. Measured, not assumed, what it unblocks: 275 open stub instances across 18
overlays in the 0x8013B568..0x8013C98C cluster, homed in an -O2 jr split — plus a
note that the T0(f) "2,192 open members" pin is STALE and must be re-derived before
costing (R37).
Also flags my own under-count: the "15 contiguous -O0 fns" came from an asm scan that
cannot see matched functions.
- §124: a "not matched" verdict can mean the definition is there under a DIFFERENT
C NAME (the §37/§73 asm-label alias). The whole "no matched unit" skip class was
one exemplar x 137 members. Includes the two traps in the fix (re-derive the
pattern PER FILE; CARRY the alias declaration or the sibling emits the wrong
symbol and still links) and the law: when corpus.stubs and a source scanner
disagree, the SCANNER is wrong.
- §124a: `0 matched-exemplar families` from family_sweep may be the --band FILTER
(defaults to `substantial`), not a wall — same shape as §53 / §116.
- cookbook-index regenerated (tools/cookbook_index.py, R33).
- CURRENT_PHASE: SESSION-28 checkpoint. Fleet 92.70 fn-count / 88.3 instr / 78.7
distinct, R22 140/140. Records the 4th -O0 region VERIFIED + SIZED (30 instances
/ 1,504 ins, ov_SC03_014+015 only) and correctly BLOCKED on the T2 re-carve, and
two R14 corrections to my own SESSION-27 checkpoint (the 137 were skips not
failures; the cause was not "banked in the wrong binary").
The 12 agents killed by the usage-limit pause were resumed and ALL returned MATCH (2 had already
banked from their partial drafts, so 10 ran). h_exact propagation leg completed over all 112 banked
exemplars: 14 propagated, 42 benign skips (h_seq tier, correctly routed away per §123), 0 failures
— the 0x801466F0 'halt' was a third benign-refusal phrase, not a partial write.
fn-count 92.61 -> 92.67% | instr 88.2 -> 88.3% | distinct 70,581 -> 70,590 unique fns.
WAVE 3 (48 agents / 8 binaries, dealt across binaries so BANKING fans out): 48/48 match_one MATCH,
48/48 banked through 8 PARALLEL per-binary gates. WAVE 2: 15/19. BEHEMOTHS: 4 non-jr confirmed
(func_8017E120 884ins x14, func_8017FA5C 728, func_8017CAD4 755, func_8017E35C 719).
Tier-routed propagation (§123): family_sweep --hseq banked 911 members across 137 overlays.
fn-count 92.32 -> 92.59% | instr 87.9 -> 88.2% | distinct 78.3 -> 78.7% (70,506 unique fns)
R22 clean-fleet 140 passed / 0 failed, under one campaign lock (treelock.sh).
CORRECTION (R14): the 'per-binary bank-rate cliff' I reported from the pre-incident gate run
(SC03_014 1/6, SC04_018 1/6, SC06_018 2/6) was an ARTIFACT — those gates ran against a tree
propagation was concurrently rewriting. Re-gated clean: 6/6 everywhere. A measurement taken during
corruption is not a measurement; I should not have theorised a cause before re-running it.
I gated 8 binaries in parallel while wave-2's propagation loop was still running, then ran
'make clean' on top. check-all 77/140; the corpus denominator moved, so the apparent 91.4% instr
was a half-written tree, not a gain. Reverted to commit:1245 (last R22-verified) — 140/140 restored,
all 58 drafts survived because agents only ever write .run/.
ROOT CAUSE, and it was structural not unlucky: my guard was
while pgrep -f dedup_propagate; do sleep; done
A CAMPAIGN is a LOOP of short-lived processes (15 sequential invocations), so it has gaps where no
process matches. The poll sampled a gap and started. Presence-of-a-process cannot express 'a
campaign owns the tree'.
treelock.sh holds one flock for the WHOLE campaign, released by the kernel on exit OR kill, with
--status; both drivers refuse to run unlocked. LAW: guard the CAMPAIGN, not the process.
Corollary (twice today): a killed process performs no undo — a fleet-tier write needs a lock ABOVE
it, not cleanup inside it.
The 4 cores dedup_propagate refused (h_exact tier) templated cleanly via family_sweep --hseq once
the family map was regenerated post-bank (a bank invalidates the map: sig-overlays + family_hseq
must run BEFORE the sweep — the standing wave-loop order). 548/686 banked, 138 failed (one
consistent per-overlay slice, diagnose next). Wave-1 total: 8 cores -> 1,121 instances.
instr 87.5 -> 87.9%, distinct 69,828 -> 70,094 unique fns.
Ultracode wave of 14 agents over fresh reach-138 cores: 14/14 match_one MATCH, 8 accepted by the
whole-binary gate (the §52b law reproduced exactly). Propagated per-function (the incident fix):
0x8012E014, 0x80151C54, 0x8012F49C, 0x80151B98 -> +573 instances. R22 clean-fleet 140/140;
instr 87.5 -> 87.7%, fn-count 92.00 -> 92.16%, distinct 69,828 -> 69,836.
The other 4 banked cores are h_seq (PURE/IMM) families: dedup_propagate is h_exact-only, so its
'reach<2' / 'not self-contained' refusals were statements about the TOOL's tier, not the functions
-> cookbook §123 (the §53 carve-law generalized to the propagation-tier axis) + a routing table.
They bank via family_sweep --hseq next.
39% prior did not generalize (S16 measured FRESH wave drafts; this is A10's stored-backlog class,
0/958 by plain re-gate) — the driver lifted ~16% over that 0%. Residue routed to T3 redraft lanes.
§61 orphan-carve residue reverted; two T3 pre-work gaps recorded (gate_stage commit add-scope for
new carve files; no tracked writes during tree-writing campaigns). Ledger pruned: 1,350 -> 1,332.
- The last big NAMED blocker, costed across four checkpoints as §112 header + §20 call-site cast +
a scripted §99 pass over 2,022 overlay-local decls. Probing first showed two of the three were
unnecessary: the conflict is entirely between DEFINE_func_80151924()'s own forward-decl
(extern s32 func_80151944(void)) and the byte-true definition (void f(void *a0)), four lines
apart in the assembled TU. The 2,022 decls live in OTHER TUs and never entered it.
- ONE 4-line edit in engine_core.h: decl -> byte-true, call site -> ((s32 (*)(void))f)() so the
caller's codegen is unchanged. rtu_match: conflicting types -> MATCH (15 ins). Sweep 138/138.
- Family 0x80131eec fully closed: 149 (T87) + 138 (T97) + 1 immediate-refusal = all 288 members.
- SHARED-HEADER RISK VERIFIED, NOT ARGUED: engine_core.h is included by all 138 overlays, so §20
cast-folding is a hypothesis. Per-binary gates 138/138 are necessary but not sufficient; the
fleet check is the one that counts. R22 clean-fleet 140/140 + tools-health RC=0 (corpus 0
PHANTOM/0 TRUNCATED, cdecl, audit-binaries, dedup 1886/0, C1 239604/239604).
- METRICS: fn-count 91.96 -> 92.00% (+138, exact) · instr 87.4 -> 87.5% (+2,070) · distinct +72.
- COSTING LESSON: the estimate came from reading the symptom (2,022 decls of this name exist)
instead of probing the failure (which decl actually conflicts). Probe before COSTING, not just
before scaling.
- The draft calls ((void(*)(void))func_80142C84)() but nothing declares that symbol above the
splice: it is DEFINED by DEFINE_func_80142C84() in engine_core.h, so gather_externs has no
extern line to harvest, and the member TU instantiates the macro BELOW our function.
- The wrong guess was the useful step: a no-prototype `extern s32 func_80142C84();` turned
`undeclared` into `conflicting types` — a DIFFERENT error, proving the diagnosis right and the
type wrong. Synthesised from the macro's own definition head -> MATCH (34 ins) -> 136/136.
- NEW macro_def_sig_map() (1,878 signatures): the complement of header_sig_map(), which reads the
externs a macro emits FOR ITS CALLEES; this reads the signature a macro DEFINES. Cookbook §121.
- ALL THREE byte-identical stragglers carried since SESSION-24 are now closed: func_80146750
137/137 (T84), func_801759D8 137/137 (T93), func_80142B2C 136/136 (T95) = 410 members, and not
one was a compiler wall (a signedness-wrong header decl, a type-name collision, a missing extern).
- Blast radius 0 (74 further families re-swept). FOUR data points now: only §117 (wrong LOGIC)
generalised at 1,209 members; §118/§120/§121 are path-reachability gaps worth ~one family each.
- GATES: R22 clean-fleet 140/140; dedup 1886/0; 0 NON_MATCHING (G4).
- METRICS: fn-count 91.88 -> 91.96% (+273, exact) · instr 87.3 -> 87.4% (+12,296) · distinct +0
(both byte-identical families — §111 predicted exactly that).
- CORRECTION 1 (R14/P9): T92's "strip-if-ambient" recipe was WRONG. Stripping the draft's duplicate
typedef breaks the extern that USES it (the TU's own copy sits below the spliced function), so the
"second stacked blocker" T92 recorded (D_800AF634 used prior to declaration) was my own fix
misfiring, not a real blocker. RENAME, don't remove: rtu_match CC1 FAIL -> MATCH (56 ins).
- CORRECTION 2: T91's wiring never RAN. family_sweep has THREE staging sites sharing the identical
two lines (edit-remap / hseq / plain h_norm); I patched by rindex twice, which lands on the PLAIN
site, so --hseq staged the draft unchanged and the lever looked ineffective. Re-anchored on the
hseq site's unique write (func_{to_addr:08X}.c) and the draft came out renamed. T91's revert was
right discipline on a false premise.
- RESULT: _uniquify_draft_types wired into the hseq path (byte-neutral — C type names never reach
codegen). func_801759D8, one of the three long-standing byte-identical stragglers: 0 -> 137/137,
0 failed. Blast radius 0 (74 further families re-swept, none moved) => TARGETED lever, like §118
and unlike §117.
- Cookbook §120, incl. the law: before concluding a lever does not work, prove it RAN — diff the
staged artifact for the change it is supposed to make.
- GATES: R22 clean-fleet 140/140; dedup 1886/0; 0 NON_MATCHING (G4).
- METRICS: fn-count 91.88 -> 91.92% (+137, exact) · instr 87.3 -> 87.4% (+7,672) · distinct +0
(byte-identical family — §111 predicted exactly that).
- CORRECTION (R14/P9): T84's '137 banked = all of 0x80161c98' is WRONG and committed wrong in
commit:1193. The 137 were func_80146750 (a byte-identical straggler), banked 1-per-overlay in
<ov>_after.c; 0x80161c98's members were still stubs. I assigned a count to the family I had
been looking at without deriving it — third instance today of that error class. The
--fix-def-sig-is-harmful finding itself stands (it unblocked func_80146750 x137).
- THE REAL BLOCKER was a flag OFF-DIAGONAL, not a defect. 0x80161c98's byte truth is (int,u32)
-> sltiu; engine_core.h says (s32,s32); and an in-TU decl disagrees with the def. The levers
pull opposite ways: --fix-def-sig bends the DEFINITION to the header; --normalize-self-decls
bends the DECLARATIONS to the definition. both-on -> slti DIFF (T79). both-off -> correct
sltiu but 'conflicting types' (T84/T88). NSD-only -> 138/138 (T89). Three sweeps across three
sessions tested only the diagonal of the 2x2. Cookbook §119.
- T90 blast radius: 23 more (NSD-only) across the remaining still-zero families — targeted, not
general; recorded so it is not over-projected.
- GATES: R22 clean-fleet 140/140; dedup 1886/0; 0 NON_MATCHING (G4).
- METRICS: fn-count 91.84 -> 91.88% (+161, exact) · distinct-code 69,593 -> 69,744 (+151).
- The T86 asm-ambiguous refusal was CORRECT (a by-value swap would corrupt the non-differing
occurrence); the safety TEST was too strict. It compared the C literal's occurrences against
EVERY asm use of that value, but gcc synthesises uses no C token names — e.g.
D_80187044[*(u16 *)((s32)a0 + 0x2)]() has one C literal 0x2 and TWO asm uses of 2 (the
per-member offset + a fixed sll ..,2 for the 4-byte stride). Unsatisfiable by construction.
- FIX (_ordinal_edits, §118): pair C occurrences to asm positions IN ORDER, accepting either
len(spans)==len(asm_pos) (every use named) or len(spans)==len(diff_pos) (extras are implicit).
Rewrite only occurrences whose instruction is in diff_idx. Order is a heuristic, so the
whole-binary byte-gate stays the sole arbiter — a wrong pairing is rejected, never banked.
- T87: func_801599A4 0 -> 137 drafts, 137 banked; +12 singletons = 149 (family 0x80131eec).
- T88 blast radius: only 9 of the other 144 immediate-refusals converted (refusals 67 -> 34).
A TARGETED lever, not a second §117 — recorded so it is not over-projected.
- GATES: R22 clean-fleet 140/140; dedup 1886/0; 0 NON_MATCHING (G4).
- METRICS: fn-count 91.79 -> 91.84% (+158, exact) · distinct-code 69,450 -> 69,593 (+143).
- T84 (item 1): the top still-zero family's whole diff was ONE instruction — slti (signed) vs the
target's sltiu. --fix-def-sig was conforming a byte-correct draft to engine_core.h's
signedness-wrong decl (extern void func_80161D20(s32,s32)) while the exemplar's own def is
(int, u32). Re-swept the 92 still-zero families WITHOUT the flag: 137 banked (all of
0x80161c98), other 91 unmoved => family-specific, NOT a second §117. Recorded as such.
- T85 (item 2): rewrote tools/rollout_801457a4_o0.py as the two-file ATOMIC driver §116 called for
(remapped body -> <ov>_o0b.c AND drop the INCLUDE_ASM from <ov>_after.c in one edit; build vs
config/check.<ov>.sha; restore BOTH files on mismatch, §61). Validated on 3, then 130/130.
No splat change — the Arm-A re-carve wall never touched.
- Item 4 PRICED AND DROPPED: STRUCT residue = 34 families / 166 members / 0.02pp.
- R14: my new_distinct estimator over-projects ~2x (priced 259, measured 125) — it counts classes
unmatched at run time, so concurrent sweeps double-count. Ranks correctly, overstates absolutely.
- GATES: R22 clean-fleet 140/140; dedup 1886/0; 0 NON_MATCHING (G4).
- METRICS: fn-count 91.72 -> 91.79% (+270, exact) · instr 87.2 -> 87.3% (+16,946) ·
distinct-code 69,325 -> 69,450 (+125).
- Re-swept the 229 eligible non-jr families (2,575 candidate members) that had never seen a
correct target spelling. 821 banked / 1,538 failed; 138 families went zero -> COMPLETE (732
members), 14 partial, 92 still zero. Top: 0x80172780 +135, 0x80128158 +31, 0x80187318 +28,
0x8016f540 +27, 0x8017bef8 +20.
- Every one of those 138 families had been swept before and booked as a failure. None was a
compiler problem — all were downstream of the one positional-map defect fixed in T82.
- GATES: R22 clean-fleet 140/140; dedup 1886/0; 0 NON_MATCHING (G4).
- METRICS: fn-count 91.48 -> 91.72% (+821, exact) · instr 86.9 -> 87.2% (+33,670) ·
distinct-code 69,024 -> 69,325 unique fns (+301).
- The 92 still-zero families are the honest residue: swept with every lever this phase built
(§114 callee, §115 named-symbol, §117 symbol-kind, def-sig, self-decl normalization), so no
known harness defect applies to them. Correct starting population for the next diagnosis round.
- CAUSE: family_remap.symbol_map zips exemplar/sibling reloc slots positionally and spelled the
SIBLING's symbol from the EXEMPLAR's kind. Same-address families always agree, so it was
invisible for 20+ phases; cross-address families need not agree — func_80174784's callback slot
is the FUNCTION func_801747CC while member func_8017CFD4's same slot is the DATA symbol
D_80182688. The map emitted func_80182688, the body materialized a name for an address that is
not a function, and the fleet gate refused all 251 members.
- FIX: spell the target by what the target address IS in the SIBLING's overlay (func_ iff in that
overlay's sig set — the same boundary oracle nins_of trusts, R33; memoized). Phase 26-A had
already established this rule and applied it only to the exemplar side.
- WHY IT HID: rtu_match/match_one MASK HI16/LO16, so a wrong %hi/%lo symbol still reports a clean
MATCH (measured: "MATCH (10 ins)" on a member the fleet gate rejected). masked-MATCH +
whole-binary DIFF is the exact signature of a compiler wall. Cookbook §117 carries the law.
- Also refuted en route (cheaply): --normalize-self-decls was NOT the cause — re-swept without it,
still 0/251.
- GATES: R22 clean-fleet 140/140; dedup 1886/0; 0 NON_MATCHING (G4).
- METRICS: fn-count 91.41 -> 91.48% (+251, exact) · distinct-code 68,782 -> 69,024 unique fns
(+242, projected 246) · instr +2,510.
- BLAST RADIUS UNMEASURED: symbol_map serves every family sweep; 229 eligible non-jr families /
2,575 members have never been swept with a correct target spelling, incl. the byte-identical
families T76 measured at 0/682 (same failure shape).
- VALIDATED FIRST, then batched: 0x80143d28 (T66's #1, T76's ApplyMatrixSV callee diagnosis)
banked 136/136 under the §114 callee axis + §115 named-symbol widening. Batch of 8 followed:
505/1039. Totals: 5 families outright + 1 partial of 9; 641 members ×N.
- Attribution DERIVED (R33), not parsed from the sweep log: live stubs recomputed per family from
corpus.stubs before/after. Reconciles exactly against the metric (fn-count +641).
- §116 (NEW): optimization level is a property of the FILE, not the function. 0x801457a4 swept
0/137 because its exemplar lives in ov_SC01_077_o0b.c (-O0 via WHALE_O0B_OBJS) while all 137
members' stubs live in <ov>_after.c (-O2). The fix moves the STUB line, not the def: <ov>_o0b's
.text ends exactly at 0x801457A4, so the relocation is byte-neutral by construction and needs no
splat re-carve (which is the Arm-A +0x20 wall). 13th time a family-wide 0/N was the harness.
- R14 CORRECTION to the handoff arithmetic: the tier is 123 families / 3,100 distinct on fresh
sigs, but 1,287 of that distinct is the -O0 cluster behind the Arm-A splat wall. Honest
addressable tier = 113 families / 85,360 ins / 1,813 distinct. Billing the walled 1,287 as sweep
yield would have repeated the T76 error.
- 0x80131eec (214 distinct, the biggest item left) diagnosed precisely: header macro decl +
§20 call-site cast + a scripted §99 pass over 2,022 overlay-local decls; param is void*, so the
T75 narrow-param refusal does not apply.
- GATES: R22 clean-fleet 140/140 from make clean + extract-all + check-all; tools-health RC=0
(corpus 0 PHANTOM/0 TRUNCATED, cdecl, audit-binaries, dedup 1886/0, C1 239604/239604);
report RC=0; 0 NON_MATCHING (G4).
- METRICS: instr 86.7 -> 86.9% (+28,205 ins) · distinct-code 76.9 -> 77.4% (68,196 -> 68,782
unique fns) · fn-count 91.23 -> 91.41% (+641). The distinct-code move is the point of this tier.
I called this "a one-line predicate widening". It was THREE, and fixing the first two changed nothing
— the sweep still reported 0/547 (cookbook §115):
1. canonical_map : re.fullmatch(r'func_[0-9A-Fa-f]{8}') + keyed by parsed ADDRESS
2. DECL_LINE_RE : (func_[0-9A-Fa-f]+) as the name group
3. split_sig_string : \bfunc_[0-9A-Fa-f]+\s*\(
Each is a SILENT SKIP indistinguishable from "no conflict found". With 1+2 done the symbol reached 3
and died there; only tracing transform's internals (`callees cast: 0` while the canonical map plainly
held `s32 RotTransPers(s32, s32, s32*, s32*)`) located it. THE TRAP WORTH REMEMBERING: a partial fix
to a name-form assumption produces the exact symptom of no fix at all, so a correct hypothesis looks
refuted. Curated naming increases as RE quality improves, so any func_-only predicate is
rot-by-design — the same shape as stub_map's (Phase 26-A).
RESULT: func_8012F40C 0/137 -> 137/137. The other three families (801759D8, 80146750, 80142B2C) still
fail on different causes.
GATES: R22 clean-fleet 140 passed, 0 failed of 140; tools-health OK; dedup 1886/0; 0 NON_MATCHING.
METRICS: instr 86.7% (+4,932 ins); fn-count 91.19% -> 91.23% (+137); distinct +0 (byte-identical).
NEXT: the byte-VARIANT tier is worth re-sweeping — T70 banked 1/10 BEFORE the callee axis existed, and
26 families remain unswept by the two levers added since.
Item 1. The T76 diagnosis was right and the fix was a lever we already owned. cast_call_sites
(§17a-1/§20) handles the callee-conflict class and lived ONLY in gate_stage, which the family sweep
deliberately does not use — the THIRD instance this session of a lever unreachable from the path that
needs it (T56 data-decl unreachable, T57 function-decl off-by-default, now T77 callee).
the 5 byte-identical families : 0/682 -> 135/682
func_80173A60 specifically : 0/135 -> 135/135
Wired after scope_data_fix (orthogonal axes: data vs callee), default ON with --no-cast-callees. Two
details that matter: the canonical map is built from the TARGET sibling's TU via cpp
(canonical_map(ov, src_file=tu) -> cdecl.tu_scope) so it sees MACRO-INJECTED declarations — a
raw-text scan returns nothing for exactly the callees that conflict (§51g LAW 7) — and it is read
AFTER any tu-scope edit is on disk.
THE OTHER FOUR STILL FAIL, different causes. And the next finding is already visible:
func_8012F40C's blocker is RotTransPers, a PsyQ LIBRARY symbol — a callee conflict the cast should
have handled. It did not, because cast_call_sites' canonical map keys on
re.fullmatch(r'func_[0-9A-Fa-f]{8}'), so NAMED PsyQ callees are structurally invisible to it. That is
a one-line predicate widening with ~270 members behind it (RotTransPers + ApplyMatrixSV families).
GATES: R22 clean-fleet 140 passed, 0 failed of 140; tools-health OK; dedup 1886/0; 0 NON_MATCHING.
METRICS: instr 86.6% -> 86.7% (+7,965 ins); fn-count 91.15% -> 91.19% (+135); distinct +0
(byte-identical — §111 predicted it).
cookbook §114 — the three decl axes, and "conflicting types for X: READ X".
Probe target switched from func_8013BD34 on measured evidence (its def is in ov_SC07_010_o0.c and
_o0 families sweep ~1/137 — a poor test of an unproven technique). func_80144B14: same class, 137
stubs, not -O0, real 34x137 family, tests both axes (void(void) -> int(int)).
THE PROBE FOUND THE PRECONDITION OVER-FIRING. The ARITY blocker exists because the macro's own CALL
SITE passes the header's arity. But DEFINE_func_* does not call func_80144B14 — it takes its ADDRESS:
*(s32 *)((s32)a0 + 0xDC) = (s32)&func_80144B14;
No call site => no arity constraint => the FULL correction is available, not the §99 no-prototype
workaround. Applied `extern int func_80144B14(int param_1);`.
RESULT: header change ALONE -> R22 clean-fleet 140 passed, 0 failed of 140 (byte-neutral); family
sweep -> 137/137, 0 failed.
METRICS: instr 86.6% (+4,658 ins); fn-count 91.12% -> 91.15% (+137); distinct-code +0 (byte-identical
family — §111 predicted it).
THE REFINEMENT (cookbook §113): the precondition must ask what the macro DOES with the symbol — a
call constrains arity, an address-taken or unused decl does not. Blocking on "both names appear"
over-fires, and it had 137 members behind it. The remaining ARITY findings should each be re-checked
for call-vs-address before assuming §99 is needed.
GATES: R22 140/140 twice; tools-health OK; dedup 1886/0; 0 NON_MATCHING (G4).
Item 5, first batch. Swept 10 byte-VARIANT non-jr non-O0 families (42,235 ins / 1,552 distinct
projected): 138 BANKED / 1,346 failed — ONE family of ten (func_801627E8 137/137), plus 152 members
skipped as "unresolved immediates (T2a)".
THE FINDING: that is a ~10x worse rate than the byte-IDENTICAL families, which banked 137/137 apiece
all session. It follows from what §111 established — a byte-variant member differs in more than
relocations, so the template must adapt immediates too, and family_remap's T2a engine refuses what it
cannot resolve. The distinct-code lever is real but it is NOT the same cheap sweep, and the projected
"2,962 distinct across 36 families" should be discounted until the immediate-resolution rate is
measured. That measurement is now item 1 of the next list, ahead of sweeping the other 26.
§111 PASSED A SECOND PREDICTIVE TEST: projected +129 distinct for func_801627E8; observed +130 (the
extra from an unrelated 2-member bank).
GATES: R22 clean-fleet 140 passed, 0 failed of 140; tools-health OK; 0 NON_MATCHING (G4).
METRICS: instr 86.5% -> 86.6% (+2,618 ins); fn-count 91.08% -> 91.12% (+138); distinct-code
68,066 -> 68,196 = +130 — the first real distinct-code movement of the session.
The audit was the right precondition: THREE of the six corrected functions were families already
queued for the item-3 sweep, and each would have failed 0/137 exactly the way five families did
earlier today.
SWEEP: 6 corrected functions, all non-jr families with 137 live stubs -> 685 BANKED / 137 failed.
Five families landed 137/137; func_80146750 failed on its own residual (undiagnosed).
GATES: R22 clean-fleet 140 passed, 0 failed of 140 — after the header batch alone AND after the
banks; tools-health OK (corpus 0 PHANTOM + 0 TRUNCATED, cdecl, audit-binaries, dedup 1886/0);
0 NON_MATCHING (G4).
METRICS: instr 86.3% -> 86.5% (11338739 -> 11372304 = +33,565 ins); fn-count 90.88% -> 91.08%
(321472 -> 322157 = +685); distinct-code 76.9% -> 76.9% (+0).
§111 GOT ITS FIRST PREDICTIVE TEST AND PASSED: all six families have a single h_exact class, so the
model predicted +0 distinct BEFORE the sweep ran, and +0 is what happened. The metric is modelled,
not mysterious.
Item 3, and it banked the third family. extract_unit located a definition with "the line matches
<type> func_<addr>( and does not end in `;`" — wrong whenever ONE LINE holds both a declaration and a
definition, which the handwritten inline-asm wrappers do:
extern void func_80156044(int, int); int func_80155FF8(int, int) { __asm__ … }
The line does not end in `;`, so func_80156044 — appearing there only in the DECLARATION — was taken
as a definition head. extract_unit lifted the neighbouring WRAPPER instead of the real definition
seven lines below; every sibling already defines that wrapper via its shared DEFINE_ macro, so all
137 failed with `redefinition of func_80155FF8` and it read as a compiler wall.
FIX: ask what follows the PARAMETER LIST, not what ends the line (`_def_head_at`) — `;` is a
declaration, `{` or end-of-line is a definition. Plus the R32 assertion: a unit that defines a
function other than its target cannot template, so refuse LOUDLY (`_foreign_defs`).
TWO TRAPS HIT WHILE WRITING THAT ASSERTION, both caught by regression-checking against families known
to bank: (1) _def_head_at ALONE over-fires — a call whose args wrap has nothing after the `(` on its
line, which "end of line => definition" reads as a definition; it refused THREE families that had
just banked 137/137. (2) The type-prefix test ALONE under-fires — it is what missed the wrapper
originally. The predicate needs both: split the prefix on its last `;`, require the remainder to look
like a return type, then check what follows the parameter list. All five known-banking families
extract byte-identically before and after.
RESULT: func_80156044 0/137 -> 137/137, 0 failed.
GATES: R22 clean-fleet 140 passed, 0 failed of 140; tools-health OK (corpus 0 PHANTOM + 0 TRUNCATED,
cdecl, audit-binaries, dedup 1886/0); 0 NON_MATCHING (G4).
METRICS: instr 86.2% -> 86.3% (11328601 -> 11338739 = +10,138 ins); fn-count 90.84% -> 90.88%
(321335 -> 321472 = +137); distinct-code 76.7% -> 76.9% (67937 -> 68066 = +129).
cookbook §110.
Item 2, and the same story as item 1: the header correction WAS the fix. With engine_core.h
declaring the byte truth, the family swept 137/137 with zero failures — no draft change.
before (header wrong) 0/137 `conflicting types` / a param-retyped body that could not compile
after (header right) 137/137, 0 failed
GATES: R22 clean-fleet 140 passed, 0 failed of 140; tools-health OK (corpus 0 PHANTOM + 0 TRUNCATED,
cdecl, audit-binaries, dedup 1886/0); 0 NON_MATCHING (G4).
METRICS: instr 86.1% -> 86.2% (11318463 -> 11328601 = +10,138 ins); fn-count 90.81% -> 90.84%
(321198 -> 321335 = +137); distinct-code 76.7% -> 76.7% (+0 — a SIXTH data point for the anomaly).
Item 1. The header flip (commit:1163's sibling, committed just before) was the whole blocker: with
engine_core.h declaring the byte truth, the family swept 137/137 with ZERO failures — no draft
change, no new lever.
before (header wrong) 0/137 `conflicting types` / a --fix-def-sig-truncated draft
after (header right) 137/137, 0 failed
GATES: R22 clean-fleet 140 passed, 0 failed of 140; tools-health OK (corpus 0 PHANTOM + 0 TRUNCATED,
cdecl, audit-binaries, dedup 1886/0); 0 NON_MATCHING (G4).
METRICS: instr 86.0% -> 86.1% (11307777 -> 11318463 = +10,686 ins, exactly 137 x 78);
fn-count 90.77% -> 90.81% (321061 -> 321198 = +137); distinct-code 76.7% -> 76.7% (+0).
The distinct-code anomaly now has FIVE data points (T52 +125, T57 +125, T56 +0, T58 +0, T63 +0) and
still no identified variable. Unchanged as the queued probe.
Ran the batch with the T57 recipe (--band all --normalize-self-decls, live stubs derived from src/
not the stale map). 6 of 8 selected (two still filtered — selection line read this time).
821 candidate members across 6 families
BANKED 137 — func_8012A1BC (78 ins) 137/137
failed 684 — the other FIVE families banked 0 each
Attribution from git diff (137 x func_8012A1BC), not the per-group log lines whose split-name field
my first aggregation mangled.
THE SHAPE OF THE REMAINING FRONTIER — the finding. Across T56->T58 the per-family outcome is BINARY
and near-total: a family banks ~137/137 or ~0/137, nothing in between. And each 0/N so far has had
its OWN distinct cause — DATA decl scope (T56), FUNCTION decl scope (T57), jtbl table-count drift
(func_8014032C), plus five more undiagnosed here. The mechanical lever is done pulling by itself:
from here each family costs one diagnosis. A batch is now a DIAGNOSIS QUEUE, not a harvest, and the
next phase of this work should be planned on that economics.
GATES: R22 clean-fleet 140 passed, 0 failed of 140; tools-health OK (corpus 0 PHANTOM + 0 TRUNCATED,
cdecl, audit-binaries, dedup 1886/0); 0 NON_MATCHING (G4).
METRICS: instr 86.0% (11297091 -> 11307777 = +10,686 ins); fn-count 90.73% -> 90.77% (+137);
distinct-code 76.7% -> 76.7% (+0).
The distinct-code anomaly now has FOUR data points and still no explanation: T52 +125, T57 +125,
T56 +0, T58 +0. All four families are PURE; the exemplar overlay does not separate them either (T56
and T57 both templated from ov_SC01_077 and disagree). Two behaviours, no identified variable.
Still not guessed at — it stays the queued probe.
First batch off the 64-family list. Fleet crosses 86.0% instr-weighted.
TWO OF MY OWN ERRORS, both caught by measuring:
1. Three of five targets never ran — --band defaults to `substantial` (nins>=80) and I picked three
at 79/78/78. The tool printed "2 matched-exemplar families" and I nearly read that as "5
attempted, 3 refused". Read the SELECTION line, not the intent.
2. Stale map: .run/family_hseq.json was regenerated in T55, BEFORE T56 banked func_80144090, so it
still listed 134 live stubs for a now-complete family. Membership is stable (h_seq over original
bytes); only the matched/unmatched split rots. Filter live stubs from src/, not from n_matched.
THE FIRST RUN WAS 0/268 — AND IT WAS A SECOND OPT-IN LEVER, NOT A WALL. Diagnosed one sibling past
the -j16 interleave and the §58 warning noise: `conflicting types for func_80133AB0` (spliced def at
2688 vs a decl at 2429) — the FUNCTION decl-conflict class, not the DATA one T56 fixed. That is
exactly what --normalize-self-decls exists for (the sibling's own caller declares the member in a
different C form than the exemplar's, which used a fn-ptr cast) — and it is OPT-IN, so it never ran.
Re-ran the identical two families with it: 0 -> 132 banked.
0x80133ab0 (137 ins, jr_8012ACE0) 132/132 BANKED
0x80143d28 (80 ins, jr_80140608) 0/136 — a different, undiagnosed blocker
THE PATTERN, TWICE IN A ROW: T56 the DATA decl lever was unreachable from the sweep path; T57 the
FUNCTION decl lever is reachable but OFF BY DEFAULT. Both present as a flat 0/N that reads exactly
like a compiler wall. A 0/N from a sweep is a statement about which levers were enabled, not about
the code.
GATES: R22 clean-fleet 140 passed, 0 failed of 140; tools-health OK (corpus 0 PHANTOM + 0 TRUNCATED,
cdecl, audit-binaries, dedup 1886/0); 0 NON_MATCHING (G4).
METRICS: instr 85.8% -> 86.0% (11279007 -> 11297091 = +18,084 ins); fn-count 90.69% -> 90.73% (+132);
distinct-code 76.4% -> 76.7% (67812 -> 67937 = +125).
SHARPENS the T56 anomaly rather than resolving it: 132 banked here moved distinct-code +125, and
T52's 132 also moved it +125 — but T56's 136 moved it +0. Three PURE families, two behave one way
and one the other. Still unexplained, still not guessed at.
T55's two-part next step as one job. +20,944 instructions banked.
1. THE LEVER WAS UNREACHABLE FROM THE PATH MOST FAMILIES USE (cookbook §107)
§103 was wired into jtbl_family_bank only (T53), and that tool runs for has_mid_jr families.
Everything else sweeps through family_sweep, which gates via PLAIN harvest_verify by design — so
the lever existed, was byte-proven, and most families could not reach it. The symptom was
indistinguishable from a compiler wall: func_80144090 swept 0/136 with `conflicting types for
D_800A651C`.
Why it does not violate the plain-harvest_verify rule: that rule exists because gate_stage's
transforms PERTURB A CORRECT DRAFT (§19/T3). The tu-scope never touches the draft — it moves a
DECLARATION IN THE TARGET TU. The test is not "is it a transform" but "does it change the draft?"
Reused the existing undo instead of inventing one: family_sweep already snapshots TUs it edits at
staging time (--normalize-self-decls) and reverts on a final MISMATCH (not byte-neutral) AND on a
zero-bank group (§61 undo law — no dead diff). The tu-scope shares that dict and inherits both
backstops; renamed nsd_snapshots -> tu_snapshots. Default ON with --no-tu-scope to A/B it (the T24
--allow-pins precedent): byte-neutral by construction, a no-op when nothing collides, auto-reverted
when it buys nothing.
2. THE DUPLICATE-DECL REFUSAL RELAXED — AND IT DID NOT MATTER
scope_tu_externs refused N>1 file-scope decls as "ambiguous"; duplicate-IDENTICAL externs are legal
C, so N identical decls are one decl written N times. Now compares whitespace-collapsed forms and
refuses only on genuine disagreement. MEASURED, and my hypothesis was WRONG: D_800B9A02 is 3 decls
in 2 DIFFERENT forms, so it was correctly refused all along — the family banked 136/136 without it.
RESULT: func_80144090 0/136 -> 136/136, 0 failed, with NO change to any draft.
GATES: R22 clean-fleet 140 passed, 0 failed of 140. tools-health OK (corpus 0 PHANTOM + 0 TRUNCATED,
cdecl, audit-binaries, report/lint/dedup 1886/0). 0 NON_MATCHING (G4).
METRICS (reconciled against make report):
instr-weighted 85.7% -> 85.8% 11258063 -> 11279007 = +20,944 ins
fn-count 90.65% -> 90.69% 320656 -> 320792 = +136
distinct-code 76.4% -> 76.4% +0 (67812 unique, UNCHANGED)
FLAGGING the third row rather than explaining it away: 136 banked functions moved distinct-code by
ZERO, where T52's 132 moved it by +125, and both families are classed PURE. I do not have a verified
cause and will not invent one — either a real property of this family or a gap in the metric. Worth
one probe before that number is quoted again.
T51's payoff. The invocation is IDENTICAL to the T49/T50 runs; the only variable is T51's decl
scoping.
T49/T50 (pre-T51) 4 banked / 133 gate-fail (and all 4 were SC07 — a different cause)
T52 sample (8) 8 BANKED / 8 52s
T52 rest (124) 124 BANKED / 124 13m04s
TOTAL 132 / 132, ZERO failures
So the 133 "gate-fails" were never a codegen wall — they were one file-scope declaration per sibling
TU. Fifth time this phase a wall has resolved to tooling/plumbing.
GATES (from a genuinely clean tree): R22 clean-fleet `make clean && extract-all && check-all` ->
140 passed, 0 failed of 140. `make tools-health` OK — corpus 0 PHANTOM + 0 TRUNCATED, cdecl,
audit-binaries, report/lint/dedup 1886 validated / 0 failed (C1 239604/239604). 0 NON_MATCHING (G4).
METRICS (reconciled against make report, not asserted):
instr-weighted 85.5% -> 85.7% 11240111 -> 11258063 = +17,952 ins
distinct-code 76.1% -> 76.4% 67687 -> 67812 unique fns (+125)
fn-count 90.62% -> 90.65% 320524 -> 320656 = +132 functions
INCLUDE_ASM stubs 33189 -> 33057 = -132
+17,952 templated instructions against T50's ~18,000 estimate. distinct-code gains 125 not 132
because seven siblings are byte-identical to code already counted unique.
ALSO SETTLED:
- item 3 is now byte-confirmed, not just inspected: [gather_externs] warned "func_80135D20 ... the
sibling will not compile" on ALL 132, and all 132 BANKED. A 100% false-alarm rate on this family,
actively masking real causes. cdecl._mask is the fix (T51 used exactly that).
- the T51 pre-pass is now worth folding into jtbl_family_bank; T51 withheld that pending a measured
payoff, and 4/137 -> 137/137 is it. Next task.
config/ (per-overlay splat.*.yaml + overlays.mk, written by the carve) is staged alongside src/ —
the `git add -A src/` omission this phase already recorded once.
T50 func_80135260 family: the §53 carve path banked 4/137 (all SC07), 133 gate-fail, tree clean
after every revert. The 3,744-site conform_decls between runs changed NOTHING for this family (99
attempts observed mid-run, 0 banks) — it is byte-neutral and axis-complete so not harmful, but my
inference that this family shared func_80177DA8's blocker was WRONG: same SC07-only signature,
different cause.
THE REAL BLOCKER, LOCATED: staged siblings are correctly remapped (family_remap works). The draft
requires 4-byte POINTER decls for the contested data symbols — the canonical extern u8 +
(*(u16**)&sym) form makes gcc CSE &sym into two callee-saved regs, costing a 7th saved register and
3 extra instructions (the identical +3 measured on the exemplar). And every sibling host TU carries
the same FILE-SCOPE blocker the exemplar did: verified on ov_SC01_000, whose host TU declares the
contested symbols at file scope (lines 3053-3056) alongside 18 block-scope occurrences. A file-scope
decl constrains every later function in that TU — the T48 finding.
So the fix is the T48 lever replicated x137: scope those decls into their consumers per sibling TU.
Byte-neutral on the exemplar (proven in two steps). That is a TOOL, and it is worth ~18,000 ins.
Also: gather_externs' warning naming func_80135D20 is a COMMENT-SCANNING FALSE POSITIVE (the symbol
appears only in header prose and is defined in another split file). Fires on all 137, masks real
causes. Same class as the Phase-19 garbled-hint bug.
CHECKPOINT REVISED (supersedes the earlier SESSION-23 block): 975 functions banked, reconciled
against the metric (fn-count 319,549 -> 320,524) with the per-task recount agreeing exactly. Fleet
85.5% instr / 76.1% distinct / 90.62% fn-count. R22 140/140 run 11x, dedup 1886/0, 0 NON_MATCHING.
Ranked START-HERE (decl-scoping tool first), the four strategic changes, my five recorded errors —
whose common thread is inference from partial output instead of measuring — and the carried defects.
The §99 conform_decls pass REFUSED this one (§85: 414 callers consume the return), so it was solved
from the DRAFT side. Three blockers, each measured:
1. §94 type-carry, and the draft's own header asserted something FALSE — it claimed both typedefs
already exist in engine_types.h. Measured: Hw4 1 hit, Prim4 1 hit, Env_800D29F8 ZERO. So in the
real TU the #ifndef guard is DEFINED and the typedef vanished -> "parse error before D_800AE7BC".
2. Signature axis: conformed the DRAFT to the fleet's declared `s32 *` return, then param 2
(s16 * -> Prim4 *). Byte-neutral because `src` is used EXACTLY once, as (s32)src. The error
("argument `src' doesn't match prototype") is again printed with NO "error:" prefix.
3. The family sweep went 0/137 TWICE before 137/137.
THE REUSABLE FINDING — a 0/N sweep whose exemplar banks cleanly is the signature of an extract_unit
carry gap. Measured on the staged member drafts:
file-scope extern -> CARRIED
file-scope #define -> CARRIED, but only while its expansion's deps stay file-scope
file-scope typedef -> NOT carried (silently dropped)
#define whose expansion references a BODY-LOCAL extern -> NOT carried
RECIPE: make the draft SELF-CONTAINED — body-local typedefs survive (PTag_80140D68 in this same
draft was the proof all along), and if that pushes a macro's dependency body-local, inline the macro
at its use sites. 0/137 -> 0/137 -> 137/137, 0 failed, each step byte-measured.
R22 clean-fleet 140 passed / 0 failed of 140; dedup-check 1886/0.
Fleet 85.5% instr, 76.1% distinct, 90.57 -> 90.61% fn-count.
§99 arc total (T41-T43): 133 + 1 + 137 = 271 functions. Both blockers Drew green-lit are CLOSED.
Drew green-lit the fleet-shared change. One function at a time from a committed-clean baseline, dry
run first, R22 after each step — the discipline the T39 shared-state hazard earned.
- conform_decls --fn func_80177DA8 --apply: byte-true def `void func_80177DA8(u8 *p, u32 v, s32 idx)`;
268 declaration sites rewritten across 268 files; the tool's own R32 completion assertion reports
"non-canonical declarations remaining: 0 OK (axis complete)" (§85 all-or-nothing as a COUNT, not a
hope). Nothing under src/shared, config or include. R22 -> 140/140: the decl axis is byte-neutral.
- Re-sweep: BANKED 133 / 0 failed, skipped {not-stub: 4} => the family went 4/137 -> 137/137, exactly
reversing T40's failure. R22 -> 140/140. dedup-check 1886/0.
- Fleet 85.4 -> 85.5% instr, 76.0 -> 76.1% distinct, 90.54 -> 90.57% fn-count.
T42 func_80140D68 — the pass correctly REFUSED it (414 callers consume the return, so widening the
return type is not byte-neutral, §85). Diagnosed in the real TU instead (rtu_match + reading ALL
stderr per §95 — gcc-2.7.2 prints hard errors with NO "error:" prefix, so grepping for "error" finds
nothing):
1. parse error before D_800AE7BC = a §94 TYPE-CARRY defect, and the draft's header asserts something
FALSE: it claims Hw4 AND Env_800D29F8 both already exist in engine_types.h. Measured: Hw4 1 hit,
Prim4 1 hit, Env_800D29F8 ZERO. FIXED by keeping Hw4 guarded (it does exist) and moving
Env_800D29F8 outside the guard, draft-local per §100. Still MATCH (65 ins).
2. conflicting types — conformed the DRAFT's return to the fleet's declared s32 * (still MATCH).
Only remaining delta: param 2 byte-true `s16 *` vs declared `Prim4 *`. conform_decls still refuses
(its return-axis precondition fires regardless). OPEN, with the next probe named.
family_sweep --hseq --band all --only <4 cores> -j12 -> 143 banked / 405 failed. R22 clean-fleet
140 passed, 0 failed of 140; dedup-check 1886/0. Fleet 85.3 -> 85.4% instr, 75.8 -> 76.0% distinct,
90.50 -> 90.54% fn-count.
Unlike T33's 548/548, this sweep mostly failed — so the failures were DIAGNOSED, not accepted:
- func_80138C60 swept 137/137 clean.
- func_8013B6A0 / func_8013B598 swept 1/137 each — EXPECTED, not a regression: Phase 20 byte-proved
the -O0 cluster is OVERLAY-LOCAL, so their siblings need per-overlay _o0 carves that do not exist.
- func_80177DA8 swept 4/137 — ROOT CAUSED: its banked def is K&R and its own TU declares it no-proto,
but NON-SC07 overlays declare a PROTOTYPE (extern void func_80177DA8(s32,s32,s32)), so the remap
conflicts. The 4 successes are SC07 overlays, which declare it not at all.
THE SYNTHESIS: that is the SAME §99 K&R-vs-prototype class as item 3's func_80140D68 (K&R def vs 138
prototype callers). ONE conform_decls pass unlocks both — ~17,000 instructions. conform_decls exists
for exactly this ("the draft's signature is byte-TRUTH; move the DECLS, never the draft"). NOT run:
it is a fleet-shared 138+-declaration change and this session already tripped one shared-state
hazard, so it wants an explicit go-ahead (P5).
MY ERROR, recorded: I read a `head -6` list of modified dirs as the complete set and briefly thought
the sweep's count did not reconcile. Measured properly it does — 143 stubs removed across 142 files.
Same class as grepping the wrong field earlier today: truncated output is not exhaustive output.
- family_sweep --hseq --band all --only <4 cores> -j12 -> BANKED 548 member-matches / 0 failed
across 137 overlays. Preconditions CHECKED not assumed: map regenerated first (sig-overlays +
family_hseq) so the exemplars read matched-ov077 not the stale draft-ov077; all 4 families
has_mid_jr=false (§53 carve law) and diff_class PURE 137/137; --band all because two cores are
`mid` and the default `substantial` band would have silently dropped them; --reconcile-raw avoided.
- R22 clean-fleet after the sweep: 140 passed, 0 failed of 140. dedup-check 1886 validated / 0
failed, C1 coverage 239604/239604, 0 NON_MATCHING in any default build (G4).
- SESSION ARC: instr 84.8 -> 85.3%, distinct-code 74.7 -> 75.8%, fn-count 90.34 -> 90.50%.
552 functions banked (4 exemplars + 548 members) ~= 74,802 templated instructions.
- sched.md SOURCE-VERSION CORRECTION: the map declares its source as gcc-papermario, which Phase 23
established is gcc 2.8.1 — not our 2.7.2 — and it was never re-derived. Citations are correct for
the WRONG compiler. One claim is byte-refuted and load-bearing: §1.7/§S12 said the S2 birthing
boost needs SET(REG_pseudo,...) so pins must be removed ("Unpin first"); real 2.7.2
birthing_insn_p (sched.c:2469) tests only GET_CODE(SET_DEST)==REG with NO pseudo check and gates on
reg_n_sets==1 (2490) — hard-reg dests ARE boosted. Corrected in place (old text struck, not
deleted) + a hand-verified 2.7.2 cross-reference table and a warning block.
DRIFT IS NOT UNIFORM: ~+27 in sched.c but +103/+377/+611 in local-alloc.c/reload1.c — big enough to
land inside a different function. ~44 drifted citations across sched/regalloc/loop .md (a screen,
a lower bound). regalloc.md is worst and is NOT yet re-derived — named as next.
- All line numbers verified by me against tools/reference/gcc-2.7.2, not taken from the agents.
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.
Drew T