prisma correction pack · for projects on prisma@7 / @prisma/client@7

What we actually measured

5 Claude models were asked for idiomatic prisma code with no tools, purely from training knowledge. 50 reproduced failures across 22 runs, each verified against the release that broke the belief.

A recent cutoff is not a defence. Every model here loses track of this library's release history well before the date it states as its own cutoff, and the stopping points cluster far tighter than the cutoffs do.

Read that column precisely. It is the newest prisma release whose contents the model can correctly attribute to that release — not the newest prisma feature it knows. Past that point a model will often write working code with a newer API while naming the wrong release for it, and that guess runs early — it names a release older than the one that shipped the feature. So the question this pack answers is not "does the model know this API" but "can it be trusted about which version the API arrived in" — which is the question that matters when you are pinned to a version.

Latest prisma is 7.10.0 (verified 2026-09-06). Separately from the corrections below, 3 of 22 runs recorded a version fact — the model named a current prisma version from memory and was behind. If a model states a version without checking, assume it is behind and check the registry.

How to read an entry

Every entry ends with a Reproduced against line. Where it names models, we have the generated code that got it wrong, dated, with the model's own words in the run write-up. Where it says no model yet, the correction is verified from the release notes but nothing has been probed for it — it is a fix, not a measurement, and the pack says so rather than blurring the two.

The section an entry sits in is the worst case if you act on the stale belief. The severity in brackets after a model's name is what that particular model's output actually did, which can be milder — a model can hold the wrong belief and still, on the day, write code that runs.

The corrections

Breaks the build, or throws at runtime

Act on the stale belief here and the code does not run. Fix these first.

prisma migrate diff --from-schema-datamodel

Renamed in prisma 7.0.0 (2025-11-19)

prisma migrate diff renamed its inputs. --from/to-schema-datamodel became --from/to-schema; --from/to-url and --from/to-schema-datasource became --from/to-config-datasource, which reads the datasource out of prisma.config.ts. Diffing two different URLs is no longer possible, because only one config applies at a time.

The stale belief: That you diff a schema file against a live database with --from-schema-datamodel ./prisma/schema.prisma --to-url $DATABASE_URL.

# Stale
npx prisma migrate diff \
  --from-schema-datamodel prisma/schema.prisma \
  --to-url "$DATABASE_URL" \
  --script

# Current
npx prisma migrate diff \
  --from-schema prisma/schema.prisma \
  --to-config-datasource \
  --script

Reproduced against: Claude Fable 5 (S1), Claude Opus 5 (S1), Claude Sonnet 5 (S1) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Removal of prisma migrate flags · 2025-11-19

engineType

Removed in prisma 7.0.0 (2025-11-19)

The client engines are gone: LibraryEngine (engineType = "library"), BinaryEngine (engineType = "binary"), DataProxyEngine and ReactNativeEngine, and with them the PRISMA_CLIENT_ENGINE_TYPE, PRISMA_QUERY_ENGINE_BINARY, PRISMA_QUERY_ENGINE_LIBRARY and PRISMA_CLI_QUERY_ENGINE_TYPE environment variables. Prisma 7's query compiler is a WebAssembly module inside the client.

The stale belief: That query execution goes through a Rust engine binary you select with engineType and can tune with PRISMA_* environment variables.

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

// Current
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}

generator.runtime = "react-native" was removed in the same release.

Reproduced against: Claude Fable 5 (S2), Claude Sonnet 5 (S2) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Removed Client Engines · 2025-11-19

generator client { output }

New requirement in prisma 7.0.0 (2025-11-19)

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.

The stale belief: That prisma generate writes into node_modules/.prisma/client and output is an optional advanced setting.

// Stale
generator client {
  provider = "prisma-client-js"
}

// Current
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}

The vendor recommends generating inside your own source tree (for example src/) so the output is handled by your existing tooling like any other code.

Reproduced against: Claude Fable 5 (S1), Claude Sonnet 5 (S1) — prisma/v1, 2026-08-31.

Source: Upgrade to Prisma ORM 7 — Schema changes · Prisma 7.0.0 release notes — Generated Client and types move out of node_modules · 2025-11-19

import { PrismaClient } from '@prisma/client'

Behaviour changed in prisma 7.0.0 (2025-11-19)

Import the client from your generated output path, not from @prisma/client. This follows from output being required: the generated client is now a file in your repository.

The stale belief: That @prisma/client is the import path — true from Prisma 2 through 6.

// Stale
import { PrismaClient } from '@prisma/client'

// Current
import { PrismaClient } from './generated/prisma/client'

The exact specifier depends on where you set output and where the importing file lives. AUDIT 2026-09-02 (JOURNAL/038): it also depends on your module resolution. Under moduleResolution: node16 or nodenext — the setting an ESM project takes, and LF19 requires "type": "module" — the extensionless form is TS2835 and the import must be written './generated/prisma/client.js'. Under bundler (Next.js, Vite) the extensionless form is correct. Both were compiled on 7.0.0 and 7.10.0.

Reproduced against: Claude Fable 5 (S1), Claude Sonnet 5 (S1) — prisma/v1, 2026-08-31.

Source: Upgrade to Prisma ORM 7 — Schema changes

new PrismaClient()

Removed in prisma 7.0.0 (2025-11-19)

Constructing the client with no arguments is no longer supported. Prisma 7 requires either a driver adapter or an accelerateUrl. new PrismaClient() and new PrismaClient({}) were both removed in 7.0.0; 7.1.0 added a dedicated error message for the no-argument case, so the failure is a runtime throw at construction, not a type error you will notice in review.

The stale belief: That the client reads the datasource out of schema.prisma and needs nothing at construction — true for the whole of Prisma 1 through 6.

// Stale
import { PrismaClient } from '@prisma/client'

const prisma = new PrismaClient()

// Current
import { PrismaClient } from './generated/prisma/client'
import { PrismaPg } from '@prisma/adapter-pg'

const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })
export const prisma = new PrismaClient({ adapter })

The adapter package depends on the database: @prisma/adapter-pg for Postgres, @prisma/adapter-better-sqlite3 for SQLite, @prisma/adapter-mariadb for MySQL/MariaDB.

Reproduced against: Claude Fable 5 (S1), Claude Sonnet 5 (S1) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Prisma Client changes · 2025-11-19 · Upgrade to Prisma ORM 7 — Driver adapters

package.json prisma key

Removed in prisma 7.0.0 (2025-11-19)

The prisma key in package.json is no longer read. Schema path and seed command move to prisma.config.ts (schema and migrations.seed).

The stale belief: That the seed script and a custom schema path are declared in a prisma block in package.json — the documented location since 2.18.

// Stale
{
  "prisma": {
    "schema": "./custom-path/schema.prisma",
    "seed": "tsx ./prisma/seed.ts"
  }
}

// Current
// Current — the key is not read. Declare these in prisma.config.ts instead:
//   export default defineConfig({
//     schema: 'prisma/schema.prisma',
//     migrations: { seed: 'tsx prisma/seed.ts' },
//   })

Reproduced against: Claude Fable 5 (S1), Claude Sonnet 5 (S1) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Removed support for prisma keyword in package.json · 2025-11-19

prisma generate --no-engine

Removed in prisma 7.0.0 (2025-11-19)

prisma generate no longer accepts --no-engine, --data-proxy, --accelerate or --allow-no-models. The first three existed to strip or swap the Rust query engine, which Prisma 7 does not ship at all.

The stale belief: That prisma generate --no-engine is the way to shrink a serverless bundle — the standard Accelerate/edge deployment advice for v5 and v6.

# Stale
npx prisma generate --no-engine

# Current
npx prisma generate

Reproduced against: Claude Fable 5 (S1), Claude Sonnet 5 (S1) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Removal of prisma generate flags · 2025-11-19

prisma.config.ts

New requirement in prisma 7.0.0 (2025-11-19)

prisma.config.ts is required for any project that runs introspection or migrations. The datasource URL lives there, not in schema.prisma. The file itself was introduced as opt-in in 6.18.0 and became mandatory in 7.0.0.

The stale belief: That project configuration is split between schema.prisma and a prisma key in package.json, with no config file in the picture.

import 'dotenv/config'
import { defineConfig, env } from 'prisma/config'

export default defineConfig({
  schema: 'prisma/schema.prisma',
  migrations: { seed: 'tsx prisma/seed.ts' },
  datasource: { url: env('DATABASE_URL') },
})

Reproduced against: Claude Fable 5 (S1), Claude Sonnet 5 (S1) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Schema and config file updates · 2025-11-19 · Prisma 6.18.0 release notes — prisma init now creates a prisma.config.ts automatically · 2025-10-22

datasource db { url }

Removed in prisma 7.0.0 (2025-11-19)

url and shadowDatabaseUrl are configured in prisma.config.ts in Prisma 7, and directUrl has been removed outright. If you used directUrl for migrations, put that value in the config file's url — that is the connection string the CLI uses for migrations.

The stale belief: That the datasource block in schema.prisma carries url, directUrl and shadowDatabaseUrl, read from .env via env().

// Stale
datasource db {
  provider          = "postgresql"
  url               = env("DATABASE_URL")
  directUrl         = env("DIRECT_URL")
  shadowDatabaseUrl = env("SHADOW_URL")
}

// Current
datasource db {
  provider = "postgresql"
}

// and in prisma.config.ts:
//   datasource: { url: env('DATABASE_URL'), shadowDatabaseUrl: env('SHADOW_URL') }

Reproduced against: Claude Opus 5 (S3) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Schema changes · 2025-11-19

driver adapter class names

Renamed in prisma 7.0.0 (2025-11-19)

The driver adapter classes were renamed to a consistent casing in 7.0.0: PrismaBetterSQLite3 -> PrismaBetterSqlite3, PrismaD1HTTP -> PrismaD1Http, PrismaLibSQL -> PrismaLibSql, PrismaNeonHTTP -> PrismaNeonHttp.

The stale belief: The v6 spellings, which are what any model that learned driver adapters before 7.0.0 will emit.

// Stale
import { PrismaBetterSQLite3 } from '@prisma/adapter-better-sqlite3'

// Current
import { PrismaBetterSqlite3 } from '@prisma/adapter-better-sqlite3'

Reproduced against: Claude Opus 5 (S1) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Driver Adapter naming updates · 2025-11-19

prisma.config.ts engine key

Removed in prisma 7.0.0 (2025-11-19)

The engine: 'js' | 'classic' and adapter keys in prisma.config.ts were removed in 7.0.0. They existed only in the 6.18.0-6.19.x window, where the config file was opt-in and engine: "classic" selected the Rust engine that 7.0.0 deleted.

The stale belief: That a Prisma config file needs an engine key, and that adapter is configured there rather than passed to the client constructor.

// Stale
export default defineConfig({
  engine: 'classic',
  datasource: { url: env('DATABASE_URL') },
})

// Current
export default defineConfig({
  datasource: { url: env('DATABASE_URL') },
})

This key is a dating fingerprint: code containing it was learned from a release published between 2025-10-22 and 2025-11-19, a 28-day window.

Reproduced against: Claude Opus 5 (S1) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Schema and config file updates · 2025-11-19 · Prisma 6.18.0 release notes — Support for defining your datasource in prisma.config.ts · 2025-10-22

@@index([...], include: [...])

Added in prisma 7.4.0 (2026-02-11)

Prisma's @@index has no include: argument — there is no schema-level way to declare a PostgreSQL covering index (CREATE INDEX ... INCLUDE (...)). @@unique likewise has no nullsNotDistinct: argument. Both are rejected by the schema validator with No such argument. at 7.4.0 and at 7.10.0. This entry exists because 7.4.0 did add a new @@index/@@unique argument — where: (LF26) — and a model that has absorbed that fact can over-extend it into a family of index arguments that were never added.

The stale belief: That because Prisma 7.4 extended @@index/@@unique with index-shaping arguments, it also accepts include: for covering-index payload columns, or nullsNotDistinct: on @@unique.

// Stale
model User {
  id    Int    @id @default(autoincrement())
  email String
  name  String

  @@index([email], include: [name])
}

// Current
// There is no schema-level covering index. Declare the plain index and add the
// INCLUDE clause in SQL, or widen the index key if the payload column is small.
model User {
  id    Int    @id @default(autoincrement())
  email String
  name  String

  @@index([email, name])
}

VERIFIED BY EXECUTION 2026-09-05. @@index([email], include: [name]) and @@unique([email], nullsNotDistinct: true) are each rejected by prisma validate with No such argument. at prisma@7.4.0 and at prisma@7.10.0. Same run, same file, the only difference being the argument name: where: validates and include:/nullsNotDistinct: do not, so the rejection is about the argument and not about the schema around it. This is a NEGATIVE claim in the machine-checkable form (the tailwindcss LF30 / better-auth LF10 shape): the assertion is that the argument does not exist, and it is checked by the shipped validator's own enumeration of what it accepts rather than by the absence of a sentence in a changelog.

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: prisma 7.10.0, shipped package — prisma validate on the stale_code schema above · Prisma 7.4.0 release notes — Partial Indexes (Filtered Indexes) Support · 2026-02-11

@prisma/client-runtime-utils

New requirement in prisma 7.0.0 (2025-11-19)

If you stay on the prisma-client-js provider in Prisma 7 while using the now-required output option, you must install @prisma/client-runtime-utils as well. It is a new package with no v6 equivalent, so nothing trained before 2025-11-19 will mention it.

The stale belief: That prisma and @prisma/client are the only two packages a Prisma project needs.

npm install @prisma/client-runtime-utils   # prisma-client-js users only

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Prisma 7.0.0 release notes — Generated Client and types move out of node_modules · 2025-11-19

/wasm export path

Renamed in prisma 7.0.0 (2025-11-19)

For prisma-client-js users, the /wasm export was renamed to /edge, and /edge changed meaning: it now means edge JS runtimes (Cloudflare, Vercel Edge) rather than Prisma Accelerate.

The stale belief: That @prisma/client/edge is the Accelerate entry point and @prisma/client/wasm is the edge-runtime one — the v5/v6 arrangement.

// Stale
import { PrismaClient } from '@prisma/client/wasm'

// Current
import { PrismaClient } from '@prisma/client/edge'

SCOPED 2026-09-02 (JOURNAL/038), against both generators. @prisma/client/edge carries a PrismaClient export only for projects still on the prisma-client-js generator, whose output is written into node_modules/.prisma/client — edge.d.ts is nothing but export * from '.prisma/client/edge'. Generate with the prisma-client generator that LF4 and LF6 prescribe and node_modules/.prisma is never created, so this import fails with TS2305, no exported member. Both directions were generated and type-checked on 7.0.0. If you are on the current generator there is no /edge entry point at all: import from your own generated output and reach the edge runtime through a driver adapter. The rename this entry records is real — /wasm is gone from the 7.0.0 export map — but it is a rename inside the deprecated path.

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Prisma 7.0.0 release notes — Miscellaneous · 2025-11-19 · @prisma/client 7.0.0, shipped package — edge.d.ts

accelerateUrl

Added in prisma 7.0.0 (2025-11-19)

Accelerate users pass accelerateUrl to the constructor instead of an adapter, and keep the withAccelerate() extension. Do not pass a prisma:// or prisma+postgres:// URL to a driver adapter — PrismaPg expects a direct connection string and will fail on it.

The stale belief: That Accelerate is configured purely by putting the prisma:// URL in DATABASE_URL and adding the extension, with no constructor option.

// Stale
const prisma = new PrismaClient().$extends(withAccelerate())

// Current
const prisma = new PrismaClient({
  accelerateUrl: process.env.DATABASE_URL!,
}).$extends(withAccelerate())

CORRECTED 2026-09-02 (JOURNAL/038), against the generated client. The API claim holds — accelerateUrl is a declared constructor option — but the snippet as published did not compile under strict: process.env.DATABASE_URL is string | undefined and accelerateUrl is declared string, so a reader copying it got TS2345. The non-null assertion is now in the code. Reproduced identically on 7.0.0 and 7.10.0. The declaration also settles a second point the entry did not state: accelerateUrl and adapter are mutually exclusive (each is ?: never in the other's arm of the union), so an Accelerate client does not take a driver adapter as well.

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Prisma 7.0.0 release notes — For Prisma Accelerate users · 2025-11-19 · Upgrade to Prisma ORM 7 — Prisma Accelerate · prisma 7.0.0, shipped package — generated PrismaClientOptions

ESM and toolchain minimums

New requirement in prisma 7.0.0 (2025-11-19)

Prisma 7 ships as an ES module and requires Node >= 20.19.0 and TypeScript >= 5.4.0. Set "type": "module" in package.json, and module/moduleResolution to ESNext/bundler in tsconfig.json.

The stale belief: That Prisma is CommonJS and drops into any Node project without touching package.json or tsconfig.json.

{
  "type": "module"
}

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Upgrade to Prisma ORM 7 — ESM support / Prerequisites

metrics preview feature

Removed in prisma 7.0.0 (2025-11-19)

The deprecated metrics preview feature was removed in 7.0.0. Read pool metrics from the underlying driver instead — for example the pg pool.

The stale belief: That previewFeatures = ["metrics"] plus prisma.$metrics.json() is how you instrument a Prisma app.

// Stale
generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["metrics"]
}

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Prisma 7.0.0 release notes — Deprecated metrics feature has been removed · 2025-11-19

new PrismaClient({ datasources })

Removed in prisma 7.0.0 (2025-11-19)

The datasources constructor option is gone. Overriding the connection string at construction time is done by configuring the driver adapter you now have to pass anyway.

The stale belief: That new PrismaClient({ datasources: { db: { url } } }) is how you point one client at a different database — the documented override for the whole v2-v6 era.

// Stale
const prisma = new PrismaClient({
  datasources: { db: { url: process.env.DATABASE_URL } },
})

// Current
const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })
const prisma = new PrismaClient({ adapter })

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Prisma 7.0.0 release notes — Prisma Client changes · 2025-11-19

new PrismaClient({ datasourceUrl })

Removed in prisma 7.0.0 (2025-11-19)

The datasourceUrl constructor option, added in 5.2 as the shorthand for datasources, was removed in 7.0.0 along with it. Pass the connection string to the driver adapter instead.

The stale belief: That datasourceUrl is the current shorthand for overriding the connection string at runtime.

// Stale
const prisma = new PrismaClient({ datasourceUrl: process.env.DATABASE_URL })

// Current
const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })
const prisma = new PrismaClient({ adapter })

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Prisma 7.0.0 release notes — Prisma Client changes · 2025-11-19

prisma introspect

Removed in prisma 7.0.0 (2025-11-19)

The deprecated prisma introspect command was removed in 7.0.0 — prisma db pull is the only spelling. db pull also lost its undocumented --url flag and its --local-d1 flag.

The stale belief: That prisma introspect still exists as an alias, which it did (deprecated) from 3.0 through 6.x.

# Stale
npx prisma introspect

# Current
npx prisma db pull

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Prisma 7.0.0 release notes — Miscellaneous · 2025-11-19

Runs, but is silently wrong

Nothing errors. The behaviour is simply not what a model trained earlier will tell you.

@prisma/sqlcommenter-query-insights

Added in prisma 7.2.0 (2025-12-17)

Prisma ships a first-party SQLCommenter plugin. @prisma/sqlcommenter-query-insights appends query-insights metadata to statements as a trailing SQL comment, so queries seen in the database’s own statistics and log views can be attributed back to the application code that issued them. Its first stable release is 7.2.0. Before it existed the only honest answer was to write the interception yourself at the driver-adapter layer, which is what every draw in this battery produced.

The stale belief: That Prisma’s first-party observability surface is OpenTelemetry tracing (@prisma/instrumentation) and metrics only, that SQLCommenter has adapters for Knex/Sequelize/pg but not Prisma, and that the ORM-generated SQL is therefore unreachable from application code.

// Stale
// wrap the driver adapter by hand and append the comment yourself
class CommentingPool extends Pool {
  query(config, values, cb) {
    const suffix = sqlcommenterSuffix()
    if (typeof config === "string") config += suffix
    else if (config?.text) config = { ...config, text: config.text + suffix }
    return super.query(config, values, cb)
  }
}

// Current
// the first-party plugin, released with 7.2.0
// npm i @prisma/sqlcommenter-query-insights

The correction here is deliberately the package name and nothing more. This Index has not driven the plugin against a database, so it states that the package exists, what it is for and when it shipped — all three read off the registry and the release notes — and does not put a configuration snippet in a subject’s mouth that it has not executed. The registry time map gives 7.2.0 on 2025-12-17 as the first stable version; the only earlier publishes are a 0.0.1 placeholder on 2025-12-04 and 7.2.0-dev.* pre-releases.

Reproduced against: Claude Fable 5.1 (S2), Claude Opus 5 (S2), Claude Sonnet 5 (S2) — prisma/v5-a, 2026-09-06; prisma/v5-c, 2026-09-06; prisma/v5-e, 2026-09-06.

Source: Prisma ORM 7.2.0 release notes — SQL Commenter plugin · 2025-12-17 · npm registry metadata for @prisma/sqlcommenter-query-insights — first stable release 7.2.0, published 2025-12-17 · 2025-12-17

queryPlanCacheMaxSize

Added in prisma 7.8.0 (2026-04-22)

The PrismaClient constructor accepts queryPlanCacheMaxSize?: number, which bounds the query plan cache. Passing 0 disables the cache entirely; omitting the option uses the default size. It is an ordinary documented optional property of the client options type — not an internal, and not an environment variable.

The stale belief: That the query plan cache is an internal detail of the query compiler with no user-facing size or disable knob, so the only lever on its memory use is reducing the number of distinct query shapes — and, in the stronger form, that passing queryPlanCacheMaxSize is an excess-property type error or makes the constructor throw on an unknown key.

// Stale
// the stronger form of the belief, offered when reviewing working code:
// "PrismaClient validates its options and throws on unknown keys,
//  so this line would fail at construction time"
const prisma = new PrismaClient({ adapter })

// Current
const prisma = new PrismaClient({
  adapter,
  queryPlanCacheMaxSize: 100, // 0 disables the cache entirely
})

VERIFIED BY TYPE DECLARATION 2026-09-06. @prisma/client runtime/client.d.ts has no occurrence of queryPlanCacheMaxSize at 7.4.0, 7.5.0, 7.6.0 or 7.7.0, and declares it at 7.8.0 and 7.10.0 with a documentation comment and a usage example. The bisection matters here because the cache is older than the option: query plan caching is a 7.4.0 feature — it is the attribution anchor in prompts/prisma.md § v2 — so a model can know the cache exists and still be four releases behind on whether it can be sized.

Reproduced against: Claude Fable 5.1 (S2), Claude Opus 5 (S2) — prisma/v4-a, 2026-09-06; prisma/v4-c, 2026-09-06.

Source: Prisma 7.8.0 release notes — Prisma Client features · 2026-04-22 · @prisma/client 7.8.0, shipped package — runtime/client.d.ts

prisma bootstrap

Added in prisma 7.7.0 (2026-04-07)

The Prisma CLI has a bootstrap command that sequences the whole Prisma Postgres setup in one interactive flow: init or scaffold from one of ten starter templates, link to a database, install missing dependencies, run migrate dev, run generate, and run db seed. It detects project state and runs only the steps that are needed, prompts before each side-effecting step, and skips completed steps when re-run. It takes --template, and a non-interactive --api-key / --database form for CI.

The stale belief: That there is no single Prisma command that walks the whole setup, and that a new project always needs a hand-assembled sequence of npm install, prisma init, prisma migrate dev, prisma generate and prisma db seed.

# Stale
# offered as "the whole path", with the claim that no single command exists:
npm i -D prisma && npm i @prisma/client @prisma/adapter-pg pg
npx prisma init --db
npx prisma migrate dev --name init
npx prisma db seed

# Current
npx prisma@latest bootstrap
# with a starter template:
npx prisma@latest bootstrap --template nextjs
# non-interactive, for CI:
npx prisma@latest bootstrap --api-key "$PRISMA_API_KEY" --database "db_abc123"

VERIFIED BY EXECUTION 2026-09-06. prisma --help was run from the shipped CLI at 7.4.0 through 7.10.0. bootstrap Bootstrap a Prisma Postgres project is absent from the command table at 7.6.0 and present at 7.7.0, which pins the introducing release from the artifact. The workaround sequence in stale_code does work, so this is a false claim about what the CLI offers rather than broken code — S2.

Reproduced against: Claude Fable 5.1 (S2), Claude Opus 5 (S2) — prisma/v4-a, 2026-09-06; prisma/v4-c, 2026-09-06.

Source: Prisma 7.7.0 release notes — prisma bootstrap command · 2026-04-07 · prisma 7.7.0, shipped package — output of prisma --help

new PrismaPg(connectionString)

Added in prisma 7.6.0 (2026-03-27)

new PrismaPg(...) accepts a bare PostgreSQL connection string as its first argument. The constructor signature widened from pg.Pool | pg.PoolConfig to pg.Pool | pg.PoolConfig | string in 7.6.0. The object form still works and is not deprecated; the point is that the string form is not an error.

The stale belief: That PrismaPg takes only a pg.Pool or a pg.PoolConfig-shaped object, so a bare connection string is a type error that has to be wrapped as { connectionString }.

// Stale
// offered as a correction to working code:
const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })

// Current
// both of these compile at 7.6.0 and later:
const adapter = new PrismaPg(process.env.DATABASE_URL!)
const adapter2 = new PrismaPg({ connectionString: process.env.DATABASE_URL })

VERIFIED BY TYPE DECLARATION 2026-09-06. @prisma/adapter-pg was installed at 7.4.0, 7.5.0, 7.6.0, 7.7.0, 7.8.0 and 7.10.0. dist/index.d.ts declares constructor(poolOrConfig: pg.Pool | pg.PoolConfig, options?: PrismaPgOptions | undefined) at 7.4.0 and 7.5.0, and constructor(poolOrConfig: pg.Pool | pg.PoolConfig | string, options?: PrismaPgOptions | undefined) at 7.6.0 through 7.10.0. The added union member is the whole change and it is visible in the published declaration file, so the introducing release is pinned by the artifact rather than by the note. The object form the stale belief insists on is itself correct code, so this is a false claim about a limit and not a broken replacement — S2.

Reproduced against: Claude Fable 5.1 (S2), Claude Opus 5 (S2) — prisma/v4-a, 2026-09-06; prisma/v4-c, 2026-09-06.

Source: Prisma 7.6.0 release notes — Driver Adapters · 2026-03-27 · @prisma/adapter-pg 7.6.0, shipped package — dist/index.d.ts

prisma postgres link

Added in prisma 7.6.0 (2026-03-27)

The Prisma CLI has a postgres command group, and its first member is prisma postgres link, which connects an existing local project to an already-provisioned Prisma Postgres database. Before 7.6.0 there was no such command and attaching a project to an existing database was a manual DATABASE_URL edit. prisma postgres --help at 7.6.0 through 7.10.0 lists exactly one subcommand: link.

The stale belief: That the Prisma CLI has no command for attaching a project to an already-provisioned Prisma Postgres database, and that prisma init --db (which creates a new one) plus a hand-edited .env is the only route.

# Stale
# the workaround, still offered as though it were the only option:
# 1. copy the connection string out of the Prisma Console by hand
# 2. paste it into .env as DATABASE_URL
npx prisma db pull
npx prisma generate

# Current
npx prisma postgres link
# non-interactive:
npx prisma postgres link --api-key "$PRISMA_API_KEY" --database "db_abc123"

VERIFIED BY EXECUTION 2026-09-06. prisma --help was run from the shipped CLI at 7.4.0, 7.5.0, 7.6.0, 7.7.0, 7.8.0 and 7.10.0 in a scratch directory. The postgres entry is absent from the command table at 7.5.0 and present at 7.6.0, which pins the introducing release without relying on the release note. prisma postgres --help at 7.6.0+ prints link Link a local project to a Prisma Postgres database and no other subcommand — which is also what makes prisma postgres branch a safe poison rung. The workaround in stale_code does work, and that is what keeps this S2 rather than S1.

Reproduced against: Claude Fable 5.1 (S2), Claude Opus 5 (S2) — prisma/v4-a, 2026-09-06; prisma/v4-c, 2026-09-06.

Source: Prisma 7.6.0 release notes — CLI · 2026-03-27 · prisma 7.6.0 and 7.10.0, shipped package — output of prisma postgres --help

statementNameGenerator

Added in prisma 7.6.0 (2026-03-27)

@prisma/adapter-pg exposes statementNameGenerator, a PrismaPgOptions callback of type (query: SqlQuery) => string. The returned string is passed as the name property to pg.Client#query(), which is what makes node-postgres cache the underlying prepared statement. The shipped declaration states the default explicitly: with no generator provided, prepared statements are not cached.

The stale belief: That the Prisma pg adapter issues every query unnamed with no supported way to change that, so node-postgres statement caching can never engage and the only route to prepared-statement reuse is running the hot query through a separate pg pool alongside Prisma.

// Stale
// offered as the only route:
// run the hot query through your own pg Pool, outside Prisma, so you can set a name
const pool = new Pool({ connectionString: process.env.DATABASE_URL })
await pool.query({ name: "hot-query", text: "SELECT ...", values: [] })

// Current
const adapter = new PrismaPg(process.env.DATABASE_URL!, {
  statementNameGenerator: (query) => "prisma_" + hashOf(query.sql),
})

VERIFIED BY TYPE DECLARATION 2026-09-06. dist/index.d.ts of the shipped @prisma/adapter-pg has no statementNameGenerator anywhere in PrismaPgOptions at 7.4.0 or 7.5.0, and declares it at 7.6.0 through 7.10.0 together with declare type StatementNameGenerator = (query: SqlQuery) => string. The documentation comment on the option carries the default behaviour, which is the part the stale belief gets right about 7.5.0 and wrong about 7.6.0.

Reproduced against: Claude Fable 5.1 (S2), Claude Opus 5 (S2) — prisma/v4-a, 2026-09-06; prisma/v4-c, 2026-09-06.

Source: Prisma 7.6.0 release notes — Driver Adapters · 2026-03-27 · @prisma/adapter-pg 7.6.0, shipped package — dist/index.d.ts

tx.$transaction()

Added in prisma 7.5.0 (2026-03-11)

$transaction can be called on the interactive transaction client. It was removed from the client deny list in 7.5.0, which added nested transaction rollback via savepoints for SQL databases: if the outer transaction fails, the inner nested one is rolled back with it. The deny list constant itself is the evidence — it reads ["$connect", "$disconnect", "$on", "$transaction", "$extends"] at 7.4.0 and ["$connect", "$disconnect", "$on", "$use", "$extends"] at 7.5.0 and later.

The stale belief: That $transaction is on ITXClientDenyList, so tx.$transaction(...) is a type error and absent at runtime, and that manual SAVEPOINT / ROLLBACK TO SAVEPOINT through $executeRawUnsafe is the only way to nest.

// Stale
// offered as the only route, and as a correction to working code:
await prisma.$transaction(async (tx) => {
  await tx.$executeRawUnsafe("SAVEPOINT sp1")
  try {
    await tx.post.create({ data: { title: "hello", authorId: 1 } })
  } catch {
    await tx.$executeRawUnsafe("ROLLBACK TO SAVEPOINT sp1")
  }
})

// Current
await prisma.$transaction(async (tx) => {
  await tx.user.create({ data: { email: "a@example.com" } })
  await tx.$transaction(async (tx2) => {
    await tx2.post.create({ data: { title: "hello", authorId: 1 } })
  })
})

VERIFIED BY TYPE DECLARATION 2026-09-06. @prisma/client was installed at 7.4.0, 7.5.0, 7.6.0, 7.7.0, 7.8.0 and 7.10.0 and runtime/client.d.ts read at each. declare const denylist contains "$transaction" at 7.4.0 and does not at 7.5.0 through 7.10.0, where "$use" stands in its place; ITXClientDenyList is defined as (typeof denylist)[number] and the interactive transaction client is Omit<..., ITXClientDenyList>, so removal from that one constant is exactly what makes tx.$transaction type-check. This is the type-level form of the 7.5.0 release note. The raw-SQL savepoint workaround still works, so a reader who follows the stale belief loses ergonomics rather than correctness — S2, not S1.

Reproduced against: Claude Fable 5.1 (S2), Claude Opus 5 (S2) — prisma/v4-a, 2026-09-06; prisma/v4-c, 2026-09-06.

Source: Prisma 7.5.0 release notes — Features · 2026-03-11 · @prisma/client 7.5.0, shipped package — runtime/client.d.ts

prisma db push --url

Added in prisma 7.2.0 (2025-12-17)

The datasource connection string can be passed to the schema-push and migration commands directly on the command line. 7.2.0 added --url to prisma db push, prisma db pull and prisma migrate dev, described in the help table as "Override the datasource URL from the Prisma config file". Before 7.2.0 these commands took the URL only from the schema or prisma.config.ts, resolved from the process environment, so the standard advice was to prefix the command with an inline DATABASE_URL=. That advice still works and is not wrong; it is simply no longer the only option, and a model that denies the flag exists will not offer it.

The stale belief: That db push and migrate dev resolve the datasource only from configuration and the environment, and that the long-standing feature request for a URL flag on them is still open — true continuously from Prisma 2 through 7.1.0.

# Stale
DATABASE_URL="$EPHEMERAL_PG_URL" npx prisma db push --skip-generate --accept-data-loss

# Current
npx prisma db push --url "$EPHEMERAL_PG_URL" --skip-generate --accept-data-loss

Bisected against the shipped CLI rather than the release note alone. prisma db push --help lists no --url at 5.22.0, 6.19.0, 7.0.0 or 7.1.0, and lists it at 7.2.0; migrate dev and db pull behave the same way across those versions. db pull is the one of the three with a pre-history — prisma introspect --url existed in the 2.x era — but the flag is absent from db pull --help at 5.22.0, 6.19.0, 7.0.0 and 7.1.0, so for every version this Index covers 7.2.0 is where it appears. The three sibling commands that took a URL throughout, and which subjects reliably name instead, are db execute --url, migrate diff --from-url and migrate diff --to-url.

Reproduced against: Claude Fable 5.1 (S2), Claude Opus 5 (S2) — prisma/v5-c, 2026-09-06; prisma/v5-e, 2026-09-06.

Source: Prisma ORM 7.2.0 release notes · 2025-12-17 · prisma@7.2.0 shipped CLI — prisma db push --help lists --url Override the datasource URL from the Prisma config file; the same table at 7.1.0 does not · 2025-12-17

automatic .env loading

Behaviour changed in prisma 7.0.0 (2025-11-19)

The Prisma CLI no longer loads .env files by itself. Load them yourself — import 'dotenv/config' at the top of prisma.config.ts is the vendor's own example.

The stale belief: That putting DATABASE_URL in .env is enough for prisma migrate to find it, which it was for the whole v2-v6 era — no load step anywhere in the project.

import 'dotenv/config'
import { defineConfig, env } from 'prisma/config'

export default defineConfig({ datasource: { url: env('DATABASE_URL') } })

Reproduced against: Claude Fable 5 (S2), Claude Sonnet 5 (S2) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Explicit loading of environment variables · 2025-11-19

@@index([...], where: ...) / @@unique([...], where: ...)

Added in prisma 7.4.0 (2026-02-11)

Prisma can express a partial (filtered) index in the schema since 7.4.0. Put partialIndexes in previewFeatures and pass where: to @@index or @@unique. Two predicate forms are accepted: a type-safe object literal, which supports only field equality and not ({ published: true }, { deletedAt: { not: null } } — no gt/lt/in, no AND/OR), and raw("...") for any connector-specific SQL predicate. Supported on PostgreSQL, SQLite, SQL Server and CockroachDB; the schema validator rejects a where: index on MySQL with "Partial indexes (with a where clause) are not supported by the current connector".

The stale belief: That Prisma's schema language cannot express a partial or filtered index at all, so the only route is a hand-written CREATE INDEX ... WHERE ... inside a migration file (or prisma db execute), leaving the index invisible to schema.prisma.

// Stale
// stale: the schema cannot express it, so hand-write it in the migration
model User {
  id        Int       @id @default(autoincrement())
  email     String
  deletedAt DateTime?

  @@index([email])
}
// then, in migrations/xxxx/migration.sql, by hand:
// CREATE INDEX "User_email_live_idx" ON "User"("email") WHERE "deletedAt" IS NULL;

// Current
generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["partialIndexes"]
}

model User {
  id        Int       @id @default(autoincrement())
  email     String
  deletedAt DateTime?
  active    Boolean   @default(true)

  @@index([email], where: { deletedAt: null })
  @@unique([email], where: { active: true })
  // richer predicates go through raw():
  // @@index([email], where: raw("\"deletedAt\" IS NULL AND active"))
}

VERIFIED BY EXECUTION 2026-09-05, both halves of the standing rule. Introducing evidence by bisection against the shipped CLI, not from the release note alone: at prisma@7.3.0 the validator answers The preview feature "partialIndexes" is not known. Expected one of: fullTextSearchPostgres, nativeDistinct, postgresqlExtensions, relationJoins, schemaEngineDriverAdapters, shardKeys, strictUndefinedChecks, views — the name is absent from its own enumeration. At prisma@7.4.0 the same enumeration contains partialIndexes and the schema above validates. There are no 7.3.x patch releases, so the boundary is exactly 7.3.0 (2026-01-21) -> 7.4.0 (2026-02-11). Current behaviour re-verified at prisma@7.10.0, the newest stable: the same schema is valid, on @@index and @@unique. Poison controls confirm the validator can fail rather than accepting anything: previewFeatures = ["partialIndexesXYZ"] is rejected as unknown, where: { nosuchfield: null } is rejected as Field 'nosuchfield' does not exist in model 'User', and dropping the preview feature is rejected with Partial indexes are a preview feature. The object form's limits were found the same way — where: { score: { gt: 10 } } is rejected with Unknown key 'gt' in nested where clause object. Only 'not' is supported, and where: { AND: [...] } with Field 'AND' does not exist in model 'User'. Connector gating checked directly: valid on postgresql and sqlite, rejected on mysql. Still a preview feature at 7.10.0 — the generator block opt-in is required and is the part a model that half-remembers this will omit.

Reproduced against: Claude Opus 5 (S2) — prisma/v2-a, 2026-09-05.

Source: Prisma 7.4.0 release notes — Partial Indexes (Filtered Indexes) Support · 2026-02-11 · prisma 7.4.0, shipped package — build/prisma_schema_build_bg.wasm · prisma 7.10.0, shipped package — prisma validate on the correct_code schema above

compilerBuild

Added in prisma 7.3.0 (2026-01-21)

The prisma-client generator takes a compilerBuild option with two values, "fast" (the default) and "small". It selects which build of the query compiler is embedded in the generated client, and it is the size/speed dial for size-constrained runtimes. A model that denies it exists sends you to bundler-side workarounds — trimming binaryTargets, marking the client external, pruning models — none of which is the option that was built for this.

The stale belief: That the generator has no size/speed dial at all, and that the only real lever on generated-client size is dropping the Rust query engine via queryCompiler plus driverAdapters — which is a different change, was already the default in 7.0.0, and is not a trade of speed against size.

// Stale
generator client {
  provider        = "prisma-client"
  output          = "../src/generated/prisma"
  previewFeatures = ["queryCompiler", "driverAdapters"]
}

// Current
generator client {
  provider      = "prisma-client"
  output        = "../src/generated/prisma"
  compilerBuild = "small" // "fast" | "small"
}

Bisected against the shipped package: the string compilerBuild does not occur anywhere in prisma@7.2.0’s build/index.js and does occur in prisma@7.3.0’s.

Reproduced against: Claude Opus 5 (S2) — prisma/v5-c, 2026-09-06.

Source: Prisma ORM 7.3.0 release notes — new compilerBuild generator option · 2026-01-21 · prisma@7.3.0 shipped CLI — compilerBuild present in build/index.js; absent from prisma@7.2.0 · 2026-01-21

postinstall prisma generate

Removed in prisma 7.0.0 (2025-11-19)

Prisma 7 runs nothing implicitly. The postinstall hook no longer runs prisma generate, and prisma migrate no longer runs generate or the seed script. Any Dockerfile or CI pipeline that relied on install-time generation produces an image with no client.

The stale belief: That npm install generates the client through Prisma's postinstall hook, so a Dockerfile needs no explicit generate step.

# Stale
RUN npm ci        # generated the client via postinstall, through v6
RUN npm run build

# Current
RUN npm ci
RUN npx prisma generate
RUN npm run build

This is the failure that passes locally and fails in CI: a developer who ran prisma generate by hand still has the output on disk.

Reproduced against: Claude Sonnet 5 (S2) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — Removal of implicit Prisma commands · 2025-11-19

enum member @map

Behaviour changed in prisma 7.3.0 (2026-01-21)

Prisma reverted the 7.0.0 mapped-enum change in 7.3.0. From 7.3.0 onward the generated enum object maps each member name to itself again — PaymentProvider.MixplatSMS is the string 'MixplatSMS' — and the @map value is the database value, which the generated client does not expose. The mapped values appear in the generated object for 7.0.0, 7.1.0 and 7.2.0 only. If you need the database string in application code on 7.3.0+, keep your own map; there is no generated export that carries it.

The stale belief: That @map on an enum member changes what the generated client hands your code, so PaymentProvider.MixplatSMS === 'mixplat/sms'. That was true of 7.0.0, 7.1.0 and 7.2.0, and it is what the 7.0.0 release notes still say. It is false at every release from 7.3.0 on, and it was false before 7.0.0.

// Stale
export const PaymentProvider = {
  MixplatSMS: 'mixplat/sms',
  InternalToken: 'internal/token',
  Offline: 'offline'
} as const

// Current
export const PaymentProvider = {
  MixplatSMS: 'MixplatSMS',
  InternalToken: 'InternalToken',
  Offline: 'Offline'
} as const

CORRECTED 2026-09-03 (JOURNAL/048), and this fact was wrong in the direction that matters: it stated the 7.0.0 behaviour as current and was verified from the 7.0.0 release note alone, never from a generated client. Prisma reverted at 7.3.0. Verified by generating a client from one schema at four releases with prisma 7.0.0, 7.2.0, 7.3.0 and 7.10.0 installed: 7.0.0 and 7.2.0 emit the mapped values, 7.3.0 and 7.10.0 emit the member names. Three charged S2 findings rested on the old wording and are RETRACTED — opus-5 F5, sonnet-5 F12, fable-5 F11 — because all three subjects wrote the member-name form, which is correct for the release that was current when they were scored. The earlier note on this fact stands as history: AUDIT 2026-09-02 (JOURNAL/038) corrected code_lang from ts to prisma; both code blocks are generated TypeScript again now, so it is ts.

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Prisma 7.3.0 release notes — Revert @map enums to v6.19.0 behavior (PR #29002) · 2026-01-21 · prisma 7.10.0 — client generated from a schema with @map on every enum member · prisma 7.2.0 — the same schema, the last release before the revert · Prisma 7.0.0 release notes — Mapped enums, the change that was later reverted · 2025-11-19

connection pool defaults

Default changed in prisma 7.0.0 (2025-11-19)

Pooling is the driver's, not Prisma's. Driver adapters use the underlying Node driver's pool settings, which differ from Prisma 6's: pg has no connection timeout by default (0) where Prisma 6 used five seconds. Connection-string parameters like connection_limit are not what tunes this any more.

The stale belief: That ?connection_limit=5&pool_timeout=10 on the datasource URL controls the pool, and that Prisma's own five-second connection timeout applies.

const adapter = new PrismaPg({
  connectionString: process.env.DATABASE_URL,
  max: 5,
  connectionTimeoutMillis: 5000,
})

The adapter option names are the underlying driver's; the example above is pg's.

Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.

Source: Upgrade to Prisma ORM 7 — Driver adapters

Deprecated, or a better API now exists

Works today. It is the older idiom, and some of it is scheduled for removal.

provider = "prisma-client-js"

Deprecated in prisma 7.0.0 (2025-11-19)

prisma-client is the default generator provider in Prisma 7 — the Rust-free ESM client. prisma-client-js still works but is stated to be removed in a future release, and using it together with the now-required output needs an extra package, @prisma/client-runtime-utils.

The stale belief: That prisma-client-js is the only generator provider, which was true until the prisma-client preview landed in 6.16.0.

// Stale
generator client {
  provider = "prisma-client-js"
}

// Current
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}

Reproduced against: Claude Fable 5 (S3), Claude Sonnet 5 (S3) — prisma/v1, 2026-08-31.

Source: Upgrade to Prisma ORM 7 — Schema changes · Prisma 7.0.0 release notes — ESM Prisma Client as the default · 2025-11-19

Wrong facts about the library

Not code — versions, minimums and metadata that models state confidently and get wrong.

MongoDB support

Removed in prisma 7.0.0 (2025-11-19)

Prisma 7 does not support MongoDB. The vendor's instruction is to stay on Prisma 6 until support returns in a future v7 release. Advising a MongoDB user to install the latest version is advice that does not work.

The stale belief: That MongoDB is a first-class Prisma provider on every current version, as it was from 3.12 through 6.x.

This is the one case where the correct answer is to pin to the previous major. Prisma 6 is still receiving releases (6.19.3 shipped 2026-04-01). SCOPE, checked 2026-09-03 against an installed prisma 7.10.0: the toolchain does not refuse the provider. A schema with provider = "mongodb" passes prisma validate ("the schema is valid") and prisma generate emits a client. What is missing is the runtime: Prisma 7 connects through driver adapters and no MongoDB adapter is published — @prisma/adapter-mongodb is a 404 on the npm registry. So the failure arrives at connect time, not at generate time, and a reader who takes "does not support" to mean "the CLI will tell you" is wrong about where it breaks.

Reproduced against: Claude Fable 5 (S4), Claude Opus 5 (S4), Claude Sonnet 5 (S4) — prisma/v1, 2026-08-31.

Source: Prisma 7.0.0 release notes — MongoDB support in Prisma 7 · 2025-11-19 · Upgrade to Prisma ORM 7

Not corrections — recorded for honesty

Claims seen in a run but not yet verified against a primary source. Never treated as findings:

• This draw and v1r-b were given a byte-identical prompt, the same model alias, on the same day, running concurrently, and placed the boundary 204 days apart (7.0.0 / 2025-11-19 here; 6.7.0 / 2025-04-29 there). Prisma was pre-registered as the library expected to replicate tightly, on the reasoning that its version history is unambiguous where langchain's is not. That reasoning is now falsified. (open since 2026-09-01)
• This draw hedged its own answer in a way the scoring rule does not capture: it called 7.0 describable "at headline level only" and volunteered that "for genuinely detailed release-note knowledge, the honest boundary is ~6.16, September 2025". Scored on its stated first-unknown-release it reads 7.0.0; scored on its stated confidence floor it reads 6.16.0. The battery has no rule for a subject that offers two boundaries in one answer. (open since 2026-09-01)
• This draw and v1r-a were given a byte-identical prompt, the same model alias, on the same day, running concurrently, and placed the boundary 204 days apart. Prisma was pre-registered as the library expected to replicate tightly; it did not. (open since 2026-09-01)
• This draw stated 6.7.0 as its boundary while producing a correct, complete, and explicitly disclaimed description of 7.0.0's contents. That is a third mode beyond the two langchain/v1r found: not a correct attribution and not a bare version string, but correct content the subject refuses to attribute. Whether the boundary instrument should score the statement or the production is now an open method question, and it is not answered by either battery. (open since 2026-09-01)
• 6.8.0 (2025-05-15) is unresolved for this draw: it said it could describe "roughly 6.7-6.8", named 6.7 as the newest it could genuinely describe, and put "6.9-and-later" in the version-number-only bucket. The bracket recorded here uses the subject's two explicit statements (6.7.0 describable, 6.9.0 not) and leaves 6.8.0 unclassified rather than guessing. (open since 2026-09-01)
• Both Opus 5 draws in this battery placed query-plan caching at the queryCompiler preview (6.7.0 / 7.0.0) rather than at 7.4.0, and both described the mechanism roughly correctly while dating it wrong. Is that a general shape — a feature whose PUBLIC name arrives in one release and whose CAPABILITY is the completion of work named in an earlier one gets attributed to the earlier one? next.js and better-auth both have candidate surfaces with that structure. Worth a battery designed around it rather than a note. (open since 2026-09-05)
• This draw's self-report about where its content knowledge stops (6.9/6.10) is four releases below where it demonstrably stops (7.0.0, described correctly in the same answer). Every boundary number the Index publishes for every subject comes from the self-report. How often is the self-report an UNDER-estimate of demonstrated knowledge, and does it bias the published boundaries downward? This is the first draw where both readings are available in one transcript and they disagree. It would take a battery that asks for content and for the self-placement about the same releases, deliberately, to answer. (open since 2026-09-05)
• Does the prisma-client generator accept a runtime key with values such as "vercel-edge" and "workerd", as the serverless answer claims? (open since 2026-08-31)

Findings, code and citations: data/prisma/ — one JSON file and one write-up per model, each finding carrying the release that broke the belief, its publication date and a verbatim quote from the primary source. Corrections: data/prisma/facts.json. This file is generated by tools/build-corrections.mjs; if the prose and the data ever disagree, that is a bug in the generator, not a stale pack.