mirror of
https://github.com/Druthulu/BFM-decomp
synced 2026-09-26 13:33:34 -04:00
Drew T
7473640838
- 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.