plan

Plan

Given a clarified requirements artifact, produce an implementation plan concrete enough that someone with no prior context could execute it. The bar: exact file paths and names, one committed architecture decision, and a phased build sequence implement consumes step by step — no abstract advice, no "add appropriate error handling". This is a peer phase: it grounds itself in the code via explore, picks ONE approach and commits, then hands a plan to implement. It does not clarify requirements (that's clarify, upstream) and does not write production code (that's implement, downstream). It does not invoke either.

Process

1. Ground in the codebase first. Read the clarified artifact (clarify's requirements + success criteria), then call explore (dispatch a sub-agent when available; otherwise inline) and consume its essential-files list and file:line citations as the starting set for the existing patterns, conventions, and integration points this work touches. Cite each finding as path/to/file.ext:line — the blueprint is built on what's actually there, not what you assume.
2. Decide the architecture and commit. Survey the realistic approaches, then pick ONE and write the decision plus a one-paragraph rationale grounded in the patterns from step 1. Do not hedge with "Option A or B" — a plan is a decision. Record approaches you rejected in one line each only if a reader would otherwise wonder why; don't relitigate.
3. Choose the test seams up front. Pick where behavior gets verified, preferring a single highest seam (one integration/end-to-end point) over many low ones. Decide what's tested and what isn't, and capture it in an explicit Testing Decisions section. New behavior gets a test; a bug fix gets a test that fails without the fix.
4. Design the components. For each unit of work name the file(s), its single responsibility, and its dependencies on other units. Split by responsibility, not by technical layer; files that change together live together; follow the established structure rather than restructuring it.
5. Write the Implementation Map — every concrete create/modify action with its exact path: Create src/x.ext / Modify src/y.ext:120-150 / Test tests/x_test.ext. No file is named only in prose; if it changes, it's in the map.
6. Sequence the build into phases. Order the work so each phase produces something verifiable, following dependency order (data/contracts → logic → wiring/config). Emit it as the Build Sequence checklist below — this is the executable artifact implement works through.
7. Pin the critical details. State the concrete error-handling behavior, state/data shape, and verification command for each phase. Add an Out of Scope section listing what this plan deliberately does not touch, so implement doesn't wander.
8. Self-review with fresh eyes. Walk every Success criterion in the clarified artifact and point to the task that satisfies it — list and fix any gap. Scan for placeholders (TBD, TODO, "handle edge cases", a test step with no assertion) and remove them. Confirm names/signatures used in a later task match what an earlier task defines. Fix inline; don't re-review.