Gate: marker-parity
Not in the default catalog: init does not seed it; a project declares it with check:.
| Property | Value |
|---|---|
| Checker | marker-parity |
How it measures
Section titled “How it measures”Confronts a rule that lives in TWO places at once: the promise at one end, and the fulfilment at the other — are they still the same rule?
The defect class is the mapping that comes undone on one side only. A rule split across two ends cannot be checked by any per-file gate: each side, looked at alone, is impeccable. What breaks is the RELATION, and it disappears without leaving an error.
The case that motivated it, measured (reference app, EXSC-Q01): the data-deletion page LISTS
what will be erased in each scope, and the backend ERASES. The two lists were born
together and nothing binds them. If a scope starts erasing more (or less), the page goes
on showing the old version — and the data subject consents on the basis of it. That is
informed consent over the exercise of a right, so the mismatch is not cosmetic.
This gate is GENERIC on purpose, and that is what separates it from every neighbour.
It is not canonical: a project may declare SEVERAL instances of it, each with its own
id, its own marker_prefix and its own marker_scopes. What it confronts is a
decision of the project — WHICH rules live at two ends — and that decision does not fit
a universal catalogue. Every other gate in the framework asks a question the framework
itself wrote; this one asks the question the project wrote.
The suffix after the prefix is the NAME of the rule, and it is the name that pairs the
ends. Two markings on the same side do NOT satisfy the gate: marker_scopes exists
precisely because counting without looking WHERE would let through the very case the
gate exists to catch.
Declaring it
Section titled “Declaring it”gates: - name: marker-parity check: marker-parity