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