Take Over Resume

Take-Over Resume

Resume work on a tree that a human may have changed while you were not looking. The failure mode is narrow and expensive: work resumes against a remembered state, the operator's manual fix is silently reverted or duplicated, and the conflict surfaces much later as a mysterious regression.

The controlling assumption is that the tree is the truth and your memory of it is a hypothesis.

When to use

• Resuming a task that was paused for manual intervention.
• Returning to a worktree after an operator hand-fix.
• Any resume where time has passed and the tree was reachable by someone else.
• A task that failed, was repaired by hand, and is being restarted.

Pausing cleanly

When work is being suspended for someone to intervene:

1. Stop at a coherent point. Suspend between steps, not mid-write. A tree caught half way through a multi-file edit is one nobody can safely reason about.
2. Record the resume anchor — the commit the work was built on, the tree involved, and the step that was about to run. This anchor is what makes the resume diff meaningful; without it, the diff has no baseline and the whole procedure degrades to guessing.
3. State what is safe to touch, so intervention does not collide with in-flight state.
4. Never remove a worktree with work still in flight. Removal kills the running work. Re-read in-flight status immediately before any cleanup, not from a status read earlier in the session.

Resuming

1. Diff against the anchor before reading anything else. List the changed files, then read the actual diff. This is the first action on resume — not a check performed after planning, because a plan built on the remembered tree is already wrong.

   git diff <anchor> does not show untracked files, and a new file is the most common human edit. A file the human created is invisible to the diff alone, so the procedure would miss precisely the change that triggered it. Enumerate untracked paths separately and read them in full:

   git diff --stat <anchor>            # tracked changes
   git status --porcelain              # '??' lines are untracked and absent from the diff above

   Read every ?? path's contents, not just its name. Treat a .gitignored path as intentional scratch unless it is obviously a deliverable.

2. Read the changes as intent. A human edit is a message: it says the previous approach was wrong, incomplete, or heading somewhere unwanted. Work out what the edit is telling you before deciding how to proceed.

3. Reconcile the plan against reality. Steps the human already completed are done — do not redo them. Steps whose premise the edit invalidated need rework, not resumption. Say which is which.

4. Do not revert a manual change to restore your plan. If a human edit conflicts with the plan, the plan yields, or the conflict is surfaced for a decision. Silently reverting an operator's fix is the central failure this procedure exists to prevent, and it is indistinguishable from a bug when it surfaces later.

5. Re-run verification from the current tree. Prior results describe a tree that no longer exists. Establish a fresh baseline before attributing any failure to your own work — a failure that predates your changes is not yours to fix, and the only way to tell is to measure.

6. Carry the change summary into the resumed work as explicit context: what changed, what it implies, and how the plan was adjusted.