Gate: flag-covered
Each flag scenario has at least one green test.
| Property | Value |
|---|---|
| Checker | flag-covered |
| Confronts | flag |
| Blocking by default — new project | yes |
| Blocking by default — existing project | no — informs |
How it measures
Section titled “How it measures”A feature flag multiplies the paths of the code without multiplying the spec. A check of a flag’s value creates two behaviours, and the spec usually describes one of them, or both mixed in a sentence that does not say which holds when. The cost shows up as silences no other gate sees: in review nobody knows which branch is current and which is dying, the test covers the ON path and leaves the OFF path unproven, and the “temporary” flag grows old until removing it is archaeology.
A flag file declares its scenarios in a table: a code with the G letter, the condition on the value,
and what holds then. Five gates confront that declaration, each answering one question:
- flag-scenario-grammar: is each condition written in the fixed grammar?
- flag-scenarios-complete: does the flag say what happens when it is absent?
- flag-scenario-exists: does every scenario a spec cites exist?
- flag-scenario-governs: is every scenario cited by some rule?
- flag-covered: does every scenario have a test, and did that test pass?
What is deliberately not read is the flag’s real value: Anchors has no access to the flag service, must not have, and the value changes per user and per minute. The gates confront the declared scenarios.
Declaring it
Section titled “Declaring it”gates: - name: flag-covered on: [flag] check: flag-covered