Gate: spec-feature-match
Every requirement declared in the spec has a scenario in the feature.
| Property | Value |
|---|---|
| Checker | spec-feature-match |
| Confronts | spec |
| Blocking by default — new project | yes |
| Blocking by default — existing project | no — informs |
How it measures
Section titled “How it measures”Confronts the edge of the unit that had no watcher: the spec declares a requirement — is there any scenario that exercises it?
feature-test-match confronts feature→test; unit-complete confronts that the PIECES
exist. Nobody confronted spec→feature — and that is where a silent hole lives: the spec
declares a constraint rule, the feature has no scenario carrying its tag, and the requirement
crosses the whole pipeline with nothing verifying it. Every gate stays green: the spec
has a code, the feature exists, the feature matches the test. The requirement simply
belongs to nobody.
Measured in a real project: 11 of 287 specs with a feature had a requirement with no scenario.
The ruler is the same as the other relational gates — CODE, not prose: every
{CODE}-{letter}{NN} the spec DEFINES must appear as a scenario tag in the feature.
Defining is different from citing: a spec that mentions another unit’s code (in a
Dependency Table, for instance) contracts no obligation. Without that distinction the
gate would be a noise generator and would be switched off.
Honest opt-out (CONCEPT §5.1): the per-requirement waiver marker (no-scenario, prefixed with @) on the requirement’s line, followed by a colon and the reason, waives
that specific requirement, with the reason written. It serves what is genuinely not
observable by scenario — and leaves the trace that it was a decision, not forgetfulness.
Declaring it
Section titled “Declaring it”gates: - name: spec-feature-match on: [spec] check: spec-feature-match