Gate: rule-implemented
Every rule the spec catalogs is marked in its code target, unless waived on its line with @no-mark: <reason>.
| Property | Value |
|---|---|
| Checker | rule-implemented |
| 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 spec against the code in the direction that was missing: did the spec end up talking to itself?
It is the inverse of the gate that validates references. That one checks that the codes CITED by the code exist in the spec; this one checks that the rules DECLARED in the spec got an implementation. Without it, a spec can declare five new rules and the code gain not a single line — with all gates green, because the spec exists, the code exists, and the two reference each other through the header.
Measured: an interface spec gained five rules and 98 lines, and the corresponding file had ZERO occurrence of the subject. Half of the delivery was dead code declared as done, and none of the 26 gates asked. The defect only showed up when someone read spec and code in the same pass.
The ruler is the declaration, not the guesswork. Demanding every rule be marked would be false by construction — measured against 592 units, it would yield 3.121 findings, and not even the well-made units would pass: among those that mark the code, none marks 100%. The reason is a good one: a constraint (“the unit does NOT do Y”) is satisfied by the ABSENCE of code, and absence has nowhere to receive a mark. But “at least one” does not serve either — it separates those who implemented from those who did not implement and says nothing about the other fifteen rules. So whoever writes the spec DECLARES, rule by rule, whether it has code.
Declaring it
Section titled “Declaring it”gates: - name: rule-implemented on: [spec] check: rule-implemented