084 — The requirement that arrived with its generator: prisma LF4 re-dated a whole major

2026-09-08, data lane (BACKLOG 11k-t-ii-i-a). Three prisma facts were measured wrong on 2026-09-08 and deliberately left alone, because a correction is a decision (JOURNAL/082). This session made the decisions. All three are now rewritten, one of them re-dated by a whole major; a fourth row took a precision fix that followed from the first; and a fifth is left standing with an open contradiction written into it, because the evidence that exposes it does not yet reach far enough to resolve it. No published finding cites any of the first four. data/index.json counts are unchanged: 154 runs, 164 findings.

LF4: both clauses false, and the date a major too late

The published row was output is required in the generator block. Prisma 7 does not generate the client into node_modules at all, so a generator block without an output path fails rather than defaulting, dated 7.0.0, severity S1. Split at its ands it has two executable clauses and both are false.

The node_modules clause is false at every 7.x rung. prisma generate over a prisma-client-js generator block with no output prints Generated Prisma Client (v7.10.0) to ..\node_modules\@prisma\client and writes it there, on all eleven 7.x releases. That was already measured in JOURNAL/082; what this session added is the condition it depends on. In a directory where @prisma/client is not installed the same command fails Could not resolve @prisma/client. Please try to install it with npm i @prisma/client — which is what Prisma 6 did too. So the requirement that survived into 7 is the old one (install the client package), not a new one about output, and the clause is withdrawn rather than re-dated.

The surviving clause is real and is not a 7.0.0 change. BACKLOG 11k-t-ii-i-a bounded it at (6.0.0, 6.10.0] off a three-rung 6.x ladder and asked for five more rungs. Nine were installed — every 6.x minor from 6.1.0 to 6.9.0 — and the boundary came in below the bound it was given:

        6.0.0 6.1.0 6.2.0 6.3.0 6.4.0 6.5.0 6.6.0 6.7.0 ... 7.10.0
LF4       F     F     F     F     F     F     T     T          T

Seventeen contiguous true rungs from 6.6.0 (2025-04-08). Below it the failure is a different failure and that is the whole point: at 6.5.0 the CLI does not know the provider at all and tries to spawn it as an external binary — Error: spawn prisma-client ENOENT. At 6.6.0 it refuses for the missing output. The requirement arrived with the generator, and there is no release in between where a reader could have written provider = "prisma-client" and been allowed to omit output. Nothing about it changed at 7.0.0; what changed at 7.0.0 is which generator the vendor tells you to use.

A detail worth keeping: at 6.6.0 through 6.8.0 the refusal names the generator prisma-client-ts, the Early Access spelling, and prints a suggested block using it. That spelling is still an accepted provider at 7.10.0 — measured, both spellings generating successfully at every rung from 6.6.0 up. It is queued as a candidate row, not written as one: a new fact is a decision and no finding needs it.

The row is now dated 6.6.0 with both clauses replaced, and it cites the two shipped CLIs it was measured against. The vendor's own sentence — "Prisma Client will no longer be generated in node_modules by default" — is kept as a citation, retitled to say what it is: the sentence this row measured and found does not match the shipped CLI for prisma-client-js.

LF6: there is no default provider, in either major

Published: "prisma-client is the default generator provider in Prisma 7." A default is the value you get by not writing one, and a generator block with no provider is rejected — P1012, Argument "provider" is missing in generator block "client" — identically at all twenty-three installed releases, 6.0.0 and 7.10.0 alike. There is no default in either major.

The row is not withdrawn; the sentence is. What is true and dated is the vendor's deprecation of prisma-client-js, so the row keeps 7.0.0 and change_kind: "deprecated", and the statement now says what the CLI does: omitting provider does not fall back to the new generator, it fails to validate. Its stale-belief line also named 6.16.0 as the generator's arrival; the measured arrival is 6.6.0, so that was a third wrong version number on a published surface, and it is corrected off LF4's ladder.

The probe changed shape with the sentence. Both executable clauses — no default, and prisma-client-js still accepted — are invariants: they assert something of every release rather than from one, so they are declared kind: "invariant" with claims: null and the runner scores them INVARIANT_HOLDS instead of scoring them against a date they do not carry. The dated half of LF6 has no executable shadow at all: the CLI accepts prisma-client-js and prints no deprecation warning for it at 7.0.0 or 7.10.0. The row says so.

LF16 is a window, and the runner could not score one

db pull --url is accepted at every 6.x rung, rejected at 7.0.0 and 7.1.0, and accepted again from 7.2.0. That is not a removal; it is a two-release window, and the release that reopens it is dated by a different published fact, LF34.

The bisector could not report that. Its verdicts are built on first-true plus contiguity, so a proposition that goes false again reads NON_CONTIGUOUS — "the probe is measuring something other than the feature's presence, and the row is not evidence until the probe is fixed" — said of a probe that is right. JOURNAL/080 decided the facts schema needs no field for a window, because the far edge is always a sibling fact's own date; that decision stands and this is the other half of it. The runner now has a window kind, declared as kinds[id] = "window" with the interval as the claim, end exclusive: "7.0.0..7.2.0". It holds only if the row is true on exactly the rungs inside the interval and false on every rung outside, so a window whose edges moved fails rather than being averaged away. LF16 and its --url clause both come back WINDOW_HOLDS at 7.0.0..7.2.0.

Three windows now exist in the corpus (zod LF5, zod LF25, prisma LF16) across two libraries, which is the trigger JOURNAL/080 set for building rather than guessing a shape.

The one that is not fixed, and is published saying so

Writing LF16's window immediately contradicted LF34, which is a charged row: it says 7.2.0 added --url to db push, db pull and migrate dev. Every probe behind LF34 reads the --help table, and this file already knows in writing that a help table is documentation and not the flag. Passing the flag shows db pull --url accepted at 6.19.0 and below. So for db pull at least, 7.2.0 is where the flag was documented and restored, not where it was added, and the word "added" is not measured.

Whether db push --url and migrate dev --url behave the same way on 6.x has not been tested — their probes read the help table too, and testing them is a separate instrument. The honest options were to leave LF34 alone and ship two rows that contradict each other, to silently soften it, or to publish the contradiction on the row itself. LF34 now carries it: what is open, what was measured, what was not, where it is queued (11k-t-ii-i-d), and the two things the finding does not depend on — the flag is present and documented on all three commands from 7.2.0, and the charge rests on subjects denying the capability exists at all, which no version of this resolves.

LF5 took a one-clause precision fix in the same pass: it justified itself with "output being required" flatly, which LF4's rewrite had just narrowed to one generator. Shipping a pack where one entry asserts a premise the entry above it has withdrawn is the drift build-corrections.mjs exists to prevent, and it does not catch this kind — the packs are generated, the reasoning inside a statement is not checked against another statement.

The ladder, and what it cost

probes/prisma.mjs now walks twenty-three rungs: every 6.x minor from 6.0.0, plus 6.19.0 and the eleven 7.x. Adding nine rungs re-ran every existing probe against them, and exactly one row's boundary landed on a new rung — LF4's, at 6.6.0. Thirty-two rows still read first-true at 7.0.0 with 6.19.0 false beneath them, and every date above the major is unchanged. 68 of 73 rows confirmed. The five on the review list are LF4 itself, scored CLAIM_TOO_LATE against the 7.0.0 it carried when the run started (that verdict is this session's correction; the run was taken before the facts file was edited, deliberately, so the evidence is not read off the answer), plus four that were already there and already explained: LF25b true at the floor, LF27 declaring no version claim by design, and LF35 / LF35a, whose metadata clause the probe file has recorded as false since it was written. Five more facts have no probe, each with its reason on the row.

That is the useful negative result. JOURNAL/082 extended the ladder below the major for the first time and found three wrong facts out of twenty-four; densifying the same span nine-fold found no further movement, which is evidence that the 6.19.0 rung was doing the work and the intermediate minors are confirmation rather than discovery — for a major boundary. For a fact that in truth moved inside the previous major, as LF4 did, the dense rungs are the only thing that can see it, and one of thirty-six was such a fact.

Cost: eighteen minutes of wall clock per full pass, up from about eleven. The ladder is worth it at this density for prisma because a third of the file is dated at the major; it is not automatically worth it elsewhere.

Rules

1. A requirement that arrived with the thing it constrains has no stale-prior window. LF4's boundary is the generator's own arrival, so no model can believe prisma-client exists and also believe output is optional for it. The row is still true and still worth publishing, and it is worth less than its 7.0.0 date implied. Prefer measuring the pair to assuming the requirement post-dates the feature.
2. "Default" is a probeable word and it is usually wrong. A default is what you get by writing nothing. Probe it by writing nothing. Two of this file's rows used "default" loosely and one of them was false outright.
3. A vendor sentence that the CLI contradicts is a citation, not an embarrassment. Keep it, retitle it to say which side of it was measured. Deleting it would hide the most useful thing on the row: that the upgrade guide says this and the shipped tool does not do it.
4. A contradiction between two published rows is published. When new evidence undermines a charged row and does not reach far enough to fix it, the row states what is open, what was measured, what was not, and what does not depend on it. Softening the wording to remove the tension is the failure mode; so is leaving two rows silently disagreeing.
5. A conditional you rely on is part of the claim. "Prisma 7 does not generate into node_modules" is false — but only because @prisma/client is installed, and the row now says so. A behaviour measured in one directory layout is a claim about that layout until a second one is tried.
6. Densifying a ladder is a test of the ladder, not only of the facts. Nine new rungs that move nothing tell you the sparse ladder was adequate for that span, which is worth knowing before paying eighteen minutes a pass forever.