vetter auditor recovery redispatches from scratch while logging "resuming" — resume the dead session instead

[thedavidmeister]

What happened

Vetter run 20260810T230003Z (trace review-runs/20260810T230003Z.jsonl): the auditor subagent for cyclofinance/cyclo.site#404 died mid-run on an API error after ~$2.70 of work (11 API calls, 89k cache-write + 675k cache-read tokens; its final call reports zero context — the error). The orchestrator then said:

The #404 auditor died mid-run on an API error. Resuming it so it continues from where it left off.

What it actually did was a from-scratch redispatch, not a resume. The trace shows:

• a fourth full audit-skill injection (the skill body is injected once per fresh auditor; this run has four — #400, #403, #404, #404-replacement),
• the replacement's first API call starting at the 18.4k-token dispatch floor with zero cache-read of prior work — identical to a brand-new auditor's first call, nothing inherited.

The replacement re-audited the PR from nothing. The dead auditor's ~$2.70 was fully discarded; the run's total was $15.46, so the death-and-restart is ~17% of the run. Auditor deaths cluster in exactly the windows where they will recur — this one happened during the same API-flaky window in which the usage endpoint was unreachable (see #273).

Defect

Two parts:

1. Recovery path discards paid-for context. When an auditor dies on a transient API error, the orchestrator should resume the dead auditor's session so it continues with its accumulated context (checkout already verified, files already read, findings in progress), and only fall back to a fresh redispatch when resume is impossible (e.g. the session is unrecoverable or the error is not transient). The harness supports continuing a stopped subagent with its context intact; the vetter's standing orders (review-prompt.txt) and/or review-run.sh recovery guidance should require resume-first.

2. The log lies about it. The orchestrator narrated "resuming it so it continues from where it left off" while redispatching from scratch. Whatever recovery the prompt ends up mandating, the narration must say which one actually happened — a redispatch reported as a resume makes traces unauditable for exactly this kind of cost review.

Acceptance

• On auditor death from a transient API error, the orchestrator's first recovery action is a resume of the dead auditor's session; fresh redispatch only on resume failure, and the log line states which path was taken.
• A redispatch is never described as a resume in the distilled log or run summary.