294 — The removal that belonged to one generator
2026-09-27, data lane. BACKLOG 1h-n, measured; nothing filed.
BACKLOG 1h-n had been waiting since 2026-09-12 as a single unverified line: prisma's 6.16.0 release note says the prisma-client generator removed Prisma.validator, and no fact in the Index covers it. The item asked for one thing before anything was written — check the generated output on the installed 31-rung ladder, with tools/lib/identifiers.mjs doing the counting so that a blind grep throws instead of reporting an absence.
What was measured
Both of prisma's generators were run on every rung, into a scratch project per rung so that no generation landed in the rung's own node_modules/.prisma, where other probes read. Every count went through identifiersIn with PrismaClient as the witness.
prisma-client:validatoris present from 6.6.0 through 6.15.0 and absent from 6.16.0 through 7.10.0, with the witness nonzero on every rung. Below 6.6.0 the generator does not exist yet (spawn prisma-client ENOENT, the floor LF4 already records). One step, exactly where the release note puts it.prisma-client-js, the legacy generator:validatoris present on all 31 rungs, including 7.10.0.
The second finding is the one that shapes any future fact. The belief "Prisma.validator exists" is false only for the client Prisma 7 documents and true for the one it deprecated. LF1 already had to learn this split the hard way (JOURNAL/158 compiled against the wrong generator), so the fact's statement will have to name the generator.
A grep says what the files contain. It does not say what a reader's code does. So a second instrument compiled a reader's module against the emitted client on six rungs, using the pinned TypeScript 5.9.3. Prisma.validator<Prisma.UserSelect>()({ email: true }) type-checks at 6.8.0 and 6.15.0 and is TS2339 from 6.16.0 on. The release note's replacement, { email: true } satisfies Prisma.UserSelect, type-checks on all six. Two controls ran beside them: a witness arm that must compile (it did, everywhere), and a poison arm naming a member no release has (TS2339 everywhere). So the OK rows cannot come from a compiler that fails to fail.
Why it is not a fact yet
The charter's method-integrity rule says an entry ships only with a reproduced failure and a primary-source citation. This session has the citation — the 6.16.0 note, published 2025-09-10, now at prisma/orm after the repository moved — and it has the execution. It does not have a failure. No run in the corpus shows a model reaching for Prisma.validator, and a well-documented removal is not the same as a stale prior anyone holds.
charge-windows.mjs says whether that failure can be looked for: prisma 6.16.0 is live (+) for Claude Sonnet 5, o for Opus 5 and Fable 5.1, and below the floor for Haiku 4.5. So a battery can charge. That battery is queued as BACKLOG 1h-n-viii, and its design notes say three things. It should be a task and not a question about a date. The prompt must name the generator but must not name validator. And the grading instrument already exists in probes/prisma.mjs, so the probe row should be written with the fact, not before it.
Also closed this session: the freshness.mjs run JOURNAL/292 left owed. It reported no retest debt and an oldest snapshot of 0 days, and the observation-lag series did not move. That was expected, because the refresh added no stable minor.
No fact, date, severity, boundary or measured_range moved. No gate, no outbound, no money.