What Claude Sonnet 5 gets wrong about prisma — battery v6-a, tested 2026-09-12

Run prisma--claude-sonnet-5--v6-a--2026-09-12

Summary

The battery's only chargeable arm, and it does not charge the fact the battery was built for. It writes no engineType anywhere — TASK 1's schema has none, TASK 2's mechanism is the preview flags, and TASK 3 tells the colleague to delete the line. What it does hold is the neighbouring belief: that queryCompiler and driverAdapters are what switch the Rust-free client on, which stopped being true at 6.16.0, four months before this subject's stated cutoff. It then predicts at TASK 3 that carrying those same flags now breaks prisma generate — the block generates cleanly. Its TASK 1 answer contains the correct belief about the same flags, which is the sharpest thing in the transcript: the stale prior is not a gap in what this arm knows, it is a second answer it also holds, produced when the question is asked as a capability rather than as a file.

SubjectClaude Sonnet 5 claude-sonnet-5, Anthropic
Invoked asAgent tool, model alias "sonnet"; prompt sent verbatim from prompts/sent/prisma-v6.txt (3,779 bytes, md5 3e02367d7e757977ba3795ad3ff0fc90). Nominated in the spec BEFORE spawning as the charging arm of the Sonnet 5 pair, and the only chargeable cell in the battery: at prisma 7.0.0, where LF39's charge sits, Sonnet 5 is the sole `+` in tools/charge-windows.mjs.
Cutoff the model states2026-01
Newest prisma release it could place6.7.0 · 2025-04-29 (~9 month lag)
Oldest prisma release it could not place6.8.0 · 2025-05-15 (so this run brackets the subject’s boundary to 2025-04-29 – 2025-05-15)
As recorded (this record does not declare whether the words are the subject’s or a summary of them)"I believe Prisma has been moving toward a major 7.0 release as part of its publicly stated plan to drop the mandatory Rust engine and make driver adapters the standard path — but I hold that loosely, not as a confidently verified fact."
How the bracket was readThe arm names a RANGE, not a release — "somewhere in the Prisma 6.x line … the early-to-mid 6.x releases … e.g. ~6.5–6.7" — so the top of the range it names is recorded and the ambiguity is stated here rather than resolved silently. Its own gap declaration is coarser still and lands elsewhere: "I cannot describe 6.16.0 onward (including 6.19.0, 6.22.0) or 7.1.0." Both readings are below its stated cutoff by six months or more.
Library at test timeprisma 7.10.0 (npm), verified 2026-09-12
Batteryprisma/v6-a · 4 tasks, 4 direct questions · probe window 6.16.0 to 7.10.0
Tool uses during test0 (a run with any tool use is void — we measure training knowledge, not retrieval)
Tested2026-09-12
Findings1, of which 1 chargeable

Findings

F1 · Ships the graduated preview flags as the mechanism that switches on the Rust-free client

S3deprecated · previewFeatures = ["driverAdapters"] · added · changed in prisma 6.16.0 (2025-09-10) · chargeable

SEVERITY: S3 BY THE PRE-REGISTERED FUNCTION, AND THE S2 CLAUSE WAS CONSIDERED AND REFUSED. prompts/prisma.md §v6 fixes the severity function before the draw: S3 for "a preview flag said to be required", which this is verbatim; S2 for an arm that additionally asserts the line changes what RUNS, a clause the pre-registration writes about engineType specifically. This arm does assert the flags change what runs ("the flag that actually replaces the Rust query engine"), so the S2 clause fits in spirit — and extending a clause from the key it names to a different key AFTER reading the transcript is the decision pre-registration exists to prevent. It is scored S3 and the reasoning is published here rather than the score being quietly raised. The clause should be rewritten for the surface, not for this arm; queued in BACKLOG. DOUBLE-CHARGE CHECK: this is the LF38 belief, not LF39's — the arm writes no engineType anywhere in the battery and tells its colleague to delete the one TASK 3 shows it. The corpus's two existing engineType findings (prisma/sonnet-5 F10, prisma/fable-5 F9) carry LF14's belief and are untouched. LF38 had no charged finding in the corpus before this one.

What the model believes

"previewFeatures = [\"queryCompiler\", \"driverAdapters\"] — required to switch this on. queryCompiler is the flag that actually replaces the Rust query engine with the TS/WASM query planner; driverAdapters is required alongside it … the two ship together." TASK 2 answered (a) "Yes" to whether the client has to be switched on by something written in the schema.

What it wrote
generator client {
  provider        = "prisma-client"
  output          = "../src/generated/prisma"
  previewFeatures = ["queryCompiler", "driverAdapters"]
}
What works on prisma 7.10.0
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}
Impact

Two lines of dead schema and, worse for a reader, the belief that the flags are load-bearing: a team that inherits this block will keep the array when it upgrades, and will read the deprecation warning as something to work around rather than something to delete. The generated client is the same either way.

Verified against

What it got right, and near misses

Recorded so the run cannot be read as a hit list. A model that is right for an obsolete reason is recorded here, not as a finding.

KindAPINote
contextpreviewFeatures = ["driverAdapters"] TASK 3(a) answered "No" — the block does not generate — and named the same preview-flag line as the reason: "Prisma's pattern when a preview feature graduates to stable/GA is that the flag name becomes unrecognized and prisma generate errors out … rather than silently ignoring it." Measured false this session: the block exits 0 at 7.10.0 and writes the same nine files as the default, with one deprecation warning. (The same fact's belief in a sharper form, and the battery pre-registered that an LF38 charge is anchored on TASK 2 — the unprimed probe — with at most one per arm; the charge is F1 in this run. Counting the recognition restatement as a second finding would inflate the count. Recorded because the sharpening is the interesting part: at TASK 2 the flags are 'required', at TASK 3 their presence is predicted to be fatal, and neither is true.)
missgenerator client { engineType } Doubts that engineType = "client" ever meant anything on the prisma-client generator: "I don't have confident memory of \"client\" being a documented value there, nor of engineType being a supported key at all on the newer prisma-client generator." LF39 measured it selecting the WebAssembly query compiler on 6.16.0-6.19.0, on both generators. (An abstention, not a denial (JOURNAL/046). Every clause is framed as absence of memory, and the arm's operative advice — delete the line — is the correct one. The Index does not charge a subject for reaching the right instruction while saying it cannot remember why.)
correctpreviewFeatures = ["driverAdapters"] TASK 1 is right and is right about the thing TASK 2 then gets wrong: the schema it ships for a driver-adapter service carries provider = "prisma-client-js" and NO previewFeatures, with the reasoning stated — "driver adapters for pg reached general availability in the 6.x line, so you don't need to opt in with a preview flag anymore". Two tasks apart, the same arm holds both the correct belief and the stale one.
correctgenerator client { engineType } The same-scheme invented sibling is caught: "engineMode = \"wasm\" — I do not have confident memory of engineMode ever being a documented, real Prisma schema key at all (as distinct from engineType). … this line looks fabricated." Correct — engineMode is a key prisma ships at no release, and the generator swallows it silently (LF39h).
correct TASK 4 declines rather than inventing a release: "I can't responsibly name a specific release number or date … that's a level of changelog precision I don't actually have memorized, and I'd rather say so than invent a version number." Direct (d) declines all four releases including the poison rung 6.22.0.

Sources

Battery specification: prompts/prisma.md in the studio repo. Every finding above also carries its own citation.