frontend-verifylisted

# Frontend Verify ## What this replaces The slow loop is: edit code, start the dev server, open a browser, click each page, watch the console, eyeball the layout, repeat. This skill does that pass programmatically with `@playwright/cli` running headless, and it does it without dumping every page state into the model context. ## The one principle that matters Reading a full accessibility snapshot or a screenshot into context on every route is the expensive part, not running the browser. So the order of operations is always cheapest signal first: 1. Console errors and failed network requests. Tiny text, catches most real breakage (crashed component, bad fetch, 500 from an API route). 2. Targeted text assertions. Ask the page "is the word Dashboard on screen", not "give me the whole DOM". 3. A snapshot written to disk, read back only for a route that already failed. 4. A screenshot, only as a last resort. For a single page (a deployed URL, a marketing page, a page outside this repo's route list) step 2 is `curl -s <url> | grep -c <text>` for the words and `declick web tree <url> --selector <css> --limit 20` for the links, buttons and inputs as JSON: no snapshot, no screenshot. `verify-routes.mjs` runs steps 1 and 2 across all changed routes in one browser pass, writes the detail to disk, and prints a compact PASS / WARN / FAIL table. You read the table, then open detail files for flagged routes only. Do not read detail for routes that passed. ## When to take a scre