After the verdict

When one task fails, what happens to the rest of the plan

A plan is a graph, and a graph has a bad day when one node fails. The interesting part is not the failure. It is the three decisions that follow it: what the failed task keeps, whether the run keeps going, and what the tasks downstream are allowed to do. Getting the third one wrong is how a broken task becomes the foundation for the next six.

Disclosure: I build Ordewell, so this is the set of decisions it makes rather than a survey. The tool is free and Apache-2.0. The mechanics are worth arguing about whether or not you install it.

A failure is missing evidence, not a nonzero exit

Before anything can be decided, the failure has to be defined, and here it is defined by evidence: each task carries a completion marker, and the verdict engine looks for that marker in the runner's output when the session ends.

If the marker appears, the task passes, and the exit code is recorded as skipped with the reason written into the record, because there is no point pretending two checks were consulted. If the marker never appears, the task fails, whether the process exited 0 or exited with a code. A clean exit with no marker is not a pass. It is a runner that ended politely without doing the thing the task was for.

  ✗ #b7c2 failed
    FAIL: agent exited cleanly but did not emit the
    completion marker

    completion_marker  failed   agent exited before Ordewell detected
                                the task completion marker
    exit_code          passed   agent exited cleanly (code 0)

Both checks stay on the record, which matters later. A verdict is evidence rather than a status label, and the difference between "the runner crashed" and "the runner finished and the marker never printed" decides whether you retry the task or fix the prompt.

Three decisions at the moment of failure

1. The failed task keeps its work. A task that fails verification has its worktree released with keep, so the tree stays on disk and stays inspectable, and the verdict plus the tail of the session's output are stored on the task. A failure you cannot open is a failure you cannot diagnose.

2. The run stops starting new work. The orchestrator sets itself back to not running and the plan returns to approved, so the scheduler stops handing out tasks. The plan is not cancelled: tasks already in a session finish and produce their own verdicts. What stops is the fan-out. A run that keeps dispatching after a failure is building on a base it knows is wrong.

3. Dependents park. A task that declared the failed one as a dependency is moved to blocked. There is a second guard behind it: a task whose dependency is failed is not ready even if its own status still says pending. Two guards, because a dependent must never start from a base missing work it was told it could rely on.

Why dependents wait instead of proceeding

A dependent session is handed the tail of its direct dependencies' output, and in an isolated run its worktree is cut from the integration branch. So "dependency met" means the work is completed and landed, not merely attempted.

Picture the alternative. Task 3 fails because its change never landed. Tasks 4 through 9 start anyway, read a repository without task 3's work, and produce six plausible diffs. Every one of them passes verification, because every one did what its prompt asked. You now own a merge problem with six authors and one root cause, and every verdict in it will disagree with you about where it came from. Parking the graph at the failure is what keeps the blast radius at one task.

Getting back on the horse

Once the run has halted, you have four moves, for four different situations.

Retry is for a failure that had nothing to do with the task's content: a flaky harness, a rate limit, a session that died. It clears the verdict and the output summary, returns the task to pending, releases the dependents parked on it, and drops the failed attempt's worktree, because a retry starts from the integration tip, which now holds what its predecessors landed.

Re-arm is for a failure that was the task's fault: the prompt was ambiguous, or the model or mode was wrong for the work. It is a plan edit rather than a control command, so it carries corrected fields in the same operation, and it releases the parked dependents too. It also pierces the planner lock on purpose, since re-arming a task the planner is normally forbidden to touch is the point of it.

Mark complete is for the case where the work is real and the evidence is not: the agent did the change and the marker never printed. It records a pass whose automatic checks are replaced by a single manual check saying no verification was performed.

Force start is for running one task now, readiness rules and dependencies aside, because you have read the repository yourself.

# the run halted at task 2
ordewell status

# fails: the task keeps its work, dependents park at blocked
ordewell run

# one task, not the plan: verdict cleared, dependents released
ordewell retry b7c2

# resume: completed tasks are not re-run
ordewell run

Honest limits

• A retry is not a re-run. Completed tasks are not re-run on resume, so a retry costs one task and whatever was parked behind it. If the failure was the plan's fault, the same prompt produces the same failure, and that is a case for editing the plan.
• Halt is not kill. A failure stops new work from starting. It does not stop a session already running. A parallel task mid-flight finishes and can land a change written against a repository where the failed task's work is absent.
• Parking is recorded, not derived. Dependents are moved to blocked when the failure is recorded, with a readiness check behind it as a second guard. A dependency list edited after the failure is where the graph has to be right for the two guards to agree.
• No checkpoint inside a task. Retry re-runs the whole session for that task, because the task boundary is the only checkpoint that exists. On a long task that is real work repeated, and each retry leaves another kept worktree behind for you to clean up.
• Nothing escalates on its own. No automatic backoff, and no automatic switch to a different model after a failure. You can re-arm a task onto another runner, but you are the one choosing it.
• Mark complete weakens the record. A manually passed task looks like a passed task in the counts. The check saying no verification was performed is only as honest as your reading of it.

Source and design notes

A plan that stops at the first task without evidence, and parks everything downstream of it, is a plan where one failure costs one task. The code behind that: the verdict engine, the scheduler, task state, and github.com/ordewell/ordewell.