Browser Verification

Browser verification

Reading the source is not verification. A component that compiles, type-checks and looks right in the diff can still render blank, overflow its container, or throw on mount.

When this fires

After any change to rendered UI, before that change is reported as working — your own work or someone else's. It does not fire for a change with no rendered surface. One change, checked once, is this skill; a matrix of states across viewports and themes, or a comparison against a screenshot baseline, is visual-verification.

Procedure

1. Get it running. Start the dev server or open the deployed URL. If it will not start, that is the finding: report it and stop the verification — never verify a stale build. The work under test is then reported as unverified, not as failed.
2. Render the route that changed, not the home page. Wait for network idle before judging.
3. Read the console and network first, before looking at pixels. An error here explains most of what you are about to see. Record the exact message, not "some errors".
4. Inspect desktop. Screenshot. Does the intended change appear; is anything clipped or overlapping; does content overflow; did images and fonts load.
5. Inspect mobile. Resize to 375×812 and reload — layout-time breakpoints and device gates do not re-run on resize alone. Same checks, plus: horizontal scrolling, tap-target reachability, text legibility.
6. Operate every control the change touches. Click the primary action, submit the form, open the menu, type in the input. A control that renders and does nothing is the most common failure this procedure exists to catch.
7. Reach the states that are not the happy path — empty, loading, error, long content — by the cheapest honest route available.
8. Re-read the console after interacting. Errors thrown on click do not appear on load.
9. Fix what you found, then start again from step 2. A fix is not verified by the reasoning that produced it.

Checklist

• The changed route was rendered, not just built
• Desktop screenshot taken and read
• Mobile viewport reloaded and read
• Every control the change touches was actually operated
• Console checked on load and again after interaction
• Empty / loading / error states reached, or named as unchecked
• Everything still unverified is named in the report

Failure handling

• Server will not start, or the URL is unreachable — that is the result. Do not fall back to reading source and calling it verified.
• Screenshot looks right but a control does nothing — trust the interaction, not the picture. Check the console: a handler that throws renders identically to one that works.
• The failure will not reproduce — say so, with what you tried. An intermittent failure reported as fixed is worse than one reported as intermittent.
• No browser tooling available — say rendered verification could not be performed, name what you did check, and do not call the change verified. Degrading honestly beats a false pass.

Evidence to report

The route and viewports checked; what each control did when operated; console output quoted, or "clean" if it genuinely was; screenshots where they show what words cannot; and the list of states and paths not checked. "Verified in the browser" with none of that is not evidence.

See references/driving-the-browser.md for which tool to reach for.