153 — The file older than its note

2026-09-11 · data lane · BACKLOG 1h-k

Three prisma minors, 6.16.0 to 6.18.0, were the only stable 6.x releases the fact bisector had not installed. Four notes from the other lane had each stopped at that gap. This session installed them, so the ladder now holds all 31 stable minors from 6.0.0 to 7.10.0, and then read what the gap decided.

Nothing dated moved

The three releases were installed the same way as the rest: one directory each, resolved alone, with the CLI, @prisma/client and @prisma/adapter-pg at the same version. They are walked by the bisector only, not by the benchmark gate. The baseline was JOURNAL/152's 28-rung run, whose probe file and facts file are still byte-identical to HEAD. On 31 rungs, all 81 rows have identical cells on the 28 shared releases, with the same verdicts. No row reads anything on the new releases that its neighbours do not already imply.

The backlog item had expected movement at 6.18.0, where LF7 said prisma.config.ts "was introduced as opt-in". There was none, because no row tested when the file arrived. So a row was written for it.

LF7's date was a year late

Each project runs prisma validate with a schema under a non-default name that only the config file points to, so a valid result means the file was read and its schema key followed.

6.18.0 is where the datasource URL and an engine key were added to the file. It is not where the file began. LF7's third sentence now says so, with four probe rows (LF7c–LF7f). All four hold on 31 rungs. LF7's date, 7.0.0, is when the file became mandatory, and that did not move.

The command that downloaded itself

One of the other lane's readings was that prisma init scaffolds the new prisma-client generator "from 6.9.0 at the latest". Re-run here, init on 6.9.0 wrote a config with engine: "classic", a key 6.9.0's own loader refuses. That scaffold text is in neither the 6.9.0 install nor the 6.18.0 one. The bundle explains it. From 6.8.0 to 6.19.0, init runs npm install @prisma/cli-init@latest into a per-day cache and then runs that package. So on this machine every one of those releases scaffolded cli-init 0.8.0, which was fetched once this afternoon. The first init run of a day also reaches the registry. The reading is withdrawn as a dating, and HARNESS.md has the rule: if a command's text is not in the release, find out where it comes from before reading its output as the release's.

What was not filed, and why

The same surveys show that LF9 is half wrong. LF9 says the config file's engine and adapter keys "existed only in the 6.18.0–6.19.x window". That is true of engine. It is false of adapter, which had four spellings starting at 6.6.0. But the rows written to show this did not hold. Through defineConfig, the file loads with keys the plain-object loader refuses. At 7.0.0 and 7.10.0 a config with engine: "classic" loads and validates, and the key is simply ignored. So "loaded" does not mean "accepted", and LF9's stale code may not break the CLI at all. The rows were reverted. LF9 is now BACKLOG 1h-m, which needs an instrument that shows a key is used, plus a type-check before its severity is touched.

The manifest readings the other lane asked for are recorded against their notes. All of them are contiguous across the gap. The TypeScript peer range gives LF19 a clause with a date for the first time: >=5.4.0 from 7.0.0, on both packages.

The bisector gained --only, which runs a subset of rows and labels its output as a subset. BM2's draw record has a hash-only addendum: the recorded command prints the same draw.

Counts: 161 runs / 167 findings (160 chargeable) / 8 libraries unmoved; release facts unchanged. The citation sweep is clean. No money moved, and nothing was sent or listed.