drive-uxlisted

# drive-ux - exercise the feature in a real browser Produces screenshots and a written report; does **not** edit code. ## Phase 0 - Decide what to walk drive-ux can be pointed at one of three things, in priority order: 1. **An explicit feature / route**: `/drive-ux /checkout` or `/drive-ux "the new settings sidebar"`. Use this directly. 2. **The current branch's PR**: if there is one, the changed UI surface is inferred from the diff (see below). 3. **Local uncommitted changes**: `git diff HEAD` - useful when iterating pre-PR. To infer the changed surface from a PR: ```bash gh pr diff --name-only | grep -E '\.(tsx?|jsx?|vue|svelte|astro|html|css|scss)$' ``` Then for each touched component file: - Grep for `<ComponentName` in `app/`, `pages/`, `src/routes/`, `src/pages/` to find which routes render it. - If the file IS a route file (Next/Remix conventions, `app/.../page.tsx`, `pages/...tsx`, `src/routes/...`), that route is in scope directly. - If multiple routes mount it, prioritise the one that appears in the PR description, then the most-trafficked path (heuristic: shorter URL wins; e.g. `/settings` over `/admin/internal/settings`). Build a short list of (route, scenario) pairs to walk. A scenario is a specific narrative - "logged-in user, has data, opens drawer, edits field, saves." Aim for 1–3 scenarios per route: one golden path, plus the highest-value edge cases (empty, error, loading). ## Phase 1 - Start the app Find the dev command. Check in