Recover Task

Step 2: Output root cause analysis

🔍 Root cause analysis: [task-NN] <title>

Failure type: <A–F>

Root cause:
  <specific details: which line / test / config caused the failure>

Blast radius:
  <this task only / affects other modules>

Step 3: Propose a recovery plan

Provide a concrete plan based on failure type:

A. Test assertion failure → Locate the assertion gap, check whether implementation logic matches the expectation, fix implementation (not the test)

B. Compile / type error → Locate the error file and line, fix the type definition or import path

C. Runtime error → Locate the throw site, add null checks or error boundaries, verify data initialisation

D. Logic defect → Re-read SPEC acceptance criteria, compare with implementation, correct the business logic

E. Environment / dependency issue → List the steps the user needs to take (install package, configure env var), wait for completion before continuing

F. SPEC ambiguity → List the ambiguous points, ask the user, update SPEC based on the answer, then re-implement

Confirm with the user: "Proceed with the above plan? (y/n/suggest alternative)"

Step 4: Execute recovery

Apply the fix, then re-run tests.

• Tests pass → proceed to Step 5
• Tests still fail → re-diagnose (is it a new failure?) → repeat Steps 1–4 (max 2 rounds)
• Still failing after 2 rounds → go to Error Handling

Step 5: Update task state

On successful recovery:

{
  "state": "in_progress",
  "updatedAt": "<current ISO timestamp>",
  "notes": "<summary of recovery actions taken>"
}

Inform the user: "Task recovered. Re-run /implement-task to finish, or run /verify-task to re-verify."

Error Handling

Done When

• Root cause has been clearly identified
• Recovery plan has been confirmed by the user
• Task state has changed from failed to in_progress
• Recovery summary has been recorded in notes