Gate: ref-resolves
The ref: points at the sibling spec’s code:.
| Property | Value |
|---|---|
| Checker | ref-resolves |
| Confronts | code feature test |
| Blocking by default — new project | yes |
| Blocking by default — existing project | no — informs |
How it measures
Section titled “How it measures”Confronts an artifact against the spec co-located with it: the reference field is filled, but does it name the right owner?
The header gate verifies that the field EXISTS. Nobody verified that it points at the right place — and a wrong reference is worse than a missing one: it looks like traceability, the gate goes green, and the whole unit is attributed to the wrong spec. Every relational gate that depends on that edge starts confronting the wrong pair, in silence.
The characteristic failure mode is the REFACTORING nobody propagated. Measured on a real project: 49 model files still referencing the identity from back when all the models lived in a single file. After the split, each one got its own spec, and not one reference was updated. The 49 kept pointing at the whole schema, and nothing raised a hand.
The ruler: if a SIBLING spec exists — the one the Structure co-locates with this file — the reference must be that spec’s own identity. With no sibling spec the gate goes quiet: charging the absence of the piece is the unit gate’s job, and two gates accusing the same defect become noise.
Declaring it
Section titled “Declaring it”gates: - name: ref-resolves on: [code, feature, test] check: ref-resolves