Gate: vr-scenarios-of-states

Every visual-regression scenario of the unit is of a state its spec registers.

Property	Value
Checker	vr-scenarios-of-states
Confronts	code
Blocking by default — new project	yes
Blocking by default — existing project	no — informs

How it measures

A state is what a screen or a component looks like under a condition, and a visual capture is what keeps it looking so. An agent setting up a project with screens wrote specs with states, features and unit tests, and no visual regression at all — every gate green, and no state of any screen protected against a visual change. vr-baseline only asked a VR scenario that exists for its image.

Four gates ask the four questions that tie a state to its capture, both ways:

Gate	Question
vr-states-covered	Does every state of the spec have a VR scenario in the feature?
vr-scenarios-tested	Does every VR scenario have a VR test, and a baseline image?
vr-scenarios-of-states	Is every VR scenario of a state the spec registers?
vr-tests-of-scenarios	Is every VR test of a VR scenario the feature declares?

Every state of a screen or a component is asked for a capture — only visual units are confronted at all. The exception is written where the state is: @no-vr: <reason> on its heading or its row, for a state with no visual value of its own, such as a transient loading or a state that looks like another. An exemption with no reason does not exempt.

They run on a visual unit’s main code file — the screen or the component, which is what a project tags as visual — and read the unit’s spec, feature and tests from it (Button.tsx → Button.spec.md, Button.feature). A VR scenario is a scenario tagged with the project’s visual regime and the code of the state it captures (@{CODE}-S01 or @{CODE}-VR-S01). A VR test names {CODE}-VR-S01 in its path or its text. A baseline is <Unit>.{CODE}-VR-S01[-variant].<ext> beside the unit.

Declaring it

gates:
  - name: vr-scenarios-of-states
    on: [code]
    check: vr-scenarios-of-states

Source: checker · its spec