phase-planninglisted

# Phase Planning Produce two artifacts before implementation begins. **Outputs:** `plans/<phase>/PLAN.md` and `plans/<phase>/LANDING-ARCHITECTURE.md` (v0). ## Landing architecture An *estimate* of the system state after the phase completes, written before it starts. Its value is the diff: at each sub-phase boundary you update it with measured actuals, and the gap between v0 and vN is the most honest signal you have about estimation quality. ```markdown # Landing Architecture — <phase> v0 (estimate) ## Sub-phase execution sequence | Sub | Title | Depends on | Parallel-safe | Blast radius | | :-- | :---- | :--------- | :------------ | :----------- | ## Expected schema state ## Expected capabilities (what the next phase may depend on) ## Expected infrastructure state ## Architecture law updates (rules this phase adds or changes) ## Parallel execution constraints ## Open questions for the next phase ## Measured actuals (empty at v0; filled at each boundary) ## Version history | Version | After sub | Changed | Why | ``` ## Planning rules - **One surface concern per sub-phase.** A sub-phase touching auth *and* the data model is two sub-phases. - **Name the planes each sub-phase crosses.** This list is what the gates are run against later. An unnamed plane is an unreviewed plane. - **Declare blast radius up front.** The author's estimate; the reviewer may revise it. Declaring early forces the scope conversation before code exists. - **State wh