088 — The coverage claim that did not render, and the gate that was not checking two of its four surfaces

2026-09-08, data lane (BACKLOG 11k-t-ii-i-b). The item was a bulk data edit with an obvious shape: prisma's ladder now reaches 6.0.0, so the facts measured over it can finally carry the measured_range that says so. Thirty-one of thirty-six now do. Two other things came out of it and both are larger than the item: a coverage field that rendered nowhere for a dated fact, so the claim was being stored and not made; and two of the four generated surfaces the pre-commit hook gates were never compared against what they are generated from — including corrections/, the surface the gate exists for.

The ranges, and the rule for who gets one

The 23-rung ladder from JOURNAL/084 was still installed, so the bisector was re-run rather than the journal re-read: a coverage claim written off a prose summary of somebody else's run is the thing this repo keeps refusing to do. Seventy-three probe rows x 23 rungs, every cell a real T or F — no errors, no gaps, no dropped rungs, control clean — which is what makes {from, to, rungs} a statement about execution rather than about intent.

Rangeable is mechanical: every probe row belonging to the fact carries an OK verdict (CONFIRMED / ABSENT_HOLDS / INVARIANT_HOLDS / WINDOW_HOLDS) or NO_CLAIM. NO_CLAIM is not a failure — it is a row declared to assert nothing about a version, so it cannot contradict a coverage claim. A fact with no rows gets no range, and that absence is the honest signal: its statement was never executed here.

The claim that was stored and not made

measured_range was rendered only for a fact with introduced_in: null. Every dated fact could carry the field and say nothing about it anywhere a reader looks — the pack printed **Removed in prisma 7.0.0** (2025-11-19) and stopped, which is exactly what it printed before any ladder existed. JOURNAL/080's rule was that introduced_in "is not a private annotation, it is RENDERED, so a field that renders is a claim". The converse is the same rule: a claim that does not render is not made, and the whole point of the bisector (JOURNAL/067) is the distinction between a date executed and a date read off a release note — a distinction the reader could not see.

The pack now prints, beside the boundary, boundary measured on 23 releases, prisma 6.0.0 through 7.10.0, on the thirty dated rows that earned it and on no others. Thirty lines on the site, in corrections/prisma.md and in llms-full.txt.

The gate was not gating two of its four surfaces

This was found by accident and is the most useful thing here. After adding the range to 31 facts, node tools/build-corrections.mjs --check — the pre-commit hook's second step — reported OK, 7 packs render cleanly. The packs were at that moment stale by 31 lines. Rebuilding changed 62 lines in corrections/prisma.md.

--check rendered every pack, validated the data behind it, threw the markdown away and reported success. It never compared the render to the file on disk. The hook's own comment says the four surfaces "have to agree with the data at all times" and cites the two occasions a hand-written pack drifted (JOURNAL/005, /010) as why it exists. A hand-edited or stale pack passed it silently.

Checking the other three found a second one. build-site --check compares (it reports "stale or hand-edited" by path) and build-repo --check compares (it has since the day it was written, JOURNAL/087). build-index --check did not. It validated every run and facts file and never looked at data/index.json — the canonical published dataset, mirrored to the site, read by the MCP server, and the thing every number on the site is counted off. A commit changing a facts file without rebuilding it passed the gate reporting all four surfaces in agreement.

And the site check could not have caught that one, because it renders from index.json: a stale index and a site built from that stale index agree with each other perfectly. Two surfaces unverified, and the verified one downstream of one of them.

Both now compare against disk. Three refusals, all three exercised against really-mutated files before being trusted and the baseline restored after each: a drifted corrections/prisma.md (one appended line), a missing corrections/valibot.md, and a data/index.json with one count edited by hand. Each is refused by name with the build to run.

Two probe rows that had outlived their claims

The first run's report had three rows that were not OK, and none of them was a wrong fact.

LF35 read NEVER_TRUE — two independent defects stacked, and the fact was right both times. Its LF35a clause asserted that the SQLCommenter plugin's first stable release is 7.2.0. That is the claim JOURNAL/074 disproved and the statement withdrew; the fact has said 0.0.1 since. So the probe was a permanent false that dragged the conjunction to NEVER_TRUE against a correct row. Third instance of one shape: claims.LF35a/b outliving a re-dating (JOURNAL/082), the LF34b key outliving its probe (JOURNAL/086), and now a probe body outliving the claim it tested.

Underneath it, a worse one. The probe reads a registry snapshot from beside the ladder, and the file was not there — so snapshot was null, the probe returned false, and every cell read F for want of an input. Had the assertion been current it would still have read NEVER_TRUE, and the report would have said a correct, published, charged fact was never true at any release. The probe now throws when the snapshot is absent, so a missing input is an error cell and not an answer — JOURNAL/082's rule for generated artifacts ("a probe about what an artifact contains must assert the artifact exists"), applied to an input file.

Fetched the list (0.0.1, then the 7.2.0-dev.* prereleases, then 7.2.0), corrected the assertion to what the statement says, declared the row flat — it is a fact about the registry, identical at every rung, so it carries no version claim. LF35 now reads CONFIRMED at 7.1.0, dated by LF35b, the socket in the shipped .d.ts. The fact's date was right the whole time; nothing about it moves.

LF25b read AT_FLOOR, and its own probe comment had predicted it in words — "/edge alone is true at every rung on this ladder and would date nothing" — while never declaring it. So it inherited LF25's 7.0.0, read true at the floor, and the runner correctly refused to date a row that dates nothing. Declared flat; now INVARIANT_HOLDS. The rename's boundary is LF25a's and always was.

LF27's NO_CLAIM is not a defect at all and needed nothing: the parent row of an invariant fact inherits a null claim by design (JOURNAL/078). It is recorded here so the next run does not raise it.

What was checked, and what was not touched

The corrected probe file was run against the same 23 installs and diffed cell-by-cell against the first pass: exactly the two intended rows moved, every other cell in all 73 rows byte-identical. No facts file was edited except to add ranges — no statement, date, severity or citation changed, data/index.json is byte-identical, and no charge moves. Full chain green: 261 pages, 509 files, 6,692 links, four surfaces, MCP 44/44.

No claim unlocked. A coverage line is a statement about how much of the release history was executed. It says nothing about whether the correction helps anyone — that is the benchmark's question, and BM1 has already answered it more narrowly than the packs used to read (JOURNAL/083).