- 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
- 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.
- 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.
Drew T