The disc-completeness oracle (R34) decoded only the RAW payload bytes, so LZSS-compressed type-4
overlay code read as noise: every type-4 row said "code 0" — a VACUOUS row for 138 known-code
binaries. This is not cosmetic. The tool exists to answer "what code did nobody onboard", and it
could NOT have found the 4 hidden SC07 overlays (their code is compressed like every type-4) — they
were caught by hand-reconciling 138-vs-134. It found the 39 type-1 modules ONLY because those happen
to be uncompressed.
- FIX: code_signals now decodes BOTH layers — the raw bytes AND the lzss.decompress() output — and
takes the stronger code signal, recording which layer (raw|dec) in the report. Uncompressed code
(type-1 resident-class) lives in raw; compressed code (type-4 overlays) lives in the decompressed
layer. Reuses the extractor's own game-semantics lzss decoder (R33), not a second one.
- onboarded_payloads() now also keys by the .dec-stripped raw path: a type-4 _EXE is the .dec, but
the sweep iterates raw payloads, so without this all 138 type-4 overlays — now correctly seen as
code — would false-flag as HIDDEN.
- RESULT: type-4 row 138 payloads / 138 code / 138 onboarded / 0 HIDDEN (was "code 0"). The 138
detections are all via the `dec` layer (verified: 100% valid, 3.39% jr). A 139th un-onboarded
type-4 overlay would NOW flag HIDDEN — structurally impossible before. The 39 type-1 modules are
unchanged and reconcile with the committed disc-completeness.md.
- Coverage still asserted (R32): 1189/1189 classified. Tonight's separate exhaustive ad-hoc sweep
independently confirmed no further hidden overlays; this makes that a REPRODUCIBLE tool, not a
one-off script. Ranked list -> .run/disc_code_sweep.txt (the file disc-completeness.md references).
The whole-binary byte-gate is structurally blind to code nobody onboarded (R34): check-all is
green over the onboarded set no matter what code sits unbuilt on the disc. This reconciles the
onboarded set against every code-bearing PAC payload.
- new_overlay.sh: optional [ENTRY] arg (default 0.4) reaches a non-0.4.dec payload. Onboarded
ov_SC07_{006,007,010,011} from 1.4.dec (they put graphics at PAC entry 0, the code overlay at
entry 1 — invisible to the 0.4 hardcode for a month). Each byte-identical (7ca772be / b3b95547 /
d7b5875d / 9885af74). FLEET 136 -> 140; check-all 140/140 (T2's pass==N re-baselined cleanly).
difficulty.py NOT in the insertion set anymore (it derives, T6) -> only 3 tool dicts touched.
- tools/disc_code_sweep.py: decode every payload (reusing sig_image.make_insn) and gate code on
BOTH valid>=0.90 AND jr_$ra density>=0.01. The jr_$ra gate is decisive: isValid() alone flags
389 false hits (type-0/2 structured data decodes ~100% valid but has ZERO returns); jr_$ra
separates code (~2.9-3.4%) from data (0.000%), validated on positive+negative controls.
- FINDING (docs/disc-completeness.md): type-4 location overlays are COMPLETE (138/138). All other
types are data EXCEPT type-1 = 40 code payloads, 1 onboarded (the resident), 39 HIDDEN
resident-class modules (mostly MAIN.CD/FILE_XXX/1.1). They load at UNKNOWN addresses (not the
shared overlay slot), so they are NOT mechanically onboardable — byte-verifying a build binary
needs its load address (P9), knowable only by runtime RE (the Phase-3 method). Deferred with
evidence, NOT force-onboarded at a guess.
- CONSEQUENCE: game-code TRUE 100% now spans 140 onboarded binaries PLUS ~39 type-1 modules
pending load-address RE. The roadmap assumed 136 — this is a real re-baselining (the +4 overlays
also add ~2.45 MB to the denominator; every family propagation is now x138). Flows to T10/T11.
- SETUP §6.3 tool inventory updated (R21).
Drew T