Files
BFM-decomp/docs
Drew T cbc5665fd8 feat(phase-29): T57 — func_80133AB0 132/132 (+18,084 ins); a SECOND opt-in lever found; fleet 86.0% instr
First batch off the 64-family list. Fleet crosses 86.0% instr-weighted.

TWO OF MY OWN ERRORS, both caught by measuring:
 1. Three of five targets never ran — --band defaults to `substantial` (nins>=80) and I picked three
    at 79/78/78. The tool printed "2 matched-exemplar families" and I nearly read that as "5
    attempted, 3 refused". Read the SELECTION line, not the intent.
 2. Stale map: .run/family_hseq.json was regenerated in T55, BEFORE T56 banked func_80144090, so it
    still listed 134 live stubs for a now-complete family. Membership is stable (h_seq over original
    bytes); only the matched/unmatched split rots. Filter live stubs from src/, not from n_matched.

THE FIRST RUN WAS 0/268 — AND IT WAS A SECOND OPT-IN LEVER, NOT A WALL. Diagnosed one sibling past
the -j16 interleave and the §58 warning noise: `conflicting types for func_80133AB0` (spliced def at
2688 vs a decl at 2429) — the FUNCTION decl-conflict class, not the DATA one T56 fixed. That is
exactly what --normalize-self-decls exists for (the sibling's own caller declares the member in a
different C form than the exemplar's, which used a fn-ptr cast) — and it is OPT-IN, so it never ran.
Re-ran the identical two families with it: 0 -> 132 banked.

  0x80133ab0 (137 ins, jr_8012ACE0)  132/132 BANKED
  0x80143d28 (80 ins,  jr_80140608)  0/136 — a different, undiagnosed blocker

THE PATTERN, TWICE IN A ROW: T56 the DATA decl lever was unreachable from the sweep path; T57 the
FUNCTION decl lever is reachable but OFF BY DEFAULT. Both present as a flat 0/N that reads exactly
like a compiler wall. A 0/N from a sweep is a statement about which levers were enabled, not about
the code.

GATES: R22 clean-fleet 140 passed, 0 failed of 140; tools-health OK (corpus 0 PHANTOM + 0 TRUNCATED,
cdecl, audit-binaries, dedup 1886/0); 0 NON_MATCHING (G4).

METRICS: instr 85.8% -> 86.0% (11279007 -> 11297091 = +18,084 ins); fn-count 90.69% -> 90.73% (+132);
distinct-code 76.4% -> 76.7% (67812 -> 67937 = +125).
SHARPENS the T56 anomaly rather than resolving it: 132 banked here moved distinct-code +125, and
T52's 132 also moved it +125 — but T56's 136 moved it +0. Three PURE families, two behave one way
and one the other. Still unexplained, still not guessed at.
2026-07-28 20:37:06 -06:00
..