parallel-impl-agent-dies-mid-stream-verify-working-tree

Parallel impl agent dies mid-stream — verify the working tree, not "completed"

Problem

You dispatch N foreground implementation agents in parallel (disjoint files). One comes back with API Error: Response stalled mid-stream (or an empty/truncated report), and the harness may even emit a background " completed (exit code 0)" line. If you trust that and integrate, you ship a hole: the agent wrote NOTHING — its target route is untouched, no test file exists, the todos it created for itself are all still pending.

Context / Trigger Conditions

• 2+ parallel Agent/Task impl agents editing code in one repo.
• One returns a stall/timeout/empty final message; subagent_tokens ~0; a "completed" status.
• You're about to run a combined git add/commit or a whole-repo check across both outputs.

Solution

1. Reconcile claimed-vs-actual before integrating. For each agent: git status --short and grep its target for the expected change (e.g. grep -n generateChineseText route.ts). A missing edit + no new test file = the agent died; "completed (exit 0)" was the harness reporting the shell wrapper exited, NOT the work landing.
2. Don't try to revive a dead foreground agent — finish its task yourself. Unlike a credit-stall suspension, a mid-stream API death leaves no resumable state. You have full context; do it in the main loop (or redispatch a fresh agent with the same brief).
3. It degrades gracefully because of the orchestration guardrails: agents do NOT commit and do NOT run whole-repo type-check (avoids git-index races + cross-agent tsc false-positives on half-written files); the orchestrator does path-scoped git add <exact files> per unit + the full check at integration. So the survivor's work is clean and committable independent of the casualty.

Variant: the agent died but the work SURVIVED (checkpointed pipelines)

The headline case above is the shared-file orchestration, where agents deliberately don't commit — so a death means zero durable output. The inverse case is just as common and the recovery is completely different: a long, single-owner pipeline agent whose stages each git commit && git push before moving on. When that agent dies mid-stream, the finished stages are already on the remote. Treating it like the headline case — redoing the task from scratch — duplicates work and can clobber pushed commits.