The warm end-to-end test failed on CI three tags in a row with the product behaving exactly as
specified, and the build change that finally printed the detail showed why in one line: the
runner's log had "running command w-1" and then nothing — no run for w-2, no refusal of it
either, because the test's send and the runner's answer had already happened and the answer
was "busy".

A run's bracket closes INSIDE the run, a hair before the runner's in-flight slot clears. So a
command sent the instant run_finished arrives can still be refused. That is the contract
working — one command at a time, the monitor owns the queue — and the right client behaviour
is to send again, which is now what the test does and what docs/monitor-design.md and
CLAUDE.md say. On a fast machine the gap is invisible, which is the whole reason it is worth
writing down rather than fixing by widening a timeout.

The retry helper reads ANY acceptance for a command id rather than the latest answer: a
resend that races an already-accepted command is itself refused as busy, so reading only the
last answer would spin until the deadline over a command that is running fine. That one is
not hypothetical either — it was the first version of the helper.

Deliberately not changed: the runner does not gain a grace window before refusing. "Rejected,
not queued" is a decided rule, and a runner that waited a little would be queueing for a
little.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019U1ut5qK9Y9ofxU7dKw7TC