plan

# Stable execution plan Turn approved behavior and architecture into reviewable execution intent. Do not choose product direction or implement the plan. ## Purpose Create or revise a concrete plan with traceable milestones, validation, dependencies, risks, and recovery. ## When to use Use after proposal, spec, and architecture are stable enough to sequence multi-file, risky, milestone-based, migration-heavy, or cross-component work. ## When not to use Do not choose product direction, replace a missing specification, implement code, review a diff, verify branch readiness, or open a PR. ## Workflow role - role_name: plan - stage: authoring - upstream: accepted proposal, approved or reviewed spec, architecture or ADRs when relevant, test-spec when present, and project-local workflow evidence - downstream: plan-review - summary: Own stable plan content and its authoring transition; initialize approved plan work only through the governed operation. - must_not_claim: implementation completion, review approval, verification, branch readiness, PR readiness, final closeout, or Done ## Invocation classification Classify the invocation before writing. - Portable planning has no exact governed change authority. It writes the plan and navigation only; it does not read or mutate `change.yaml` as lifecycle state. - Governed planning requires one exact `stage-owned-change-local-v1` change, settled prerequisites, plan-owned authority, and a deterministic plan path. Load `reference...