What Claude Opus 5 gets wrong about prisma — battery v1, tested 2026-08-31

Run prisma--claude-opus-5--v1--2026-08-31 · self-test: the subject is the operator

Summary

The sharpest measurement in the Index so far. Opus 5 can describe Prisma 7.0.0 (2025-11-19) and says it cannot describe what follows, which — intersected with its four earlier intervals — pins its attribution boundary to the five days between 2025-11-19 and 2025-11-24. Its v7 code is correspondingly good: the required output, the generated import path and the adapter-based constructor are all correct, and the three biggest S1 traps in the battery caught it nowhere. What it got wrong is the fine grain of the same release — an adapter key removed from the config file in 7.0.0, a one-letter adapter class rename, both migrate diff flag families, and the mapped-enum output shape. Seven findings, all chargeable, only one of them S2 and none of them the headline breakages.

SubjectClaude Opus 5 claude-opus-5, Anthropic
Invoked asAgent tool, model alias "opus"
Cutoff the model states2026-05
Newest prisma release it could place7.0.0 · 2025-11-19 (~5 month lag)
Oldest prisma release it could not place7.1.0 · 2025-12-03 (so this run brackets the subject’s boundary to 2025-11-19 – 2025-12-03)
In its own words"Most recent release whose contents I can actually describe: Prisma 7.0, which I place at roughly October–November 2025 (moderate confidence on the composition, lower confidence on the exact date) ... First release I know only as a version number, with no idea of its contents: roughly 7.2 onward. I can describe 7.0 with moderate confidence, I could bluff at 7.1 but shouldn't."
Library at test timeprisma 7.10.0 (npm), verified 2026-08-31
Batteryprisma/v1 · 10 tasks, 4 direct questions · probe window 6.18.0 to 7.0.0
Tool uses during test0 (a run with any tool use is void — we measure training knowledge, not retrieval)
Tested2026-08-31
Findings6, of which 6 chargeable (and 1 retracted, kept below)
this run as JSON write-up (markdown) all prisma findings method

Findings

F1 · prisma.config.ts written with an adapter key, removed in the same release that made the file mandatory

S1breaks-build · prisma.config.ts adapter key · removed · changed in prisma 7.0.0 (2025-11-19) · chargeable

What the model believes

Produced a prisma.config.ts containing adapter: () => new PrismaPg({ connectionString: process.env.DATABASE_URL! }) and described the file's job as including "how the CLI (migrate, studio, db push) connects when you're using driver adapters".

What it wrote
export default defineConfig({
  schema: 'prisma/schema.prisma',
  migrations: { path: 'prisma/migrations', seed: 'tsx prisma/seed.ts' },
  adapter: () => new PrismaPg({ connectionString: process.env.DATABASE_URL! }),
})
What works on prisma 7.10.0
export default defineConfig({
  schema: 'prisma/schema.prisma',
  migrations: { path: 'prisma/migrations', seed: 'tsx prisma/seed.ts' },
  datasource: { url: env('DATABASE_URL') },
})
Impact

The CLI config carries a key 7.0.0 removed and lacks the datasource block that replaced it, so the migration commands the same answer prescribes have no connection string to use.

Scope note

The subject hedged the neighbouring key names ("I'm less sure of the exact key names for the rest — whether it's migrations or migrate") but stated adapter as one of the three it was confident about. Charged under the code-vs-claim rule: the file as written does not work.

Verified against

F2 · Connection string left in the schema's datasource block rather than the config file

S3deprecated · datasource url · removed · changed in prisma 7.0.0 (2025-11-19) · chargeable

What the model believes

"Where it lives: in .env at the repo root as DATABASE_URL, referenced from schema.prisma via env("DATABASE_URL")" — with shadowDatabaseUrl shown in the same block, commented out.

What it wrote
datasource db {
  provider          = "postgresql"
  url               = env("DATABASE_URL")
  // shadowDatabaseUrl = env("SHADOW_DATABASE_URL")
}
What works on prisma 7.10.0
datasource db {
  provider = "postgresql"
}

// prisma.config.ts
//   datasource: { url: env('DATABASE_URL'), shadowDatabaseUrl: env('SHADOW_DATABASE_URL') }
Impact

Survives today — the upgrade guide calls these fields deprecated rather than removed — but it is the v6 arrangement, and combined with F1 it leaves the project with no datasource the CLI is meant to read.

Scope note

Scored S3, not S1: the 7.0.0 notes say the URL "is now configured in the config file" while the upgrade guide says the schema fields are "deprecated". Where two vendor pages differ in force, the Index takes the weaker claim.

Verified against

F3 · SQLite adapter imported under its pre-7.0.0 class name

S1breaks-build · PrismaBetterSQLite3 · renamed · changed in prisma 7.0.0 (2025-11-19) · chargeable

What the model believes

"import { PrismaBetterSQLite3 } from '@prisma/adapter-better-sqlite3'" — hedged as "what I remember from the 6.6-era adapter; if the import fails, check the package's named export".

What it wrote
import { PrismaBetterSQLite3 } from '@prisma/adapter-better-sqlite3'
What works on prisma 7.10.0
import { PrismaBetterSqlite3 } from '@prisma/adapter-better-sqlite3'
Impact

The named import does not exist in the v7 package; the smallest script in the battery fails to start.

Scope note

The hedge names a verification step but not the correct spelling, so the code-vs-claim rule charges it. It is the finest-grained miss in the run: one letter case.

Verified against

F4 · migrate diff invoked with both removed flag families

S1breaks-build · prisma migrate diff · renamed · changed in prisma 7.0.0 (2025-11-19) · chargeable

What the model believes

Gave --from-url "$DATABASE_URL" --to-schema-datamodel prisma/schema.prisma --script as "the exact command", plus three variants built on the same two flags, with no hedge.

What it wrote
npx prisma migrate diff \
  --from-url "$DATABASE_URL" \
  --to-schema-datamodel prisma/schema.prisma \
  --script
What works on prisma 7.10.0
npx prisma migrate diff \
  --from-config-datasource \
  --to-schema prisma/schema.prisma \
  --script
Impact

Unknown-flag error. This is the answer most likely to be pasted straight into a CI drift gate, which the subject explicitly proposed.

Verified against

F6 · Set a MongoDB project up on the version that dropped MongoDB

S4wrong-metadata · MongoDB support · removed · changed in prisma 7.0.0 (2025-11-19) · chargeable

What the model believes

Produced a full MongoDB setup on the v7 prisma-client generator, then flagged: "I am not confident that MongoDB is on the Rust-free path in 7.x ... If you're weighing 7 vs. 6.x, confirm MongoDB's status in the 7 release notes before committing."

What it wrote
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}

datasource db {
  provider = "mongodb"
  url      = env("DATABASE_URL")
}
What works on prisma 7.10.0
// Stay on Prisma 6 for MongoDB:
//   npm i -D prisma@6
//   npm i @prisma/client@6
Impact

A MongoDB team following this ends up on a major version that does not support their database, having been told the risk is a possibly-lagging connector rather than a removal.

Scope note

The strongest hedge in the run — it named the right document to check and the right decision point, without naming the answer. Charged S4 rather than S1 because the defect is version selection, and recorded here with the hedge quoted so a reader can weigh it.

Verified against

F7 · Version knowledge stops at 7.0.0, five months before its own stated cutoff

S4wrong-metadata · version-fact · changed in prisma 7.1.0 (2025-12-03) · chargeable

Anchored to 7.1.0 (2025-12-03), the first release the subject says it cannot describe — not to the current release. 7.1.0 precedes the stated 2026-05 cutoff, as do seven further releases up to 7.8.0 (2026-04-22).

What the model believes

"First release I know only as a version number, with no idea of its contents: roughly 7.2 onward. I can describe 7.0 with moderate confidence, I could bluff at 7.1 but shouldn't ... Everything you'd want to know about Prisma between roughly December 2025 and today is a hole in my knowledge."

Impact

Nine months of releases — 7.1 through 7.10, including the 7.4.0 query-plan cache — are invisible. The subject states this itself and explains the mechanism, which is the ideal behaviour; it is charged because the gap is real and dated, not because it was concealed.

Verified against

F5 · Claims the generated enum object holds member names, not the mapped database values (retracted)

Retracted 2026-09-03. The subject was right and this Index was wrong. Prisma reverted the 7.0.0 mapped-enum change in 7.3.0 (2026-01-21), so at every release from 7.3.0 onward — including the 7.10.0 that was current when this run was scored — the generated enum object maps each member name to itself, which is what the subject wrote. The charge rested on the 7.0.0 release note and was never verified against a generated client. See JOURNAL/048. This charge is excluded from every count on this site, from the prisma correction pack and from the MCP tools. The text below is exactly as it was published and is not edited to match the retraction.

S2silently-wrong · generated enum values · behavior-changed · changed in prisma 7.0.0 (2025-11-19) · chargeable

What the model believes

"The key thing that surprises people: your code uses the Prisma-side names, never the mapped database strings" — followed by a generated object mapping MixplatSms: 'MixplatSms' and a comment marking provider: 'mixplat/sms' as a type error.

What it wrote
export const PaymentProvider = {
  MixplatSms: 'MixplatSms',
  InternalToken: 'InternalToken',
} as const
What works on prisma 7.10.0
export const PaymentProvider: {
  MixplatSMS: 'mixplat/sms'
  InternalToken: 'internal/token'
}
Impact

Nothing errors. Any comparison against the member-name string, or any payload that serialises the enum, sees the mapped database value instead — the failure surfaces at the edge of the system, not at the query.

Scope note

Charged against the shape 7.0.0 documents. What the pre-7 generator emitted is not separately verified here; the finding is about the subject's claim about today, per the code-vs-claim rule.

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
correctgenerator client { output } Wrote the prisma-client generator with a required output path, imported PrismaClient from the generated path, and constructed it with a PrismaPg adapter — the three v7 changes the battery was built to catch, all correct.
correctprisma.config.ts Knew prisma.config.ts exists, is the config surface, replaces the package.json#prisma key, and does not auto-load .env — "the single most common upgrade surprise". Only the adapter key inside it was wrong (F1).
correctpostinstall prisma generate Did not rely on implicit generation anywhere: the Dockerfile runs npx prisma generate explicitly, and the answer explains that the generated client compiles into dist like ordinary source.
imprecisionnew PrismaClient({ datasourceUrl }) Question (d) listed datasourceUrl and datasources as constructor options, then immediately flagged: "I believe datasourceUrl/datasources are deprecated or removed in 7 in favor of adapter ... Verify before relying on datasourceUrl on 7." (Question (d) is a belief probe, leading by construction, and the hedge names the correct fix. Under the code-vs-claim rule this is an imprecision, not a finding. No task code used either option.)
context— Every v6-specific block in the run was labelled as such — "On Prisma 6.x, drop this file entirely", "If you're on Prisma 6.x (client generated into node_modules)". The v6 escape hatch in the battery's scoring notes applies: v6 code presented as v6 is not a finding. (Correctly scoped to the version it belongs to.)

Open questions from this run

Sources

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