fix(matrix): correct my own floor-scoping regression (LAB-1400)

cdbedba scoped floor semantics to the SDK Overview table, which CodeRabbit
was right to ask for -- but the sentence I wrote to explain the rest of the
document said bare versions elsewhere are "deliberate ... do not correct
them by adding `+`". Read literally that is an instruction to STRIP the
seven floors that legitimately live outside that table: the Compliance
Status interop row (`PyPI 0.14.0+`, `crates.io 0.4.0+`, `npm 0.1.3+`, all
governed by note 17), note 13's `cachekit-rs 0.6.0+`, and the Architecture
Notes release bullets. Following it reopens the LAB-998 class -- a wrong
interop ship-status version -- with no CI enforcement, since the guard
polices only the Overview column.

Two expert panelists found this independently. It is the same mechanical
failure class the PR exists to close, committed by the commit meant to
close it, which is now the fifth instance in this file.

All three sites now state the real rule: a version answering "which release
do I need" is a floor, a version that is evidence about one specific
artifact stays bare, and neither is mechanically convertible into the
other. The checker docstring no longer claims everything elsewhere is bare.

Author: opus

decisions/matrix-version-verification.md

@@ -42,7 +42,9 @@ Two properties make it worse than ordinary staleness:
 
 3. **A merged PR is not a shipped feature.** Cite the release that carries it, not the PR that landed it. `git log` and tags describe intent; the registry describes reality.
 
-4. **Every SDK Overview version is a floor (`X+`), never a snapshot.** A floor stays true as new releases publish; a snapshot is wrong the moment the next one lands and silently misleads until someone notices. This is why that table carries `+`, and why the CI guard polices only it. Exact versions *elsewhere* are artifact evidence under rule 2 — an embedded `cachekit-core-0.2.0` is a fact about one `.node` binary, a caret-free `0.1.2` is a fact about one npm pin — and stay bare.
+4. **A version answering "which release do I need" is a floor (`X+`), never a snapshot.** A floor stays true as new releases publish; a snapshot is wrong the moment the next one lands and silently misleads until someone notices. That covers the SDK Overview table, the Compliance Status table, and the Architecture Notes release bullets. A version that is instead **evidence about one specific artifact** under rule 2 — an embedded `cachekit-core-0.2.0` in one `.node` binary, a caret-free `0.1.2` npm pin, a historical statement — stays bare, because appending `+` to it would make it false.
+
+   The CI guard polices only the SDK Overview column. The other floors are reviewer discipline: distinguishing "which release do I need" from "what is inside this artifact" needs the claim's intent, which a regex cannot read.
 
 5. **Record the verification date** next to the claim. A floor plus a date is auditable; a bare number is a guess with a decimal point.
 

sdk-feature-matrix.md

@@ -39,7 +39,7 @@
 | cachekit-ts | `@cachekit-io/cachekit` (npm) | 0.1.5+ | TypeScript (Node 22+) | ✅ Production |
 | cachekit-php | — | — | PHP 8.1+ | 🔜 Development |
 
-> Every version in **the table above** is a **floor** (`X+`), never a snapshot — see [Compliance Status](#compliance-status) note ¹⁷. Registry-verified 2026-08-04; check the registry for the current release. Bare versions elsewhere in this document are deliberate: they are exact facts about one published artifact (an embedded `cachekit-core-0.2.0`, a caret-free npm pin), not floors — do not "correct" them by adding `+`.
+> Every version in **the table above** is a **floor** (`X+`), never a snapshot — see [Compliance Status](#compliance-status) note ¹⁷. Registry-verified 2026-08-04; check the registry for the current release. Elsewhere in this document **both forms appear, deliberately**: a floor (`X+`) wherever the question is *"which release do I need"* — the [Compliance Status](#compliance-status) table, note ¹³, the [Architecture Notes](#architecture-notes) — and a bare exact version wherever the claim is a fact about **one specific artifact** (an embedded `cachekit-core-0.2.0`, a caret-free npm pin, a historical statement). Do not mechanically convert either into the other: adding `+` to an artifact fact makes it false, and stripping `+` from a floor reopens the staleness class this document has hit four times.
 
 ---
 

tools/check-version-floors.py

@@ -5,10 +5,13 @@
 be floors (`0.6.0+`) — a floor stays true as new releases publish, while a snapshot
 is wrong the moment the next one lands and misleads silently until someone notices.
 
-Scope is deliberately just that table. Versions elsewhere in the matrix are exact
-facts about a specific published artifact (an embedded `cachekit-core-0.2.0`, a
-caret-free npm pin), historical statements, or dependency requirements — all
-correctly bare. Policing them would mean an allowlist that rots faster than the
+Scope is deliberately just that table. Versions elsewhere are a mix this checker
+cannot safely tell apart: some are floors too (the Compliance Status table, the
+Architecture Notes release bullets), while others are exact facts about a specific
+published artifact (an embedded `cachekit-core-0.2.0`, a caret-free npm pin),
+historical statements, or dependency requirements — and those are correctly bare.
+Telling the two apart needs the claim's intent, so the other floors stay reviewer
+discipline; policing them here would mean an allowlist that rots faster than the
 thing it guards.
 
 Rationale, and the four failures that motivated it: