phase-executionlisted

# Phase Execution Drive a planned phase from implementation to commit, resuming cleanly after interruption. ## Why checkpoints exist Long agentic sessions get compacted. The conductor state is what lets a fresh context pick up mid-phase without re-deriving where it was. It is written **after every step**, not at the end — a state file that only exists at completion has no value. `plans/<phase>/.conductor-state.json`: ```json { "phase": "phase-04", "sub_phase": "04B", "state": "EXECUTING", "current_step": 3, "total_steps": 7, "steps": [ { "n": 1, "title": "...", "status": "done", "files_modified": ["..."] } ], "user_gates_passed": ["plan-approval"], "notes": "..." } ``` ## State machine | State | Meaning | Next | | :--- | :--- | :--- | | `PLANNED` | Plan approved, no sub-phase started | `VALIDATED` or `EXECUTING` | | `VALIDATED` | Design checked against the real codebase; drift recorded | `EXECUTING` | | `EXECUTING` | Implementation in progress; resumable at `current_step` | `REVIEW_PENDING` | | `REVIEW_PENDING` | Built; review not yet run | `REVIEWED` | | `REVIEWED` | Gates passed and smoothness converged | `COMPLETED` | | `COMPLETED` | Committed | next sub-phase, or `PHASE_COMPLETE` | **Review is mandatory.** `REVIEW_PENDING` cannot transition directly to `COMPLETED`. Refuse the commit and say why. ## Validation before execution Check the plan's assumptions against the codebase as it exists now, and write a drift file recording what is aligned