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
- 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.
- Render the route that changed, not the home page. Wait for network idle before judging.
- 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".
- Inspect desktop. Screenshot. Does the intended change appear; is anything clipped or
overlapping; does content overflow; did images and fonts load.
- 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.
- 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.
- Reach the states that are not the happy path — empty, loading, error, long content — by the
cheapest honest route available.
- Re-read the console after interacting. Errors thrown on click do not appear on load.
- Fix what you found, then start again from step 2. A fix is not verified by the reasoning
that produced it.
Checklist
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.
1---2name: browser-verification3description: Prove a UI change actually renders and works — desktop and mobile, controls operated, console clean. Use before reporting any change to rendered UI as done, when asked whether a screen actually functions, or when checking someone else's frontend work. Not for judging whether a design is good, and not a substitute for tests you intend to keep.4---56# Browser verification78Reading the source is not verification. A component that compiles, type-checks and looks right in9the diff can still render blank, overflow its container, or throw on mount.1011## When this fires1213After any change to rendered UI, before that change is reported as working — your own work or14someone else's. It does not fire for a change with no rendered surface. One change, checked15once, is this skill; a matrix of states across viewports and themes, or a comparison against a16screenshot baseline, is `visual-verification`.1718## Procedure19201. **Get it running.** Start the dev server or open the deployed URL. If it will not start, that21 is the finding: report it and stop the verification — never verify a stale build. The work22 under test is then reported as unverified, not as failed.232. **Render the route that changed**, not the home page. Wait for network idle before judging.243. **Read the console and network first**, before looking at pixels. An error here explains most25 of what you are about to see. Record the exact message, not "some errors".264. **Inspect desktop.** Screenshot. Does the intended change appear; is anything clipped or27 overlapping; does content overflow; did images and fonts load.285. **Inspect mobile.** Resize to 375×812 and **reload** — layout-time breakpoints and device gates29 do not re-run on resize alone. Same checks, plus: horizontal scrolling, tap-target reachability,30 text legibility.316. **Operate every control the change touches.** Click the primary action, submit the form, open32 the menu, type in the input. A control that renders and does nothing is the most common failure33 this procedure exists to catch.347. **Reach the states that are not the happy path** — empty, loading, error, long content — by the35 cheapest honest route available.368. **Re-read the console** after interacting. Errors thrown on click do not appear on load.379. **Fix what you found, then start again from step 2.** A fix is not verified by the reasoning38 that produced it.3940## Checklist4142- [ ] The changed route was rendered, not just built43- [ ] Desktop screenshot taken and read44- [ ] Mobile viewport reloaded and read45- [ ] Every control the change touches was actually operated46- [ ] Console checked on load and again after interaction47- [ ] Empty / loading / error states reached, or named as unchecked48- [ ] Everything still unverified is named in the report4950## Failure handling5152- **Server will not start, or the URL is unreachable** — that is the result. Do not fall back to53 reading source and calling it verified.54- **Screenshot looks right but a control does nothing** — trust the interaction, not the picture.55 Check the console: a handler that throws renders identically to one that works.56- **The failure will not reproduce** — say so, with what you tried. An intermittent failure57 reported as fixed is worse than one reported as intermittent.58- **No browser tooling available** — say rendered verification could not be performed, name what59 you did check, and do not call the change verified. Degrading honestly beats a false pass.6061## Evidence to report6263The route and viewports checked; what each control did when operated; console output quoted, or64"clean" if it genuinely was; screenshots where they show what words cannot; and the list of states65and paths **not** checked. "Verified in the browser" with none of that is not evidence.6667See `references/driving-the-browser.md` for which tool to reach for.
nahid-sparktales