BFM-decomp/cookbook/C0144.md

§133 — The DEFAULT-FILTER class: three times in one session, a tool silently answered a narrower question than the one asked (P30 S1–S3)

Not one of these was a broken tool. Each was correct for its own purpose, and each silently scoped down a question that was asked more broadly — which is the same defect class as §124/§126/§132, one level up: not a wrong measurement, a mis-scoped one.

1. My own analysis filter. Sizing the remaining ×138 work I required nins >= 80 ("substantial"), reported "only 2 crackable fleet-wide families remain — the ×138 era ends", and wrote it into the phase plan as a structural signal. Re-run without the size cut: 33 families / 238,478 templatable ins, of which 30 (137,186 ins) were below my line. The conclusion was an artifact of a threshold I chose and then forgot I had chosen.
2. worklist.md prices by h_exact reach. A per-location PURE family shares only h_seq, so the worklist prices its head at ×1. Byte-proof: the day's banked pair was priced 272 and 198 ins and delivered 37,536 + 27,324; func_80176734, the single largest item in the frontier, sits at rank ~50 there. Rank family work by .run/family_hseq.json templatable weight; the worklist is correct only for genuinely h_exact-reach functions.
3. family_sweep --hseq defaults to --band substantial. A propagation run over nine freshly banked heads — all under 80 ins — reported 0 matched-exemplar families and banked nothing. The sweep was right; the band was the question it had been asked. --band all is the fix.

The practice. When a scan returns "nothing" or "far less than expected", the FIRST hypothesis is your own filter, not the world. State the filter out loud in the same breath as the number ("33 families with ≥100 members, any size"), and re-run once with it removed before any conclusion is allowed to shape a plan. A number that scoped a phase deserves the same instrument-check R35 demands of a probe.