fix(hw-gate): never let a dead decide seat hold the GPU lock, never re-gate a merged PR

[Kaden-Schutt]

Two defects found while driving the ladder tonight. Both cost live rungs their hardware lane, and both are gate plumbing rather than product code.

1 · A decide seat that cannot answer holds all five GPUs for 45 minutes

fable-decide takes flock --exclusive on hw-gate-gpu.lock around the whole review.py --phase decide process (workflow line 411), for its full HW_GATE_MAX_MINUTES budget. Tonight #711's decide phase had no provider credits and could never produce a verdict — yet it held that lock for ~20 minutes while #687 and #688 sat queued with hardware (gfx1201) unable to start. I only found it by fuser-ing the lock file and seeing a --pr 711 process on a PR that merged at 19:16.

A seat that cannot answer must not own the hardware.

Fix: one 90 s toolless probe of the decide model before the lock is taken.

• probe replies → the locked phase runs exactly as before, unchanged
• probe fails → the locked step is skipped entirely, and a new unlocked step records the hold via --decider-unavailable REASON, which short-circuits the model call in review.py and lets the floors, PR comment, and labels run as usual

The GPUs are never claimed, and the PR still gets a comment explaining why it held. This is not a fallback model or a retry — an out-of-credit seat still fails, it just fails without taking the hardware down with it.

2 · A merged PR can re-run the entire gate

pull_request_target fires on labeled even for a closed PR, and the gate itself applies labels. Run 33915818350 re-ran the whole gate on #711 five minutes after it merged, taking the runner and the exclusive lock from live rungs; the same thing happened again on #691, #686, #687 and #688 after each staging merge — I cancelled six of these by hand tonight.

Fix: select refuses any event whose PR is already merged. workflow_dispatch is explicitly unaffected, so a manual re-gate of a merged PR still works when you want one.

Test

test_decide_unavailable_seat_holds_without_calling_the_model asserts the hold, the recorded reason, no merge — and no model invocation at all (the fake never opens its log, so the assertion is not omp_log.exists()). 105/105 hw-gate tests pass.

Touches .github/workflows/hw-gate.yml and scripts/hw-gate/**, so it is policy-floor by construction and cannot self-merge.

[hipfire-sol]

hw-gate sol prelim

summary: The change skips automatic gate runs for already-merged PRs, probes the Fable decide provider before acquiring the exclusive GPU lock, records an unavailable-seat hold without invoking the model, and changes serve/Redline validation to use harnesses from the gate checkout rather than the PR checkout. The preflight failure path currently interpolates provider-controlled stderr into generated shell source, creating a command-injection path on the self-hosted runner.

run_hardware: false
run_hardware_reasons: The workflow introduces a new networked omp process and carries its externally produced stderr into shell source on a self-hosted runner. This is an unaccounted process-execution boundary and must not run until the reason is transported as data rather than executable shell text.; GPU fixtures cannot validate these policy and orchestration changes; the appropriate evidence is focused hw-gate unit tests plus a workflow-level failure-path test covering hostile stderr.; The gate-root harness selection itself is bounded and improves oracle integrity: PR binaries remain under test while serve_harness.py and redline_daemon_harness.py come from the trusted gate checkout.

routes:

mode	tag	source	why
—	—	—	no routes

unavailable_routes:

(none)

claim_assessment: The merged-PR guard and unavailable-decider short circuit are visible in the diff, and the review.py unit test exercises that no model invocation or merge occurs after --decider-unavailable. The claimed safe unlocked workflow path is not proven because no test exercises GitHub Actions output transport and shell rendering, and that path is presently unsafe for shell metacharacters in probe stderr. The separate gate-checkout harness correction is supported by a focused serve-harness unit test, but the analogous Redline path lacks a focused test.

questions_for_author:

• Can the unavailable reason be passed through a quoted environment variable or a file instead of ${{ steps.seat.outputs.reason }} interpolation, with a regression test containing command-substitution syntax in probe stderr?
• Can the workflow-level test also prove the failed probe path never reaches the flock command, rather than only proving review.py skips its own model call?

[Kaden-Schutt]

Added a third defect, found ten minutes after opening this: the hardware lanes run the PR's own copy of the harness.

run.py resolved serve_harness.py from --repo pr, so #682 — a fork PR based on master from before #703 — ran the pre-guard harness and false-flagged the 3-token answer Answer: 43 as a token attractor on both lanes (run 33921475093), hard-flooring a rung whose own evidence rows all read attractor:false, recall_ok:true.

That is two problems in one: every PR older than a harness fix inherits that harness's bugs (a false-failure generator that worsens as the harness improves), and a branch can weaken the oracle that judges it — which must never be possible in a gate. Fixtures, registry, prompts and review.py already resolve against the gate checkout for exactly this reason; the two harnesses now do too, including their existence preconditions. The PR still supplies the binaries under test.

31ef8cb88, with test_serve_harness_runs_from_gate_root_not_pr writing a different harness into each tree and asserting the gate's is invoked. 106/106 hw-gate tests pass.

All three defects cost live rungs tonight: #687/#688 lost ~20 min to a credit-less seat holding the exclusive GPU lock, I hand-cancelled six re-gates of merged PRs, and #682 failed on a correct answer.