- the quick hi/lo sweep paired lui/lo16 WITHOUT tracking base registers -> phantom refs
(0x800AE868 read where the true target was 0x8018E868); register-tracked rescan: the ONLY
literal loc-table ref fleet-wide is SC02/9's (solved)
- standing truth: MAIN/7, MAIN/9, SC03/53/54/56 all load via table-INDEXED paths; homework
respecified (descriptor-data hunt + ResourceGetCdLoc/StreamLoad index math)
- fn 0x80161E08's real gate: currentLocationId vs {0x3012,0x3054,0x3079,0x3096} — the
'variable 0x800C3054' never existed; cookbook §155 (track the register)
- the gate DECODED from matched C (func_8012832C case 0x300E -> func_80128998 -> streaming
API with &cdFileLocTable[144]) -> scene arithmetic named the 1ST-BOSS arena -> ONE targeted
load captured it at 0x801E4C60
- RETRO-VERIFIED: Phase-3's dumps/ram_castle.bin (2026-06-14) holds it at the SAME address,
same 6,764-B exact prefix — R10 two independent datapoints two months apart;
bossHp_SteamKnight (0x801E4398) lives inside this module's image
- onboarded md_SC02_009 (id 0x3E, TLO 0x4): BYTE-IDENTICAL first build; fleet 213;
R22 213/213; tools-health OK; audit-disc UNCLAIMED 6 -> 5, residue 0
- the last 5 (MAIN/7, MAIN/9, SC03/53/54/56) reclassified emulator->STATIC-RE targets with
decoded leads (memory-map §S45 p3); loc-id map appended to docs/debug-menu-list.txt
- negatives banked: pause menu, memory-box prompt, new-game intro, high/low game, Minku
spawn (slot-A actor 0x15 = md_MAIN_015 candidate naming)
- THE TOUR (Drew driving the retail debug menu; mode-7 hammer over the Redux web API):
all 28 script modules captured live at four byte-verified per-chapter slots
(SC03/73-79 @0x801EF468 ch2-period, SC03/132-138 @0x801E25E8 ch3, SC04/24-30
@0x801E7B28, SC05/23-29 @0x801ED988); the routing law: debug-menu AREA selects the
chapter, each CITY interior streams its own module (member k <-> interior k).
md_MAIN_011/DISELECT byte-proven 24,236/24,240 in RAM; slots A/B/boot R34-verified live.
- MAIN/3 DISCOVERED: the main-menu module (id 0x39, 121,884 B), mis-bucketed as data by
BOTH audit oracles; live byte-proven @0x800CEDF8 (42,632-B exact prefix); onboarded.
- 29 onboardings BYTE-IDENTICAL on first build -> fleet 212; R22 212/212 after three
md_MAIN_003 catches: the A4 DsMix leak; an extract-order-sensitive splat boundary
(bytes: a 1-word data sentinel in .text + fn at +4 -> pinned in symbols file);
corpus.stubs now treats D_*/jtbl_* INCLUDE_ASM as blob includes (mirrors progress.py)
- module-id census (offline, disc-wide): 77 id-law code payloads, 0 further misses;
SC03/55 = confirmed DATA. audit-disc: UNCLAIMED 34 -> 6, residue 0 — the 6 carry
byte-checked negative evidence; next tier = the CD-read tracer
- docs: memory-map §S45 (slots + routing + debug-menu ops), disc-completeness S45
addendum, decision-log R31 entry, docs/debug-menu-list.txt (Drew's transcription)
- .run/s45 evidence allowlisted (tour logs/scripts/rosters); 104 ram dumps LOCAL-ONLY
- new baseline: 93.8% instr / 95.68% fn / 87.2% distinct over 212
- roadmap §1.1: 183 onboarded binaries; the 100% claim's exclusion list = the 34-row
parked-for-L3 ledger (28 script + SC02/9 + MAIN/7/9 + SC03/53/54/56 — 3 rows S44 never
tiered); supersedes the '39 type-1 backlog' framing (43 of them now build byte-identical)
- disc-completeness.md S45 section: what landed, the full parked list, the L3 resolution path
- decision-log: the S45 entry — five instrument findings a 'mechanical' batch surfaced, each
negative-control-proven; honest baseline 94.0% instr / 95.96% fn / 87.6% distinct over 183
- DELETED: disc_code_sweep.py (superseded by disc_audit/make audit-disc), reconcile_decls.py
(superseded by reconcile_tu; incumbent row removed from cdecl audit_differential — the
differential existed to prove this deletion safe), rollout_801457a4_o0/rollout_whale_o0/
rollout_o0_cluster one-shots (rollout_o0.py is the live generic), ImportOverlay.java +
VerifyOverlay.java (ghidra_import_raw.sh is the live path)
- reference check first (R14): the plan's 'zero build refs' was wrong for 3 — comment refs
annotated, the one LIVE import (cdecl) reworked; audit-cdecl + tools-health re-proven green
- SETUP §6.7: module-class recipe (TEXT_LO derivation, paired-.rodata hdr carve, A4 symbol-
window law, ELF-seeded sig-modules) + new_binary.sh inventory row + 3 RETIRED rows (R21);
disc-completeness Reproduce marked retired
- the .run/sig.ov_*.jsonl glob had no md_ entries, so every module member fell into an
empty stubs.get() and booked a silent 'not-stub' skip — the I.1d glob-widening class,
missed because family_sweep sat on the audit's 'auto-OK' list
- negative control: --only 0x80165b28 --stage-only staged 0 md members before, 32/32 after
- slot A 29/29 (md_MAIN_013..041 @ 0x800CAE08), slot B 6/6 (md_MAIN_042..047 @ 0x800CCB1C),
boot trio 3/3 (md_MAIN_001 [=MAIN/0 twin], md_MAIN_008, md_MAIN_011 @ 0x800CEDF8) — every one
BYTE-IDENTICAL on its FIRST build (byte-corroborating the §S44 loader table for slots A/B/boot)
- TLO roster derived from the §154 id-word law (.run/s45/derive_tlo.py): 0x4 default;
011=0x7C, 025=0xC, 034=0x80, 039=0xC (first-prologue scan)
- new_binary.sh: module hdr carve is now a dot-typed .rodata PAIRED with the c segment —
a header can hold a function's jump table (md_MAIN_034), and standalone rodata emits
.L locals that don't cross objects; bin links in the data block (both refuted by bytes)
- A4 law: symbols.resident.txt dropped from the boot trio's stacks (windows inside the
resident region; DsMix @0x800D1BD8 had minted a phantom fn boundary in md_MAIN_011) —
re-extracted clean, all three byte-identical, phantom gone
- R22 clean-fleet 143/143; fleet 96.13% fn / 94.4% instr (honest grown denominator; pre-expansion
line 95.00% on 140 kept for continuity) / 88.3% distinct. audit-binaries OK over 143.
- make audit-disc: UNCLAIMED 78 -> 75 payloads (3,564,021 -> 2,038,104 B), residue 0 — the three
claims flipped automatically via check.sha, exactly as the ledger was designed.
- S44 session total: 5,126 member-functions banked into the 3 new overlays; the ~2,051 remaining
stubs are the new frontier, visible to every tool via citizenship (no separate ledger rows —
recorded as a deviation from plan I.2e, redundant by construction).
- Part II handoff live in the plan file + the S44 checkpoint block.
- family_sweep --hseq scoped by --only to the 637 families with a matched exemplar AND a member in
the new 3 (2,232 stageable; avoids re-gating the swept-dry fleet). BANKED 290 / 81 failed /
6 skipped (unresolved immediates), every one whole-binary byte-gated; all three SHAs green.
- Session total into the big 3: 4,836 h_exact + 290 template = 5,126 member-functions.
- Remaining stubs 624+717+710 = 2,051 = the ~802 novel functions x instances + the genuinely
failed/unstageable tier (the new frontier).
- tools/dedup_extend.py over the clean tree (the prior run correctly REFUSED my uncommitted tree,
H4 — that refusal was the tail I misread as a result; and my earlier '0 stubs left' was a
single-file grep -c display artifact, caught before being reported).
- BANKED 4,836 / 5,016 planned (1,612 DEFINE_func per binary; 180 skipped incl. 8/binary
verbose-form). Each splice byte-gated; all three binaries remain BYTE-IDENTICAL (SHA re-checked
per binary post-run). engine_core.h include added -> audit-binaries green again (R36).
- Remaining stubs: ov_MAIN_012 712 · ov_SC02_037 822 · ov_SC03_107 802 = the h_norm-only tier +
the ~802 novel functions (the new frontier).
- Three uncompressed (PAC type-1) overlays at the standard 0x80128158 slot, onboarded via the new
tools/new_binary.sh, each byte-identical at 100% INCLUDE_ASM on the FIRST build:
ov_MAIN_012 d6b3e8b9 (383,783 B, 2,324 fns)
ov_SC02_037 b0c5394a (661,903 B, 2,434 fns)
ov_SC03_107 87d02b57 (474,087 B, 2,414 fns)
This also BYTE-PROVES the statically derived base (the §S44 loader table + the 500:1 h_exact
vote): a wrong vram could not have produced byte-identical images once symbols resolve.
- Fleet: 140 -> 143 binaries. audit-binaries currently FAILS on all three by design (no
engine_core.h include yet — the SC07-blindness check working as built); dedup_extend is the fix
and the next commit.
- Registered by the script: overlays.mk blocks, check.sha, symbols seeds, the 3 BINARIES dicts.
family map regenerated (3,577 target families / 279 with a matched sib — the new binaries'
members now visible).
- Generalized from new_overlay.sh: ALIAS + PAYLOAD + VRAM + optional TEXT_LO (file offset of code).
Class registry chosen by alias prefix (ov_* -> overlays.mk, md_* -> modules.mk; modules.mk
created with its contract header on first use). Fixes the two places new_overlay.sh re-hardcoded
the slot literal instead of $VRAM (:39 TEXTHI, :44 CODEEND).
- TEXT_LO wires the §154 module-id law end-to-end: sig bootstrap gets --text-lo (else 0 functions
on 75/78 payloads), and the splat yaml gets [0x0, rodata, hdr] + shifted code start (the
resident's leading-word trick — ONE shared template, no second file, R33). _TEXT_LO lands in the
mk block as a VRAM for make sig-modules.
- The sentinel-anchored 3-dict registrar + check.sha/symbols/extract/build steps reused verbatim.
- new_overlay.sh is now a 30-line WRAPPER (same CLI, docs preserved, H5); exec's new_binary.sh with
the overlay defaults.
- family_hseq: widened from src/ov_*+sig.ov_* to every non-main binary (resident + md_*); the map
now carries 139 binaries incl. resident (was overlays-only — which is exactly why the R36 gate's
CHECK 4 could never see them). Self-count uses the SAME widened globs (cannot drift).
- progress --weighted :647 + audit_frontier :57: + sig.md_* globs.
- corpus.sig_is_independent: md_* sigs are sig_image-signed => independent (R34 trust).
- backlog alias regex + prefetch_fleet (md_* derived from splat configs) + dedup_propagate
(reads modules.mk alongside overlays.mk — excluding modules would re-create the SC07
invisible-work bug one class over).
- VERIFIED: family map regenerated with resident (139 binaries); audit-binaries OK over 140;
all six tools parse.
- onboarded() derived from EVERY config/splat.<alias>.yaml (R33; templates + us.exe normalized) —
was splat.ov_*.yaml + a hand-set {main,resident}: the gate that exists to catch unwired binaries
was itself structurally blind to any class it did not know about.
- CHECK 4 widened: resident + modules must appear in the family map too (only main is exempt —
structurally barren, checked twice in S39). New honest warn: resident missing from the current
map (family_hseq widening lands next commit).
- NEGATIVE CONTROL: a planted config/splat.md_TEST.yaml FAILS check 1 ('MISSING md_TEST — invisible
to every derived tool'); removing it restores OK over the 140.
- -include config/modules.mk (silent when absent, same contract as overlays.mk) and
BINARIES += $(MODULE_BINARIES). Everything downstream of $(BINARIES) — prune, check-all,
build-all, expected — is untouched and picks modules up automatically.
- NEW sig-modules target: signs every module at ITS OWN vram with ITS OWN --text-lo (the §154
module-id-word law — bootstrap from offset 0 yields 0 functions on 75/78 payloads). Derived
MODULE_SIG_JOBS from modules.mk (R33, the sig-overlays pattern). Wired into tools-health after
sig-resident. Empty registry = clean no-op (verified).
- NEGATIVE CONTROLS: make -n sig-modules iterates an empty list; main rebuilds 143dbb89
byte-identical with no modules.mk present.
- VRAM was a module constant (0x80128158) used in ALL offset math (reloc_targets :98, stream_words
:160) — correct for the 138 shared-slot overlays, silently WRONG for every other class (resident
0x800CEDF8, the new md_* module slots): addr-VRAM would read garbage bytes without erroring, the
R32 silent-skip shape in the tool the whole family engine stands on.
- NEW vram_of(alias): read once from config/splat.<alias>.yaml (the jtbl_carve pattern; cwd-relative
like img_path). Unregistered alias raises LOUD (R32, no default).
- REGRESSION: the 0xECC-family remaps (ov_SC03_003/ov_SC04_021/ov_SC05_019) are byte-identical to
the S43 banked drafts. Negative controls: resident derives 0x800CEDF8, overlays 0x80128158,
unregistered alias raises.
Plan-approved campaign (Fable5Max, ~/.claude/plans/optimized-squishing-engelbart.md). I.0 = capture
while hot (R30/R31), before any code:
- memory-map.md §"Phase 30 S44": the COMPLETE loader routing table, static-derived (G5) — the EXE's
loadDestPtrTable (0x80072C70: resident/overlay/slotA/slotB/type-7), the boot k-set {1,3,8,10,11},
the RESIDENT's index tables D_800D3764 (29x8, MAIN/13-41 -> 0x800CAE08) and D_800D384C (6x8,
MAIN/42-47 -> 0x800CCB1C), resident.c:641 (MAIN/12 -> 0x80128158), the SC07 pair's header-derived
0x801A00D8, gbase arithmetic (LIST.CD carries LBA+len ONLY), the slot-adjacency proof, the
module-id-word law (word0, dense 0x13..0x73, resident=0x36; MAIN/9-vs-39 duplicate flagged), and
"PAC type 1 = uncompressed overlay, type 4 = LZSS". SUPERSEDES P3-T5's "entries [1]+ are
runtime-indexed (no static xref)".
- disc-completeness.md: the "only knowable by runtime RE" doctrine REFUTED in place (H5, original
kept) — 46 of 78 addresses are static; the runtime-only remainder is 28 script modules + 4
stragglers, parked for L3 with evidence. Byte-sum correction (rows 3,406,325 B vs bucket
3,564,021 incl. PAC headers), MAIN/7 raw-path exception, MAIN/0≡1.
- tooling-audit.md §S44: EVERY tool classified with file:line — 8 must-change (family_remap VRAM
const, Makefile+modules.mk, sig-target generalization, audit_binaries de-ov_, family_hseq/
progress:647/audit_frontier globs, corpus.sig_is_independent), 7 one-line registrations, 5
retirements (disc_code_sweep superseded by disc_audit; reconcile_decls; 3 rollout one-shots;
ImportOverlay/VerifyOverlay.java), rest auto-OK/N-A. new_overlay.sh -> new_binary.sh design.
- decision-log (R31): the pivot entry — the emulator dependency dissolves; the "modules" mostly
dissolve into overlays (~75-77% h_exact-known; 802 novel fns); why the doctrine was missable for
30 phases (a confident negative doctrine is a claim like any other — date it, cite it, re-measure).
- cookbook §154 + index regen (454 sections): module-id word / dual base-voting (h_exact ~500:1 +
jal-alignment, must AGREE; thin votes => park, P9) / diff a mystery payload's head against classes
you already own before inventing a new one.
- MY BUG, found by reconciling against the old sweep (R14): when I introduced the two-oracle UNION I
updated the BUCKET accounting but left the ledger's row-listing condition on L1 alone. So the byte
total was already right (3,564,021) while the LIST under-reported — 34 rows instead of 78. Same
"two code paths, one updated" shape as the day's other defects. Fixed: rows use the same union.
- THE COMPLETION CONTRACT'S "39 type-1 modules" IS SUPERSEDED: the real backlog is **78 unclaimed
code payloads / 3.56 MB** — MAIN.CD 42, SC03 18, SC05 7, SC04 7, SC07 2, SC02 2. The 39 came from
disc_code_sweep, which reads only the RAW layer through a 4,096-WORD WINDOW and has no notion of a
claim. Reconciled decisively: all 39 hash-checked against config/check.*.sha -> 0 of 39 claimed, so
the new set strictly CONTAINS the old one. docs/disc-completeness.md updated, old text kept for
provenance.
- WORKED EXAMPLE of why the window mattered: SC07.CD FILE_003/1.1 is 345,132 B whose HEAD is code —
the old window saw valid=100%, the whole-payload average is valid=0.571 (L1 says data), and L2
carves 3 real functions. Only the union gets it right, which is the entire argument for R34.
- Partition still holds: residue 0 over 416,021,760 B, 1,291 payloads examined.
L2 (R34) is sig_image boundary carving: walk the payload cutting each function at the first `jr $ra`
at/after every forward branch target. Structurally different question from L1's statistical test
(valid>=0.90 AND jr>=0.01), so the two can ARGUE — and they did, 80 times, all one shape.
- L1 DEFECT 1 — A CLAIM OUTRANKED BY A HEURISTIC. A payload whose SHA1 equals a committed
config/check.<bin>.sha IS that onboarded binary (the build gates on that hash daily), but I let the
statistical verdict file it as classified-data. Onboarded bucket understated by 14.5 MB.
- L1 DEFECT 2 — WHOLE-PAYLOAD AVERAGING DILUTES CODE. A real location overlay is code followed by a
large data tail, so its whole-payload valid-ratio is ~0.87, under the 0.90 gate — while L2 carves
real functions from its head. The "classify the whole payload" fix for the old 4,096-word window had
traded a head-only bias for an averaging bias. 80 disagreements, every one this shape.
- RESOLUTION (bucket_of): a claim wins outright; otherwise take the UNION of both oracles. Union is
the conservative direction for this audit's question — over-reporting code yields a review queue,
under-reporting HIDES code, the exact failure that produced three "more code all along" surprises.
- RESULT: partition still holds, residue 0 over 416,021,760 B / 1,291 payloads.
onboarded-code 47,066,812 · UNCLAIMED-CODE 3,564,021 (34 payloads) · classified-data 134,265,572
· audio-video 184,338,000 · filesystem-metadata 46,787,355
Largest unclaimed: MAIN.CD sub-file 12 entry 1 type 1, 383,783 B; the rest small type-1, mostly MAIN.CD.
- The ledger now carries an explicit L2 REVIEW QUEUE section; L1=data/L2=code is flagged as the
DANGEROUS direction (missed code).
L1 of Drew's definitive disc audit ("we really need a full audit that definitively lists ALL code
that we need to decomp"). THE INVARIANT (R32): every byte on the disc belongs to exactly ONE bucket,
the buckets SUM TO THE DISC, and residue is a DEFECT — a partition with an asserted residue of zero
is a completeness proof; a longer list is only a longer list.
- WALKS THE DISC IMAGE, NOT OUR CONFIGS, classifies WHOLE payloads (no window), and decodes BOTH the
raw and LZSS layers — the three shapes that produced the three "more code all along" surprises
(the 0.4.dec glob missing 4 SC07 overlays; disc_code_sweep blind to COMPRESSED code, its type-4
row vacuous for 138 known binaries; a 4,096-word window reading only payload heads).
- CLAIMED-BY IS DERIVED (R33): config/check.<bin>.sha IS the SHA1 of that binary's disc payload, so
payload->binary is a hash lookup against the build's own byte-identity gate. It cannot drift.
- RESULT, 416,021,760 bytes, 1,291 payloads, RESIDUE 0:
onboarded-code 32,564,876 (7.83%) · UNCLAIMED-CODE 1,700,049 (0.41%) ·
classified-data 150,631,480 · audio-video 184,338,000 · filesystem-metadata 46,787,355
34 UNCLAIMED code payloads — largest a 383,783 B type-1 in MAIN.CD, the rest small type-1 entries.
These are the "there was more code all along" surprises, now ENUMERATED instead of stumbled into.
- MY OWN FIRST RUN FAILED THE PARTITION by -49,709,520 B, and the fail-closed exit is what caught it:
.DA entries' LBAs point PAST track 1 into the CD-DA tracks (double-counted against the whole-track
audio total), and .STR/.XA are MODE2 FORM2 (2324 user bytes/sector, not 2048). Both fixed.
- NOT wired into tools-health: it needs disks/, which a fresh clone does not have (H1).
- KNOWN GAP, stated not hidden: LIST.CD fails the TOC walk (it IS the TOC cache, not a container)
and is booked as data — correct today, worth a real classifier when L2 lands.
- ROOT CAUSE PINNED, and my first hypothesis was WRONG (R14, corrected in the log): I wrote that a
gate transform ate a `/*` opener and turned comment prose into code. REFUTED — cast_call_sites,
sig_unify and reconcile_tu each run with the gate's real --src-file all preserve it. The real
cause is family_remap's preamble backscan, whose accept-set (blank/extern/comment/typedef) HALTS
AT THE FIRST `#define` and never reaches typedefs above the macro block. `_carry_macros` then
re-attaches the macros, which HIDES the truncation — the unit looks complete and is not.
"parse error before 'unsigned'" was that failure surfacing at the next token (the following
`extern unsigned char` line): a misleading label, not a second defect.
- FIX: _carry_typedefs() — additive, TRANSITIVE (a carried typedef may name another; measured:
carrying Vec8_80182FD4 alone then failed on SVECTOR_8016E7C8), and BRACE-AWARE (a `;`-terminated
scan stops INSIDE the struct at its first member line, emitting a truncated unclosed typedef).
Emits dependency-first for C89. Only types the unit actually names and does not already carry.
- VERIFIED: the 0x80182FD4 unit now carries its Prim_8016E7C8 block complete; the 0xECC family's
remaps now carry the four typedefs I had prepended BY HAND before gating them — i.e. the fix
automates the exact workaround that banked those three siblings. Residual isolated-compile failure
on SVECTOR_8016E7C8 is a match_one artifact: that type lives in src/shared/engine_types.h, which
the real TU includes — the typedef gap is fatal ONLY when the target TU lacks the type, which is
why this class failed loudly for some families and silently succeeded for others.
- R22 CLEAN-FLEET: 140 passed, 0 failed of 140. Fleet 12,502,519/13,160,961 = 94.997% instr
(+18,146 instructions this session, 23 functions). 393 instructions from the 95.000% bar.
- REDO of the S43-9 retraction, done correctly through harvest_verify (splice/build/keep-iff-
byte-identical/revert) instead of hand-building. 5/5 banked, each re-verified three ways:
image SHA == locked SHA, stub gone, real definition present.
ov_SC03_101/func_801814F8 · ov_SC03_104/func_80184934 · ov_SC04_003/func_8017E4F4 ·
ov_SC04_005/func_80181054 · ov_SC04_007/func_8017FF08
- THE DEFECT THIS PROVES: family_sweep --hseq reported this family 0/5 with
"PLUMBING: parse error before 'unsigned'" — but the remapped drafts are byte-CORRECT. The only
`unsigned` in the draft is INSIDE A COMMENT, so a gate-pipeline transform is eating a `/*` opener
and turning comment text into code. Per-transform runs on the draft alone all preserve it, so it
needs the gate's real invocation (--src-file) to reproduce. NOT YET PINNED — and it is silently
costing banks in every sweep it touches. Next: run the three transforms with --src-file and diff.
- Workaround that banked them: carry the exemplar's typedefs by hand (the family_remap _carry_macros
gap, §146/§152) and gate directly, bypassing the sweep's recovery ladder.
- Also killed a self-inflicted infinite poll: an `until ! pgrep -f "permuter_ils.py <fn>"` loop whose
pattern matched its OWN bash command line, so the condition could never go false (spun 2h30m).
Same family as the day's other defects: a check that cannot return the answer that ends it.
- ✅ R22 CLEAN-FLEET: make clean && extract-all && check-all -> 140 passed, 0 failed of 140.
Discharges the [R22 PENDING] caveats on commit:1486 (the 0xECC family x12) and commit:1487
(func_8018D98C). All 18 of today's banks are confirmed, not incremental artifacts (§130).
- FLEET: 96.63% fn-count / 94.99% instr-weighted (12,501,204/13,160,961) / 89.4% distinct-code.
Session +16,831 instructions, 18 functions. P30's 95% instr bar is 1,708 instructions away
(18,539 at session open). NOTE the report line rounds to "95.0%" — the bar is NOT yet met.
- THE 5th WAVE AGENT: func_8017CE58 is TWO bodies at one address (246 in SC02_000/003, 734 in
SC03_092). The 246 body is byte-identical to func_8017C294 — THE FUNCTION §147 WAS WRITTEN FROM —
so one draft covers 4 instances, and it went 12 (with a recorded "stop searching" verdict) -> 2.
- §147 CORRECTED IN PLACE (H5: original text preserved, correction appended):
* A "stratum 3, unreachable from C" is REFUTED — there is NO stratum 3. The frame is declared
locals then reload spill slots in pseudo-regno order; the mystery 0x108 slot is an ordinary
spill on a loop.c-created pseudo, reachable by writing the loop as an INDEX loop (a pointer
walk puts it at the bottom). Prior drafts faked it with volatile pEnd + dead[7]. (121 -> 54)
* B the unreferenced slots are combine-orphaned sign-extension intermediates (combine.c:10839),
not "?: on memory" frame cost.
* E the qty_compare tie IS breakable — §148-C's zero-emission ref slider. (30 -> 25)
* D applied properly (drop volatile out + the $24 pin, let a1 spill) remains: 54 -> 30.
- CONSEQUENCE: func_8017C294's 15 siblings were parked "until stratum 3 is explained" — that hold
is VOID. Both near-misses logged to the ledger with their measured closeness, not forced (P9).
- PROCESS LESSON in §147: a confident NEGATIVE verdict is a claim like any other — date it, name
its evidence, and re-measure it before letting it park work (same shape as §146).
- func_8018D98C (ov_SC06_033, 710 ins): MATCH, gated, carved into its own split
(src/ov_SC06_033/ov_SC06_033_jr_8018D98C.c); image matches its locked SHA; stub gone.
NOT a family — `find asm -name func_8018D98C.s` returns exactly one file, so this banks 1x710.
The prompt's "renderer sibling" premise was wrong: it is a 12-state entity state machine over
jtbl_801CF234; func_8017C6F4's C shares nothing with it. Structurally exact on the first draft.
- §153 THE ADDRESS-REMATERIALISATION LAUNDER (third zero-emission asm lever, after §148-C's allocno
numerator and §151's blocked scheduler tick): an `&SYM` used as an argument >=2x in ONE cse basic
block gets its pseudos unified (4 refs), so local-alloc.c:1080's remat path (needs reg_n_refs==2)
never fires and global.c:388 hands it a CALLEE-SAVED register, cascading a rename. 14 probes prove
no respelling reaches it (do/while splits cse1; cse2 puts it back). Cure, zero bytes, one per site
in its own block: `{ s32 _m = (s32)&SYM; __asm__ __volatile__("" : "=r"(_m) : "0"(_m)); f(x,_m,y); }`
— the volatile asm is never entered in cse's table AND sets _m, emptying the equivalence class.
Placement is load-bearing (#APP is a scheduling barrier); with two address args, launder BOTH.
- INTEGRATION CAUTION: the agent's TU-CONFORMED variant gated DIFF while the PLAIN one banked.
rtu_match MATCHing does not promise a decl-rewritten variant survives the real build — gate the
plain variant first.
- R22 clean-fleet still owed (one agent remains on asm/); this and the 12 family banks are
incremental-gated (§130) until it runs.
⚠️ R22 CLEAN-FLEET OWED (two agents still reading asm/, so `make clean` is unsafe). Each of the 12
was gated whole-binary AND independently re-checked against its own config/check.<bin>.sha (12/12),
stubs confirmed replaced — but incremental (§130). Treat as UNCONFIRMED until the clean run.
- THREE isolated cheap-Opus agents, briefed with §150/§151 + the mandatory all-drafts scan,
CONVERGED INDEPENDENTLY: func_8017C6F4's 947-ins body exists in 12 OVERLAYS under 5 DIFFERENT
NAMES at 6 DIFFERENT ADDRESSES, each differing by exactly TWO per-overlay symbols (screen-rect
helper + 64x64 cell table). Gated 12/12, 0 failed. 11,364 ins from this morning's single crack.
- WHY IT HID ~30 PHASES (cookbook §152): name-keyed grouping scattered it across 5 names,
address-keyed across 6 addresses (and the address collides with an unrelated 15-ins body in 3
other overlays), and h_seq-keyed scattered it too — which is why the Phase-26 sweeps missed it.
THE KEY IS BYTE SIZE: `grep -rl 'nonmatching .*, 0xECC' asm/*/nonmatchings/*/` returns exactly
the 12, reads the asm (cannot go stale like family_hseq.json), no false positives. Refines the
Phase-26 "h_seq is spent" finding: h_seq is worth exactly ONE size-keyed sweep behind each FRESH
core crack — here it paid 11:1.
- TWO CAUTIONS THAT TRAVEL WITH IT: (1) a MASKED tool cannot validate a remap — match_one and
rtu_match both mask jal/%hi/%lo, exactly the fields a remap edits, so a wrong symbol map still
reports MATCH; gate remaps by the whole-binary SHA only. (2) a stale residual is NOT evidence two
functions differ — I briefed "func_8017C59C scores 340, different body"; refuted in one command
(that 340 came from a pre-§150-fix draft, which scores nonzero against its own target too).
- OPEN TOOL DEFECT (R32): family_remap's unit backscan halts at the first #define, so it carried
16/16 gte macros and 0/10 typedefs, silently — the §146 gap from the other side.
- MY ERROR, RETRACTED IN THE LOG (S43-9): I reported the 263x5 cluster as "5 byte-identical, 1,315
ins". FALSE — the drafts had been reverted, so I measured the INCLUDE_ASM STUB BASELINE, which is
byte-identical by construction. R34's trap, self-inflicted by hand-building instead of using
harvest_verify. Nothing was banked there; the cluster is UNRESOLVED. ("41 behemoth drafts" was
likewise a file count — 79 files, 20 distinct functions.)
- func_8017EF68 MATCH 969/969, re-verified by me, gated: ov_SC06_000 byte-identical at da4a26ff.
- MECHANISM (from cc1's own -dR trace, not inferred): the r3000 machine description gives the
memory unit load-ready-cost 2 / store 1, so blockage(load,store)=2 — a LOAD CAN NEVER BE PICKED
IN THE TICK IMMEDIATELY AFTER A STORE PICK. sched2 therefore always wedges one ready ALU insn
between the lw and the sh, and the target's zero-wedge order is UNREACHABLE BY ANY STATEMENT
ORDER. That is why ~20 documented hand variants AND the repaired permuter both floored at 2.
The draft's own §49 sched1-LUID story was incomplete — real but secondary.
- THE LEVER (cookbook §151, "the ghost wedge"): a zero-emission tied in/out asm
`__asm__("" : "=r"(v) : "0"(v), "r"(rival));` — 0 bytes, but a schedulable insn that absorbs the
blocked tick, and it sets reg_n_sets(v)=2 which also kills sched1's birthing boost (one
instrument, both passes). Two measured fallouts: rival-read in the same asm (22->12), then a
second re-tie on a HIGH-REF host to restore allocno live-length parity (each in-loop insn is +1
live length for every loop-spanning allocno; a trio of invariant addresses sat exactly on
allocno_compare's integer-floor boundary). Host choice empirical: pkt=MATCH, ot=705, double=10.
- ✅ R22 CLEAN-FLEET: make clean && extract-all && check-all -> 140 passed, 0 failed of 140.
This DISCHARGES the [R22 PENDING] caveat on commit:1484 — all five banks are confirmed, not
incremental-build artifacts (§130).
- FLEET: 96.63% fn-count / 94.9% instr-weighted (12,489,130/13,160,961) / 89.2% distinct-code;
0 NON_MATCHING (G4); dedup 1919 groups. Session +4,757 ins from 2 cracks x 5 binaries.
Distance to P30's 95% instr bar: 13,782 ins (was 18,539 at session start).
⚠️ R22 CLEAN-FLEET VERIFY IS OWED, NOT DONE. All four gates below were INCREMENTAL builds
(§130: an incremental build can report BYTE-IDENTICAL for a change a clean build cannot link).
Committed now only to protect the work — a second Fable5 agent is reading asm/, so `make clean`
would destroy its inputs mid-run. The clean-fleet run follows the moment that agent finishes;
treat these four banks as UNCONFIRMED until then.
- THE CRACK (Drew approved the Fable5 escalation, R27): byte-exact, PIN-FREE, 947 ins. My §147-E
"qty_compare tie, unreachable from source" diagnosis was WRONG. The residual was VARIABLE
IDENTITY: (1) the X-pass and Y-pass min/max intermediates are DIFFERENT variables (8, not 4
reused); (2) mnc/mxc do not exist — the cell clamps reuse the prim-loop mn/mx (X) and mny/my (Y).
Ablations: split-only 63, reuse-only 624, conjunction MATCH. That is also why S42's "separate
X vs Y variables" probe was filed as a failure (it was half the fix), and why every allocator
lever was inert — pins, §148-C sliders, declaration order and 14 permuter restarts cannot reach
a draft with the wrong NUMBER OF PSEUDOS.
- VERIFIED INDEPENDENTLY BEFORE BELIEVING IT (R14): I re-ran match_one -> MATCH (947 ins), then
the whole-binary gate per binary.
- BANKED ×4 (every 948-ins sibling of this body), each byte-identical:
ov_SC03_126 c48a8bb8 · ov_SC03_003 898bf52a · ov_SC04_021 33614234 · ov_SC05_019 3f5b4f13.
family_remap produced all three siblings cleanly.
- §146 SEEN AGAIN: all three siblings first failed with `PLUMBING: parse error before 'MTX_C6F4'`
— _carry_macros carries #defines but NOT typedefs; prepending the 9 typedef lines fixed all
three. That label is legible ONLY because of this session's classifier fix; before it, it read
"CC1-FAIL: make: *** Error N" and cost a manual splice-and-rebuild each.
- cookbook §150 (decode register ownership from the MATCHING diff regions before touching the
allocator; per-instance register asymmetry ⇒ per-instance variables; the deleted-self-move tell
and the global.c:719-vs-:729 death-before-store exemption behind it). §147-E corrected: it named
the wrong allocator — these are global.c allocnos, not local qty_compare quantities.
- THE ALL-DRAFTS SCAN PAID (S4's law): .run/drafts-p30beh/func_8017EF68.c is a 969-ins draft that
scores "969 mismatched" against ov_SC03_007's 12-ins body — which is what every name+home scan
keyed on. Against its OWN body (ov_SC06_000, 970 ins): DIFF 969/969, **2 mismatched**,
SCHEDULE-REORDER/2, everything else — registers, frame, spill map — already byte-exact.
- THIRD instance of today's address collision: 0x8017EF68 = 12 ins (SC03_007) AND 970 (SC06_000);
0x8017CE58 = 246 (SC02_000/003) AND 734 (SC03_092). The serial queue's own size annotations
("func_8017EF68 (969)", "func_8017CE58 (733x3)") are therefore unreliable — re-derive from bytes.
- THE VINDICATION: the draft's header ends "NEXT STEP: this is the permuter's exact profile", and
drafts-p30beh is one of the 63 GTE dirs S43-1 unblocked — this function sat ONE working permuter
run from a bank, with the note naming the permuter, for as long as the silent fallback existed.
- The residual is a 2-ins adjacent transposition (lw $v0,0($s3) <-> srl $a2,$a1,16), root-caused in
the draft to a sched2 INSN_LUID tie (§49) with ~20 hand variants recorded DO-NOT-RE-BUY.
Repaired-permuter ILS (schedule profile, 6x240s) reaches 2 and holds flat; a free 12x600s run is
queued. Logged to the backlog at closeness 2 with the correct binary.
- Queue triage: func_8017C974's 22 stored drafts are all far (best 812/947); func_8017CE58 has only
a CC1-FAILing Ghidra-C draft. Neither is a near-miss.
- func_8017C6F4 FINAL for this session: hand 63 -> ILS 42 (pin-free seed, masked 44, flat over 8
warm restarts) -> ILS 41 (pin-t5 seed, masked 43, flat over 5). Best draft
.run/s43/func_8017C6F4.ils43-pin.c (closeness 41), logged + allowlisted. Both basins are now
MEASURED FLAT — do not re-run the ILS on these seeds; next levers are §148-C by hand, then Fable5.
- .gitignore: allowlist .run/s43/*.py + *.json so the refutation evidence (probe_leftovers.py,
leftover_probe.json) is preserved, not one `git clean` from gone (R20, the S42 lesson).
- S43 checkpoint block refreshed at the top of the file: the four instrument defects as one table,
the one number that moved, the resume list (with "26 unpropagated members" struck as refuted),
the harvest_verify import hazard, and my four process errors.
- RE-DERIVED from the tree (R35): the S40 propagation banked 59 families; 22 still have open
members = 31 instances, not the carried 26.
- SCANNED all 31 (not sampled, S4's lesson): mechanical family_remap from EVERY binary where the
same fn is already matched (up to 4 sources each) fails 31/31 with gross reloc-count mismatches
(2!=15, 12!=2, 11!=20, 2!=0). Script + JSON: .run/s43/probe_leftovers.{py,json}.
- WHAT THEY ARE: structurally DISTINCT bodies sharing an address and a name — the func_8017C6F4
15-vs-948 collision one level down. family_hseq independently agrees (R34): these cluster into
families with matched=0, several n_members=1. No matched sibling => nothing to template from =>
the failures were NEVER plumbing. They are per-member drafting work, not deterministic fuel.
- SCOPE STATED (P9): what is refuted is mechanical remap from a matched sibling (0/31). An
h_seq-staged draft + recovery ladder is formally untested — but that path produced the original
CC1-FAILs, its labels were content-free until this session, and --hseq --only now stages 0
families for these addrs. Cost the next wave as agent work.
- cookbook §149: the four instrument defects of this session as ONE pattern (silent fallback =
"found nothing"; same addr != same body, ledger side; make's wrapper is not a diagnosis; carried
cheap fuel nobody probed) + the rules each one yields.
- ROOT CAUSE: classify_fail took errs[-1], and make prints its own summary
`make: *** [Makefile:N: build/src/<ov>/<tu>.o] Error N` LAST, always — so the wrapper won
every time and the label carried only the TU name the record already stores. Each CC1-FAIL
therefore cost a manual splice-and-rebuild to learn what cc1 actually said (3x in S42 alone).
- MEASURED (R37, over the committed .classified.txt corpus): ~3,000 of ~4,000 CC1-FAIL labels
are that wrapper; a further 1,019 are bare CC1-FAIL with no message at all.
- FIX: _MAKE_WRAP guard excludes make's summary lines; the FIRST real diagnostic wins (cc1
cascades — error #1 is the root cause); nothing-but-wrapper is now labelled
CC1-FAIL(no-diagnostic) rather than disguised (R32). Same family as the §58 warning
red-herring guard directly above it: a label identical for every input carries no information.
- VERIFIED on the exact branch (exec'd the real source, see hazard below):
"CC1-FAIL: make: *** [...] Error 33" -> "CC1-FAIL: src/…/tu.c:2240: error: too few arguments
to function `gte_ldv3'". DIFF/SKIP/PLUMBING paths unchanged.
- HAZARD DOCUMENTED (mine): harvest_verify.py has NO `if __name__ == '__main__'` guard — the
whole gate is module-level, so `import harvest_verify` PARSES argv, RUNS A BUILD and overwrites
.run/harvest_*.txt. Tripped it unit-testing classify_fail (resident stayed 8e17e02f, 0 banked,
tree clean, no damage). Nothing imports it today, so it is flagged in the file header rather
than fixed by a risky 500-line refactor of our most load-bearing gate.
- THE FLOOR MOVED: permuter_ils on the S42 draft -> masked 65->44 (cycle 1, flat over 5 warm
restarts); re-measured in match_one terms 63 -> 42 mismatched, 947/947 ins. First movement
after ~40 hand probes, and it came from repairing an instrument (S43-1), not from new C.
Draft preserved + allowlisted: .run/s43/func_8017C6F4.ils44.c; logged at closeness 42.
- THE S42 "rumour" CLAIM WAS WRONG (R14): the 2026-07-01 row HAS an artifact, it IS on disk,
and it reproduces exactly (14 mismatched of 15 target ins, SIZE-MISMATCH/redraft). It is a
near-worthless draft on a DIFFERENT BODY: 0x8017C6F4 is 15 ins in ov_SC03_010/011/013 and
948 ins in ov_SC03_126/003 + ov_SC04_021 + ov_SC05_019 (§148-E, ledger side).
- THREE ledger defects fixed: (1) load_best keyed on ADDRESS ALONE -> the two bodies merged and
the lower ABSOLUTE closeness won, so 14-of-15-wrong (7% correct) masked 63-of-947 (93%);
now sub-keyed by known nins, legacy rows unchanged. (2) binary=null defaulted to ov_SC01_077,
where the fn does not exist AT ALL, and "not an open stub" was read as "banked" -> today's
result was invisible to render/grinder/target-selection (absent != done, R32/R34); now derive
binary from the draft path + only drop when closed everywhere it exists. (3) `log` had NO
--binary flag -- the root cause of every null; added + derived in append_record.
- IMPACT DERIVED, NOT ASSERTED (R37): replaying the pre-fix selection = 836 -> 837, 1 appeared
(func_8017C6F4 nins=947), 0 vanished. One row today; the mechanism would eat every future one.
- PROBED AND NOT BUILT: relative-closeness ranking (only 24/836 rows carry closeness+nins, and
the two orderings agree 14/15 on those). Documented in the log instead.
- ROOT CAUSE (reproduced): make_base_c ran cpp_expand_macros BEFORE #include lines were
dropped, so `cpp -P -nostdinc -` died on `#include "common.h"` (rc=1, empty stdout) and the
`return c` fallback handed back the UNEXPANDED draft. hide_asm then ate the gte_* #define
block + the function itself -> "Function not found in base.c" -> decomp-permuter no-opped
in 0s, indistinguishable at the call site from "searched, found nothing".
- FIX: strip #include inside cpp_expand_macros (byte-neutral) + RAISE on cpp failure (R32/R35,
no silent fallback); NEW defines_fn() assertion in setup() guards the OUTPUT so it catches
every swallow cause (this, the §G comment class, future macro shapes); main() catches per-fn
so a bad draft is loud+counted but cannot abort a batch.
- VERIFIED: func_8017C6F4 base.c keeps the def, 0 gte_ macros left, 35 asm b64-carriers;
proxy validated over 388 stored drafts = 0 false alarms, 0 cpp raises (macro-free untouched);
permuter now loads at base score 65 and iterates (was a 0s no-op).
- BLAST RADIUS (14,899 drafts scanned): 63 carry `#define … __asm__` + `#include`, incl. the
behemoth renderer drafts — the permuter was silently dead on the highest-byte-weight targets.
- CONSEQUENCE (R14): §147/§148's ~40-probe floors were measured with the permuter UNAVAILABLE;
"the permuter also plateaus" was never actually tested on those functions. §148 note corrected.
Answering "did you bank the results": the two serial functions did NOT match, so there was nothing
to bank (G3 -- NEAR is not a match). Everything that DID match this session is already banked and
committed (7 from the S4 redo, 24 wave exemplars + propagations, both giants x138).
But the drafts were about to be LOST, which is worse than not banking them:
.run/s42/ov_SC01_077/func_8017C294.c NEAR(12) of 246 ~245k subagent tokens
.run/s42/ov_SC03_126/func_8017C6F4.c NEAR(63) of 947 ~434k subagent tokens
.run/s42/ov_SC03_126/func_8017C6F4.pin-t5.c NEAR(47), pinned variant
All three were gitignored -- one `git clean` from gone (R20: commit irreplaceable work). Added a
curated /.run/s42/ allowlist and committed them. They are the best base any future attempt has:
func_8017C6F4 has frame 0x120 + vars=232 EXACT with only a register rotation left, and its permuter
has never been aimed at it (make_base_c fails on the gte_ macro block -- demacroize first).
Both logged to the backlog with today's MEASURED values, class, reach and draft path.
⚠️ LEDGER INTEGRITY, flagged not silently fixed: the backlog already held
`func_8017C6F4 closeness=14` (2026-07-01, ov_SC03_010, source=bulk-harvest) -- BETTER than today's
63, but with **draft: None, klass: None, nins: None, reach: None**. There is no artifact behind it
and no draft of it survives on disk (today's agent scanned every stored draft and found two, both
junk). `load_best` takes the LOWEST closeness per address, so this unverifiable row will out-rank
today's real, reproducible 63 in every future target selection.
This is the Phase-28 defect class (`func_80178004` recorded close=0 when it was 91). It is left in
place rather than deleted because deciding between "a lost good draft" and "a bad number" needs
evidence I do not have. **Whoever picks this up: treat the 14 as UNVERIFIED, start from the
committed 63/47 drafts, and if the 14 cannot be reproduced, purge the row.**
The general rule this argues for: a backlog row with no draft artifact is a rumour, not a result --
`backlog.py log` should require a draft path (or mark the row unverifiable) so an artifact-less
number cannot outrank a reproducible one.
Answering "did we do S4?" honestly: NO, not properly. The earlier pass re-gated only the NEWEST
stored draft per draft-exemplar head (8 banked of 35). S6 then proved that is sampling, not scanning
-- its giant's match was the 9th of 31 drafts, and my first pass had reported "closeness 40".
Redone with EVERY stored draft run through match_one, over the 39 draft-exemplar heads + Drew's
named large-function list (38 targets, 33 with drafts on disk):
14 of 33 targets MATCH from a stored draft (some had 51-57 drafts each)
-> 6 banked first pass, +1 after recover_giant = 7 banked
-> including func_8018057C (897 ins), which was on the "needs an agent" list
The 14 came overwhelmingly from ov_SC01_077 -- exactly the heads where only the newest draft had
been tried. The winning drafts sit in .run/_a10_sample-cn-cast-rc/, .run/drafts-wave-cn-cast/,
.run/drafts-wave-cn/, .run/ab-exp/opus-cn/, .run/backlog_drafts/ -- i.e. spread across many
historical pipelines, which is precisely why "newest" is the wrong selector.
7 still open after recovery (5 near, 2 failed) -- integration classes, drafts kept in .run/s41/rec/.
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140.
Fleet 12483035 -> 12484373 instr; distinct +1,338 / +7 uniq; fn-count +7. instr-weighted 94.9%.
audit-digest OK. 0 NON_MATCHING (G4).
STILL OPEN from S4: the 263x5 cluster (0x80182fd4 exemplar) sweeps 0/5 with `parse error before
'unsigned'` in the spliced draft -- NOT the missing-type class, undiagnosed, do not assume codegen.
And the 2 resident stubs with gate-rejected match_one-MATCH drafts remain untouched.
THE RULE (cookbook §146, now paid for twice): SCAN every stored draft, never sample. A head with 57
drafts has 57 chances, and the pipelines that produced them differ in ways that matter.
The two functions the roadmap has carried as PERMANENT WALLS since Phase 24 are matched in all 138
overlays. Neither needed a siege. Both matched from drafts ALREADY ON DISK.
func_80178004 165 ins x 138 = 22,770 Phase 26: Fable5, ~477k tokens, "intrinsic 3-integer
regalloc wall". THREE stored drafts report match_one
MATCH today; one banked first try, no new work.
func_801412A8 198 ins x 138 = 27,324 close=29/110 since Phase 24. Matched from 1 of 31 stored
drafts + the §37/§124 alias.
WHY func_801412A8 LOOKED INTRINSIC (worth understanding — match_one is structurally blind to it):
the TU declares `extern int func_801412A8(int,int,int,int,int,int)` and its callers USE the return
(`param_1 = func_801412A8(...)`), while the byte-true definition is
`Prim_1412A8 *(Prim_1412A8 *, int, int, int, u16, u16)`. Narrow params cannot agree with an `int`
prototype and the no-prototype escape is illegal once a param promotes, so NEITHER side can move --
and the resulting byte difference is in the CALLERS, which match_one never compiles. The §37/§124
def-side asm-label alias decouples them: the TU decl keeps governing the call sites (codegen
untouched), the definition keeps its byte-true signature.
THEN PROPAGATION RETURNED 0/137 TWICE, both times a missing TYPE, not codegen:
family_remap's `_carry_macros` carries file-scope #defines but (a) NOT typedefs, and (b) is NOT
TRANSITIVE -- it brought addPrim_1412A8 and stopped, though that macro calls setaddr/getaddr and
getaddr casts to PTag_1412A8. Lifted Env_1412A8 / PTag_1412A8 / Prim_1412A8 + OT/getaddr/setaddr
into src/shared/engine_types.h (inside the include guard) -> 137/137, 0 failed.
MY ERROR, CAUGHT BY THE GATE: I lifted the typedefs but did not STRIP them from ov_SC01_077.c, so
they were declared twice and gcc-2.7.2 rejects a repeated typedef even when identical -- the lesson
already recorded at the foot of engine_types.h. R22 came back 139/140 with [FAIL] ov_SC01_077 (the
exemplar's own overlay). Stripped, re-verified, 140/140. A proper lift strips the source;
build_engine_types --strip does both and I did it by hand.
Also a measurement error worth recording: I checked whether the draft defined Prim_1412A8 with a
plain `grep -c` -- which matches inside `addPrim_1412A8` -- and briefly concluded the carry worked.
Substring false positive; the same shape as reading a `return` as a declaration.
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140.
Fleet 12432941 -> 12483035 instr (+50,094 -- EXACTLY the two giants x138); fn-count +276;
instr-weighted 94.5% -> 94.8%. audit-digest OK. 0 NON_MATCHING (G4).
THE RULE THIS BUYS: re-measure a wall before respecting it, and SCAN every stored draft rather than
sampling (my first pass checked 8 of 31 and reported "closeness 40" for a function whose MATCH was
in the 9th). Four minutes of re-measurement was worth 50,094 instructions.
Propagation behind every crack, same session (the multiplier the waves exist for). 19 newly-banked
exemplars from waves 1+2, all in the family_sweep lane (0 has_mid_jr):
87 candidate members / 10,212 ins -> 61 BANKED / 26 failed across 39 overlays
The 26 that did not bank are the known plumbing shapes, not codegen: 20 CC1-FAIL + 5 callee
`conflicting types` (func_8017EFA0 x3, func_8012B23C x2) -- the same classes the S40 recovery ladder
already has levers for (§17a-1 no-proto + call-site cast; recover_giant block-scoping). Left open
deliberately rather than force-banked (P9); they are the cheapest fuel on the board next session.
TOOLING GAP RECORDED: the sweep's classifier writes "CC1-FAIL: make: *** Error 33" WITHOUT the actual
cc1 message, so 20 of 26 failures carry no actionable reason. Diagnosing one currently requires
manually splicing the draft into its TU and rebuilding (done twice this session). The classifier
should capture cc1 stderr the way harvest_verify already does -- worth fixing before the next big
sweep, or every CC1-FAIL costs a manual reproduction.
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140.
Fleet 12425854 -> 12432941 instr (+7,087); distinct +6,145 / +51 uniq; fn-count +61.
instr-weighted back to 94.5% ON THE HONEST (post-main-regen) denominator of 13,160,961.
audit-digest OK. 0 NON_MATCHING (G4).
Two ultracode waves over the open-only h_norm clusters (the pool nobody had ever aimed a wave at),
pool VERIFIED from the sigs first (R14).
wave 1 8 targets 8/8 match_one 5/8 gate first pass -> 8/8 after recovery
wave 2 16 targets 16/16 match_one 14/16 gate first pass -> 16/16 after recovery
THE HEADLINE IS NOT 24/24 -- IT IS THAT NOT ONE FAILURE WAS CODEGEN. All six first-pass gate
failures were TU-integration plumbing, each with an already-documented lever:
func_801802EC redefinition of morph_lerp strip the §77 PROBE LAYER (the draft carries types +
a static inline so match_one can compile standalone;
the real TU already defines them -- scaffolding is
not part of the bank)
func_8018B238 conflicting types D_80115158 recover_giant: draft declared it file-scope as a
struct array, TU declares u8[] BLOCK-scope inside
other functions -> block-scope the draft's externs
func_8017EF54 conflicting types (SELF) §37/§124 def-side asm-label alias (TU declares
void f(void) for no-arg callers; byte-true def takes
s32 in $a0; no-proto escape illegal once a param
promotes)
func_80183D78 conflicting types (callee) recover_giant
func_8017F278 conflicting types func_80146C3C §17a-1: the fleet canonical is the NO-PROTOTYPE
form + the intended signature applied AT THE CALL
SITE; a concrete prototype collides with it
(wave-2's 14 first-pass banks needed nothing -- the wave-1 lessons were folded into the prompt)
=> the gate number measures INTEGRATION, not matching. Run the recovery ladder before recording a
wave's yield or the metrics under-report the drafters and send the next wave hunting walls that are
not there. docs/wave-metrics.md S40-1.
POOL VERIFICATION (R14, and it cut both ways): the frontier report's cluster pool MEASURED
1,677 clusters / 5,795 fns / 319,755 ins at a 3.68x multiplier vs its claimed 1,689 / 5,956 /
326,261 at 2.7x -- within 2-4%, and the multiplier is BETTER than claimed. The SAME document's whale
claim was 3/4 wrong. Verify each claim separately; do not accept or reject a source wholesale.
ALSO: 24/24 members propagated from wave 1's 5 banked exemplars (0 failed) -- the same machinery
that returned 0/39 before this session's cast_call_sites fix.
NEW IDIOMS, distilled in-session (R16/R30):
§144 the LITERAL'S SPELLING picks the immediate encoding (`cnt + 0xff` vs `cnt - 1`: mod-256
identical, both one addiu, but gcc emits 0x00FF vs 0xFFFF from the source text)
§145a combine_givs ANCHOR RULE -- the address-giv group anchors on the LAST address-giv in SOURCE
order (record_giv prepends, combine_givs takes the head); store order decides the base and a
wrong choice spawns a third induction register
§145b a bare `p = r;` is a COMBINE BARRIER (can_combine_p/use_crosses_set_p) -- it preserves a
pointer-bump addiu that combine would otherwise fold into every MEM offset
§145c chained assignment `a=b=c=0` emits stores RIGHT-TO-LEFT
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140.
Fleet 12420375 -> 12425854 instr (+5,479); distinct +5,479 / +43 uniq; fn-count +43.
audit-digest OK. 0 NON_MATCHING (G4). Cost: 3.73M subagent tokens across 24 agents, 0 errors.
Drew T