Gate: scenario-letter-declared
Every scenario code’s letter is a rule letter — the project’s rule_types, or the canonical ones.
| Property | Value |
|---|---|
| Checker | scenario-letter-declared |
| Confronts | feature |
| Blocking by default — new project | yes |
| Blocking by default — existing project | no — informs |
How it measures
Section titled “How it measures”Confronts a scenario code against the project’s own vocabulary: does the letter it carries mean anything?
The project declares which letters it recognises, and a sibling gate charges the spec’s SECTIONS for using the right ones. Nobody charged the same of the code a SCENARIO carries — and an invented letter passes every other gate. The code matches itself across feature and test, the unit is complete, the relational gates find both ends of the edge, and nothing notices that the letter means nothing.
Measured in the project that originated this gate: 18 codes carrying five undeclared letters, always accompanied by tags equally outside the vocabulary. The pattern is recognisable once seen — someone needed a nature the project did not have and invented it instead of declaring it.
Both repairs are legitimate, and the choice belongs to the project: declare the letter (if the nature is genuinely missing) or remap the scenario onto a letter that already exists (if it was only an alias for one). The gate does not choose — it shows what is outside.
That is why the verdict is UNDETERMINED and not a failure. Discovering that a nature was used without registration is information; deciding between adopting it and remapping it is work for whoever knows the domain.
Declaring it
Section titled “Declaring it”gates: - name: scenario-letter-declared on: [feature] check: scenario-letter-declared