Quality & readiness · Verify
Visual Regression Check
Verify the selected rendered change against accepted behavior and visual references for supported states and viewports.
MCP library 1.6.1 · Instruction library 1.6.1 · English technical instructions
← Back to searchUse this workflow
Connect Vibe Coding Library to a coding agent that supports MCP over Streamable HTTP. Choose Other / MCP agent for a neutral prompt, or a ready-made Codex or Claude Code invocation. Add your task details below.
Operation
Verify the selected behavior against explicit expected results; do not change product code.
Goal
Verify the selected rendered change against accepted behavior and visual references for supported states and viewports.
Context
Identify the selected change, affected routes/components/states, supported browsers/viewports and existing visual references. Use the project’s rendering and test tools.
Scenarios
Select the cases that test the requested guarantee. Define expected state/effects before execution; use the authorized environment and a valid control.
- Render loading, empty, error, success, validation, disabled, permission, long-content, localization, reduced-motion, and dark/high-contrast states when applicable.
- Compare responsive layout, overflow, focus order/visibility, keyboard interaction, semantic/accessibility tree, and pointer/touch targets.
- Use deterministic data, fonts/assets, animation disabling, stable viewport, and documented screenshot masks only for proven nondeterminism.
- Review baseline changes semantically; never bulk-accept screenshots to make the suite green.
- Correlate visual diffs with DOM/style/component changes and run interaction/a11y assertions for behavior that pixels cannot prove.
Verification
Report actual rendered differences and interaction results; identify any missing renderer or baseline. A code-only inspection cannot establish visual equivalence.
Fix the candidate, data, viewport and expected behavior before capturing evidence. Compare the failed state and a nearby normal state using the same rendering conditions. Separate intentional changes from regressions by the accepted interaction/design contract, rather than accepting every new screenshot.
Pass a failed result to the component/token/state owner with its reproduction, rendered evidence and expected observation. If repair is authorized, rerun that state after correction and check directly affected interactions before Patch Checking. If no comparison baseline exists, report the rendered constraints actually verified instead of claiming pixel equivalence.
Workflow ID: visual-regression-check · View the versioned source · Shared workflow and authority rules