Files
BFM-decomp/tools/workflows
Drew T c916115291 feat(phase-29 T3): the §53 has_mid_jr INTERLOCK + worker_wave -O0 build-step fix
- family_sweep §53 INTERLOCK (the Task-3 deliverable): a has_mid_jr family CANNOT bank through the
  carve-less --hseq path — its exemplar's own bank needed a jump-table carve. The sweep now SKIPS them
  LOUDLY, names the right tool (jtbl_family_bank), and states that a 0% from this path is a TOOL
  ARTIFACT, not a wall. Uses the manifest's has_mid_jr (family_hseq already derived it — R33, one
  oracle, shared with dedup_extend; no re-derivation). --allow-jr is the escape hatch.
  WHY: a silent 0% from the wrong tool is exactly what manufactured the Phase-26 "structural families
  ≈0% / don't template" doctrine and steered two phases of strategy (§53, Phase-28 T1). The interlock
  makes the omission impossible to misread.
  VERIFIED (live-fire + negative control, R32/R35): manifest carries 11 has_mid_jr families / 163
  member-slots of 1418 sweepable; --band substantial -> skips 9 families / 155 slots (159 -> 150
  families); --allow-jr -> 159 (does NOT skip). It correctly flags 0x8017bebc (n=115) = B2, the very
  family whose missing carve produced the ≈0% doctrine (0/8 -> 102/115 once carved).

- worker_wave.js: pass --o0 to the match_one self-check for -O0 targets (new `o0` target flag) + an
  -O0 prompt block (§18/§18-P29: the %lo-fold residual and the array-of-struct crack). Without it an
  agent iterates a -O0 target against an -O2 compile and can NEVER match — the same wrong-build-step
  trap that produced the Phase-28 "~3%" swing number (Task 1). Exercised live by func_8013C414.

- byte-neutral: tooling only, no src/config touched.
2026-07-17 02:12:17 -06:00
..