Commit Graph

408 Commits

Author SHA1 Message Date
Drew T c666450df4 fix(phase-30 S48): wave harness — backticks in the §165 citation broke the template literal
A workflow script is plain JS; the cookbook citation I added used markdown
backticks inside a template string, which terminated it. Caught at launch
(parse error, 0 agents, 0 tokens) rather than mid-wave.
2026-08-12 13:33:28 -06:00
Drew T 165e2a3e82 chore(phase-30 S48): wave harness cites §165 (129 vetted laws, 48 refutations) 2026-08-12 13:31:05 -06:00
Drew T 54de1bf245 feat(phase-30 S48): check the crack-wave harness into tools/wave
The wave script encodes contracts paid for in real failures (per-agent output
dirs after wave 2 lost 21 verified drafts; sha1-last verification; prior-notes
seeding at 7/9 then 10/12; size routing). It was living only in the workflow
scratch dir, so each wave rebuilt it from memory — which is how the cookbook
citation list went stale: it still named only §162 while §163 and §164 (87 more
entries) had been banked in between.

Updated the citation list to §160-§164 and pointed agents at §164z, the 28
REFUTED claims, so they do not re-derive a disproved mechanism.
2026-08-12 12:58:47 -06:00
Drew T 043532b475 feat(phase-30 S48-T6): wave 4 — 18 exemplars banked; + a 4th comment-blindness fix
Wave 4 (wf_05895a19-121, 75 agents, 7.9M tok): 40 targets -> 35 agent-MATCH,
0 refuted, 5 NEAR, 0 FAIL, 0 drafts lost. 18 banked so far on the whole-binary
gate across 9 binaries; the other 17 are re-gating on a clean tree (see below).

PRIOR-NOTES SEEDING HELD AT SCALE: 10 of 12 seeded targets confirmed (wave 3
was 7 of 9). func_8017C294 — the x16 family, the largest single item on the
board — is now NEAR at **2 ins** (18 -> 11 -> 2 across three seeded attempts).

THE 4th COMMENT-BLINDNESS DEFECT OF THE SESSION, and the first with blast
radius. A crack agent annotated a decl in its draft:

    extern void func_801842DC(s32 a0);   /* TU:4023 INCLUDE_ASM (no decl) */

`corpus._INCLUDE_ASM_CAND` only skips lines that BEGIN with a comment marker,
so it read `INCLUDE_ASM (` out of the trailing PROSE, found no quoted path, and
refused the whole binary's stub oracle — correctly, by its own R32 contract.
That then failed gate_stage for every LATER binary in the run, because they all
walk the corpus: 12 binaries banked, then 5 were blocked by one comment in a
13th. Fixed the same way as the other three today: decide candidacy on
cdecl._mask'ed text, PARSE FROM THE ORIGINAL (the mask blanks string content
and would erase the asm path). Verified on 4 binaries incl. main (2,002 stubs).

AND THE DAMAGE IT LEFT: gate_stage raised out of the CorpusError BEFORE its
revert, stranding failed drafts spliced in src/. The 17 solo re-gates that
followed all read 0/17 — they were building a POISONED TREE, not judging their
own drafts. Residue reverted here; the 17 re-gate clean next.

The pattern is now sharp enough to state: any scanner that greps C source for a
token must mask comments and strings FIRST — and agent-authored drafts make it
far likelier, because their prose mentions the exact tokens our tools hunt for.
2026-08-12 12:25:20 -06:00
Drew T c0e64f48b6 feat(phase-30 S48): tools/recover_drafts.py — the transcript IS the backup
Today a 28-agent wave lost 21 adversarially-verified drafts to a shared output
directory, and I wrote them off before Drew asked whether the workflow results
could just be analysed. They were all recoverable, for zero agent tokens.

Encodes the method that worked 21/21, including the two shortcuts that do NOT:
- taking each Write's content recovers only single-write drafts (8/21 — agents
  refine);
- taking an Edit's new_string as a file yields a FRAGMENT, not a file.
So it replays the mutation history per (agent, file_path), snapshots after
every mutation, emits newest-first, and also scans Bash heredocs (the 21st
draft never used Write/Edit at all). --gate runs match_one newest-first and
keeps the first MATCH.

Self-test on wf_d804f25a-f6f: 3/3 including the heredoc case.
2026-08-11 21:12:44 -06:00
Drew T ec1f388d16 fix(phase-30 S48): name the §154-A leading-island wall instead of mis-blaming the carve
`jtbl_family_bank` fed every module jr member to `jtbl_carve`, which died with
`jtbl_… not found in the raw data asm`; `harvest_verify` turned that into
CARVE-REFUSED and never built. So the verdict named the TOOL, and 12 slots in
the wave-1 propagation read as a carve bug. Probing one member to the byte
level shows it is a LAYOUT the carve model does not cover:

  A module binds `.rodata` at 0x0 to the SAME subseg as its code (§154-A), so
  the object's rodata order IS the C file's include chain — INCLUDE_RODATA
  pieces, then each INCLUDE_ASM'd function's MIGRATED table, in address order.
  That reproduces the island exactly while the function is a stub. Matching it
  PRUNES its .s, its table leaves the chain, and cc1 re-emits it at the END of
  the object's .rodata: build 43,768 vs 43,760 bytes, first diff at 0x144
  inside the island's own pointer table.

`JTBL_PADS` does not reach it either — `jtbl_rodata_pads` refuses the object
outright ("unexpected rodata content .include ... D_801EF468.s"): the carve
model covers jump tables, not an island of mixed included data.

- `migrated_tables()` detects the layout by EVIDENCE (table absent from the
  data asm, present as a dlabel in the function's own .s), refuses loud with
  the measurement and the design that would work (isolate the jr function into
  its own subseg so its .rodata is a separate OBJECT, then ld_interleave — the
  §8 machinery re-aimed at a LEADING island instead of a data tail), and
  refuses a mixed carve set rather than half-carving (R32).
- Regression-checked both ways: overlay stubs classify [], modules classify
  migrated.

SIZED (R37): 70 module binaries, 42 with this layout; 1,345 open module
member-slots in sibling families, of which only 44 are jr. The island work is
worth 44 slots — it is NOT the module lane's main gate.

R22 clean-fleet: 213 passed / 0 failed of 213.
2026-08-11 19:16:26 -06:00
Drew T ba1fead353 fix(phase-30 S48): scope_data_externs spliced carried externs INTO a comment
`_body_open_brace` ran BOTH its scans on unmasked text. A crack agent's draft
opens with a header comment that names the function and quotes C at it:

    /* func_801EE8E0 (ov_MAIN_012 / jr_801789AC) — 188 ins, byte-exact vs …
     *  3) The `do { } while (0)` around the loop-1 call is a REGISTER-ALLOCATION

so `sig` matched the COMMENT's first line and `find('{')` found the comment's
`do {`. Every carried `extern` was spliced into the comment — silently
commented out — and the gate reported `'D_8011511A' undeclared`.

The sweep classified that CC1-FAIL, so it read as a property of the SIBLING
(all 4 members failed identically) when it was a property of the EXEMPLAR'S
PROSE. It had nothing to do with module binaries, which is where I had filed
it. Every richly-commented agent draft is a carrier; the trigger is any brace
inside the header comment — so this would have grown with the campaign.

- both scans now run on `cdecl._mask`ed text and index the original by the
  masked offsets (§134 / R33: one masking oracle);
- refuse outright if the length invariant is broken, rather than mis-place a
  declaration into live code (R32).

Measured: family func_8017CBC8 -> its 4 md_ siblings went 0/4 -> 4/4 banked.
2026-08-11 19:07:07 -06:00
Drew T 6eea1ac6a4 fix(phase-30 S48-0b): _carry_typedefs' already-carried test was line-oriented
The test was `^\s*typedef\b[^\n]*\bNAME\b` — the name must sit on the SAME LINE
as the keyword. True of `typedef unsigned char u8;`, never true of the
multi-line form the preamble backscan actually carries:

    typedef struct Foo {   …   } Foo;

so every multi-line typedef already in the unit was carried a SECOND time and
the unit reached the gate with two definitions of one tag. canon_sig_reconcile
uniquifies draft tags, so the duplicate is exact: `redefinition of struct
Foo_8013C0F8`.

- Extract the block capture as `_typedef_blocks(lines)` and derive the
  already-carried set from it (R33: one parser, two callers), so the
  multi-line form is recognised exactly as the single-line form always was.

Measured on the 0b population: func_8013C0F8 (3 slots) carried Foo+Bar twice;
func_8013B83C dropped a redundant file-scope copy of a typedef its body
declares at block scope. 6 other families byte-identical output.
2026-08-11 16:00:02 -06:00
Drew T dba6defb10 fix(phase-30 S48-0b): a def item can OPEN inside a block comment
`_proto_from_lines` starts `_strip` with in_block=False, but item boundaries
are `;`-terminated — so a declaration whose TRAILING comment wraps hands the
comment's continuation to the NEXT item, and the implied prototype came out as

  extern * a prototyped (s32) decl is `conflicting types` … */ void func_80151664(void);

It compiled only because the hoist emits the opening `/*` line immediately
above it, so the garbage lands back inside a comment — but `_file_scope_decls`
then meets a col-0 `extern …;` whose base type is `extern` and REFUSES (R32).
That is the isolate-fail class: 23 of the 111 open 0b member-slots.

- overlay_src_split._proto_from_lines: apply family_remap's D1 backstop — a
  `*/` with no `/*` before it means the chunk opened inside a comment; drop
  that residue before parsing the header.
- Repaired the 16 already-emitted region files (the garbage line's live
  payload was a redundant `extern void func_80151664(void);`).

Byte-gate after the repair: ov_MAIN_012 / ov_SC02_037 / ov_SC03_107 all
BYTE-IDENTICAL.
2026-08-11 15:58:25 -06:00
Drew T ec749fa584 fix(phase-30 S48-0b): JTBL_PADS follows its span through jr isolation
The 0b blocker was not "the pads line is left behind" alone — it fails two
different ways, and the second one is silent:

* bare isolate + `make build`: the stale line arms the pads filter on the
  RESIDUAL object, which emits no jump table ->
  `jtbl_rodata_pads: consumed 0 rodata .align(s) but 4 pad spec(s) given` (S47).
* isolate -> jtbl_carve (the jtbl_family_bank path): `set_pads_vars`
  regenerates the block keyed by the CURRENT subseg names, finds no prior spec
  under the new `_jr_<addr>` name, and DROPS the line. cc1's natural `.align 3`
  then pads the span's non-8-aligned interior tables and the image shifts —
  reported only as `built, bytes differ`.

- jr_isolate_all.repoint_overlays_mk: repoint the `build/src/<ov>/<sub>.o:
  JTBL_PADS` target with the `--order` leaf whenever a carve moves; refuse
  loud if the old object still hosts a .rodata piece (R32).
- jtbl_carve.set_pads_vars: second, disagreeing oracle (R34) — refuse when a
  spec would vanish for a subseg no longer in the carve set (rename/merge
  drift), instead of silently emitting a padless object.

R37 probe: func_801789AC -> ov_SC02_037 went `built, bytes differ` -> BANKED
on the whole-binary byte gate. ov_SC02_037's spec is 0,0,0,0 over tables
+0x0,+0x14,+0x34,+0x4c — load-bearing (span start is 4 mod 8).
2026-08-11 15:31:57 -06:00
Drew T fd80bd7007 feat(phase-30 S47-0a.1): the symbol-KIND fix banks 205 members; the residue crosses over to DIFF
Stage 0a's first defect, and the largest single zero-token bank of the session.

family_remap's kind test asked ONE question — is this address a function in the SIBLING'S OWN sig?
— and defaulted to `D_` on "no". But a body calls outside its image constantly: an overlay calls
resident helpers, an md_* module calls the overlay-range engine. Those addresses are absent from
the sibling's sig, so the test fell through and emitted a DATA NAME FOR A FUNCTION —
`D_800183E0`, `D_800D1EBC`, `D_80171A1C`. None exist anywhere in src/ or config/symbols.us.txt,
while `func_80171A1C` alone has 1,061 references. Measured: 611 member-rows across 45 symbols,
the largest named residue class. "Not in MY sig" means "not mine", not "is data".

Fix — three oracles, strongest first, never a blanket fallback:
 1. the sibling's own sig (authoritative for its image; this is what preserves the Phase-29 T82
    case where a slot is a function in the exemplar and DATA in the member — unioning every sig
    would have re-broken the 251 members T82 fixed),
 2. the always-linked images via extern_fn_addrs() — resident + main, 2,146 addresses whose ranges
    cannot collide with an overlay's,
 3. the exemplar reached it by `jal` — a call target is a function BY DEFINITION, which covers an
    external address neither sig claims (0x80171A1C from an md_* module, 112 rows).
Only a non-call reloc no oracle claims still falls to `D_`.

Result: BANKED 205 member-matches, failures 670 -> 575, derived net = report = 205.
R22 clean-fleet 213 passed / 0 failed of 213.
Fleet 94.4% instr / 88.3% distinct / 96.27 -> 96.33% fn-count; stubs 13,563 -> 13,345.

THE RESIDUE HAS CROSSED OVER: DIFF is now the LARGEST class at 143 of 575 — real byte divergence
outranks plumbing for the first time this session (undefined-ref 611 -> ~8, PLUMBING-other
231 -> 81). The ~5:1 plumbing:DIFF ratio that justified "tooling beats volume" has inverted in this
queue, exactly as the frontier analysis predicted: the declaration-axis vein was one-time.
The new head class is `conflicting types for func_80175414` (27) — the same addresses this fix
started naming correctly, now surfacing the NEXT layer (the symbol resolves; its declared signature
disagrees). That is the conform axis, not the remap axis.

Note for anyone auditing this class: rtu_match MASKS HI16/LO16, so a wrong %hi/%lo symbol still
reports MATCH (the T82 comment records `MATCH (10 ins)` on a member the fleet gate refused). This
defect is invisible to the per-function tool by construction — only the whole-binary gate sees it.
2026-08-11 14:02:38 -06:00
Drew T d5fbd2630f fix(phase-30 S47): family_hseq derives its own SCOPE, not just its own count; + a zero-crack glossary
The targeting oracle stamped its scope as "the N OVERLAYS only (no main, no resident)" while
load() has scanned the md_* modules and the resident since S44. Measured at this HEAD: 141 location
overlays + 70 md_* modules + the resident = 212 binaries. That is the §159 coverage law broken by
the file that documents coverage, on the repo's most load-bearing targeting instrument — and it is
how "main is structurally barren" survived two phases unexamined.

The COUNT beside it was already derived, with a comment saying "report the scope we ACTUALLY
scanned, never a hardcoded count". The PROSE describing what the count meant was hardcoded and
rotted. Both are derived now.

Caught while fixing it: my first cut read glob(".run/sig.main.jsonl") and stamped "main INCLUDED"
the moment that file existed — while load() still did not glob it. Same defect one layer down: a
stamp describing the filesystem instead of the run. Now derived from the loaded instances.

Also added a glossary line: "zero-crack" means n_matched == 0 (needs its FIRST crack) in this map,
and the OPPOSITE (a matched exemplar awaiting propagation) in roadmap §3 T3 — a ~30x mis-scope risk
for any session reading one against the other.

NOT DONE — main inclusion (0c) is still blocked on settling the attribution. Confirmed the
mechanism: main has 49 LINKED PsyQ subsegs, corpus.stubs('main') returns 2,002 INCLUDING them,
progress.py correctly excludes them and reports 1,034 game-code stubs. progress.linked_subsegs'
own docstring records this exact trap ("an importer then classifies ~1,300 already-byte-identical
LINKED library stubs as outstanding game-code work") — and my sig-main seeded from corpus.stubs,
so it inherited the LINKED rows, which is why G2's 207-family finding was inflated.
My partition probe is NOT trustworthy: 954 of 2,002 stubs returned no asm path from
corpus.asm_path, so 199 LINKED / 849 game / 954 unresolved does not reconcile with 1,034. Fix the
probe before trusting any main-scope number.
2026-08-11 13:42:40 -06:00
Drew T d806766eef feat(phase-30 S47-W1c): crack the reach-57 exemplar; fix the instrument that called it a wall
func_801EDC18 (md_SC05_023) is the largest multiplier remaining — 57 members. The wave agent
abandoned it at "closeness 6" with class SIZE-MISMATCH [redraft]. It was two lines from correct.

THE CODE (cookbook §160a): the target copies 8 bytes with lwl/lwr + swl/swr — gcc-2.7.2's
emit_block_move for a type with ALIGNMENT 1. The draft used a u32 copy (aligned lw/sw), which is
wrong by construction. `typedef struct { char c[8]; } Blk8; buffer = D_801ED98C;` reproduces it.
Six spellings were tried in parallel; two independent agents converged on the same one.

THE INSTRUMENT (§160b) — this is the part worth more than the function. The target .s bundles a
leading `.section .rodata` block (D_801ED98C as two .word) ahead of .text. Those lines carry the
same `/* off vaddr HEX */` shape as instructions, so masked_diff.insns_from_s counted them as TARGET
instructions, while insns_from_object (objdump -j .text) can never emit them. A byte-perfect draft
therefore read `mine=26, target=28, 26 mismatched` — every position shifted by a constant +2 — and
got classified as needing a redraft. 116 of 12,583 .s files in the corpus have this shape, one at
-29 instructions. Every one of them would report a false wall to any agent that tried it.
Fixed: insns_from_s tracks .section and counts only .text. Full-corpus control: 12,467 unchanged,
116 corrected, 0 regressions. Same artifact class as §129a (post-carve jtbl inflation).

THE OWNERSHIP LAW (§160c) — my own error, corrected by the gate. Four sites declare
`extern short D_801ED98C;` and nothing in src/ defines it, so I shipped an extern-only draft. The
gate refuted it: `undefined reference`. The .s block the draft REPLACED was the definition. The
variant emitting `const Blk8 D_801ED98C = {{...}}` banks clean. Never infer ownership from externs.

R22 clean-fleet: check-all 213 passed / 0 failed of 213.

ALSO BANKED — the wave's idiom harvest, which had been sitting unwritten in workflow transcripts
(R16/R30 debt): §160d the ASYMMETRIC INDEX RELOAD (a just-stored narrow field read twice emits
reuse-then-reload; the C is deliberately asymmetric), §160e a stack-layout scheduling rule now
byte-proven on a SECOND independent function (promoting it from coincidence to rule), §160f the
address-only global store via array decl, §160g sibling-search keyed on the CALLEE SET as step 0 of
every wave prompt (one grep turned a 126-instruction crack into a copy-edit).
Cookbook index regenerated: 468 sections.
2026-08-11 12:05:24 -06:00
Drew T 974401668f feat(phase-30 S47-F4a): cpp-derived TU type map clears the data-conflict class (+31)
scope_data_fix detected conflicts by SCANNING TU TEXT, which cannot see a MACRO-INJECTED
declaration — and that is where these conflicts live: `extern Vec8 D_80114F24;` sits inside a
DEFINE_func_* macro body in engine_core.h while the overlay .c holds only `DEFINE_func_XXXX()`.
That declaration is a genuine file-scope decl of every TU invoking the macro, and it is what the
draft collides with.

Fix: family_sweep builds a per-TU map from cdecl.tu_scope (cpp-derived, cached — 467 data decls in
ov_MAIN_012 vs 0 findable by text scan) and passes it to scope_data_fix, which now takes an
optional tu_types. tu_scope is the repo's stated oracle for "what does this TU declare", and its
own docstring warns that the `above` form answers VISIBILITY, not CONFLICT — C requires
compatibility regardless of order. scope_data_externs was built on that wrong question.

Banked 5 -> 31; failures 730 -> 699. The whole data-symbol class is gone: D_80114F24 (12),
D_800AE620 (10), D_80126B58, D_80078EB4, D_800183E0 all cleared.
R22 clean-fleet: check-all 213 passed / 0 failed of 213.

REGRESSION I CAUSED, AND FIXED: the reclassification showed 9 fresh `conflicting types for
aD800B9A02` — my own alias colliding. The group-level path suffixes the alias per function
precisely to prevent this; scope_data_externs did not, so two drafts aliasing one symbol declared
`aD800B9A02` twice with different types — re-creating the collision one level down. Both paths now
use _alias_name(sym, func). Verified: distinct names, each keeps its own type, both bind the real
symbol via the asm label.
2026-08-10 22:39:13 -06:00
Drew T 3e0028c2ed feat(phase-30 S47-F2b): group-level draft-vs-draft data aliasing (83 aliased, 5 banked)
family_sweep stages every member of an (overlay, split) group into ONE TU before gating, so two
templated bodies routinely carry different views of one address — D_80114F24 is `s32` in one body
and `Vec8` in another. scope_data_fix is handed one draft plus the pre-splice TU and structurally
cannot see the others, so that collision was invisible to it.

_alias_group_data_conflicts(): after staging, any data symbol a group's drafts declare with >=2
distinct types gets a PER-DRAFT §37 asm-label alias. The alias is suffixed with the function name
(aD80114F24_8017B880) — aliasing both drafts to a shared name would re-create the same collision at
one remove, which the unit test exists to catch. Each body keeps its own type: for data the declared
type drives the load (lh vs lhu), so canonicalising would silently change codegen for every other
view. Codegen unchanged — the asm label pins the emitted symbol.

83 conflicts aliased across 172 groups; banked 2 -> 5. R22 clean-fleet 213 passed / 0 failed of 213.

WHY THE HEADLINE SYMBOLS DID NOT MOVE — root cause now CONFIRMED, not inferred. D_80114F24 (12)
and D_800AE620 (10) are unchanged because the conflicting declaration is MACRO-INJECTED:
`extern Vec8 D_80114F24;` lives inside a DEFINE_ macro in engine_core.h (D_800AE620 has 6 such),
while the overlay .c holds only DEFINE_func_XXXX() invocations. Neither a scan of the staged drafts
nor a scan of the TU text can see it — that needs the preprocessed TU. The sweep already does
exactly this for CALLEES (cast_call_sites' canonical map is cpp-derived "so it sees macro-injected
declarations"); the data path never got it.

This collapses F2's remainder and F4 into one fix: memcpy's 26 failures are the same shape — task B
found nine `extern void *memcpy(...)` spellings inside those same DEFINE_ macros. A cpp-derived
declaration map feeds both, and the alias mechanism is already built and control-tested; only the
detection SOURCE is wrong. For memcpy the alias is the documented house solution, not a workaround
(engine_core.h:24480 hand-writes `extern void func_8005C324(...) __asm__("memcpy")`).

Four attempts on this class for 5 members: three mechanisms proposed before reading what the
compiler actually complained about. The mechanisms are correct; they targeted the wrong collision.
2026-08-10 22:24:13 -06:00
Drew T d4d35ec738 feat(phase-30 S47-F2): auto-alias conflicting data externs (partial: 2/44); real cause recorded
The 44 data-symbol conflicting-types failures are NOT the cdFileLocTable duplicate-typedef class.
They are genuine per-view type differences: D_80078EB4 is s16 at 2,409 sites and u16 at 1,341;
D_800AE620 is Blk20/s32/Mat32. For data the declared type drives the load (lh vs lhu), so
canonicalising would rewrite thousands of already-banked sites' codegen. The answer is one type
PER VIEW — the §37 asm-label alias the fleet already hand-writes for D_800AE620 (9 sites).

Shipped: scope_data_externs now auto-aliases a conflicting extern —
    extern s16 aD80078EB4 __asm__("D_80078EB4");
keeping the draft's own type (byte-truth for that body) while the private C name makes collision
impossible and the asm label pins the emitted symbol, so codegen is unchanged. Fires only where
the TU declares that symbol with a DIFFERENT type text; same-type and already-aliased drafts are
untouched (4 controls, 2 of them negative). Applied on both scope paths — a staged draft's externs
arrive indented, so a demote-path-only fix reached 1 of 44.

R22 clean-fleet: check-all 213 passed / 0 failed of 213.

WHY ONLY 2 BANKED — the collision is DRAFT-vs-DRAFT, not draft-vs-TU. The failing draft declares
`extern s32 D_80114F24;` and ov_MAIN_012.c declares that symbol nowhere; the error lands at the
splice point. family_sweep stages every member of an (overlay, split) group into one TU before
gating, so two templated bodies with different views of one symbol collide with each other.
scope_data_fix sees one draft plus the pre-splice TU and structurally cannot see the others.
The real fix belongs in the staging loop, which knows the whole group: alias any data symbol
declared with >=2 distinct types across the drafts staged together. Not attempted here.

Three wrong inferences on this one task before reading a failing draft: scoped as the typedef
class; aliased only the demote path against the file's own comment; targeted the wrong collision.
2026-08-10 21:56:31 -06:00
Drew T b9033851cf fix(phase-30 S47-F1): classify diagnostics by position, not vocabulary — 93 unknowns all named
harvest_verify.classify_fail kept only stderr lines containing the word `error`. gcc-2.7.2 emits
no `error:` prefix on hard errors, so lines like

    src/…/ov_SC02_037_jr_8013B83C.c:447: multiple storage classes in declaration of `tail_…'
    src/…/ov_SC06_025_jr_8012ACE0.c:2217: `tbl_D_80187044' undeclared (first use this function)

never survived the filter, `errs` held nothing but make's `Error 33` wrapper, and every hard error
was labelled CC1-FAIL(no-diagnostic) — "the compiler failed and we cannot see why". Measured cost
this session: 132 siblings of func_80132018 classified that way by one missing declaration, which
reads as a codegen wall and gets a family deprioritised. rtu_match had the same blindness repaired
at T0(b); the fix was never propagated here.

Fix: a diagnostic is a POSITION, not a vocabulary — `<file>:<line>: <text>`, plus the assembler's
`{standard input}:<line>:` (_SRC_DIAG). Context lines carry no `:<line>:` and are skipped.
Five controls pass, including the two that guard against over-fixing: PLUMBING still wins on a
declaration conflict, and a warnings-only failure still returns no-diagnostic.

Re-swept: 0 no-diagnostic remain. The 93 resolve to 35 redefinition-note, 11 D_801202A0
undeclared, 10 too-many-arguments, 4 too-few-arguments, 4 func_8001534C undeclared — every one a
cheap declaration/arity class, not a wall.

Residue now fully named (737): 207 undefined-reference across 42 symbols (a link-stage REMAP gap,
now the largest class), 138 DIFF (real divergence, 19% — the honest floor), 44 data-symbol
conflicting-types, 35 redefinition-note, 26 memcpy, 24 redeclared, 15 undeclared, 14 arity.
2026-08-10 21:28:00 -06:00
Drew T 713b093845 fix(phase-30 S47): three splitter defects blocking the monolithic-overlay carve
Found while scoping the jr carve for the 3 newly-onboarded binaries. My scoping said "one
unplaceable construct" — it was the first of four layers. Three are fixed here; the fourth is out
of this tool's scope and leaves the carve blocked.

1. asm_label_aliases: the scan could START inside a #define. `#define gte_SetRotMatrix(r0)
   __asm__ volatile ("lw $12, 0( %0 );" ...)` is textually `ident(...) __asm__(...)`, and
   cdecl._mask blanks string CONTENT — deleting the `;`s that would stop the greedy [^;{}]*.
   The match ran 116 lines and swallowed the real `aF8012EFB8 ... __asm__("func_8012EFB8");`,
   so the alias never entered the map and addr_of returned None. jr_isolate_all then refused to
   carve (R32, correctly), which presented as 112 isolate-fails that looked like a per-binary wall.
   Fixed: _mask_cpp_directives() — a preprocessor directive is the other place a match must not
   start. Masking comments/strings fixed the comment case and left this one.

2. _split_macro_body returned a `static inline` internal HELPER as the macro's definition, so
   _proto_from_lines hoisted `extern static inline void tail_8012F274(...);` into all 41 regions:
   invalid C (multiple storage classes) AND the wrong function — the exported definition sits
   below the helper and lost its implied declaration. Fixed: skip static definitions
   brace-balanced on the masked body. A static helper needs no hoisted declaration at all.

3. A declaration that WRAPS across continuation lines was taken as one line, so half became a
   `;`-less extern and the continuation was read as the definition header, producing
   `extern __asm__(""); void aF801466F0(...);` in 22 regions. Fixed: accumulate until the
   statement terminates, tested on the masked text. Same wrapped-declaration blindness
   family_remap._alias_decl_for records fixing at S33 — never propagated here (§134/§139).

Not fixed, and why: jtbl_rodata_pads reports "consumed 0 rodata .align(s) but 4 pad spec(s) given
— table-count drift vs the carve". The carve moves jtbl-owning functions into _jr_ regions but
leaves the pad specs on the residual gap object. jr_isolate_all's docstring states this class is
NOT isolate-fixable; it needs JTBL_PADS repointing in overlays.mk. 122 jr member-slots stay blocked.

Regression-checked: 1,948 macros parse with 0 malformed externs; alias maps unchanged on three
already-carved overlays. No build impact (splitters run offline). Carve reverted, tree clean.
2026-08-10 20:08:53 -06:00
Drew T efec1b9b71 fix(phase-30 S47-A1): asm-label aliases must never be dropped by §8d; +148 members
scope_data_externs §8d drops the draft's decl of any symbol the TU already declares at file scope.
It keys on the SYMBOL, but a §37 asm-label ALIAS binds a DIFFERENT C identifier to that symbol:
the TU declares `D_801851BC`, it does NOT declare `tbl_D_80187044`. Dropping the alias left the
body referencing an undeclared name, which cc1 reports with no `error:` prefix — so the sweep
classified all 132 siblings as CC1-FAIL(no-diagnostic), i.e. as a codegen wall.

The bitter part: the alias exists PRECISELY BECAUSE the TU declares that symbol with a conflicting
type (a `void (*[])(void)` dispatch table vs this function's 20-byte-stride view). The drop rule
fired on exactly the declarations written to survive it. Why 1 of 2 died was fully determined:
tbl_D_80187048's symbol is not in the TU, so it demoted normally.

Fix: is_asm_alias() — an alias is demoted into the body, never dropped (the identifiers differ, so
it cannot collide with the TU's decl). Control-tested 6 ways incl. self-labels and plain externs.

Measured: func_80132018 3/135 -> 135/135; full re-sweep +16 more. Total +148 members.
R22 clean-fleet 213 passed / 0 failed of 213. tools-health OK, dedup-check 1949/0.
Fleet 96.11 -> 96.15% fn-count, 87.8 -> 87.9% distinct; stubs 14,120 -> 13,972 = -148 (2nd oracle).

CORRECTION TO MY OWN CLAIM (R14): after the probe I said the 58% aggregate was concealing a broad
problem. The re-sweep refuted it — only 16 more banks fleet-wide. The alias class really was one
family; the first read ("outlier") was right and the correction was wrong.

875 sweep failures classified: 231 PLUMBING-other, 141 DIFF (real divergence, only 16%),
136 `conflicting types for cdFileLocTable` (ONE symbol — biggest single class left),
77 CC1-FAIL(no-diagnostic), 26 memcpy, 12 D_80114F24, 11 D_800AE620, 9 D_800183E0.

STILL UNFIXED, and the most dangerous instrument left: the sweep's failure classifier greps for
`error:`, which gcc-2.7.2 never emits on hard errors. Every hard error therefore reads
CC1-FAIL(no-diagnostic). That is how a missing declaration looked like a codegen wall across 132
functions. rtu_match was fixed for this at T0(b); this classifier was not.
2026-08-10 18:50:48 -06:00
Drew T e92ba14028 feat(phase-30 S47-C): dedup_extend banks 62/129 (first non-zero); gate_stage verified-out fix
C, unblocked by B's declaration conform. 23/23/16 banked across ov_SC03_107, ov_MAIN_012,
ov_SC02_037 — the first non-zero result on this population (S46 got 0/142, then 0/129).
R22 clean-fleet: check-all 213 passed / 0 failed of 213. tools-health OK.
dedup-check 1949 validated / 0 failed, C1 coverage 249295 (= 249233 + 62, independent
confirmation of the count). Fleet 93.9% instr / 87.2% distinct / 95.72% fn-count.

THE TOOL REPORTED "BANKED 0 / 129" AND WAS WRONG. gate_stage's ladder hands the same
--verified-out path to harvest_verify on every rung, and each rung opens it for write: stage 0
banked 23 and wrote them, then a later rung that banked nothing truncated the file to 1 byte.
The in-memory list uses += and stayed correct, which is why the JSON verdict listed all 23 names
while the file said nothing. dedup_extend read the file, printed BANKED 0, and took its
`if not banked:` branch — skipping add_members_surgical, so the registry was missing 62
memberships for functions already spliced in and byte-verified.

- Registry repaired by deriving the banked set from git diff (+DEFINE_func_*), not from the
  broken file. Post-check: 0 missing.
- ensure_include_revert did NOT fire (added_include False, include already present) — the
  P29-S19 defect that once stripped a load-bearing include from 135 binaries stayed closed.
- gate_stage now writes verified_out once at the end from the accumulated truth.

Caught only because bank truth is derived from source (§55b), never from the gate report.
Residue (67) is consistent with the symbols B deliberately left: memcpy 17, ApplyMatrixSV 12,
gte_SetRotMatrix 4, plus 21 CC1-FAIL and 3 DIFF. Not separated: how much of the 62 is B's
conform vs the ladder's own recovery rungs.
2026-08-10 16:35:57 -06:00
Drew T 9ab9120e04 feat(phase-30 S47-B): conform 8 declaration axes (~10,930 sites); 3 guard defects fixed; 213/213
Task B, re-scoped from evidence. The 129 dedup_extend failures are 106 conflicting-types /
21 CC1-FAIL / 4 undefined-ref / 3 DIFF — real byte divergence is 2%, and memcpy is 17 of 106,
not the story. Direction reversed too: the byte-true DEF of func_80128ED8 is what the target
.c files already declare; engine_core.h's macro-local extern was the stub-era guess.

Conformed 8 axes to byte-truth (func_8012F14C 2843, func_8012E5CC 2052, func_8012F038 2214,
func_8014C568 1816, func_80128ED8 1524, func_8012C750 406, func_8012C0EC 50, func_80144A04 25).
R22 clean-fleet: check-all 213 passed / 0 failed of 213. Zero functions banked by design.

Tooling (R33/R35) — three guards that asserted completeness over a narrowed population:
- NEW tools/macro_draft.py: a deduped fn has no definition in any .c (body lives in a DEFINE_
  macro), so conform_decls had been refusing the largest class it was built for.
- conform_decls skipped engine_core.h wholesale as "a defining TU": 10 stale externs survived
  while 1,514 fleet sites moved, and it still printed "axis complete". Skip now scoped to the
  defining macro's span.
- Return-axis compare was literal: typedef int/s32 and a missing `extern` faked a return change.
  Now compares normalized types.
- §85 consumer scan under-reported (the dangerous direction): a cast between `=` and the call
  hid `s0 = (s32 *)func_80144A04(...)`. Now classified by position, validated both ways.

Corrections to my own predictions (R14): the documented scalar-narrowing hazard was benign
across 2,052 sites; the breaks were arity (6 call sites, fixed with §17a-1 fn-ptr casts) and
the consumer-guard gap. A header-only first probe broke ov_SC01_000 — §85 is literal.

Not done, named: memcpy (builtin codegen), ApplyMatrixSV (no DEF), gte_SetRotMatrix (link bug),
func_80147364 (unparseable macro), D_800AE620/D_80126CC4 (data axis). Cookbook §159.
2026-08-10 16:01:49 -06:00
Drew T b0c1e14fda feat(phase-30 S46-final): 400+ cascade banked (11) + waste-prevention gate; B re-scoped, C blocked
- BANKED: 11 functions at 400-952 ins from the cascade (func_8017D898 952, func_8017CE58 733,
  func_801902EC 673, func_8018C2D8 673, func_8018A8D4, func_8017C6F4, func_800CBB38,
  func_800CF3A4, +3). check-all 213/213 from a clean tree. 6 near = jr/switch (§53 separate
  banking step), 1 failed. The cascade agents wrote 6 new cookbook sections incl. §158.
  ⚠️ tools-health UNVERIFIED at commit (stale cookbook index fixed, confirming re-run
  interrupted) — run it first next session. check-all is the byte oracle and it is green.
- WASTE PREVENTION (Drew: "prevent this from ever happening again, however you need to"):
  * tools/validate_targets.py (NEW) — names 5 defect classes (NO-ASM / MID-BODY /
    OUT-OF-RANGE / ALREADY-DONE / NO-BOUNDARY), exits non-zero.
  * WIRED INTO wave_snapshot so it fails closed — every wave passes through there for its .s
    files, so no path from target list to spawned agents bypasses validation. Negative-control:
    a 3-target bad list is refused with the exact mid-body offset (+72 bytes of 100).
  * The cascade `done()` predicate now short-circuits on SKIPPED as well as MATCH. It tested
    only MATCH, so a non-existent target fell Sonnet -> Opus -> Fable and three agents each
    proved the same phantom absent: ~29 invalid targets x 3 tiers = 87 of 119 agents, ~9.7M
    tokens. A tier that cannot act must END the pipeline, not escalate emptiness.
  * docs/accelerators.md A9, including that wave_snapshot's own R32 assertion REFUSED that list
    (24 of 57 found) and was routed around — the one instrument warning that was right and ignored.
- B RE-SCOPED (S46-10) and deliberately NOT done: the extend blocker is INTRA-HEADER, not
  target-side. engine_core.h declares memcpy FOUR incompatible ways across its DEFINE_ macros;
  two in one TU collide. NOT a safe cleanup — the in-tree note at ov_MAIN_012.c:14333 records
  that `extern memcpy` disables gcc's builtin and turns an inlined block-move into a CALL, so the
  declaration CHANGES CODEGEN. Probe one macro in one binary and byte-gate before any sweep.
- C (dedup_extend over the 129) stays blocked on B. Full context for both in the checkpoint.
2026-08-10 14:16:19 -06:00
Drew T d54d0a899e feat(phase-30 S46-6): recovery ladder banks +6; wire gate_stage into dedup_extend
- RECOVERY PASS A (wave residue): gate_stage over the 3 big-3 draft dirs recovered
  6 sites the bare gate rejected — func_80168664 x3, func_80168F40 x2, func_8012B77C
  x1. That is 6 of 19 PLUMBING = ~32%, matching the 16-39% range P29 measured. Batch 1
  goes 27 -> 33 of 60. R22 213/213 + tools-health green.
- HONEST SIZING (correcting my own claim): ~32% is NOT "a one-time fix for a ~50% draft
  loss". It moves the batch loss from 55% to 45%. Real and free; not transformative.
- WIRED (task 9): dedup_extend now gates through gate_stage (the ladder:
  canon_resident_calls -> cast_call_sites -> sig_unify -> harvest_verify) instead of
  harvest_verify verbatim. Its 142 candidates failed 0/142 with reasons 118 PLUMBING /
  21 CC1-FAIL / 3 DIFF — ~1 in 50 a real byte divergence, the rest declaration conflicts
  in the TARGET TU, which is exactly what the ladder reconciles.
  GATE_NO_ARITY=1 is forced for the child: gate_stage's arity pre-pass writes the
  fleet-shared engine_core.h BEFORE the gate and a failing draft can leave that edit
  behind — the F1 defect that broke 141 of 213 binaries in S45. The ladder's other rungs
  are draft-local. --ladder can be disabled to restore the old path.
- DOCTRINE (step 3): gate every wave with gate_stage, not bare harvest_verify. Batch 1
  needed a second manual pass only because I used the bare gate first.
- LEVERAGE METRIC CORRECTED (R14/R35): the behemoth ranking must use LIVE reach
  (unmatched sharers), not total sharers. func_80144B9C reads 770 ins x 141 = 108,570
  by total, but 138 of those are already banked — its true weight is 770 x 3 = 2,310.
  Same x134 over-count the cookbook records in §25; build_wave_args --rank live exists
  precisely for this and I used the wrong ranking. Remaining >=400 ins: 57 distinct
  functions / 77 live instances / 38,968 ins, reach ~1.35 => ~0.3% instr-weighted.
2026-08-10 10:43:44 -06:00
Drew T f6e48b60c5 perf(phase-30 S46-4): parallelise the propagation — 24min -> 11.4min, and +62 MORE instances
Drew: "make it more multi-threaded... I still see my cpu idle for far too long."
Measured, fixed, and regression-tested against the S46-3 bank as a KNOWN ANSWER.

- THE MEASUREMENT: 31s saturated (33 makes/48 cc1/load 27) then ~25s with ONE build alive
  while 31 cores idled, repeating. Causes: ex.map starts in list order so the giants land
  last, and apply/restore is single-threaded.
- gate_all -> gate_failures: return EVERY failure the sweep already computed (~138 rounds -> 1).
- Longest-first gate scheduling; results re-sorted into `changed` order so the verdict stays
  bit-identical to the serial loop's.
- PER-OVERLAY INDEPENDENT SEARCH, IN PROCESSES. My first cut used threads and the box refuted
  it: 0-4 builds alive at load 3, because the work is regex over 15k-line files and 138
  "parallel" searches all queued on the GIL. Same logic in a ProcessPoolExecutor: 14-29 builds,
  load 34.75, search phase ~100s. Safe because the shared header is written ONCE by the parent
  and each overlay owns its own .c files + build/<bin>/. Seeded with one in-process search
  first — a pool submitted at once gives every worker an empty suspect list and makes all 138
  pay a full bisection. place_in_overlay extracted to module level so the worker and the
  in-process apply cannot drift (R33); compiles_standalone's fixed t.c is per-call now.
- THE REGRESSION (the point, not the stopwatch): revert src/+config to pre-bank, re-run the
  identical command -> 29 functions (same), 141 overlays byte-identical, 682s vs ~1440s, and
  285 exclusions vs ~350 => +62 MORE member instances (249,161). The old prefix-based
  necessity probe was OVER-EXCLUDING (charging 4 fns to 9 overlays that did not all need
  them); the per-overlay shrink minimises per overlay. The faster path is also more correct —
  a timing comparison would never have shown it. R22 213/213 + tools-health green.
- STILL SERIAL, now the actual wall-clock (neither is a build): ~3min setup before the first
  gate (registered_addrs() yaml-parsing a 1949-group/249k-instance registry + 213 sig loads)
  and ~2.5min of sequential reconcile_caller_extern after the search.
- Captured as defaults: docs/accelerators.md A8 + memory fleet-tool-parallelism-defaults.
  cookbook index regenerated (my §155c append left it stale — the gate caught it, exit 1).
2026-08-07 23:14:15 -06:00
Drew T 9351b17f48 feat(phase-30 S46-2): the master IDXTAB/DESTPTR load map — and the tracker blind spot that hid it
Drew's S45 idea, delivered fleet-wide + wired into the permanent references.

- THE BLOCKER WAS OUR INSTRUMENT (R35, the 3rd time): the S45 plan ("require a
  register-verified reference to the run's address") returns ZERO for both byte-proved
  tables. They are read by gcc's indexed global-array form —
      lui $at,0x8019 ; addu $at,$at,$a0 ; lh $v0,-0x2844($at)  -> 0x8018D7BC
  — where the address exists only as (lui imm, LOAD offset) with the index add between.
  find_addr_refs killed the lui register at the addu, so the halves never rejoined and
  the tables looked unreachable. Now it carries the hi half through the index add (still
  strictly register-tracked, never window-paired) and labels those hits `-indexed`.
- tools/idxtab_map.py (NEW): fleet-wide payload -> owning binary -> load address.
  Controls-gated (refuses to emit unless ov_SC01_000 0x8017EEC8/37 + *0x801A3234, and
  ov_SC03_001 0x8018D7BC/5 + *0x801EBC68 reproduce from the images alone). Index space
  DERIVED from the extracted tree (reproduces §S44's table independently). Process-pooled.
  Rejects all-zero and majority-zero runs (132 of the first pass's 452 "tables" were that).
- RESULT: 213 binaries -> 143 with a referenced table (294), 141 with a DESTPTR (141/141
  resolved from the binary's OWN image), 61 payloads. The two dominant tables are
  fleet-wide CONSTANTS (5-entry and 37-entry, identical in all 141 overlays); the
  per-binary variable is the destination (134 distinct).
- CORRECTION 1 (R14): §S45 p6's "the SC03 trio are owned by ov_SC03_001" is refuted —
  that 5-entry table is identical in ALL 141 overlays. The byte-observed parts stand.
- CORRECTION 2 (P9): this route CANNOT settle MAIN/7+9. They are absent from all 294
  tables — but so are MAIN/13/20/34/42/44, which are byte-proved to load. Absence here
  means "not on this route", nothing more. Recorded so it is not re-derived as a finding.
- Confidence is stated per-claim in docs/idxtab-map.md: proven (controls) / high (283
  fleet-wide-class tables) / low (3 named rare rows) / UNMEASURED (recall — no oracle
  for "all tables" exists beyond the 2 controls).
- Wired in permanently: docs/idxtab-map.md (the how/when/limits), memory-map.md §S46,
  cookbook §155c (the generalizable law: "no code references X" is a claim about your
  DECODER until it is shown to recognise the forms the compiler emits), SETUP.md
  tooling inventory (R21).
2026-08-07 22:09:05 -06:00
Drew T 91c64ce92c fix(phase-30 S46-1): dedup_propagate — no silent skips, no unproven REVERTs
The S45p9 blocker: `[FAIL] ov_MAIN_012: 0x80156600 not instantiated — REVERTED`
92 minutes into a --auto-from run, naming no mechanism.

- FIRST, the honest finding (R14/R35): it does NOT reproduce at HEAD. A replay of
  apply_plan's per-file site resolution over the exact 30-fn plan resolves
  0x80156600 as a stub at line 7505, and def-range/stub-line overlaps = 0 (the
  splice-swallow hypothesis refuted). The failing input state was not the committed
  tree — most likely a concurrent writer mid-run. So this commit does not "fix" that
  run; it makes the next occurrence name itself.
- SILENT SKIP -> LOUD (R32): an address resolving as neither the sp-regex stub nor a
  def just stayed in `remaining`. apply_plan now records gaps={ov:[addrs]} and the
  caller fails FIRST with a per-site diagnosis (whole-overlay find_site verdict,
  in-sig, file list) instead of struct_check's terse late message.
- CAPABILITY GAP that produces exactly that skip: find_site returning 'stub' was
  ignored (apply_plan acted only on 'def'), so a stub whose INCLUDE_ASM asm-subdir
  != its file stem was invisible to the stem-anchored sp regex AND unhandled. Now
  placed ('macro' treated as already-placed). find_site's stub match is an exact
  stub_line(ov,addr) compare against THIS file's text — it cannot cross files/TUs.
- INCOMPLETE REVERT (the §156 class, different path): struct_check restored only
  `touched`, leaking every kept Part-B reconcile. New _abort() undoes touched AND
  every kept reconcile, then diffs the worktree against a start-of-run baseline and
  reports any residue. A tree dirty in a way nobody knows about makes every later
  byte-gate report `near` — that is how S45p7 lost two batches.
- NEGATIVE CONTROL: neuter ov_MAIN_012's stub -> [GAP] fires naming the exact
  condition (find_site=None, in-sig=True) -> "[revert] tree restored to baseline;
  no residue" -> exit 1 (fail-closed). Restore -> tree clean.
2026-08-07 21:26:03 -06:00
Drew T e86e45320a chore(phase-30 S45p9): session close — 32-way parallel gate in dedup_propagate; banking deferred on a tool bug
PARALLEL GATE (landed, verdict-proven): dedup_propagate's byte-gate loop was serial --
one `make build BINARY=<ov>` at a time over up to 141 members per function. Measured: a
propagation ran 95 minutes at load 1.6 on a 32-core box (~5% utilisation). The Makefile
has parallelised extract-all/check-all since Phase 26 (xargs -P$(JOBS)), but this tool
predates that and drives the SINGLE-binary target from Python, so it never saw any of it.
  - new gate_all(): ThreadPoolExecutor over distinct overlays, 32-way by default (JOBS env
    overrides; deliberately NOT capped at the Makefile's conservative 16).
  - SAFE by the same argument check-all relies on: byte_gate only runs `make build`, writing
    solely to per-binary-disjoint build/<bin>/**; it mutates no source. Splice happens before,
    restore after -- only the VERIFICATION is parallel.
  - DETERMINISTIC: ThreadPoolExecutor.map preserves order, so the reported first failure is
    the first in `changed` order -- identical verdict to the serial loop. Control run: same
    verdict on a clean tree.
  - Measured and NOT optimised: setup (sig load + registered_addrs) is 8.6s of a 5,700s run
    = 0.15%. All the time is gating. Don't thread the setup.

BANKING DEFERRED on a genuine pre-existing tool bug (NOT the parallel change -- 0 gate
batches ran, it never reached that code):
  [FAIL] ov_MAIN_012: 0x80156600 not instantiated -- REVERTED
  Inputs verified sound at HEAD (in sig, find_site->stub, stub line matches), so the bug is
  in apply_plan's multi-function edit path. Run #1 missed it because it launched before the
  15 wave-3 banks were committed; they landed mid-flight, enlarging run #2's plan.
  SECOND DEFECT: the failure exit printed REVERTED but left 38 files dirty incl.
  src/shared/engine_core.h -- the same incomplete-restore class as the reconcile-ledger bug
  (cookbook 156), on a different path. struct_check needs the same ledger treatment.

Not patching the fleet-shared writer at the end of a marathon session -- that is how the
next 141-binary incident happens. Tree clean, 44 banks safe, propagation is pure
multiplication and can run any time.

Checkpoint p9 carries: the fix-then-resume plan, the master-IDXTAB-map design (DESTPTR half
proven 14/14), wave guidance, and an 8-item error ledger with its single root cause.
2026-08-07 21:08:25 -06:00
Drew T 537bd90a9a feat(phase-30 S45p6): SOLVED — the SC03 trio are ov_SC03_001's script modules (static decode)
Found the IDXTAB: ov_SC03_001 @0x8018D7BC holds 5 s16 entries, -1 terminated:
224, 231, 232, 234, 233 — i.e. the ENTIRE parked trio (SC03/53/54/56) plus its DATA
companion (SC03/55 = 233), in one table, in the binary whose *DESTPTR points at the
script-module slot the tracer watched load live an hour earlier.

THE CHAIN (every link register-verified or byte-observed):
  ov_SC03_001 IDXTAB @0x8018D7BC  -> indices 231/232/234 (+233 data, +224)
  func_80128CFC (the S44 wrapper) -> cdFileLocTable[idx] -> {loc,size}
      register-tracked: addiu->0x800AE830, lw[0x800AE834] size, lw[0x800AE830] loc
  *DESTPTR @0x801EBC68 = 0x801EF468 -> the script slot
      the ONLY occurrence of that word fleet-wide; read 8x by code, 2x from inside func_80128CFC
  slot confirmed LIVE by tools/cdtrace.py: SC03/76 and SC03/34 both loaded there
  and 0x801EF468 lies inside SC03/54's independently-derived base window [0x801EDED0..0x801EF6C8]

VERDICT: LIVE script modules owned by ov_SC03_001. Not dead code, not boss-gated, not
chapter-gated (that framing retired — scripts swap per SCENE). Every sweep missed them
because the SC03 scenes we visited run DIFFERENT overlays (124/125/051).

WHY THE EARLIER HUNTS COULD NOT WORK: the index never appears in CODE — it lives in a
per-overlay DATA table, and so does the destination. Both invisible to fleet-wide code
scans. That is the structural reason four value-scans and three payload-side oracles failed.

NOT PROVED: the exact load BASE within the slot (the three differ in size; none observed
loading). The byte-gate arbitrates — onboard at 0x801EF468 and let the first build decide.

New tool: tools/find_addr_refs.py — register-tracked absolute-address search (cookbook 155:
no window-pairing), self-tested against cdFileLocTable, with a STRICT addu-index rule
(full-address match, not page match — 342 loose hits -> 7 real ones).

METHOD: a runtime observation supplied ONE constant, and that made a previously-impossible
static decode trivial. Neither alone sufficed. Pair the oracles, don't choose between them.
2026-08-07 20:41:18 -06:00
Drew T de02dc750c feat(phase-30 S45p6): tools/cdtrace.py — a runtime CD-load oracle; 7 routing-table addresses confirmed live
Three static oracles failed to derive the parked payloads' load addresses this session. The
runtime answer needed NO breakpoints, no Lua (no pcsx.lua wedge hazard) and no GDB stub: the
loader mirrors its whole request in RAM (cdReq_curSector / cdReq_dest), and CdReadRequest's
own MATCHED signature says cdlFile points INTO cdFileLocTable -- so (ptr-0x800AE830)/8 is the
global file index and cdReq_dest is the destination. Both readable from the RAM-dump API we
already had working.

VALIDATED FIRST (R35): cdFileLocTable's live sizes reproduce our extractor's file sizes exactly
for all five parked payloads. Then confirmed 7x against independently byte-proved addresses --
loadDestPtrTable slots [0]/[1]/[3], MAIN/10 (Phase-3 resident), MAIN/3 (S45-p2 md_MAIN_003),
MAIN/12 (the resident's func_800CF94C row), and the LIST.CD bootstrap read from matched C.
This is the R34 second oracle for the whole S44 routing table, which was static-only until now.

FINDING: the script-module slot 0x801EF468 is live and GENERAL. SC03/76 AND SC03/34 both load
there; 34 is outside the SC03/73-79 block, so S45's "chapter-2 period" label described one
tenant, not the slot -- scripts swap PER SCENE.

PRE-REGISTERED HYPOTHESIS (written before the test, kept honest): slot CONFIRMED (it lies inside
SC03/54's independently-derived base window); "chapter-gated" WEAKENED (per-scene, not per-chapter);
trio 0 sightings across 38 load events, 2 saves, multiple SC03 scenes.

NEXT (static, no emulator): 0x801EF468 is now a concrete anchor. Register-track the code that
loads into it and decode its scene->script-index SELECTOR -- answers all three at once instead
of sweeping rooms. The correctly-scoped successor to the four refuted value-scans.

Also lands the attract-cycle load map (.run/attract_loadmap.jsonl): MAIN/7 + MAIN/9 absent
across a complete 304s cycle.
2026-08-07 20:36:04 -06:00
Drew T bac3155abc fix(phase-30 S45p7): wave_snapshot must carry the GENERATED includes too
I claimed the .s snapshot alone fully decoupled a drafting wave from `make clean`.
CHECKED — it does not. match_one does not merely compile: it ASSEMBLES (AS with
-Iinclude, match_one.py:59), and the assembly step needs splat's generated
include/macro.inc, labels.inc, gte_macros.inc and include_asm.h. `make clean`
deletes all four.

The gap was worse than a plain missing file: a wave would survive the clean right up
until an agent hit a macro-using (e.g. GTE) function, then fail in a way that reads as
a BAD DRAFT rather than a missing include — a phantom wall booked into the backlog.

Snapshot now copies the whole include/ root (6 files; common.h and psyq/ are tracked and
would survive anyway, copied so the snapshot is a self-contained -Iinclude root), and
asserts the four generated ones are present, warning loudly if not (R32 — a
half-populated include root must announce itself, not fail later as someone else's bug).

Verified: all 4 present in a fresh snapshot; exit 0.
2026-08-07 19:07:20 -06:00
Drew T fe399b4550 feat(phase-30 S45p7): Stage 2 — verify_worktree, a COMMIT-COMPLETENESS checker (not a concurrency device)
tools/verify_worktree.py: check a commit out into its own git worktree, provision the
untracked build deps (cc1 from the COMMITTED tarball, checksum-verified against the
COMMITTED record; .venv + extracted/ symlinked; maspsx submodule at the expected pin),
run make extract-all && check-all there, write .run/verify/<sha>.json with verdict +
toolchain provenance.

RESULTS
  GREEN at HEAD: 213 passed / 0 failed, 86.6s wall.
  NEGATIVE CONTROL PASSES: a throwaway commit splicing a deliberately corrupted body over
  func_8014CBE8 went RED naming exactly ov_SC02_037 (212/1 of 213). The detector fires, so
  its green means something (R35 — an unproven detector's green is not evidence).

TWO DESIGN CLAIMS CORRECTED BY CONTACT WITH REALITY
  1. Sparse checkout (to save ~1GB of ghidra/) was proposed, and would have owed an R34
     sparse-vs-full validation. Measured free space: 941 GB. Full checkout instead —
     simpler AND strictly more trustworthy; the validation obligation disappears.
  2. "A pristine checkout of exactly C's tracked content rebuilds byte-identical" is NOT
     ACHIEVABLE here. Only 3 files under extracted/ are tracked; the 760MB of ROM payloads
     are gitignored, so a pristine checkout extracts NOTHING (first honest run: 212/212
     FAIL). No commit in this repo is self-sufficient, by design. The honest claim is
     "the commit's TRACKED SOURCE, built against a supplied extraction" — corrected in the
     docstring AND in the emitted `licenses` string, which is what actually gets quoted.

SCOPE, REFRAMED (Drew's challenge, and he was right)
  I sold this partly on concurrency. At 86.6s, serializing R22 costs almost nothing, so the
  concurrency argument is WEAK. What it actually buys is commit-completeness: the worktree's
  src/ holds only committed content, so a source file someone forgot to `git add` fails BY
  CONSTRUCTION — the documented "a clone of such a bank commit failed to build" class.
  => Run it at checkpoints and before pushing, NOT every batch. Plain in-tree check-all is
     fine for routine verification.
  => The wave-vs-`make clean` blocker that started all this was already solved, more simply,
     by tools/wave_snapshot.py. Neither the worktree nor path-parameterizing was needed for it.
  => STAGE 5 (verify coalescing / auto-bisect) IS CANCELLED: it existed to handle verify
     lagging commits, which cannot happen at 87 seconds.
2026-08-07 19:06:15 -06:00
Drew T e0eaa16741 feat(phase-30 S45p7): Stage 1 complete — shared-state RW lock + 15 more banks (wave-3 revived)
STAGE 1 of docs/concurrency-design.md, landed and negative-control proven.

tools/shared_lock.py (NEW) — one reader/writer flock over the FLEET-SHARED state
(src/shared/*, config/overlays.mk, config/dedup.us.yaml, the overlay .c files
propagation rewrites). Per-binary resources keep gate_stage's existing per-binary flock.
  - gate_stage takes it SHARED when the gate writes no shared state, EXCLUSIVE when it
    does (propagate, or the arity pre-pass enabled) -- so distinct-binary gates still run
    concurrently but can never overlap a writer.
  - dedup_propagate and fix_arity_callers --apply take it EXCLUSIVE.
  - NESTING-AWARE: gate_stage SPAWNS both writers, so a naive child lock would deadlock
    against the parent. The holder exports BFM_SHARED_LOCK_HELD and children inherit.

NEGATIVE CONTROLS (all pass):
  NC1 a held SHARED lock refuses a non-blocking exclusive writer, loudly, naming the lock
  NC2 parent-holds/child-inherits does NOT deadlock (the real risk in this design)
  NC3 two readers acquire concurrently (0.00s) -- phase-B parallelism preserved

bulk_harvest docstring CORRECTED: its "propagation is the ONLY writer of the shared
engine_core.h" claim was FALSE as written and had been asserted for phases (F1 -- the
arity pre-pass writes it from inside every worker). Now states what is actually true,
under which two conditions, plus the one-line assertion that detects a violation.

BANKS: wave-3's drafts re-gated on a CLEAN tree -> 15 of 20 banked. The same drafts
previously reported 0 banked / 20 near -- that verdict was 100% an artifact of the
broken tree, which is why they were held as UNJUDGED rather than accepted as failures.
check-all 213 passed / 0 failed. F1 bracketing assertion CLEAN.

Session total banked: 44 functions + func_8015C030 propagated x7.
2026-08-07 18:57:10 -06:00
Drew T 0ef53c7b22 test(phase-30 S45p7): prove the reconcile-ledger undo — the owed negative control
The full-propagation control did not fire (that run succeeded), so the guarded path was
never executed and the fix was committed honestly marked UNPROVEN. This proves it directly.

Exercises the exact overlay+fn that broke the fleet (ov_SC07_010 / func_80146A6C):
  apply a REAL reconcile_caller_extern  -> 35 edits across 18 files on disk
  drive the ledger undo as the fixed code does when a fn leaves the plan
  assert all 25 of the overlay's source files are byte-identical

PASS. The orphaned caller-extern class that broke 141/213 cannot survive this path.
The test restores what it edits and asserts it (tree clean after).
2026-08-07 18:50:29 -06:00
Drew T fe946595fd fix(phase-30 S45p7): dedup_propagate leaves no orphaned reconcile on failure + func_8015C030 propagated x7
ROOT CAUSE of the 141/213 breakage earlier this session (correctly derived this time;
my first attribution to F1 was WRONG -- no arity journal ever touched func_80146A6C and
the arity undo reported success):

  dedup_propagate --recover's Part B reconciles a conflicting caller extern and
  DELIBERATELY leaves the edit on disk when it buys the byte-match ("keep the reconcile
  on disk"). Correct while the fn survives -- but a fn can still be dropped by a LATER
  iteration against a different overlay, and when the plan finally emptied, the
  "all candidates dropped" sys.exit fired with NO restore. Reconciles kept for
  ov_SC07_001..009 were orphaned: no-proto'd caller externs for functions that were
  never propagated -> ov_SC07_010 "passing arg 2 of func_80146A6C makes pointer from
  integer" -> 141 of 213 binaries failed check-all.

  The byte-gate never mis-banked (it fails closed). The real cost was VERDICT VOIDING:
  every subsequent gate reported "near" against the broken tree, so two whole batches
  (4/4 and 20/20) were mis-read as draft failures when they measured the tree (R35).

FIX: a reconcile LEDGER. Every kept reconcile is recorded against its fn, undone the
moment that fn leaves the plan, and ALL outstanding reconciles are restored before the
failure exit -- so a failed propagation leaves the tree exactly as it found it.

HONESTY: the fix is IMPLEMENTED AND REVIEWED BUT NOT YET PROVEN. The negative control
aimed at the exact failing propagation SUCCEEDED instead (different tree state), so the
guarded path never executed. A targeted test of the ledger is still owed.

Also lands the propagation that control performed: func_8015C030 x7 overlays
(func_80168B70 excluded from 4 SC07 overlays, survived elsewhere). check-all 213/213.
2026-08-07 18:49:56 -06:00
Drew T 0d05d91293 docs(phase-30 S45 p7): F1 confirmed live (cookbook 156) + the cheap-tier size cliff (157) + wave_snapshot
- cookbook 156: a FAILED draft can poison the fleet. gate_stage's arity pre-pass writes
  the shared engine_core.h before the gate; a rejected draft's caller-signature edit
  survived and broke 141/213 binaries. Byte-gate held (fail-closed). The trap: a broken
  tree makes every later gate report 'near' -- two batches of verdicts were void, not
  evidence. Standing practice: GATE_NO_ARITY=1, assert 'git status --porcelain
  src/shared config' empty after every batch, recover by revert+replay (deterministic).
- cookbook 157: the cheap-tier size cliff, measured over two controlled waves.
  Haiku 4-27 ins 86% (~44k tok/match); >=50 ins 20% (~177k, 4x worse). The documented
  '<=50' band was optimistic. Agent honesty 63/63 claims true across 100 drafters.
- tools/wave_snapshot.py: immutable sha1-manifested per-wave .s copy, so a running wave
  can no longer block R22's 'make clean'. Coverage-asserting (exit 2 on a missing target),
  negative-control proven.
- docs/concurrency-design.md (Fable5): the lane contract, the false-bank correctness
  argument, and the finding that a worktree verify certifies the COMMIT -- strictly
  stronger than our main-tree R22, which also compiles untracked strays.
- checkpoint p7.
2026-08-07 18:04:26 -06:00
Drew T 788f33d523 feat(phase-30 S45 L3-p3): SC02/9 = the Steam Knight boss module — decoded, captured, retro-verified, onboarded; parked = 5
- 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)
2026-08-07 15:07:55 -06:00
Drew T fa7b9d4c71 feat(phase-30 S45 L3): the emulator tour — all 28 script modules + MAIN/3 onboarded; fleet 212, R22 212/212
- 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
2026-08-07 14:03:51 -06:00
Drew T a0f07d629e chore(phase-30 S45 II.2): retirements (R33) + SETUP module recipe
- 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
2026-08-06 13:34:50 -06:00
Drew T 4cadac4e11 feat(phase-30 S45 II.1c): module batch dedup-banked + verified — 408 banks, R22 183/183, audit-disc 75->34 (parked-only)
- dedup measure (R37 probe): 69/1,113 module fns h_exact-match matched corpus (~6%, LOW as
  planned — modules are novel frontier); dedup_extend inapplicable (same-vram group model) ->
  family_sweep --hseq --band all over the 57 matched-exemplar families: 408 member-matches
  banked (182 into modules, 226 into the big 3 — families Part I's --only scoping missed),
  169 failed + 77 STRUCT = genuine per-member frontier
- R22 clean-fleet 183/183 BYTE-IDENTICAL; audit-disc UNCLAIMED 75->34 residue 0 (34 = 31
  parked-for-L3 + SC03/53,54,56 — 3 rows Discovery-3 never tiered, now parked with evidence)
- three instrument fixes, each negative-control-proven:
  - family_sweep --hseq stub map derives ov_*+md_*+resident (was sig.ov_* glob -> module
    members silently 'not-stub', R32 class) [committed earlier as commit:1506]
  - sig-modules seeds from the built ELF's func_* symbols (bootstrap GLUES adjacent fns
    around jtbl dispatch -> 24 false TRUNCATED; perturbed-sig control still bites)
  - corpus.audit counts CODE lines only (module .s carries its header jtbl as .word lines);
    progress.py buckets INCLUDE_RODATA symbols as blobs (unbucketed R32 hole)
- NEW HONEST BASELINE (183 binaries): 94.0% instr / 95.96% fn-count / 87.6% distinct;
  tools-health OK, audit-digest OK
2026-08-06 13:14:03 -06:00
Drew T b1dbfcb572 fix(phase-30 S45): family_sweep --hseq stub map derives ov_*+md_*+resident (R32)
- 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
2026-08-06 12:43:19 -06:00
Drew T b15dae1077 feat(phase-30 S45 II.1b): SC07 module pair onboarded byte-identical at 0x801A00D8
- md_SC07_003 (345,132 B, text-lo 0xFC, 100 fns) + md_SC07_004 (365,152 B, text-lo 0x158,
  315 fns) — both BYTE-IDENTICAL on first build at the header-derived own slot
- independent first-prologue scan reproduced the plan's documented TLOs exactly
2026-08-06 12:37:24 -06:00
Drew T 85b526cddd feat(phase-30 S45 II.1a): all 38 MAIN modules onboarded byte-identical at the §S44 static addresses
- 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
2026-08-06 12:36:49 -06:00
Drew T f6bbe7272a feat(phase-30 S44 I.2a): the big 3 onboarded BYTE-IDENTICAL — ov_MAIN_012, ov_SC02_037, ov_SC03_107
- 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).
2026-08-06 11:12:19 -06:00
Drew T f5ea0fdd49 feat(phase-30 S44 I.1e): tools/new_binary.sh — one onboarder for every flat-blob class
- 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.
2026-08-06 10:59:03 -06:00
Drew T 369dd14f4f fix(phase-30 S44 I.1d): the module class reaches every enumerating consumer
- 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.
2026-08-06 10:57:17 -06:00
Drew T 1826033fb0 fix(phase-30 S44 I.1c): the R36 citizenship gate is no longer blind to non-ov_ binary classes
- 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.
2026-08-06 10:55:38 -06:00
Drew T 9ae1c9a743 fix(phase-30 S44 I.1a): family_remap derives vram per-alias from the splat config (R33)
- 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.
2026-08-06 10:53:44 -06:00
Drew T 7473640838 fix(phase-30 S43): audit-disc listed only L1's code — the real backlog is 78 payloads, not 39
- 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.
2026-08-06 09:51:39 -06:00
Drew T 964afdba4e feat(phase-30 S43): L2 second oracle — it found TWO L1 defects; unclaimed code 1.70 -> 3.56 MB
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).
2026-08-06 09:48:16 -06:00
Drew T 03794d91cd feat(phase-30 S43): make audit-disc — the disc PARTITION holds at residue 0; 34 UNCLAIMED code payloads
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.
2026-08-05 23:55:29 -06:00