plan-execution

Plan Execution

Turn an accepted plan into reviewable evidence while preserving the user's work and authority boundaries.

Preconditions

• Confirm the requested action includes implementation. A plan alone is not authorization to mutate the repository.
• Re-read the original request, accepted plan, repository instructions, and current status before the first edit.
• Preserve staged, unstaged, and untracked user work. Never reset, clean, stash, overwrite, or reformat unrelated files.
• Treat commit, push, pull request, issue mutation, deployment, infrastructure apply, external messaging, and publication as separate authorities.
• Stop rather than weaken an assertion, skip a gate, broaden an exclusion, or hide a warning.

Workflow

1. Reconcile the plan: Verify that paths, symbols, dependency versions, commands, and assumptions still match the checkout. Amend the execution notes when reality differs; request direction if the required outcome would materially change.
2. Capture the baseline: Record branch, HEAD, status, relevant test state, and known external boundaries. Identify which existing edits belong to the user.
3. Order the work: Follow the dependency graph and critical path. Choose the smallest vertical slice that produces independently useful behavior and proof.
4. Establish red evidence: Use test-driven-development for behavior changes or create a characterization test when changing legacy behavior. For non-code changes, define the failing contract or validation signal first.
5. Implement minimally: Use the applicable language, infrastructure, site, or document skill. Touch only files traceable to the current slice and explain non-obvious trade-offs at the decision point.
6. Verify the slice: Run the focused test, formatter, static checks, and any bounded runtime/manual check promised by the plan. Read the full output and fix root causes.
7. Review the delta: Compare the actual diff with the intended slice. Remove only artifacts introduced by this work, confirm no requirement drift, and use diff-review for risky changes.
8. Checkpoint honestly: Mark the slice complete only with fresh evidence. Record partial results, deviations, and residual gaps before moving on.
9. Protect unrelated work: Before any full gate, inspect the full gate's task definition and working-tree state. If it runs whole-tree write-formatters and unrelated or user changes are present, validate the exact candidate in an isolated temporary worktree or run equivalent non-mutating checks; never reformat unrelated work.
10. Run the whole contract: Test changed behavior first, then run the repository-owned full gate, normally mise run all. Keep local, exact-head CI, runtime, deployed, and published evidence separate.
11. Hand off: Summarize changes, verification, untested boundaries, and remaining tasks. Leave the worktree for review unless further mutation was explicitly authorized.