Gate: validation-transitions
Every validation of a visual unit is the trigger of a state transition, or says @no-state: <reason>.
| Property | Value |
|---|---|
| Checker | validation-transitions |
| Confronts | code |
| Blocking by default — new project | yes |
| Blocking by default — existing project | no — informs |
How it measures
Section titled “How it measures”A validation changes the screen: the form refuses, a field turns red, a button disables, the flow takes another path. Each of those is a state, and the states are already proven by their visual capture. So a validation does not need a capture of its own; it needs to say which state it leads to. An error, too, shows on the screen — as the message the spec catalogs; the state is the same, what changes is the text, and the messages are captured.
Two gates tie each change of a visual unit to what the screen shows:
| Gate | Question |
|---|---|
validation-transitions |
Is every validation the trigger of a State Flow transition, from the state it is checked in to the state it leads to — or does it say @no-state: <reason>? |
error-message-declared |
Does every error name the message it shows — or say @no-message: <reason>? |
They run, like the visual-regression gates, on a visual unit’s main code file and read the spec beside it; sections and columns are read in any language of the catalog.
Declaring it
Section titled “Declaring it”gates: - name: validation-transitions on: [code] check: validation-transitions