0039: A person's answer continues the run that asked, on its own branch

• Status: Accepted (Navjyot, 2026-10-07)
• Date: 2026-10-07
• Related: 0001 (the watcher decides what runs next), 0027 (how an answer reaches the ticket)

Context

A run can stop on a question no advisor can answer. It ends "blocked", a person answers it, and the watcher posts the answer and queues the ticket again (0027). The next claim then cut a new branch and worktree (orion/lta-161-2) and started over with the ticket and the person's note. Everything the first run had read and committed was left on the old branch, and the page showed two unrelated runs.

Resuming a worktree already exists for a different case: a claim whose holder died reattaches to its branch and re-enters at the stage it reached. It deliberately does not apply to a retry, because a failed run queued again must not be built on top of the failure (workspace.AddWorktree explains why). The question was how to tell an answered run from a retry.

Decision

1. An answer continues the run that asked; a retry does not. A run is a continuation when all of these hold, read only from what the logs already record:

   • the ticket's last piece of work (bookkeeping events such as usage, notes and run-end do not count) is a blocked, so the run stopped to ask rather than failing;
   • a person's answer was delivered after it, and no work has happened on the ticket since;
   • the branch the ticket was last on is on record.

   Nothing else is a continuation. A failed run queued with --reset, a ticket that was never answered, and an answer older than the last block all get a fresh branch, as before. No new state is stored.

2. It reuses the branch and worktree, not the agent session. The claim goes through the same ResumeWorktree, so the earlier commits are kept, a dirty tree is committed as an unverified snapshot first, and the pipeline re-enters at the stage the earlier run reached. The implementer starts a new session, with the ticket, the person's answer and what the branch already holds. Resuming the agent's own conversation (claude --resume) is possible and cheaper, but it ties the run to a session file that may be gone and to how the CLI stores it; it is left for a later decision.

3. If the branch or its worktree is gone, start fresh and say so. ResumeWorktree already falls back to a new branch. The run now states that it could not continue, and the log records reused: false, so the page does not suggest work was kept.

4. One run id per attempt, with a recorded link. The new run has its own id. A note on it records which run it continues, the branch and whether the branch was reused (continues, branch, reused). The page shows that link; it does not merge two runs into one.

5. The decision is the engine's, not the page's. It is made inside internal/work when the claim chooses a branch. The watcher still decides what runs and when (0001); the web only reports what was recorded.

Consequences

• An answered ticket keeps the work done before the question, and does not pay to re-derive it on a new branch.
• A new session still re-reads the code. The saving is the committed work, not the agent's memory of it; session resume would add that.
• orion queue add --reset after a failure still starts clean. A person who wants a failed ticket continued has to answer it, not retry it.
• If a ticket is answered, then also requeued by hand before the watcher claims it, the answer still counts: nothing has happened on the ticket since.

Rejected

• Always reuse the branch on any requeue. It would build a retry on a failed attempt, which the existing branch policy exists to prevent.
• Mark answered tickets with a label. It would add state to keep in step with the log; the log already says what happened.
• Resume the agent session now. Larger saving, more ways to fail, and it needs the CLI's session storage to be stable. Decided separately.

Status

Accepted. It accepts the continuation rule and the fall-back; the session question stays open.