S9: two short ADR amendments — what a check may rest on, and what mutation-proven means

[Polichinel]

Re-scoped 2026-08-12. Now carries both rules this epic produced. Two short amendments, not an essay — this repository's ADRs are held to a plain-prose standard and a solo maintainer has to re-read them.

Part of #241, Gate 3. Registers C-93. Do this last.

Amendment 1 — ADR-017: what a check here may rest on

The clause that makes this epic a roadmap instead of a queue:

A check in this repository may rest on a fact we own, on a fact another repository has declared in the public registry, or on an outcome we can observe. It may never rest on another repository's implementation.

Where a needed fact is none of those three, the check is not built here. It is requested as a declaration, requested as a consumer obligation, or registered as an accepted gap with a named owner and trigger.

ADR-003 already says declarations over inference. It was applied rigorously to the product and not at all across the repository boundary — and every defect in C-89…C-92 sits on a check that broke that rule.

Evidence to cite, with dates: the consumer source-read broke on 2026-08-11 (views-faoapi) and 2026-08-12 (views-crafdapi), both times because the other repository refactored a literal into a named constant. Their code got better; our test went red.

Amendment 2 — ADR-014 §2: what "mutation-proven" is allowed to mean

§2 says a guard is mutation-proven or it is decoration. That is right and it is not sufficient.

A mutant list written by the author of the guard covers the cases the author already had in mind — which are, by construction, the cases the guard already handles.

Measured, on the guard protecting a public repository from publishing a coordinate value: 13 forms proposed by the author, 13 caught; 29 proposed independently, 15 missed.

The useful rule is a diagnostic, not a process:

If a guard can only be proven against inputs you invented, that is the signal the guard is on the wrong side of a boundary — it is verifying a fact you do not own. Prefer moving the check to where the fact lives, or anchoring the mutant list in something real: this repository's own corpus, the registry's actual rows, an outcome you can observe.

Where that is impossible, two cheap obligations: the mutant list is a declared artifact in the test file (tests/test_ci_sibling_coverage.py::_MUTANTS is the pattern), and a proof must be able to fail — mutate the function, watch the proof go red, record it.

Do not adopt a rule requiring an independent mutant author on every guard. The friction would exceed the disease for a single maintainer. The diagnostic is the load-bearing part.

Acceptance criteria

• Both amendments landed, in the plain-prose style — jargon defined inline, no clause-ID shorthand, stable section numbers.
• Each cites its measurement with a date.
• The ADR-014 amendment fits in a screen. If it does not, it is teaching rather than ruling.
• C-93 closed, or amended with what was decided instead.
• No claim in either amendment is itself unguarded — if it says a pattern is followed, name where; if nothing checks it, say so.

Why last

This is the generalisation of the other stories. Writing the rule before doing the work would draw it from the same imagination that caused the problem, which is what the rule is about.

Labels

story, documentation, planning

[Polichinel]

Landed in #257.

Three amendments: ADR-017 §7a (what a check may rest on), ADR-017 §7b (an ADR records a decision, never current implementation state), ADR-014 §2 (mutation-proven as a diagnostic, not a process).

§7b is the one the post-mortem earned — it is the root cause of nine stale claims in two days, including a rule repealed on a premise false by six hours.