Browser Verification
Trust the browser, not static guesses. Use real rendering for frontend claims.
Setup
Prefer the repo's existing Playwright setup. If none exists, install browser tooling in a local tool directory or temporary environment rather than adding a production dependency.
Use a local static or dev server when file URLs would not match production behavior.
For security review of live targets, request routing through authorized-security-router first so scope, allowed actions, and non-destructive boundaries are explicit.
Verification Loop
- Start the app or static server.
- Open the target URL in a browser-controlled session.
- Check console errors and failed network requests.
- Verify key selectors render and have nonzero bounding boxes.
- Verify images/assets are complete and natural dimensions are nonzero.
- Check desktop and mobile viewports.
- Check horizontal overflow:
document.documentElement.scrollWidth <= innerWidth + 1. - Exercise the primary interaction path.
- Capture screenshots only when useful for review or debugging.
- Stop local servers before finalizing.
Common Assertions
- page loaded with expected title or heading;
- no failed requests for CSS, JS, images, fonts, or data;
- no severe console errors;
- target controls are visible and enabled;
- form submission or navigation reaches expected state;
- responsive layout has no text overlap or horizontal scroll;
- animated/canvas/3D surfaces have nonblank rendered pixels when relevant.
Guardrails
- Do not commit local Playwright tooling unless the repo already owns browser tests.
- Do not claim visual verification if only static checks ran.
- If browser install fails, report the fallback checks honestly.
- For authenticated or paid flows, avoid real side effects unless explicitly approved.
Final Report
Include URLs, viewports, checks run, commands, failures found, and whether screenshots were captured.