fix(orchestrate): a dead Orca runtime is exit 4, and a timed-out ask is resumed, not decided

[choiyounggi]

Two failure modes measured on a live 3-worker Orca run. Both read as normal operation at the time, which is what makes them worth closing.

1. orca-wait.sh could not tell a runtime outage from a quiet window

The check result went through .result.count // 0, so all three of these scored "0 messages" and continued:

reality	what orca-wait saw
ordinary timeout — ok:true, count:0, timedOut:true, status 0	0 messages → checkpoint ✅
runtime fault — {"ok":false,"error":{"code":"runtime_unavailable"}}, status 1	0 messages → checkpoint ❌
CLI killed — no output at all, nonzero status	0 messages → checkpoint ❌

An outage therefore burned the entire budget one silent 15s window at a time and finished on no message in <tmo>ms — checkpoint, keep waiting. The coordinator never learned the runtime was gone.

New exit 4, fired only on an explicit fault signal: nonzero status, ok:false, or connectionLost:true mid-wait. A missing ok still checkpoints, so a partial or replayed payload can never be reported as an outage.

Exit 4 is deliberately not a restart signal: a dead runtime does not stop a worker session. Measured — a worker landed three commits and a push while the runtime was down.

Envelopes verified against the live CLI, not assumed:

$ orca orchestration check --run <fresh> --wait --types worker_done --timeout-ms 20000 --json
{"ok":true,"result":{"count":0,"timedOut":true,"connectionLost":false,...}}     rc=0

$ orca orchestration worker-show --dispatch bogus --json
{"ok":false,"error":{"code":"dispatch_not_found",...}}                          rc=1

2. The worker prompt never said what a timed-out ask means

Rule [4] told workers to ask and end their turn, and stopped there. Orca leaves a timed-out question pending, to be resumed by its original message id — but with nothing said about it, both workers proceeded on a self-chosen "conservative assumption" (at 600s and 900s) and reported the guess only afterwards. One guess happened to match the human decision; that is luck, not a protocol.

Rule [4] now states that a timeout is not an answer, requires ask --resume <message_id>, and forbids re-asking (a second --question creates a second thread the coordinator cannot disambiguate). The same rule is added to SKILL.md's worker contract.

Tests

386/386 bats green. Six new tests on the outage split — the real timeout envelope (regression guard), ok:false, a killed CLI through the live orca path, connectionLost while ok:true and count:0 (the boundary that looks exactly like a quiet window), and no-ack-on-fault. The orca test double gained an rc-fail marker so the nonzero path is exercised through the real code path, not only through canned JSON.

The Orca prompt-set checksum is bumped in this commit, per the guard's own instruction, and a new test names the ask-timeout obligation so a reword that keeps the command but drops the rule shows up in that test's diff.

Not changed, and why

• Worktree reuse (--worktree id:<repoId>::<path>) — already the documented path in O3; the run rediscovered it rather than finding a gap.
• Usage-limit stalls invisible in worker-show — already covered by orca-worker-stalled.sh (agent updatedAt silence, not lastOutputAt); the run simply did not use it.
• _keepalive lines breaking JSON parsing — keepalive goes to stderr and is documented in orca agent-context --json; our scripts already drop stderr. Caused by merging streams with 2>&1 by hand.
• worker-release returning retained — documented behavior for user-taken-over terminals.
• zsh glob on ?/* in a message body — an interactive-typing artifact; no script builds --body/--question through an unquoted expansion.

🤖 Generated with Claude Code