e2e-setup

# Set up an e2e test suite E2e tests verify the whole running system *through the app* (browser/API), not one module. They are the per-PR gate. Pairs with `dev-local-setup` (a reproducible local stack) and `verifier-setup` (which scaffolds the repo's `/verify` skill — the verify→ship loop this gate feeds into). ## Where it lives - **Unit/integration tests** stay inside each app/package — they own one module. - **System e2e** is a dedicated top-level package (e.g. `e2e/`) — it spans all apps, so it belongs to none. Add it to the workspace if a monorepo. ## The recipe 1. Stand the app up reproducibly — see `dev-local-setup`. The e2e suite **never boots the app itself**; it runs against the already-running stack. That stack can be **local** (`dev-local-setup`) **or an isolated cloud box** (`crabbox-setup`) — same specs, run against either. For **parallel agents** use the cloud box (one laptop can't host concurrent stacks). 2. Pick the framework that fits (Playwright for browser; your HTTP client for API). Turn on **video + trace** — the recording is the proof, and it's gitignored output. 3. **Explore the flow live first** (don't guess selectors), then crystallize it into a committed spec. 4. Keep the gate **small**: a handful of critical journeys, deterministic. Each new feature PR adds its spec — the suite compounds. ## Practices that make e2e trustworthy - **Real flow, not bypass.** Drive the genuine path. For email codes / OTP, read the real code ...