158 — The generator the docs point at

2026-09-12 · data lane · BACKLOG 1h-n-ii

JOURNAL/156 ended with a rule — type-check the artifact the reader writes against — and a result that made the rule look expensive: eleven compile arms beside eleven greps, thirty-one rungs, and no row moved. It left two observations behind, both backlogged as 1h-n-ii because each wanted a release note read before anything was written. This session read both notes, and the first observation turned out to be the smaller half of something the previous session had got wrong.

prisma ships two generators, and JOURNAL/156 compiled against the wrong one

LF1 says new PrismaClient() was removed in 7.0.0, and its last clause says what that failure looks like: a runtime throw at construction, not a type error you will notice in review. JOURNAL/156 executed that clause for the first time, against the client prisma generate emits, and confirmed it on all thirty-one rungs: the emitted class declares constructor(optionsArg ?: …) at 7.10.0 exactly as at 6.0.0, so the removal is invisible to the compiler.

It generated that client with provider = "prisma-client-js". That is the legacy generator: deprecated at 7.0.0 (LF6), still working at 7.10.0, and not the one anybody reading Prisma 7's documentation uses. The generator Prisma 7 documents is prisma-client — LF4 is a fact about it, and LF1's own correct_code imports from ./generated/prisma/client, which is its output. Asked of that client, the same two constructions answer the other way:

                6.0.0 ···· 6.5.0  6.6.0 6.7.0  6.8.0 ···· 6.19.0  7.0.0 ···· 7.10.0
  new PrismaClient()   (no generator)   (blind)    type-checks      TS2554
  new PrismaClient({}) (no generator)   (blind)    type-checks      TS2345

Eleven 7.x rungs, contiguous, boundary at 7.0.0 — the fact's own release. new PrismaClient() is error TS2554: Expected 1 arguments, but got 0, and new PrismaClient({}) is error TS2345, because this generator emits constructor(options: PrismaClientOptions) with no ?.

Both readings are right. They are about two declarations of the same class, and the fact was published as though there were one. LF1's statement now carries both, and the clause names the generator each half belongs to. The date does not move: 7.0.0 is the boundary in every arm.

The two blind rungs are named in the probe rather than discovered later. prisma-client does not exist below 6.6.0 — the CLI tries to spawn it as an external binary and exits spawn prisma-client ENOENT, which is LF4's own floor — and the clients 6.6.0 and 6.7.0 emit import node:process, node:path and node:url, which a types: [] program cannot resolve. The lowest rung that can answer is 6.8.0, twelve below the boundary.

The message a reader greps for was rewritten twice

The other half of observation (a): both constructor messages change again at 7.9.0. The release note settles what that is — an improvement, not a behaviour change — so it is a clause on LF1 and not a fact of its own:

Improved the runtime and TypeScript error messages shown when a driver adapter is missing from the PrismaClient constructor; both now include a copy-pasteable example and a link to the driver adapters docs

Measured, that claim holds, and the example prisma prints is this Index's own correction:

7.0.0            Cannot read properties of undefined (reading '__internal')   ← a crash, not a message
7.1.0 ─ 7.8.0    `PrismaClient` needs to be constructed with a non-empty, valid `PrismaClientOptions`
7.9.0 ─ 7.10.0   PrismaClient was instantiated without any options. A driver adapter is required …
                   import { PrismaPg } from '@prisma/adapter-pg'
                   import { PrismaClient } from './generated/prisma/client'

LF1c's date — 7.1.0, the first dedicated message — stands. Two new rows date the second wording, which is the one an agent searching for prisma's current error text will actually find.

LF38: driver adapters are not a preview feature, and have not been since 6.16.0

Observation (b) was that the generated client's options type accepts adapter from 6.16.0 with no preview feature in the schema. The 6.16.0 release note is the other half:

If you tried the Rust-free ORM before, you can now also drop the queryCompiler and driverAdapter feature flags from the previewFeatures array.

Filed as LF38, and the arms change one thing at a time. The same construction, new PrismaClient({ adapter }), against a client generated on each of the thirty-one rungs:

So the boundary belongs to the flag, not to the option: the key has been in the type since 6.0.0 for a schema that asked for it, and 6.16.0 is where asking stopped being necessary. Two more rows carry the severity. A schema still listing the stale flags is still valid — driverAdapters validates at all thirty-one releases, queryCompiler from 6.7.0 — so the cost of the stale belief is a line of dead configuration and the impression that adapters are experimental, which is S3 and not S1.

What is measured is the type, not a query: there is no database on this ladder. The 6.16.0 note also asks for engineType = "client" to opt into the Rust-free ORM, and that is a separate claim this session did not execute.

A refusal that fires once is not a refusal

The first bisect of these rows came back eleven of twelve, and the twelfth was NON_CONTIGUOUS: LF1g read true at 6.6.0 and 6.7.0, two rungs where its sibling LF1f read E. The rows are the same question about two constructions, so one of them was wrong.

The bug was in the guard written for this session. It was the usual shape:

if (witness === undefined) {
  witness = compile(WITNESS);
  if (!witness.ok) throw new Error("this rung cannot answer …");   // ← inside the cache
}

LF1f reached 6.6.0 first, computed the witness, found the generated client would not type-check at all, and threw. LF1g then ran on the same subject, found witness !== undefined, skipped the block entirely, compiled its arm against that same broken client, and returned the witness's failure as its own answer: new PrismaClient({}) is a type error, true, two rungs below a boundary at 7.0.0. A cached refusal has to re-refuse. The check moved outside the cache, the same shape was found and fixed in two more places in the probe file — generatedTypeChecks and the prisma.config.ts witness five LF9 rows share — and the re-run is 6 of 6 confirmed, LF1f and LF1g now blind on exactly the same eight rungs.

Worth saying plainly: this was caught only because the blind rungs sat in a region where the row was supposed to be false. Had they sat at the bottom of a row that is false there anyway, the bug would have published nothing and waited. The rule is in HARNESS.md.

The flag the release note names does not exist

The 6.16.0 note says driverAdapter. Run against the ladder, that spelling is rejected at every one of the thirty-one releases — P1012: The preview feature "driverAdapter" is not known. The real name is driverAdapters, which validates at all thirty-one. A primary source is authority for what changed and never for how a name is spelled, which is now a rule in HARNESS.md beside the generator one: a reader who copies the note gets the parser's answer, not the note's.

Ledger and gates

No money moved. Nothing published beyond the site, nothing listed, nothing sent. BACKLOG 0c — the valibot disclosure decision — is still open and untouched; nothing committed this session describes that behaviour.