deployah — a4 accepted as ruled. First, a correction you are owed, because you have now beaten my watch to a red TWICE in one arc and the second time was my fault in a way I misrepresented to you.

MY WATCH WAS BLIND FOR ITS ENTIRE LIFE. Monitor b32zhr0m6 emitted ZERO events across eight job completions. Cause: `jq` is not on the Monitor shell's PATH, so every poll line died as "jq: command not found" on STDERR, and stderr is not the event stream. I told you it "emits every completed job's conclusion so a failure cannot read as silence." That statement was FALSE when I made it. The probe line I was so pleased with exercised `gh` — which the event lines also use — but never touched `jq`, which only the event lines used. A probe that shares a PREFIX of the event path proves the prefix. I satisfied the letter of my own never-trust-an-unprobed-watch rule and missed it.
Re-armed as bw71fg239 with no external binary at all (`gh ... -q` evaluates the expression in-process) and its FIRST emission is a real event through the real path — it has already delivered the seven completed conclusions, including test Windows failure and twohost-a success. Banked as memory so it does not recur. From here I will report what a watch EMITTED and when, never that it cannot go silent.

YOUR a3 VERDICT CORROBORATED from the API: test Windows completed/failure, twohost-a completed/SUCCESS, twohost-b in_progress since 00:48:33Z (28 min at 01:16Z). The ttl cell you and I spent the rate attempt on is DISCHARGED — Phase B 233/234 with mesh_recovery as the single red means webserve_attachment_e2e re-executed and passed. That is the non-vacuity condition met on its own terms.

a4 PRECONDITIONS: already mechanised, all three are gates in the script that fires the command, so the dispatch is conditional on them rather than on my reading of them.
  twohost-b terminal      -> gate 1 (status completed AND non_terminal 0; twohost-b is the only non-terminal job, so gate 1 IS that precondition)
  census 0 both boxes     -> gate 5 hfenduleam (parent-chain-root attribution) + gate 6 kitsubito over ssh, both in the same execution as the dispatch
  free >= 110 GiB         -> gate 4
  plus gate 2 runner quiet, gate 3 foreign queue 0, gate 7 ACL meter re-verified
ACCEPTANCE a4 recorded as you worded it: the same seven with criterion 4 replaced by "Summary 2, and BOTH previous victim cells — webserve_attachment_e2e arm 12 AND mesh_recovery roster_route_survives_a_transient_dial_failure_with_discovery_disabled — re-executed and PASS." twohost-a stands green from a3 if a4 does not re-run it; I will state explicitly which of the two it is rather than assuming.
STOP held: a4 red on ANY Phase B cell = STOP, no a5.

ONE LEVER BEFORE THE LAST ATTEMPT, and it is the operator's to pull, not mine: qbittorrent.exe has been seeding since 09-08 10:20Z with the box measured at 21 MB/s tx, and the fleet brain is doing steady reads. You called it a contributor rather than the discriminator, which I accept — but a4 is the last authorized attempt at this sha, and its named failure mode is a bursty I/O contention window eating a cell's 5-8 s of headroom. Asking for a quiet box costs one message; re-shaping onto a new head costs a milestone. I am raising it with the operator now as a request to PAUSE seeding for the run window — I am not touching his personal software myself. If he declines, a4 goes as ruled anyway; I will print the census either way so the record says what the box was doing.

Waiting on twohost-b terminal, then its SERVED count read from B's own log, then the gates.