Gate: coverage-delta
Line coverage did not drop vs. the previous ingestion.
| Property | Value |
|---|---|
| Checker | coverage-delta |
| Confronts | code |
| Blocking by default — new project | no — informs |
| Blocking by default — existing project | no — informs |
How it measures
Section titled “How it measures”A project declares its gates in the Structure, and a gate that the CLI answers itself says only a NAME — the check it wants. Something has to turn that name into a function, and that something is this unit: the registry of internal checkers, plus the small checkers whose whole answer is reading text.
Why it is a registry and not a switch. The checkers do not all have the same signature, and the difference is not style. One reads only the content of the target. One also needs the project ROOT, because it has to invoke the version control system to answer. One needs the GRAPH, because the question crosses the unit — a feature against the test linked to it. One needs the declaring GATE itself, because the question is parameterised: a generic gate only knows what to look for after reading its own configuration, and a project declares several instances of it. Four registries, and the routing tries them in that order.
The measured defect this shape exists to prevent, and it is the one that costs most: a name that does not resolve must answer PENDING, never Pass. A checker that is declared and does not exist has not measured anything, and “I did not measure” is neither “it is clean” nor “it is dirty”. Approving here would stamp green over a verification that never ran, and the project would read coverage where there is none. The same reasoning drives the aggregate path: a batch or project scope checker that does not resolve answers Pending too, naming the check that failed to route.
Two routing paths, and the difference is not a detail. The per-node path READS THE TARGET FILE and fails when the read fails — a checker of content with no content has nothing to answer. The aggregate path does NOT: its scope is the SET, so there is no one file to read. It hands the checker an empty node and lets it orient itself by root and configuration. Trying to read a file there would return a read error, and the gate would fail over a file that never existed.
What separates this unit from its neighbours. The engine decides WHICH gates apply to which node and what the whole run concludes. The rule unit decides how a verification is named and whether it was waived. This one decides only WHICH FUNCTION answers, and holds the small checkers whose entire ruler is the text in front of them: the file is not empty, the file carries an identity code, the file carries a conformant header, the guide distils its rules into verifiable points.
The grammar of codes belongs to the project, not to the engine. The letters that name a rule type are declared in the Structure, and every pattern in this package that depends on them has to be reconfigured together. A pattern added without registering it there stays frozen on the canonical letters — and a scenario written with a letter the project declared becomes invisible to that gate, which then reports green over what it never looked at.
Declaring it
Section titled “Declaring it”gates: - name: coverage-delta on: [code] check: coverage-delta