From b4e450108ef3f7565936b02eab38634ca79835ed Mon Sep 17 00:00:00 2001 From: Torben Nehmer Date: Fri, 4 Sep 2026 19:20:35 +0200 Subject: [PATCH] docs: Coverage-Untergrenze als zweiter Fall in why-gates-are-code.md (#10) Files changed: - docs/why-gates-are-code.md --- docs/why-gates-are-code.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/why-gates-are-code.md b/docs/why-gates-are-code.md index 91f8fc5..eec09b1 100644 --- a/docs/why-gates-are-code.md +++ b/docs/why-gates-are-code.md @@ -55,3 +55,12 @@ to feel routine. That's the deeper reason these numbers live in a tool rather than in prose: prose is read once and remembered loosely, but a threshold enforced every call is tested by every call, and a threshold that fails its own test gets noticed and re-measured rather than quietly ignored. + +The suite's coverage floor is the same argument run forwards instead of backwards. The ceiling +above was wrong first and measured afterwards; the floor was withheld on purpose until the number +existed - measured, then watched across 38 runs while the code grew by a quarter, and only then +written down as 85 against an observed 87.0%. The two points of daylight are the same +consideration as the ceiling's headroom: a limit the ordinary case keeps tripping stops being a +limit. A coverage floor set at the measured number goes red on the next thin command wrapper, +which is not a regression, and a threshold that goes red for a non-reason gets lowered rather +than earned - the failure mode above, reached from the other direction.