mirror of
https://github.com/Druthulu/BFM-decomp
synced 2026-09-26 21:36:06 -04:00
Drew T
2d7694ba2d
Ran the batch with the T57 recipe (--band all --normalize-self-decls, live stubs derived from src/ not the stale map). 6 of 8 selected (two still filtered — selection line read this time). 821 candidate members across 6 families BANKED 137 — func_8012A1BC (78 ins) 137/137 failed 684 — the other FIVE families banked 0 each Attribution from git diff (137 x func_8012A1BC), not the per-group log lines whose split-name field my first aggregation mangled. THE SHAPE OF THE REMAINING FRONTIER — the finding. Across T56->T58 the per-family outcome is BINARY and near-total: a family banks ~137/137 or ~0/137, nothing in between. And each 0/N so far has had its OWN distinct cause — DATA decl scope (T56), FUNCTION decl scope (T57), jtbl table-count drift (func_8014032C), plus five more undiagnosed here. The mechanical lever is done pulling by itself: from here each family costs one diagnosis. A batch is now a DIAGNOSIS QUEUE, not a harvest, and the next phase of this work should be planned on that economics. 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 86.0% (11297091 -> 11307777 = +10,686 ins); fn-count 90.73% -> 90.77% (+137); distinct-code 76.7% -> 76.7% (+0). The distinct-code anomaly now has FOUR data points and still no explanation: T52 +125, T57 +125, T56 +0, T58 +0. All four families are PURE; the exemplar overlay does not separate them either (T56 and T57 both templated from ov_SC01_077 and disagree). Two behaviours, no identified variable. Still not guessed at — it stays the queued probe.