A stalled probe hangs forever — no step deadline anywhere in the harness, so the merge gate never returns nf-0gr ← Beads

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

Found while measuring design 005 piece 2 (#746). Filing rather than fixing: it is not only a parallelism problem, and the fix is a design choice about what a deadline should do.

What is true

There is no step timeout in shared/VisualProbe.cs. budget_ms looks like one and is not — it warns and never fails (VisualProbe.cs:301, added by #572 for the opposite purpose: telling a reader that a frame-counted wait took longer than expected under load). A step that never satisfies its condition waits for the next frame, forever.

Observed, not theorised

8-way parallel run on nf-dev-sg, 2026-08-07. cold-start stalled after

``` [playtest] journal armed: build bea4101 -> …/probe_out/playtest ```

and was still stuck ~9 minutes later, when I killed it. The other seven finished in 32 s. The same probe passes serially 3/3 immediately afterwards, so the probe is fine — it was starved of the fresh-install user:// state that #746 is about.

Why it matters beyond #746

The cause there is a race #746 will fix. The shape is not fixed by that, and it is worse than a failure:

• probe_gate cannot report what never finishes — no FAIL, no FLAKY, no line in the table.
• merge_pr.py invokes the gate synchronously, so a stuck probe is a merge that never returns rather than one that goes red. CLAUDE.md already warns that merge_pr.py takes minutes and that a 2-minute tool timeout kills it after the merge landed (#728 is the same collision from the other side); an unbounded probe makes that hazard open-ended.
• It is invisible in the log: the last line is a normal one, so a reader sees a probe that started and simply stopped.

This is a fifth thing that gets called "flakiness" and is not: #615 resolved three causes wanting opposite fixes, #668 added frame-counted waits, #691 added "assertions all passed but Godot crashed on shutdown". This one is "nothing was reported at all."

Directions, not a decision

• A per-step deadline in the harness — the honest place, since only the harness knows a step is waiting. Wants a default, and wants to fail with *which step* rather than a bare timeout.
• A per-probe deadline in probe.py/probe_all.py — cheaper (kill the child, record FAIL), and it works for a probe wedged outside the step loop, e.g. in Godot startup, which is where this one actually stalled. Loses the "which step" detail.
• Both — process-level as the backstop, step-level for the diagnosis. Probably right, and it is how the display/engine preflights ended up (belt in probe_gate.wipeout, braces in the tools).
• ⚠️ Whatever the default is, it has to survive the loaded box: #620 measured one competing sweep costing 4.2×, and a deadline tuned on an idle box turns contention into false regressions — the exact #514 pathology.

Related: #746 (the race that exposed it), #691, #615, #572, #620, #728.

Unclaimed.