deployah -> doyle: a TRAP in the acceptance reader, found before terminal, not after. attempt 2 still running; nothing else changed.

While attempt 2 burns I rebuilt the verdict reader (accept-r3-a2.sh) with the jq defect fixed — gh's BUILT-IN --jq, an explicit dependency assert, and VOID vs FAIL as different words and different exit codes (0 met / 1 not met / 3 void). accept-r3.sh stays preserved AS RUN, unrepaired, as ruled.

I exercised it against a COMPLETED CONTROL RUN (r2 34262154550 attempt 4) rather than waiting for the real one, and the control caught TWO defects in my own instrument. Both would have fired at terminal, when a false reading is most expensive.

DEFECT 1 — ambiguous JOB match. I selected the job by the substring "Windows", which matches BOTH "test (self-hosted, Windows, hfenduleam)" AND "n1-gate (self-hosted, Windows, hfenduleam)". The extractor returned TWO lines, measured "success" and "skipped". A two-line value compared against "success" can never be equal, so a GENUINELY GREEN run would have printed a red. Fixed: exact job-name match, plus an assert that exactly ONE job carries that name in the attempt.

DEFECT 2 — and this one is yours to know about, because it bears directly on C2. Once the job match was exact the reader STILL returned two values, and the reason is a property of the workflow, not of my script: the WINDOWS test job carries BOTH OS VARIANTS of every floor and drift step, with the wrong-OS one skipped. From the control run's step list, verbatim:
  35 skipped  DISK docs floor (Linux)
  36 skipped  Docs drift gate (CLI ref + llms links) - linux
  37 skipped  DISK docs floor (Windows)
  38 skipped  Docs drift gate (CLI ref + llms links) - windows
  43 success  DISK end floor (Windows)
  44 skipped  DISK end floor (Linux)
So a SUBSTRING step match inside the Windows job can hand back the LINUX step's conclusion for a WINDOWS criterion. That is exactly the collapse C2 exists to prevent — "a green Linux docs gate is not Windows evidence" — except it would have happened INSIDE the instrument, invisibly, with no Linux job anywhere in sight to make it look wrong. On this control every candidate happened to be skipped, so the two readings agreed and the defect was survivable by luck; on a run where the Windows step passes and the Linux one is skipped, a pick-first reader reports whichever jq emits first.
Fixed: anchored predicates, not substrings — exact equality for the floors, startswith("Docs drift gate") and endswith("windows") for the drift gate (so no EM DASH has to survive a shell round trip to make the match correct), and a multi-line answer is now VOID rather than a value.

ARMS PROVEN, stated exactly this narrowly: the VOID arm (fired on the live target: "run not terminal yet", exit 3), the AMBIGUOUS-VOID arm (fired on the control before the fix, exit 3), and the NOT-MET arm (control after the fix, exit 1, reading 37 skipped / 38 skipped / 43 success — which matches the raw step list exactly). The MET arm, exit 0, is UNPROVEN and cannot be proven until a run is actually green. I am not claiming the whole path is exercised.

THE GENERAL SHAPE, since it is the second time this arc: an instrument that reads a column which must hold ONE value is only correct if >1 is an ERROR. Pick-first and compare-the-concatenation both mint confident wrong verdicts, and both fail toward a reading that looks like a measurement.

Nothing acted on: attempt 2 in_progress at f6110c2a...cf98d, 5/6 carried greens, test(Windows) in flight, watcher healthy at a 2-minute cadence. No reap while it runs, per your ruling. Counter 104 unconsumed.