Create validation plan

Create Validation Plan

Scope

Generates the validation plan FILE (e2e-evidence/validation-plan.md). Does NOT run validation (use e2e-validate), write gates into a deepest-plan PLAN.md (the deepest-plan skill itself does that), or check evidence (use gate-validation-discipline).

Why This File Exists

Without an upfront PASS-criteria contract, validation devolves into "browsing the app and hoping it looks right." The plan file is the arbiter: every gate verdict references the plan's criteria.

Plan Structure

# Validation Plan
**Project:** {name}
**Platform:** {ios|web|api|cli|fullstack}
**Created:** {YYYY-MM-DD HH:MM}
**Evidence dir:** e2e-evidence/
**Status:** DRAFT | APPROVED

## Prerequisites
- [ ] {every condition that must be true before validation starts}

## Journey Inventory
| ID  | Journey                | Priority | Depends on | Status  |
|-----|------------------------|----------|-----------|---------|
| J1  | Signup with email      | P0       | —         | pending |
| J2  | Login                  | P0       | J1        | pending |
| J3  | View dashboard         | P0       | J2        | pending |
| J4  | Edit profile           | P1       | J2        | pending |
| J5  | Password reset         | P1       | J1        | pending |

## Journey Details

### J1 — Signup with email
**Steps:**
1. Navigate to /signup
2. Enter unique email + password
3. Submit
4. Redirect to /verify-email

**PASS criteria:**
- POST /signup returns 201 with `user.id` non-null
- Email row exists in users table with matching email
- Redirect location header = /verify-email

**Evidence:**
- e2e-evidence/j1-signup-response.json
- e2e-evidence/j1-db-user.txt
- e2e-evidence/j1-redirect.txt

**Capture commands:**
- `curl -s -o e2e-evidence/j1-signup-response.json -w "%{http_code}\n%{redirect_url}" ...`

## Execution Order
J1 → J2 → J3 → J4 (in parallel with J5 allowed)

## Summary
- P0: 3 journeys (must pass to ship)
- P1: 2 journeys (should pass)
- P2: 0 journeys

PASS Criteria Rules

Every criterion MUST satisfy all 8 of these.

Rule	Bad	Good
Specific	"Login works"	"POST /login returns 200 with token field"
Measurable	"Fast"	"DOMContentLoaded < 2s at p95"
Observable	"Saves correctly"	"GET /users/1 returns updated name"
Complete	Happy path only	Happy + error paths
Ordered	Dashboard before login	Login PASS before dashboard starts
Evidence-mapped	No proof method	"Screenshot shows 3 metric cards"
Non-redundant	"Login works and dashboard loads"	Separate criteria
Falsifiable	"App doesn't crash"	"Navigate 5 screens, zero console errors"

Journey Discovery

Scan the codebase for candidate journeys by platform:

• Web: routes in src/pages/, src/app/, src/routes/ + forms in components
• API: route handlers in src/routes/, src/api/, OpenAPI spec, app.get() / fastify.route() calls
• iOS: NavigationLink, NavigationDestination, deep-link schemes, UISceneDelegate handlers
• CLI: subcommand definitions in clap::Command, cobra.Command, argparse.add_subparsers()

Rule of thumb: every route = at least one journey; every form = a user-interaction journey.

Quality Checklist

Before starting evidence capture, verify ALL:

• Every journey has unique ID (J1, J2…) and priority (P0 / P1 / P2)
• Every journey has explicit steps with expected outcomes
• Every journey has ≥ 2 PASS criteria
• Every criterion is specific, measurable, observable, evidence-mapped
• Error paths covered (not just happy)
• Dependencies documented and execution order respects them
• Prerequisites list everything needed before validation starts

Rules

1. Plan MUST be created before any evidence capture begins
2. Plan saved to e2e-evidence/validation-plan.md (persistent)
3. PASS criteria must be falsifiable
4. Never skip journey discovery — missing journeys = ship gaps

Security Policy

Plans must never contain secrets, credentials, or PII. Use placeholders like [TEST_USER_EMAIL] for test credentials.