skip to content
Jobs

Judging Whether the Work Was Actually Finished

Review learns to ask if a sprint covered its brief, and a cut-off agent stream stops meaning failure.

Gantry milestones
Review learns to ask if a sprint covered its brief, and a cut-off agent stream stops meaning failure.

Gantry hands each piece of work to a fresh coding agent, runs the tests itself, and then has a review step look the result over before it is kept. That review used to assume the work was already done — it opened by stating the agent had passed the tests and only looked for small safe fixes. Nothing asked whether the agent had actually built everything the brief called for, or only part of it.

A second, sharper problem sat next to it. When an agent's output stream was cut off partway — messages arrived but the final "here is the result" signal never did — Gantry read that as the agent having failed and stopped the whole run. Sometimes the agent had in fact finished real, correct work before the connection was severed, and that work was thrown away.

This job taught review a second question: did the diff cover the brief, or fall short? And it made a cut-off stream mean "I can't tell from the stream what happened" rather than "the agent failed" — letting the actual files on disk, the test suite, and the completeness check decide the outcome instead.

Build

The work split into three changes in strict dependency order — a completeness verdict, a rollback primitive, then truncation handling — so each could be proven on its own before the next relied on it, and the whole run stayed green.

The three pieces are genuinely coupled: routing a truncated run forward safely only works if review can catch a half-finished diff, and that catch is only useful if there is a way to rewind and retry. Built as one change, that knot would have had to be reasoned about all at once by a single agent. The cut untangled it into a fixed order — teach review to emit a scope verdict, add the worktree rewind it needs, then reclassify truncation on top of both — where each change was written to be independently testable.

The ordering is what made that possible. The rewind primitive, a hard reset that returns the project tree to a captured commit while leaving Gantry's own ledger and logs untouched, was landed and unit-tested with no caller yet depending on it. Only the following change wired the completeness branch to use it, and only the last change made a truncated execute fall through into that same machinery. A later piece never had to reach back and change an earlier one to make itself work.

The safety property the whole thing rests on — a chunk can rewind and re-run at most once, then it stops loudly, never looping — was stated in the first brief and carried forward unchanged through the other two, so no change could reintroduce an infinite retry. The run bears this out: every sprint executed, passed its gate, and passed review on the first try, with no rewind of the plan and no sprint sent back. The difficulty here was in the coupling, and the decomposition spent it in advance by choosing the order.

Feature

Review now emits a structured scope verdict backed by a parser biased toward passing, the worktree gained a bookkeeping-safe hard reset, and truncation became a distinct inconclusive outcome that routes to ground truth — all still in the tree today.

Before this work, Gantry's review could not say a diff had missed part of its assignment, and a truncated agent stream was classified as an outright error that halted the run. Both are now handled by machinery that is still present at the current tree.

Review asks the agent to end with a `SCOPE:` line alongside its existing plan-impact judgement, and a defensive parser reads it. The parser is deliberately biased: an absent, garbled, or unreadable verdict defaults to "complete" and is logged, because the downstream response can re-run execution and a hallucinated shortfall could otherwise spin forever. When a shortfall is real, the pipeline resets the project tree to its pre-execute state and re-runs the chunk once; a second shortfall stops with a distinct, surfaced reason rather than retrying again. That reset lives on the worktree and its tests, which confirm it reverts project files while preserving the orchestration directory and surfaces a pre-existing stash instead of clobbering it, are still there.

Truncation became its own agent outcome, separate from success, error, oversized, and transient. A stream that ends without a terminal result becomes that inconclusive verdict — unless the events show an upstream throttle first, in which case it is transient and retried. An inconclusive execute no longer stops the run; it falls through to the no-op guard, the gate, and completeness review, and commits only if the tree is non-empty, the gate is green, and review calls the scope complete.

The design has since been extended rather than unwound: the scope verdict now distinguishes a retry from a re-plan, and the large build module that held the pipeline was split into a directory of smaller files, carrying this logic with it. What the job introduced is intact under that reorganization.

unavailable sessions
unavailable context
44,784 in / 214,282 out tokens
$24.90 cost
0 x 3 milestones x sprints
unavailable edits
unavailable commands
55m duration
unavailable roles
0 x 0 fixes x replans
- harness