Deepworkplan Resume

DeepWorkPlan — Resume

Safely continue an interrupted plan from where it stopped — no duplicated work, strict order, continuing from the first [ ] task.

Shared resources (read these)

• ../shared/context.sh — resolve repo root, branch, and dwp_dir.
• ../shared/dwp-paths.md — plans at .dwp/plans/PLAN_{name}/.
• ../shared/adaptation.md — the two repository archetypes (relevant for orchestrator/child-DWP awareness).
• ../execute/SKILL.md — the execution rules this flow resumes into (team-agents, orchestrator task types, Dailybot golden rule).

Parameter Support

• /dwp-resume {plan_name} — resume directly (skip the menu).
• /dwp-resume latest — resume the most recently modified plan.
• No parameter → interactive selection (Step 1).

Normalize the PLAN_ prefix; validate .dwp/plans/PLAN_{name}/ and its README.md. If not found, show available plans and ask the user to choose.

Trust boundary (write scope)

allowed-tools includes write-capable Edit, Write, and Bash.

Writes: identical scope to execute (task outputs, .dwp/ working state, per-task commits after gates pass) — resume continues an interrupted plan, it does not widen the boundary. Recorded state follows the DWP Resume Protocol (spec/DWP_SPECIFICATION.md §5.3): completed [x] tasks are trusted as recorded — never re-validated unless the developer explicitly asks, or the protocol's smoke test fails in a way that implicates a completed task — while the world is smoke-tested (cheapest standing validation) before anything is built on it.

It MUST NOT: re-run or "fix up" already-completed tasks unless the developer asks or the §5.3 smoke test implicates them, skip the post-interruption smoke test, push without instruction, or write outside the repo checkout and .dwp/.

Workflow

Step 0 — Check for Parameters

If a parameter was given, resolve the plan (or latest), validate folder + README under .dwp/plans/, and skip to Step 2. Otherwise go to Step 1.

Step 1 — Identify Plan

List PLAN_* folders in .dwp/plans/; mark the most recently modified as latest. Present a numbered menu (number / name / latest) and validate the choice.

Step 2 — Assess Current State (CRITICAL)

This step implements the DWP Resume Protocol (../spec/DWP_SPECIFICATION.md §5.3) — the named six-step ritual any resuming session performs:

1. Read the plan README fully (objective; which tasks are [x] vs [ ]).
2. Run git status, git log --oneline -10, and git diff (if uncommitted changes exist). In a workspace without git, read state.json's checkpoint instead (../spec/PLAN_STATE.md §4.4).
3. Reconcile the state layer (when present): compare state.json against the README checkboxes. On any desync the markdown wins — regenerate state.json from the README (and git log), note the reconciliation in PROGRESS.md, then continue (../spec/PLAN_STATE.md §5). If state.json.blocked is set, surface it: that is why the plan stopped.
4. Find the resumption point — the first unchecked [ ] task.
5. Check for partial work: if git status shows uncommitted changes, review them against the current [ ] task; read that task's Completion & Log for notes.
6. Smoke-test before building: run the repo's cheapest standing check (from AGENTS.md Quick Commands) to confirm the world still works before adding to it. A failing smoke test is investigated first.

Step 3 — Report Resumption Status

Report: completed [x] tasks; pending [ ] tasks; the task to resume from; git state (uncommitted changes, recent commits, last commit); the current task file and any completion-log notes; partial-work findings; and the plan to finish the task. Location: .dwp/plans/PLAN_{name}/.

Step 4 — Handle Partial Work

If uncommitted changes exist, classify them: valid partial progress (incorporate and complete), incomplete (finish remaining work), or unclear/unrelated (ask the user before proceeding). If none, proceed directly.

Step 5 — Resume Execution

1. NEVER redo [x] tasks — trust the README, cross-check git commits.
2. NEVER skip [ ] tasks — strict order; complete each fully.
3. Continue from the first [ ] task — open its file, read fully, address any logged blocker first.
4. Complete the current task — follow its Execution Checklist; run all validations; on failure, log in Completion & Log, leave [ ], report and wait; on pass, update the log, mark [x], and commit.
5. Continue to the next [ ] task until done or paused.

From here, the standard Execute rules apply (../execute/SKILL.md): the per-task significance Dailybot report, the plan-completion milestone golden rule, and — for orchestrator plans — orchestrator task types (create_child_dwp / integration_checkpoint / execute_child_dwp), manifest checks, and team-agents parallel groups (real team agents, not subagents) with sequential fallback. Resume from the first [ ] task using those same rules, including hub-vs-individual-repo navigation per ../shared/adaptation.md.

Step 6 — Handle Blockers

If a task log shows a blocker, read it, fix the issue, re-run validations; on pass: mark [x], commit, continue; on fail: log again, stop, request help.

Step 7 — Progress Reporting

After resuming and completing a task: ✓ Resumed and completed: Task N with files changed, validation result, commit, and the next task. On blocker: ✗ Task N blocked with the blocker, action taken, status, and next step.

Important Notes

• Trust the task list ([x] done / [ ] pending); verify with git; read completion logs; never duplicate work; never skip; assess partial work carefully; stop on blockers.

Error Handling

• Invalid plan structure → report; ask to fix or proceed with caution.
• Missing task file → report; ask whether to skip or create.
• Unclear git state → report findings; ask before proceeding.
• Unresolvable blocker → log in Completion & Log; report; wait for guidance.