Skip to main content
A run plans, changes the code and checks the change, as Planning before any code changes, Changing the code, within the plan and Checks describe. This page covers what happens when that first plan does not hold.

​
When the plan does not work: re-planning

​
What starts a re-plan

A re-plan starts in three cases:
  • A declared check fails on a run that has a plan.
  • The evidence gate fails on a run that has a plan, for example a criterion has no evidence. The fresh planner is given the failing items.
  • The agent escalates because a step cannot be done as written, needs a file the plan does not name, or is too large for one context.
A run with no plan, because none could be made, does not re-plan. A failing check or evidence gate goes back to the agent, as Checks and The evidence gate describe.

​
What the fresh planner sees

A new planner starts, and it does not continue the old one. It is given:
  • the previous version of the plan,
  • the failed check, the escalation or the failing gate items, with a one-line summary of each, and for a check the end of its output,
  • the change made so far, as its changed files and its diff.
It is never given the agent’s conversation or the earlier planner’s. It can read files in the sandbox to look at anything the diff cuts short, and it cannot change one. It writes a whole new version of the plan. The agent then carries on from the new version, starting at the first step the new version adds, so steps already carried out are not run again. A new version has to keep every step already carried out and add at least one step after them, because the steps carried out are not run again. A version that only rewrites an earlier step, or that drops a file an earlier step changed, is refused and counts as no new plan. If the plan cannot be corrected without a person deciding, or the planner records no usable new version, the run waits on you. The detail after the reason says which of these happened, and for a failing check the session shows the agent’s last message, as When the agent cannot fix a failing check describes.

​
Attempts

Every failure spends one of the run’s attempts: as many as your project’s Attempts setting gives it, 3 unless an admin changed it, shared with the review’s send-backs, as Rounds and attempts describes. A failing check spends one, a failed evidence gate spends one, an escalation spends one, and a review that sends the change back spends one. A failure that is both, such as a failing check that also leaves the gate failing, spends one attempt and not two. Re-planning has no limit or setting of its own. It follows a failure, and the failure has already spent its attempt. With three attempts, a run re-plans at most twice: the third failure leaves none, and the run does not re-plan.

​
When the attempts run out

When a check or the evidence gate fails, or the agent escalates, and no attempt is left, the run does not re-plan. It becomes Waiting on you with the detail out of attempts.
  • For a failing check the reason is The checks fail and need you.
  • For a failed evidence gate the reason is Evidence gate failed.
  • For an escalation the reason is The plan did not cover this.
Your reply in Send a message starts a new turn, and the run carries on from it as Changing the code, within the plan describes.

​
Every version is kept

Each new version adds a line to the conversation, such as Plan changed to version 2: A check failed. The line ends with View version 2, which opens that version of the plan above the conversation. There, Why this version says what started it, with the failed check, the escalation or the failing gate items in one line, and See version 1 opens the version before. The Plan panel shows the same Why this version for whichever version you pick in its Version list. Earlier versions stay readable, and the plan the agent is working from is the latest one.