Drew T
264fe6c115
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).
4.0 KiB
Disc-completeness audit (Phase-27 T7)
Generated 2026-07-15. Reproduce:
tools/disc_code_sweep.py(committed). The question this answers is the one the whole-binary byte-gate is structurally blind to (R34):make check-allonly touches binaries someone ONBOARDED, so a code payload nobody onboarded is invisible to it however green the fleet is. This reconciles the ONBOARDED set against every code-bearing payload ON THE DISC.
What the disc holds (extracted PAC payloads, by type)
extracted/retail/** holds 1189 raw PAC payloads across 8 types (docs/formats.md):
| type | payloads | code-bearing | onboarded | note |
|---|---|---|---|---|
| 0 | 301 | 0 | 0 | data (graphics/blobs) |
| 1 | 166 | 40 | 1 | resident-class code modules — the resident is one; 39 more are NOT onboarded |
| 2 | 201 | 0 | 0 | data (decodes ~100% "valid" but 0% jr $ra — the false-positive class) |
| 3 | 201 | 0 | 0 | data |
| 4 | 138 | 138 | 138 | location overlays — COMPLETE (134 at PAC entry 0 + 4 SC07 at entry 1) |
| 6 | 29 | 0 | 0 | data |
| 7 | 139 | 0 | 0 | data |
| 8 | 14 | 0 | 0 | data |
Code detection (disc_code_sweep.py): decode the first 4096 words as MIPS-LE (reusing
sig_image.make_insn, GTE-aware) and require BOTH valid ≥ 0.90 AND jr $ra density ≥ 0.01.
The jr $ra gate is decisive: isValid() alone is far too permissive (structured type-0/type-2 data
decodes ~100% valid), but real MIPS code carries a jr $ra roughly once per function — 2.9–3.4% of
words across the onboarded overlays + the resident, versus 0.000% for the data blobs. Validated
against positive controls (SC01/077/0.4.dec 3.39%, resident MAIN/FILE_010/1.1 2.91%) and negative
controls (type-2 0.00%, type-0 0.00%).
The finding
Type-4 (location overlays) is complete. All 138 type-4 payloads are onboarded and build
byte-identical. The 4 that were invisible for a month — ov_SC07_{006,007,010,011} — put graphics at
PAC entry 0 and the code overlay at entry 1 (1.4.dec); new_overlay.sh hardcoded 0.4.dec. They are
now onboarded (byte-verified: 7ca772be, b3b95547, d7b5875d, 9885af74). Fleet: 136 → 140.
Type-1 holds 39 additional, un-onboarded code modules. These are resident-class code (the resident
MAIN.CD/FILE_010/1.1 is the one already onboarded), the largest being MAIN/FILE_027 (1318 w),
FILE_036 (1229 w), FILE_028 (1115 w). Full ranked list: .run/disc_code_sweep.txt (regenerate with
the tool). They are NOT location overlays — they do not load at the shared slot 0x80128158; each
loads at its own address, the way the resident loads at 0x800CEDF8. So — unlike the SC07 overlays —
they cannot be onboarded mechanically: a build binary needs its load address to byte-verify (P9), and
that address is only knowable by runtime RE (a PCSX-Redux RAM-dump proof, the Phase-3 method). Onboarding
them is a Gen2 RE task, deferred with this evidence — NOT a false "complete" while code sits unbuilt.
Consequence for the completion contract (roadmap §1)
The contract's binary count is no longer "136". Two corrections:
- 140 binaries onboarded now (main + resident + 138 overlays) — the number
check-allverifies. - A documented backlog of 39 type-1 code modules pending load-address RE before they can be onboarded and counted. Game-code TRUE 100% (the contract's bar) is only honest once these are either onboarded-and-matched or explicitly excluded with a reason. They are recorded here so the "100%" claim cannot be made while they sit un-onboarded and unexamined (R34 — the byte-gate cannot see them).
This is a re-baselining event, expected to LOWER the headline % (the 4 SC07 overlays add ~2.45 MB of mostly-unmatched code to the denominator; every "×134" family propagation is now "×138"). That is the honest direction — the prior number was measured over an incomplete disc.
Reproduce
tools/disc_code_sweep.py # the table above + the ranked hidden list
tools/disc_code_sweep.py --types 1 # just the type-1 code modules