design 005 piece 5b: the three standing reds all pass serially — re-read the premise before fixing them nf-oyhz ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/757 by tools/beads/import_github.py's reconcile pass.

Piece 5b of design 005's work breakdown (§8), under #686: *"Fix focus-ring, butterbar-gate, playhead-song; re-sweep Linux."*

⚠️ Its premise does not currently reproduce, so read this before fixing anything.

A full serial sweep came back 34/34, under load 17.76

Measured 2026-08-07 on nf-dev-sg at 73faacc:

``` === running 34 probes, 1 at a time (8 cores, load 14.2) === ──── 34 passed, 0 failed ──── 517 s ```

All three of the named probes passed, untouched. So did every other one.

Why this is not "a good day"

Same tree, same commit, run with a worker pool instead of serially:

| workers | result | failing set | |---|---|---| | 8 | 28 / 6 | butterbar-gate, explore-walk, focus-grammar, playhead-song, playtest-capture, sound-modal | | 6 | 32 / 2 | butterbar-gate, focus-grammar | | 2 | 33 / 1 | row-label-wrap | | 1 | 34 / 0 | — |

A different failing set at each concurrency, and all six of the 8-way failures pass when re-run one at a time on the same box. The serial run was the *most loaded* of the four. That is contention, not three broken probes.

The harness said so itself:

> ⚠ HOST NEAR/OVER THE WINDOW — the 2-frame wait and the steps bracketing it took 1501 ms against a 300 ms budget … that is this host's frame rate, NOT the UI: do not re-pin it and do not change the game's threshold — run on a quieter/faster host.

What this means for the piece

Do not "fix" three probes that pass. Re-pinning a correct assertion to chase a host difference is the treadmill notes/probes.md warns about and that focus-ring has already been on twice.

butterbar-gate in particular is the corpus's single most contention-sensitive assertion by construction — it is the only probe asserting a threshold has *not yet* elapsed, twice, which is why both steps carry budget_ms: 300 (#572, #615). Anything that slows frames turns its quick tap into a sustained hold and the bar is then correctly shown.

What the piece should become

1. Reproduce serially on a quiet box first. If it is 34/34 again, the three have no defect to fix and this piece is done by measurement.
2. If a red survives that, then it is real — and #572/#615 already carry diagnoses for two of the three (focus-ring samples a 1 px boundary rather than the stroke interior; butterbar-gate is the host-contention case).
3. Feed anything that survives into piece 5 (#756) rather than into a re-pin, since the durable fix is making the assertion independent of frame rate.

⚠️ S10 is affected and stays parked. §6 Phase 2 says *"if it comes back 34/34 then S10 is dead weight and should not be built"*. It came back 34/34, so the trigger is now *positively* unfired rather than merely unobserved.

⚠️ One clean sweep is not proof. The post-merge gate runs on a box whose load nobody controls, and #700 reports butterbar-gate failing in consecutive sweeps. The right question there is *what else was running*, not *what is wrong with the probe*.

Refs #686 · Refs #700 · Refs #755 · Refs #746 · Refs #615 · Refs #572