Resume Recovery
Resume Without Losing Bookkeeping
Repairing a resume loop by preserving Gantry state and accepting already-satisfied reruns only after the gate proves them.
0 milestones 2 tasks 6 agents
2 plan 2 execute 2 review
126k peak context
26m 24s total 8m 32s per task
2m 48s plan 13m 38s execute 3m 13s review
25 edits 166 commands
codex harness
This run fixed a resume wedge where Gantry could throw away its own bookkeeping while cleaning up an interrupted run worktree. Once that happened, completed work could be rediscovered as pending; if the same work was already present, the rerun could then fail for having nothing new to commit.
The repair split that problem into two contracts. Resume cleanup became project-scoped, so run ledgers, logs, and history survive while unverified project scratch is discarded. Then the no-change path learned to ask the gate whether the sprint was already satisfied before treating the lack of a new commit as a stop.
How this walkthrough is structured
Feature
What did the run build and ship?
Current Gantry still preserves orchestration state during interrupted-worktree recovery and carries green no-change completion through the newer generic run machinery.
Build
How did Gantry structure the work?
The run cut the resume loop into a preserved-bookkeeping recovery contract followed by an idempotent rerun contract, and both sprint-local gates stayed green.
Lossless Resume
2 agents 8m 46s wall time 126k peak context
The surviving tree still has a run-level resume reset that fires only for preexisting dirty worktrees whose selected pattern opts into interrupted-worktree recovery. That path resets project files to the current head while preserving the orchestration directory, then records the reset as durable support-stage history. The tests still cover dirty resumed trees, clean resumes, fresh builds, and Map resumes that must not be cleaned because their uncommitted artifacts are state. Some original code lived in build modules that have since been replaced, but the recovery contract remains visible in the current run and worktree modules.
This sprint owned the root cause: a dirty resumed worktree needed cleanup, but Gantry's own run directory was not disposable project scratch. The brief kept the scope tight enough for one fresh agent by making the contract explicit across flat, milestone, and design-style runs while leaving Map recovery alone. It also required the forensic ambiguity to be resolved before coding, so the regression matched the observed ledger loss rather than a guessed failure. The run record shows the piece passed its gate and review without a repair loop, so the next sprint could treat preserved completed rows as a stable premise.
Idempotent Reruns
2 agents 8m 17s wall time 118k peak context
The original sprint-driver files are gone from the current tree, so this unit's exact implementation cannot be isolated today. The standing behavior has moved into generic pattern execution: a green unchanged task can record completion without creating a work commit, skip review work that only applies to changed code, and clear stale retry state before continuing. Current tests exercise that green no-change route and the guard that prevents an old review verdict from steering an already completed task back into recovery. The feature now reads as a shared pattern-completion rule rather than a special branch in the old sprint driver.
With the resume cleanup contract in place, this sprint handled the defense-in-depth case where a completed sprint is nevertheless executed again. Its boundary was the no-change decision: run the gate before calling the attempt a failure, accept the result only when the gate is green, and keep the red-gate path as a real stop. That made the assignment narrow enough to avoid revisiting the reset mechanic from the prior sprint. Its gate and review also stayed green, so the idempotence layer landed without forcing a re-plan of the already established recovery behavior.