plan-review

# Plan Review Improve a plan by attacking its load-bearing assumptions while course correction is still cheap. ## Review Boundary - Review only unless the user explicitly requests revisions or implementation. - Read the plan, its source requirements, repository reality, and available evidence. Do not review a summary when the full artifact is available. - Steelman the intended outcome before criticizing the approach. - Prefer five decision-changing findings over a long generic risk list. - Do not inflate scope in the name of ambition. The strongest review may recommend a smaller plan, a cheaper test, or no build. - Separate verified conflicts, evidence-backed risks, assumptions, and questions. ## Lenses Apply the lenses relevant to the plan and name which were used: - **Founder:** Target user, painful job, wedge, why now, distribution, switching, monetization, defensibility, and kill assumptions. - **Product:** Journey completeness, independent value, success metrics, guardrails, accessibility, trust, support, and learning loop. - **Engineering:** Architecture, data flow, interfaces, invariants, failure handling, security, privacy, performance, compatibility, and maintainability. - **Delivery:** Dependency order, vertical slices, test seams, migrations, observability, rollout, rollback, operational ownership, and authority boundaries. ## Workflow 1. **Reconstruct intent:** State the desired outcome, non-goals, constraints, evidence, and proof required for completion. ...