ui-iteratelisted

# ui-iterate — look at what you built before calling it done UI edited blind is UI shipped broken. Code that compiles says nothing about what renders. This loop forces the screenshot-critique-fix cycle that separates polished frontends from plausible ones. Run it after every meaningful UI change, before declaring the task done. ## The loop 1. **Find the live page.** Locate the dev server: check for a running process on common ports (3000, 5173, 4321, 8080), `$CONDUCTOR_PORT`, or the `dev` script in package.json (start it if the repo has one and nothing is running). Identify the route your change affects. 2. **Screenshot three widths.** Using the browser tools (claude-in-chrome; `resize_window` then `computer` screenshot), capture the affected page at: - 375px — phone - 768px — tablet - 1440px — desktop If browser tools are unavailable, use a headless fallback (`npx playwright screenshot` or agent-browser) — never skip the looking step because the preferred tool is missing. 3. **Critique what you see.** Judge the screenshots, not the code, against: - **Hierarchy** — is the most important element visually dominant? Does the eye land where the page's job says it should? - **Spacing** — consistent scale (4/8px grid), no cramped clusters or orphaned gaps, breathing room around groups. - **Typography** — clear size/weight contrast between levels; line length 45–75ch; no near-identical sizes competing. - **Contrast & accessibil