164 — The key that was never removed: engineType, and the difference between an engine and the word for it

2026-09-12, data lane (BACKLOG 1h-n-iv). The item was one unmeasured clause of a note JOURNAL/158 cited: the prisma 6.16.0 release note asks for engineType = "client" in the generator block to opt into the Rust-free ORM, and LF38 had deliberately declined to state it because nothing had run it. The item's own prediction was that this "either dates a row or closes with the note's opt-in has no schema-level shadow".

It dates a row. It also found that the Index already published a fact about engineType whose stale_code invites a reader to expect a build failure that does not happen.

What was measured

Thirty-one stable minors, 6.0.0 to 7.10.0, both generators (prisma-client-js and prisma-client, which agree on every boundary here), through the probe file's own subject. The reading is LF37's: the set of files prisma generate wrote, never a file hash — a generated client embeds the schema text, and the schemas being compared differ by the engineType line itself (JOURNAL/134).

engineType = "client", with nothing in previewFeatures:

So the note's opt-in is real and its window is [6.16.0, 7.0.0) — sixteen weeks wide. The note itself predicted the far edge: "While the Rust-free ORM will become the default in Prisma ORM v7 soon, for now you still need to opt-into using it." From 7.0.0 the default is the Rust-free client, so the key it asked for stopped meaning anything.

And it stopped meaning anything for every value, not just that one. On all eleven 7.x rungs, engineType = "client", "library", "binary" and a value that does not exist all generate without error and all emit the identical file set to a schema carrying no engineType at all. A second and independent instrument agrees on the same 7.0.0 boundary: the CLI's own success line reads Generated Prisma Client (v6.19.0, engine=binary) on every release from 6.0.0 to 6.19.0 and names no engine from 7.0.0. That line is the only signal a reader who does not diff the output directory would ever see.

Filed as prisma LF39, generator client { engineType }, behavior-changed, 7.0.0, S3. Seven probe rows, all confirmed by the committed bisector on 31 rungs: one window (LF39a, 6.16.0..7.0.0, WINDOW_HOLDS), three risers at 7.0.0 (LF39b the headline conjunction, LF39c the single value LF14's stale_code writes, LF39d the CLI annotation), two flat controls (LF39e, LF39f) and one flag date (LF39g, 6.7.0).

The published fact that was true and read wrong

LF14 says "The client engines are gone", dated 7.0.0, S1 breaks-build, and every word of it is true — the engines are gone. Its stale_code is:

generator client {
  provider   = "prisma-client-js"
  engineType = "binary"
}

That schema does not fail on Prisma 7. It generates, silently, and the client it generates is the Rust-free one the reader was trying to avoid. The only observable difference from deleting the line is that the CLI stops printing , engine=binary.

The probe file's own comment had known half of this since JOURNAL/134 — "a generator ignores an option it does not know" — but it lived in a comment, the fact stated nothing, and no row asserted it. The engines and the word for them are two claims, and the Index was publishing one of them under the other's severity. LF14 keeps its change_kind and its date, which are about the engines and are right; its note now carries the measurement and points at LF39, which carries the boundary and the controls. The api strings differ deliberately (engineType versus generator client { engineType }) and the alias gate enforced that: the first draft of LF39 listed the bare engineType in also_known_as and build-corrections.mjs refused the whole build — "two facts claim the api engineType: LF14 and LF39". That check has now paid for itself.

Two rules, both paid for in this run

An inertness row over one value cannot tell "recognised and redundant" from "unrecognised and dropped." LF39b's first version asserted that engineType = "client" builds and emits the default, and the bisector returned NON_CONTIGUOUS — true from 7.0.0 and true on 6.0.0–6.2.0, where the value is simply not one the release knows. There is no instrument that separates those two at 7.x: a generator ignoring an option it never heard of and a generator ignoring an option that became redundant produce the same bytes and the same exit code. That indistinguishability is the finding, and it is the whole of why the stale schema is quiet rather than loud. The fix was to state the claim as the conjunction over every value — what separates 6 from 7 is not what "client" does, it is that on 6.x "binary" still differs from the default and on 7.x nothing does. Contiguous rise at 7.0.0, CONFIRMED.

validate is blind to an option's VALUE, not just its name. The cohort header has said since JOURNAL/074 that prisma validate does not check generator options. The sharper form, measured here: prisma validate reports the schema valid at all 31 rungs for engineType = "client" — including the nine releases where prisma generate refuses that exact file with a named error. A user who validates, sees "valid" and ships is holding a schema that will not generate. Where a tool has a check subcommand and a do subcommand, the check's silence is evidence about the check; measure on the one that does the work, and publish any disagreement, because the check is what a reader relied on.

Not done, and deliberately

No finding is charged. This session measured the library, not a model — whether any subject actually emits engineType = "client" for a Prisma 7 project is a battery, and tools/charge-windows.mjs should be run against LF39's window before one is designed. The severity is S3 rather than S1 for the reason LF38 is S3: the stale schema still builds, so the cost is a line of dead configuration, plus — below 6.16.0 and without the flag — a build that fails for a reason the error message states exactly.