Start with what a killed run leaves behind. Every entity it had in flight stays frozen in `running`, and nothing in the system will move it out on its own, so a resumed run sweeps stale `running` back to `pending` before it schedules anything [9]. The reclaim stops at entity state. The lock file the dead run also left has a different owner, and the author says they found that out the hard way [10].
That split is the design in miniature. Five states on one axis [6]; on the other, six failure categories: `timeout`, `quota`, `validation`, `phase_error`, `planning_error`, `unknown` [7]. Keeping the category off the state axis is what makes `paused` and `failed` different verbs, because quota exhaustion is a metered API saying come back later, while a validation error is a deterministic verdict that waiting will not improve, so it stops the run for a human [8].
The hole with the widest blast radius is in the fan-out. The generation step launches many agents in parallel for one topic and waits for all of them, collecting outcomes rather than letting the first failure escape, which the author defends on the grounds that one dying agent should not orphan its seventeen-odd siblings mid-flight [13]. But the runners returned an empty result on permanent quota exhaustion instead of raising [12]. An empty result is a value, and values pass through a gather-all aggregator as data, not as alarms [18]. The batch reported success, missing content was recorded as produced, and the run carried on [12]. The state log simply recorded what the runner told it, and the runner had gotten it wrong.
Separately, three places in the stack each recognised rate-limit errors with their own string matching, so which layer noticed depended on where the error happened to surface; the fix deleted two of the matchers and pointed everything at the third [14]. Three matchers agreeing was luck tied to a maintenance schedule, not something you could test for.
The build order explains more than the bug list does. By the author's own count the circuit breaker after three consecutive quota failures, and the shutdown path that kills child processes rather than orphaning them, predate the runner by eleven days [3], which puts them at 5 March 2026 [1]. The retry that continued a half-written file instead of regenerating it landed four days after the runner [4], on 20 March [2]. That is the confusion in one commit: retry is about surviving a call that failed, resume is about not paying again for a call that already succeeded, and the author admits he assumed for a while that the second came free with the first [5]. Resume here means knowing what is finished across separate runs and across two different machines, which is not the same problem as an agent remembering a conversation across turns [19].
Four bugs in one audit is a claim about this pipeline's shape [11]. For it to transfer you need a parallel step whose outcomes are collected instead of raised [13], a provider that signals exhaustion in-band as a value rather than an exception [12], progress you keep in a state log you parse yourself [1], and more than one machine allowed to start a run [19]. Drop any one of those and the failure set changes into something else entirely.
