ui-visual-self-review

UI Visual Self-Review

Overview

A change that compiles and passes its tests has not been looked at. The UI you're about to hand off is not done because the build is green or because you read the JSX and it looked right — it is done when you have screenshots at four widths that prove it.

Core principle: Default assumption: the change is NOT done until the screenshots prove it. Be the skeptic here, not the advocate — look for what's still wrong, not for confirmation that it's fine.

The procedure (exact tool calls)

1. Start the dev server detached, as your main instructions' "Seeing the change" section describes: mkdir -p /tmp/tt-<task key> && npm run dev > /tmp/tt-<task key>/dev.log 2>&1 &, then sleep 5; cat /tmp/tt-<task key>/dev.log to read the port.
2. browser_navigate to the changed page.
3. browser_wait_for the content that proves the page actually rendered (not a spinner, not a blank shell).
4. For each width in the four-width table, in order:
   • browser_set_viewport with the exact args from the table below.
   • Read its response: whether the page scrolls horizontally, and which elements overflow. That response is itself a finding — don't discard it once you've glanced at the screenshot.
   • browser_screenshot with full_page: true and no width argument (passing width here re-emulates the viewport and silently throws away the size you just set).
   • Look at the screenshot against the checklist below.
5. browser_read_dom with contains: "..." for each new element, to confirm it's actually present (and whether hidden) — this is not a substitute for looking at the screenshot, it's a second signal.
6. Drive the interactive states at phone width at minimum: open the mobile menu, an accordion, a dialog; submit a form with empty required fields and look at the errors.