docs: establish staged feature planning workflow

docs/plans/template.md

@@ -1,37 +1,98 @@
-# Plan: <Title>
+# Implementation Plan <ID>: <Title>
 
 Status: proposed
 
-## Goal
+Target executor: GPT-5.6-Terra
 
-State the outcome this plan must achieve.
+Feature roadmap: `docs/roadmap/features/<id>-<slug>.md`
 
-## Non-goals
+## Objective
 
-List adjacent work that is intentionally outside this plan.
+Summarize the implementation outcome. The feature roadmap remains authoritative
+for scope, rationale, target end state, and acceptance criteria.
 
-## Owning Repositories
+## Execution Rules
 
-List every repository this work may change and what each repository owns.
+- Execute stages in numeric order.
+- Number stages with consecutive integers beginning with `Stage 1`. Do not use
+  zero-based, decimal, nested, or nonsequential stage identifiers.
+- Before each stage, confirm its preconditions and the working-tree state of
+  its owning repository.
+- Preserve unrelated and pre-existing changes.
+- Do not make unresolved product or architecture decisions during execution;
+  stop and report the decision required.
+- Run every stage's validation before committing it.
+- Commit each completed stage when it leaves the repository in a valid state,
+  using the commit intent specified by that stage.
+- Do not begin a dependent stage after an earlier stage fails validation.
 
-## Dependencies and Settled Decisions
+## Starting State and Preconditions
 
-Link applicable roadmap sections and decision records. Record prerequisites
-that constrain implementation.
+- List required branches, revisions, tools, dependencies, and prior features.
+- Identify expected clean or intentionally dirty working trees.
 
-## Acceptance Criteria
+## Repository Scope
 
-- Define observable conditions for completion.
+- List every repository that may change and the changes it owns.
+- List repositories that may be inspected but must remain unchanged.
 
-## Implementation Sequence
+## Stage 1: <Independently Verifiable Outcome>
 
-1. Describe the first independently verifiable step.
+### Objective
 
-## Validation
+State the single outcome delivered by this stage.
 
-List the commands, tests, or inspections that demonstrate completion.
+### Preconditions
 
-## Progress
+- List facts that must be true before editing begins.
 
-Keep only concise current state and blockers here. Git history should preserve
-obsolete execution detail.
+### Owning Repository
+
+`<repository path>`
+
+### Required Changes
+
+1. Describe concrete behavior to implement, including relevant files or
+   components where known.
+2. State invariants, compatibility requirements, and explicit exclusions.
+
+### Validation
+
+Run:
+
+```text
+<exact validation command>
+```
+
+Expected result: describe the required observable outcome, not merely a zero
+exit code.
+
+### Completion Criteria
+
+- List the evidence required before this stage is complete.
+
+### Commit
+
+Commit intent: `<type and concise purpose>`
+
+## Stage 2: <Next Independently Verifiable Outcome>
+
+Repeat the complete stage structure above. Add, remove, or split stages so
+each is ordered by dependency, reviewable on its own, and small enough to
+diagnose without repeating unrelated work. Continue with `Stage 3`, `Stage 4`,
+and subsequent consecutive integers as needed.
+
+## Final Validation and Handoff
+
+- Run cross-stage and cross-repository validation required by the feature
+  roadmap.
+- Confirm every changed repository is clean and identify all resulting commit
+  hashes.
+- Summarize deviations from this plan, unresolved findings, and deferred work.
+- Do not mark the feature `done`; implementation results require review first.
+
+## Progress Notes
+
+Keep only concise current state, completed stage references, and blockers here.
+Git history and implementation commits should preserve detailed execution
+evidence.