Gate: scenario-type-aligned

A scenario’s nature tag agrees with the letter of its code.

Property	Value
Checker	scenario-type-aligned
Confronts	feature
Blocking by default — new project	yes
Blocking by default — existing project	no — informs
Presupposes	rule_types — until these are declared in anchors.yaml, the gate is pending and asks nothing

How it measures

Confronts a scenario’s classification tag against the nature letter embedded in its identity code: the classification tag of a scenario must agree with the rule letter of its code.

The nature of a rule is declared twice: once in the letter embedded in its identity code (such as S for State or B for Behavior) and once in the scenario’s classification tag (such as @state or @behavior). When the two disagree, one of them lies — and no other gate catches the contradiction because each inspects only a single facet:

• rule-types validates that specification sections conform to the declared rule vocabulary;
• feature-test-match pairs scenario identity codes and descriptions against test cases. Neither gate cross-references the scenario’s Gherkin classification tag against the code’s embedded letter.

Measured in doctrine: in the project that originated this gate, 46 scenarios exhibited tag and letter disagreements upon audit. Distinguishing between the two failure modes is essential:

• 36 were wrong tags: for instance, “Intro present is rendered in italics” had the body When the component is rendered / Then I should see the intro text — pure state without user action, under a correct -S code, but tagged @behavior. The remediation was correcting the tag.
• 10 were borrowed codes: for instance, “Tapping a chip selects priority” was genuine interactive behavior, attached to a -S code because the specification had not catalogued the event. The remediation was creating a dedicated code in the events table.

This gate detects both cases. Deciding whether the tag was misapplied or the code was borrowed requires reading scenario steps and understanding domain context. The gate guarantees that the divergence does not remain silent.

The gate issues a Pending verdict rather than a blocking Fail: type mismatch represents inherited technical debt in codebases adopting this gate after scenarios were already written, and resolving each finding requires case-by-case editorial judgment.

Furthermore, if the project configuration defines no tags: mappings in its rule types, the gate skips silently. Guessing tag meanings across different project languages would introduce false alarms; silence here respects projects that did not request this check.

Declaring it

gates:
  - name: scenario-type-aligned
    on: [feature]
    check: scenario-type-aligned

Source: checker · its spec