An implementation plan is a risk and verification contract
A useful plan explains what will change, what will not change, how the result will be checked, and when to stop. It is not a prediction that the implementation will succeed.
Plans should be small enough for one review and explicit about public contracts, data, configuration, and rollback.
| Plan field | Content |
|---|---|
| Goal | Observable outcome |
| Files | Confirmed affected paths |
| Steps | Ordered minimal changes |
| Risks | Potential regressions and boundaries |
| Verification | Commands, tests, and review |
| Stop | Condition that returns control |
Plan review
- Compare the plan with the task scope.
- Remove unrelated cleanup and speculative improvements.
- Name a verification step for each success criterion.
- Add a rollback or recovery point.
- Mark assumptions as Unknown.
- Wait for the owner decision before implementation.
Plan skeleton
# PLAN.md
Goal: <observable outcome>
In scope: <paths and behavior>
Out of scope: <explicit exclusions>
Steps:
1. <small change>
2. <focused check>
Risks: <list>
Rollback: <checkpoint>
Stop if: <condition>
Status: proposed; execution result: Unknown.Canonical lesson source · JavaRush
Open JavaRush material