- 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.
Drew's call (2026-08-01, P5d in-phase re-plan): gate 2 was reached and deliberately NOT taken —
closing now would strand roadmap-v2 bucket W3 (the overlay family mass) with no owner phase
(P31 = scope-complete/main/resident, P32 = walls/behemoths).
Order derived from the S29 frontier regen, ranked by TEMPLATABLE weight:
S1 zero-crack propagation (29 families / 67,470 ins, ~0 agent tokens)
S2 the LAST two reach-138 fresh cracks (func_80176734 51,198 + func_8016EC0C 12,144)
S3 close=0 stored drafts as a DIAGNOSTIC pass (not a blind re-sweep)
S4 PINS bounded wave (14 fns / 44,279 ins)
S5 the x10-133 mid-multiplicity families (142,527 ins)
Excluded: the 2 GIANT walls (P32), the x2-9 mass, the x1 singleton residue.
THE PRICING FINDING (R14/R35): worklist.md ranks by h_exact reach, so a per-location PURE family
is priced x1 — under-pricing the frontier head by up to 138x. Byte-proof: S29's pair was priced
272 and 198 ins and delivered 37,536 + 27,324. func_80176734 (the single largest item on the
board) sits at rank ~50 in worklist.md. Rank family work by .run/family_hseq.json.
THE STRUCTURAL SIGNAL: after S2 the x138 era ENDS (last two crackable fleet-wide families);
everything after is <=133 members and mostly <=9. That cost-per-point rise, not a session count,
is P30's honest ROI floor and T5's trigger.
- tools-health OK: sigs regenerated post-bank; corpus(+resident) 0 PHANTOM/0 TRUNCATED; cdecl;
audit-binaries 140/140 citizens (R36); report(lint+dedup) 1905/0; cookbook-index 357 sections.
- Fresh overlay frontier at HEAD: 93.6% fn / 90.1% instr / 82.5% distinct; unmatched 22,550
instances / 1,298,980 ins / 15,029 distinct classes -> 2,414 families + 3,767 singletons
(472 substantial / 543,901 templatable ins; 29 zero-crack).
- T1 ticked with its honest scope: delivered as T1a (+18 banked, 16% vs the S16 39% prior which did
NOT generalize); the ~90 integration-decayed drafts route to T3 redraft lanes (A10).
- T3 ticked with a PER-LANE verdict: Lane B (top-mass) pays and is not exhausted; Lane C (x2-reach
cached tail) is at the floor (1.33M tokens -> 12 banks -> +0.00pp). The ROI floor is a lane
property, not a phase property.
- 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.
I reported func_8013B83C + func_8013BD74 as "BOTH BANKED - BYTE-IDENTICAL". That was
WRONG. My in-loop gate ran `make extract && make build` without `make clean`, and it gave
a FALSE PASS. The clean rebuild does not link at all:
ov_SC01_077_o0.c:(.text+0x10f8): undefined reference to `$L105'
ov_SC01_077_jr_801588CC.o: undefined reference to `func_8013C938'
- the first is a local label from the C-emitted jump table;
- the second is a PREVIOUSLY-MATCHED cluster fn going undefined (the incremental build
reused objects that still satisfied it).
Reverted; R22 140/140; nothing lost, nothing was committed.
SS42b named the stale-object trap for a FALSE FAIL. This is its MIRROR: a FALSE PASS, on a
change that is not even linkable — false in the most convincing direction possible, a green
SHA. Anything touching config/ (carve, resegment, split) must be gated by a full
clean-fleet R22 before it is BELIEVED, let alone reported.
THREE WRONG CLASSIFICATIONS ON THIS PAIR, all corrected in the ledger:
CC1-FAIL-UNREAD -> it has no compile error at all
JTBL-PAD-SPEC-DRIFT -> I had carved ONE fn of a TWO-table span; carving both gives
pad spec [0,4,4] and the filter is satisfied
"both banked" -> the false pass above
Real class: JR-PAIR-IN-ONE-O0-OBJECT. Both bodies ARE byte-correct (match_one --o0 and
rtu_match --o0 both MATCH, 272 / 198 ins); the blocker is integrating TWO jr fns into ONE
-O0 object. Untested escape: SS81 step 1, isolate one into its own code subseg so each
object owns exactly one table.
Also records the diagnostic ladder that found it: diff the two BINARIES and bucket each
differing byte against the function's own vram range. 3,749 of 3,791 diffs were OUTSIDE the
function, first diff near the overlay START, image 57 bytes LONGER - the SS8 signature of
.rodata floating to the front. That fingerprint separates a codegen residual from a layout
effect in one build, and it is what finally redirected three wrong guesses.
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.
First Ultracode wave against the population the -O0 routing made draftable. 30 agents
(15 drafters + 15 adversarial verifiers), 1.33M tokens, 8.8 min. Every drafter self-checked
with match_one --o0 AND rtu_match --o0; every MATCH claim was then re-run from scratch by an
independent skeptic instructed to default to REFUTED. Result: 15/15 confirmed, 0 disputed.
WHOLE-BINARY GATE (the sole arbiter, G3/P9): **12 banked / 3 failed** — a textbook SS52b
outcome (an rtu MATCH is a CANDIDATE, not a bank). All three failures are NAMED INTEGRATION
classes, none a compiler wall:
func_8013BD74 CARVE-REFUSED — it is a jr function; needs the SS81 carve chain (reach 138)
func_8013B83C CC1-FAIL — real-TU compile, error not yet read (reach 138)
func_80184058 PLUMBING — recovery ladder
BANKED: func_8013C08C + the 11 fourth-region fns (func_80183CF0/D50/F28, func_80184028/264/
2E0/354/474/538, func_801847EC, func_80184868).
Bank truth read from the SOURCE (INCLUDE_ASM absence), never the gate report (SS55b trap 4).
R22 CLEAN-FLEET: extract-all 139/139 (+main); check-all 140 passed, 0 failed of 140.
PROPAGATION OF func_8013C08C (reach 138) IS NOT DONE: the first sweep returned "0 families"
because the family map still listed it as a stub — regenerated it (the documented
crack-wave-sweep-map-regen path), after which the sweep found 137 candidates and banked
**0/137**. Per SS94 a family 0/N is a TYPE-CARRY failure until proven otherwise, and this
body carries a SS100 body-scoped typedef, so that is the first hypothesis to test. Recorded as
open, NOT as a wall.
FLYWHEEL FEEDBACK (R16), the honest read: the cookbook index fired on only 3/15 targets.
Agents independently re-derived the SAME undocumented idiom — the -O0 CONSTANT-OFFSET FOLD
(`p->f` folds to `lbu 3(r)`; `p[i]` does NOT, it emits `addiu; lw 0(r)`) — and two found their
decisive levers in a SOURCE HEADER COMMENT in ov_SC01_077_o0.c rather than in the cookbook.
The -O0 regime is under-documented relative to how much of the frontier now lives in -O0 TUs.
SS71 also generalises to -O0: several agents cracked their target off an already-banked sibling
in the same TU (func_80184868 came straight off the shape banked earlier today).
(1) --fix-def-sig POSTURE: AUDITED CLEAN. `action="store_true"` (defaults False), one
consumer via getattr(a,"fix_def_sig",False), and NO caller anywhere passes it — checked
tools/, .run/ scripts, docs recipes and the Makefile. The flag help already carries the
SS119 warning.
BUT the audit surfaced a live hazard the earlier pass missed: docs/decision-log.md
still recommended "--fix-def-sig should likely be default-on for the h_seq path".
That was byte-REFUTED by T84/SS119 — the flag is a REPAIR, not a default; on 0x80161c98
it imposed a signedness-wrong `s32 a1` over the true `u32`, turned a byte-correct draft
into a 1-instruction DIFF (slti vs sltiu), and held 137 members at 0 until DROPPED.
Struck through in place with a superseding note rather than deleted, so the original
reasoning stays legible (R31) — but a forward-looking "should be default-on" sitting in
a doc a fresh session reads FOR DIRECTION is a hazard, not a historical note.
(2) GRINDER WARM-START: tools/permuter_ils.py has sat beside grinder.py since Phase 24 and
was never wired in, so every grind was a COLD search that burned its whole time box
re-descending ground the previous run had already covered. grinder.py now runs `--cycles`
(default 4) timeboxed permutes, each warm-restarted from the previous cycle's best byte
waypoint, stopping early on no gain. `--cycles 1` reproduces the old cold behaviour exactly,
so it is opt-out. --permute-secs is now documented as the PER-CYCLE box.
JUSTIFIED BY MEASUREMENT, not by the task list: the lane looked dead (Phase-22 audit: 7
all-time banks, all Phase 21, 0 since), so I checked for live fuel before building. The
backlog holds 665 open near-misses in the permuter-tractable band (close 1-20), 157 of them
close 1-4, including func_8016BA68 at close=1 with reach=134.
HONEST LIMIT: this is a WIRING change whose yield is UNPROVEN. The Phase-24 evidence for ILS
is one function (func_80148094, 72 -> 36 over ~8 restarts); I have not run it on this
backlog. A winner remains a CANDIDATE — the whole-binary byte-gate is still the sole arbiter
(G3/P9), and an intermediate waypoint is only ever re-seeded, never banked.
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.
I under-counted this cluster 8x (reported 275 stubs/18 overlays; truth 2,184/138). The
scan ran during a background rebuild AND wrapped corpus.stubs() in `except: continue`,
so every R32 coverage refusal became a silent skip and the total was taken over the few
overlays that happened to be re-extracted already.
Two of our own rules broken at once: a measurement taken during a rebuild is not a
measurement (caught EARLIER the same session, by the same assertion I then suppressed),
and R32 lives in the CALLER — an oracle only asserts coverage if the caller lets it raise.
It also cost credibility the other way: I used the bad number to declare the T0(f)
"2,192 open members" pin STALE. The pin was right. R35 applies to a re-measurement as
much as to the original measurement.
Checkpoint updated with the corrected population and the completed fleet-wide sweep.
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.
Promotes the proven probe (commit:1266) into a real tool, and validates it FIRST-TRY on a
fresh overlay.
tools/o0_subsplit.py <ov> --lo <vram> --hi <vram>:
- derives the range's contents from the SOURCE ANCHORS (overlay_src_split.parse_overlay_c:
`asm` = unmatched stub, `define`/`def`/`nonmatch` = already matched), NEVER from an asm
scan -- a matched fn emits no .s, which is exactly the blindness that made the range look
like a clean contiguous run (SS126 / SS124's shape);
- computes the -O0 bound as (address range MINUS already-matched bodies) and emits ONE
sub-region per maximal run of unmatched anchors (K matched islands => K+1 regions);
- names each `<ov>_o0<letter>` picking free suffixes, so the widened Makefile glob selects
them; refuses loudly if it runs out or if the range spans >1 object or is already -O0;
- honours the one-carve-per-region law (forces a cut at every already-banked jr in the
object) and reuses jr_isolate_all's plan/build_new_config/ascending-unique validation
verbatim, so carve-repoint + source-repartition stay on the proven path;
- warns (does not refuse) when a stub in an -O0 run lacks the frame-pointer prologue --
the byte-gate is the arbiter, not the heuristic.
VALIDATION on ov_SC03_015 (untouched by the manual probe): the tool independently derived the
SAME structure found by hand on ov_SC03_014 -- 2 matched -O2 islands (func_80184440,
func_801848E4), 2 -O0 regions (8 + 7 fns), same 5 cuts. Sub-split -> BYTE-IDENTICAL. Then 3
drafts, each global DERIVED FROM THAT OVERLAY'S OWN ASM (%hi operand) rather than copied:
3/3 match_one --o0 MATCH (22 ins), 3/3 through the whole-binary gate.
BANKED this commit: func_801846E4 / func_8018473C / func_80184794 in ov_SC03_015 (6 across
the two overlays now). The other 24 stubs in the region are undrafted -- the route makes them
DRAFTABLE (they were un-bankable at any effort before); drafting them is crack-wave work.
R22 CLEAN-FLEET: extract-all 139/139 (+main); check-all 140 passed, 0 failed of 140.
cookbook SS126 (the address-range-is-not-an-optimization-region law + the probe ladder).
Max-effort re-measurement of the three jr refusals I ledgered earlier this session.
Two of the three verdicts were FALSE. Every number below is SHA vs config/check.<ov>.sha
from a clean tree, with the restore re-verified.
func_8018057C / ov_SC01_009 : jr_isolate_all is BYTE-NEUTRAL
-> "JR-ISOLATE-BREAKS-BYTES" RETRACTED; original failure not reproducible.
func_80191C50 / ov_SC06_018 : isolate NEUTRAL -> carve DIVERGED
(got 1b1667ea, want cbbc4f44) -> the ONE real instrument failure. CONFIRMED.
func_8017BEBC / ov_SC04_004 : carve is BYTE-NEUTRAL (body-free)
-> failure is the TEMPLATED BODY, the OPPOSITE of what SS125 first claimed.
Re-probed once more from a verified-clean tree: still gate-fail. Reclassified
BODY-TEMPLATE-GATE-FAIL.
So the tidy "two apparent walls are ONE tooling problem" conclusion was wrong: they
are two different problems, and the third target has no demonstrated problem at all.
ROOT CAUSE, and it is mine not the tools': a grep-of-the-build-log gate inside a driver
that did not revert on abort. config/overlays.mk is SHARED, so target 1's half-applied
isolate was still in the tree while target 3 was measured. Separately reproduced the
SS42b stale-object trap head-on: `git checkout -- config/` WITHOUT a re-extract turned a
byte-identical overlay into [FAIL] got 8f28aa77 / want 38a3d919 (Phase-20's R22
corollary, live).
SS125 rewritten. The METHOD (split the carve from the body, one build) is kept and is
what refuted this section's own first conclusion; what is added is the instrument rules
that make its answer trustworthy: compare the SHA against config/check, never grep the
log; re-extract after every config change AND every revert; a driver that aborts a
target must revert it before the next; verify the BASELINE against canonical too.
Meta-lesson recorded: SS53 says a 0% from the wrong TOOL manufactures a doctrine — this
is the same failure one level up, a verdict from the wrong MEASUREMENT, and my own
diagnostic script is an instrument subject to R35 like any other.
Ledger corrected in place (3 entries, superseding the earlier misattributions), so the
scheduled repair is the right one. No source/config change; no bank affected; the fleet
is untouched at 140/140 (last full R22 this session, HEAD commit:1263).
The session's most useful finding is an instrument ticket, not a match.
SS125 (new): before ledgering any jr residue, run jtbl_carve with NO body spliced
and rebuild. Byte-identical => the carve is neutral and the failure is the template;
NOT identical => the failure is the carve and the body was never fairly tested.
One build, and it collapses ambiguity that SS53 warns has twice steered strategy.
MEASURED: group B func_8017BEBC had gate-failed 3 probes in a row (default AND
--raw, cross-address ov_SC02_015 AND same-address ov_SC04_004). Carve-only on
ov_SC04_004 broke the bytes with nothing spliced — so all 3 probes were testing a
body that never got a fair run. The SAME stage had already refused behemoth
func_80191C50/ov_SC06_018. Two "unrelated walls" = ONE tooling problem.
func_8018057C/ov_SC01_009 fails at a DIFFERENT stage (jr_isolate_all, step 1) and
is deliberately NOT grouped with them.
Both tools reported SUCCESS on every failing target; only the whole-binary gate
refused (G3/P9). A tool's exit code is not the oracle.
Ledger: the three logged by STAGE (JTBL-CARVE-BREAKS-BYTES / JR-ISOLATE-BREAKS-
BYTES), not by function, so a carve fix auto-reopens every target it should.
None is diagnosed, so none is called a compiler wall — that guess has been wrong
four times running on this project (R35).
CURRENT_PHASE: SESSION-28 checkpoint refreshed; the carve diagnosis is now resume
item 1 (it gates 13 members + a 710-ins behemoth and every future jr family).
- §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.
Every line is a symptom an agent HIT and had to re-derive from gcc internals because title-keyword
search structurally cannot surface it:
- SIZE-MISMATCH/short + frame-pointer prologue => the target is -O0, pass --o0 (the flag was
documented nowhere an agent would look; a 4th -O0 region also exists beyond the 3 known ones)
- rotated instruction window => sched1 order; brute-force all N! statement orders (24 runs, 2 min)
- if/else result in $v1 vs target's $v0, and load-hoisted-above-store => §76 variable reuse
(§76's title reads behemoth-only, so nobody finds it for a 48-ins function)
- ori 0xffd8 vs addiu -0x28 => negative const in an UNSIGNED narrow local; signed keeps the lhu
- LENGTH-DRIFT -1 as a missing jal-delay copy => narrow ANSI prototyped param (not just K&R §43)
- lwl/lwr+swl/swr is a delay-slot SPONGE (the inverse of the §5a fence case)
- a vanished param copy => cse.c make_regs_eqv live-range rule
- a ghidra_c seed may be a DIFFERENT function (overlays share VAs)
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.
WAVE-2 MEASURED THE INDEX: 15/19 index hits and the bank rate went 57% (wave 1, no index) -> 79%
(wave 2, index-first) on the same gate. Agents also NAMED its gaps, which is the flywheel working.
Two real defects found and fixed:
1. COVERAGE. The parser required a '§' prefix, so 111 h2-h4 headers were invisible — including
'### T4 — Branch polarity', the fix match_one names by class (BRANCH-POLARITY) and which two
agents re-derived by hand, and the §1/§2 idiom-catalog entries (I1-I4, T1-T4).
2. THE ASSERTION ITSELF. My R32 check compared §-headers-parsed against §-header-CANDIDATES — a
tautology over a set I had already narrowed. R32 says the candidate set must OVER-approximate;
it now counts EVERY header and accounts for each as indexed-or-explicitly-skipped. The tool
written to stop silent skips had the silent-skip defect.
3. Keyword matching over titles cannot surface an idiom whose title omits the symptom, so the
index now opens with a hand-curated SYMPTOM -> section list, seeded from what agents actually
hit (branch polarity, (void)-canon conflicting types, asm-label alias, one-base-register reuse,
folded andi, slti/sltiu, sibling-first, delay-slot theft, void->s32).
Wave-1 measured the tax: three agents each reported a 'NEW idiom' that was ALREADY documented —
the asm-label alias (line ~2516, same 'address-of perturbs regalloc' mechanism) and the void->s32
non-neutrality (§41d, Phase 26; the agents cited the very entry §41d corrects). They consulted the
cookbook as instructed and could not FIND them. 716 KB / 226 sections with no index = a
discoverability failure, and every wave re-paying for prior waves' findings is the inverse of R16.
docs/cookbook-index.md maps SYMPTOM (what you see in the diff) -> sections, 14 buckets, a section
listed under every symptom it addresses. Derived by tools/cookbook_index.py (R33 — cannot drift),
--check wired into tools-health.
R32 on my own tool: the first regex required an em-dash separator and silently dropped 50 sections
— including §1 (idiom catalog), §2, §5a (cross-jump, cited by an agent today). An index missing its
most-cited entries turns 'I could not find it' into 'it is not there'. Now asserts extracted ==
candidate '§' headers and hard-exits on a gap.
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.
o0b-bearing != o0b-adjacent: T85's 0x801457A4 banked by append only because it abuts the o0b
object's END; the 0x8013Bxxx-0x8013Cxxx families mis-place by construction (probe 1/1 gate-reject)
and per-fn isolation IS the Arm-A re-carve. Frontier report corrected; T2 pivots to the Arm-A
+0x20 defect itself (symbol-pin hypothesis first). Driver stands as the post-fix sweep harness.
One representative per remaining h_seq distinct class + all main/resident stubs -> .run/ghidra_c/.
Resumable (skips cached); serial on the exclusive project lock; auto-stops a serving MCP (R23);
imports missing overlay programs on demand via ghidra_import_raw.sh (blob derived via
family_remap.img_path, vram from the splat yaml — R33, never guessed); R32 per-program outcome
report, continues past failures. Dry-run: 126 programs / 7,966 uncached representatives.
- STAGE 0: gate the RAW drafts before any transform (GATE_NO_STAGE0 escape) — the carried
'ladder destroys good drafts' defect (SESSION-22 reproduction: _o0 pair + func_80138C60,
ladder-FAILED/bare-VERIFIED) is impossible by construction; ladder+arity now touch only
stage-0 failures. TU-blind-transform root-cause hypothesis recorded in-code, open.
- fix_arity_callers --journal/--undo-journal --keep: exact per-edit undo in the WRITER,
shared by ladder AND bare workflows (the 17-TU residue class); replaces the two-special-case
file snapshot; undo moved after stage 2 (closes the stage-2 arity parity gap); stale-journal
guard. Negative-control: apply->undo byte-identical; --keep exact.
- Flow test .run/t0a_flowtest/driver.py 7/7 PASS. Cookbook §122. CURRENT_PHASE T0(a) logged.
- 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).
- T80: the §116 rollout prescription was WRONG and the build refuted it in 56s across 133
overlays. "Byte-neutral by construction" was a claim about the LINKER; splat keys asm/
generation to the SEGMENT, so deleting func_801457A4's INCLUDE_ASM from <ov>_after.c stops
func_801457A4.s being emitted and <ov>_o0b.c cannot assemble. Reverted, nothing committed.
Cookbook §116 corrected IN PLACE with the refutation + the corollary (build it before you call
it neutral). Real route: a two-file atomic driver (body -> _o0b.c AND drop the stub from
_after.c in one edit). 129 distinct still on the table, now costed.
tools/rollout_801457a4_o0.py kept as the inventory pass ONLY — do not --apply.
- T81: 0x80131eec 0/288, and the two halves have DIFFERENT blockers — func_80151944 (138)
staged and gate-failed on the T71 decl conflict; func_801599A4 (137) + 13 singletons were
REFUSED AT REMAP for unresolved immediates and never reached a compiler. My prediction that
the correct-decl half would bank was the T76 error shape (reason from one property, ignore the
disqualifying diff_class: IMM) — recorded, not buried.
CORRECTION IT BUYS: T71's "the immediate engine is not the bottleneck" holds for T70's
families and is FALSE here (150 of 288). T2a immediate resolution is now a named, sized lever.
- Refuted from source before spending a probe: the reloc tracker DOES see a function address
materialized as an argument (LO_OPS includes addiu), so 0x80174784's 2/255 is not that.
- SESSION-25 checkpoint: fleet 86.9% instr / 77.4% distinct / 91.41% fn-count; 641 banked this
session; ranked next-list with all six items measured. Nothing running, tree clean.
Drew T