- 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