Gate: scenario-identity
Each scenario code identifies one scenario: no code repeated and no body copied under another title.
| Property | Value |
|---|---|
| Checker | scenario-identity |
| 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 feature against the question that decides whether its scenarios can be paired at all: each scenario has a code, but does each code point at ONE scenario?
A rule legitimately has several scenarios — the happy path and its alternatives. What it cannot have is two that are INDISTINGUISHABLE. With the same code, nothing links one scenario to one test, and the relational gates end up comparing N titles against a single test: at most one matches, and the others become a divergence nobody can resolve.
The way out is the scenario SUFFIX. Numbering keeps the rule legible in the prefix and gives each case an identity of its own.
Measured on the project that originated the gate: 204 repeated codes, and 65 of them carrying CONFLICTING kind tags on the same code — one scenario tagged as state, the other as behaviour. That is the signature of a BORROWED code, not of a rule with two paths. One of them proved to be a real defect: the spec defined the rule as one thing, and the second scenario described a different behaviour that had no code of its own.
PENDING and not FAIL: numbering scenarios is a migration, and the gate is born over a base that did not know the notation. Whoever already migrated stays green; whoever did not sees what is left.
Declaring it
Section titled “Declaring it”gates: - name: scenario-identity on: [feature] check: scenario-identity