Files
BFM-decomp/docs
Drew T 2c4e2344da fix(phase-28 T5): progress.py — #if 0 blindness + the len()-sum; resident 123/146 -> 122/145
R35: fix the instrument before planting a flag on its denominator.

- #if 0 BLINDNESS: classify() knew `#ifdef NON_MATCHING` (:425) but not `#if 0`, so a dead
  analysis body was read as a live definition AND its real INCLUDE_ASM stub counted separately —
  the SAME function in BOTH `real` and `stubs`. Live case: resident.c:868-925 wraps a full
  void func_800D00E4(s32){...} in #if 0 (its jtbl dossier) and re-declares the stub at :926.
  Now the block is skipped entirely: dead code is neither matched nor stubbed.

- THE len()-SUM (the dual defect): `placed` was a set union, so it caught a function in NO bucket
  — but `matchable` SUMMED len()s, so a function in TWO buckets counted twice and nothing
  complained. matchable/byteident are now SET unions, plus a new OVER-coverage assertion that
  fails loudly if any fn lands in multiple buckets. R32 means both directions: nothing missing,
  nothing double-counted.

- NEGATIVE CONTROL (the fix must change an answer the old tool gave):
    resident REAL 123 -> 122 | matchable 146 -> 145 | 85.62% -> 85.52% | func_800D00E4 no longer
    double-counted. FLEET instr 68.9% UNCHANGED (no #if 0 in the overlays) — the fix is scoped.

- FINDING (logged for T7's audit-binaries, does NOT block the flag-plant): the two INDEPENDENT
  oracles now agree exactly at 144 — corpus (21 stubs + 123 matched, derived from the tree) and
  sig_image (the 2nd oracle) — with EMPTY set difference both ways. progress.py still reports 145
  because it counts func_800CEDFC and func_800D33E0, which are DEFINED in resident.c but absent
  from sig_image. 0x800CEDFC is the resident's vram base +4 (the first function, code starts at
  file offset 0x4 after the leading data word), yet make audit-corpus reports 0 PHANTOM +
  0 TRUNCATED. Either sig_image has a boundary blind spot or those defs are not image functions.
  progress.py's text-scanning classify() is exactly the re-parsing R33 says should be DERIVED from
  corpus instead — a real refactor, logged not rushed.
  The flag-plant claim is unaffected: it rests on corpus.stubs('resident') == 21 (tree-derived,
  verified 5 ways), not on the contested denominator.
2026-07-16 00:17:57 -06:00
..