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. `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 screenshot Almost never. Reach for one only when: - A route is canvas, WebGL, or PixiJS. The accessibility tree is blind to pixels drawn on a canvas, so text and console checks cannot see the actual render. - You are chasing a visual or layout regression (overlap, spacing, z-in