Gate: code-cataloged

Every exported symbol has a rule in the spec or a written waiver.

Property	Value
Checker	code-cataloged
Confronts	spec
Blocking by default — new project	yes
Blocking by default — existing project	no — informs

How it measures

Confronts a spec against the code it governs, starting from the OTHER side: this symbol is public — does it have a rule?

It is the inverse of rule-implemented. That one starts from the spec and asks “does this rule have code?”; this one starts from the code. Without both, the divergence escapes on one of the sides — measured in a real project: a spec catalogued 2 rules for 7 exported functions, and no gate asked about the remaining 5.

Noise is not an argument for not building — and this line has already been wrong here. The earlier version said that charging a spec of every symbol would produce hundreds of legitimate-but-useless findings, and a gate that accuses everything is switched off. The fear was right; the conclusion was not. Compare the two outcomes: a granular gate switched off by the project does not protect, and the project KNOWS; a gate too coarse and left on does not protect either, and it reports GREEN. The outcome is the same; what changes is the honesty. And there is a decisive asymmetry: a noisy gate is CALIBRATABLE by whoever uses it, while a gate that is too coarse cannot be sharpened by the project — the decision was taken inside and there is no way to recover it. When in doubt between granular-with-noise and coarse-with-silence, the default is GRANULAR.

The same principle governs the language: the export pattern used to be TypeScript syntax built in, so in a Go, Python or Ruby project it matched zero symbols and the gate reported VERDE — stamping approval, with blocking: true, over what it had never read. Without knowing how to read, the gate goes quiet; it never approves.

Declaring it

gates:
  - name: code-cataloged
    on: [spec]
    check: code-cataloged

Source: checker · its spec