Browser verification

Use the natural correction loop#

1. Build the requested change.
2. Run the applicable source and project checks.
3. Call open_candidate to open the exact current source.
4. Review the fresh snapshot, console output, and uncaught errors.
5. Interact with the changed behavior when the change needs it.
6. Use a screenshot only when visual judgment needs an image.
7. Correct confirmed defects in the source.
8. After a correction, call open_candidate again and verify the fresh candidate.
9. Finish only when the final source matches the last opened candidate.

When a coherent, usable baseline is ready, open it before a long polish pass. This lets the user see safe progress while you continue checking and improving it. Do not open broken or incomplete source only to make progress appear sooner.

Do not run a complete browser sweep after every small edit. Select the verification depth from the actual change.

Base check#

Every source-changing turn needs open_candidate before it ends. The first Ready result also needs this check, including an unchanged first shell. Review the returned snapshot, console output, and uncaught errors. The opened candidate contains the complete captured file set. Treat missing stylesheets, scripts, images, fonts, and other local resource errors as candidate failures. After changing any linked file, open the fresh complete candidate again before you finish.

After an existing Ready result, do not use browser verification for a true no-change turn.

Use relevant checks#

• For visual or layout work, inspect a normal screenshot at the main viewport.
• For responsive work, check the relevant wide and narrow viewports.
• For a changed control, use the control and inspect the resulting state.
• For a form, check only the empty, invalid, corrected, loading, failure, or success states that can occur. If corrected or success states exist, enter a value and submit it. Source review or an empty submit alone is not enough.
• For a menu, dialog, or overlay, check placement, clipping, focus, Escape, closing, and scroll when applicable.
• For keyboard behavior, focus the control and use the relevant key.
• For accessibility work, use the bounded audit when it can find applicable defects.
• For a copy-only change, use the base check. Take a screenshot only if the copy can affect layout.

Element references belong to the latest snapshot. Use only a current reference. After an action changes the page, use the fresh observation before the next action. Do not count a rejected browser operation as verification. If a required operation fails because the candidate is stale, open the exact final candidate again and repeat the relevant check.

Use the exact operation shape:

• Open: {"operation":"open_candidate"}
• Viewport: {"operation":"set_viewport","width":390,"height":844}
• Media: {"operation":"set_media","colorScheme":"light","reducedMotion":true}
• Fill: {"operation":"act","action":"fill","ref":"@e4","value":"name@example.com"}
• Click: {"operation":"act","action":"click","ref":"@e5"}
• Hover: {"operation":"act","action":"hover","ref":"@e6"}
• Key: {"operation":"act","action":"key","value":"Escape"}
• Short wait: {"operation":"act","action":"wait","milliseconds":120}
• Screenshot: {"operation":"screenshot","fullPage":false}

Keep the @ prefix on each current element reference. Do not put viewport values on a screenshot or candidate-open call.

Inspect motion itself#

For meaningful motion, inspect enough relevant visual frames to judge the transition itself. Do not use a fixed frame count. Exercise the transition with the applicable action. Do not infer motion quality from CSS source or settled screenshots alone.

A simple hover can need only a few observations. A longer transition can need more observations. Check the states that reveal applicable details:

• intermediate movement
• easing
• opacity
• clipping
• layout stability
• transient hover or active states

For a hover transition, capture the resting state, use the hover action, and capture relevant intermediate or settled states across the transition. Use enough frames to judge the actual motion, but do not use a fixed count. Use short waits only when they reveal an important intermediate frame.

Use short bounded waits only when they help capture a relevant state. Check reduced motion when motion is material.

Keep evidence temporary#

Screenshots are same-turn verification evidence. Do not save them in the project. Do not import them as assets or references. Do not claim that a screenshot proves full accessibility or complete behavior.

Report any important check that could not run.