Files
BFM-decomp/docs
Drew T f5498c3c66 feat(phase-30 S43): the 0xECC family — ONE crack banks 12 overlays / 11,364 ins [R22 PENDING]
⚠️ R22 CLEAN-FLEET OWED (two agents still reading asm/, so `make clean` is unsafe). Each of the 12
was gated whole-binary AND independently re-checked against its own config/check.<bin>.sha (12/12),
stubs confirmed replaced — but incremental (§130). Treat as UNCONFIRMED until the clean run.

- THREE isolated cheap-Opus agents, briefed with §150/§151 + the mandatory all-drafts scan,
  CONVERGED INDEPENDENTLY: func_8017C6F4's 947-ins body exists in 12 OVERLAYS under 5 DIFFERENT
  NAMES at 6 DIFFERENT ADDRESSES, each differing by exactly TWO per-overlay symbols (screen-rect
  helper + 64x64 cell table). Gated 12/12, 0 failed. 11,364 ins from this morning's single crack.
- WHY IT HID ~30 PHASES (cookbook §152): name-keyed grouping scattered it across 5 names,
  address-keyed across 6 addresses (and the address collides with an unrelated 15-ins body in 3
  other overlays), and h_seq-keyed scattered it too — which is why the Phase-26 sweeps missed it.
  THE KEY IS BYTE SIZE: `grep -rl 'nonmatching .*, 0xECC' asm/*/nonmatchings/*/` returns exactly
  the 12, reads the asm (cannot go stale like family_hseq.json), no false positives. Refines the
  Phase-26 "h_seq is spent" finding: h_seq is worth exactly ONE size-keyed sweep behind each FRESH
  core crack — here it paid 11:1.
- TWO CAUTIONS THAT TRAVEL WITH IT: (1) a MASKED tool cannot validate a remap — match_one and
  rtu_match both mask jal/%hi/%lo, exactly the fields a remap edits, so a wrong symbol map still
  reports MATCH; gate remaps by the whole-binary SHA only. (2) a stale residual is NOT evidence two
  functions differ — I briefed "func_8017C59C scores 340, different body"; refuted in one command
  (that 340 came from a pre-§150-fix draft, which scores nonzero against its own target too).
- OPEN TOOL DEFECT (R32): family_remap's unit backscan halts at the first #define, so it carried
  16/16 gte macros and 0/10 typedefs, silently — the §146 gap from the other side.
- MY ERROR, RETRACTED IN THE LOG (S43-9): I reported the 263x5 cluster as "5 byte-identical, 1,315
  ins". FALSE — the drafts had been reverted, so I measured the INCLUDE_ASM STUB BASELINE, which is
  byte-identical by construction. R34's trap, self-inflicted by hand-building instead of using
  harvest_verify. Nothing was banked there; the cluster is UNRESOLVED. ("41 behemoth drafts" was
  likewise a file count — 79 files, 20 distinct functions.)
2026-08-05 17:40:27 -06:00
..