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

"const prisma = new PrismaClient();" in tasks 1, 2, 3 and 5, with the mechanism stated explicitly: "The connection string itself isn't passed here ... PrismaClient picks it up automatically at instantiation."

Every runnable artefact in the run throws at construction on Prisma 7. This is the single highest-frequency stale prior the battery found.

• Prisma 7.0.0 release notes — Prisma Client changes published 2025-11-19

  new PrismaClient() support has been removed

"generator client { provider = \"prisma-client-js\" }" with no output, and in question (d): "Generated client code goes to node_modules/.prisma/client by default." — CORRECTED 2026-09-08 (JOURNAL/096): this finding published introduced_in: 7.0.0 / 2025-11-19 and an impact clause that LF4 has since measured to be false. LF4 was corrected the same day against twenty-three installed releases: the output requirement belongs to the prisma-client generator and dates to its arrival in 6.6.0 (2025-04-08), not to the major, and the prisma-client-js block this draw actually wrote does NOT refuse — with @prisma/client installed it generates into node_modules/@prisma/client at every 7.x release the Index covers. The version and date are corrected here and the false clause is withdrawn. THE FINDING STANDS AND THE CHARGE DOES NOT MOVE: the draw is stale about the setup Prisma 7 documents, and 6.6.0 is ten months inside this subject's stated cutoff — further inside it than the withdrawn date was. RE-SCORED 2026-09-08 (JOURNAL/098), and this is the first re-score in the corpus: S1 breaks-build → S3 deprecated. The severity was set from the withdrawn clause, and applying the same failure-mode scale to the corrected fact yields S3. The draw above is untouched and was not re-read.

Stale setup advice, not a build break. Measured 2026-09-08 across twenty-three installed releases (LF4): a prisma-client-js generator block with no output generates into node_modules/@prisma/client at every 7.x release this Index covers, provided @prisma/client is installed. What the draw misses is the generator Prisma 7 documents and tells you to move to — prisma-client, which has refused to run without an output path since it arrived in 6.6.0.

• Upgrade to Prisma ORM 7 — Schema changes

  the output field is now required in the generator block. Prisma Client will no longer be generated in node_modules by default.

prisma-client-js in every schema shown; the newer provider is never mentioned in any of the ten tasks.

Still functions in 7.x, with a stated removal ahead of it, and needs the extra @prisma/client-runtime-utils package once output is set.

• Upgrade to Prisma ORM 7 — Schema changes

  The older prisma-client-js provider will be removed in future releases of Prisma ORM.

"import { PrismaClient } from '@prisma/client';" in every file, and in (d): "@prisma/client re-exporting from there — which is why npx prisma generate has to run after every npm install".

With the generated client now living in your own tree, the package import does not resolve to a client.

• Upgrade to Prisma ORM 7 — Schema changes

  // Before import { PrismaClient } from "@prisma/client" ; // After import { PrismaClient } from "./generated/prisma/client" ;

Task 4 lists the files involved as .env, prisma/schema.prisma, the migrations directory and the generated client — no config file. In (d): "historically the only config file is schema.prisma itself", with prisma.config.ts recalled but explicitly held "with meaningfully less confidence than the rest of this answer".

prisma migrate in 7.x requires the config file; the answer's exact migration commands have nothing to read a datasource from.

• Prisma 7.0.0 release notes — Schema and config file updates published 2025-11-19

  prisma.config.ts is now required for projects looking to perform introspection and migration.

"The string lives in .env as DATABASE_URL, referenced from prisma/schema.prisma via url = env(\"DATABASE_URL\")" — with no loading step anywhere in the run.

The variable is simply unset when the CLI runs, and the error names the connection rather than the missing load.

• Prisma 7.0.0 release notes — Explicit loading of environment variables published 2025-11-19

  we're no longer automatically loading environment variables when invoking the Prisma CLI

"With that prisma.seed entry in place, the seed runs automatically whenever you run npx prisma migrate dev ... and whenever you run npx prisma migrate reset. No extra CI/dev wiring needed beyond that config block."

The key is not read, so the seed never runs — and the answer's closing promise is that no further wiring is needed.

• Prisma 7.0.0 release notes — Removed support for prisma keyword in package.json published 2025-11-19

  With the move to prisma.config.ts, this no longer makes sense and has been removed.

"the prisma/@prisma/client npm packages register a postinstall hook that runs prisma generate automatically when npm install sees a prisma/schema.prisma" — and, in task 1, "usually run automatically as a postinstall".

The Dockerfile it wrote does run npx prisma generate explicitly, so that artefact survives; the belief is charged because the run states the hook as a fact twice and offers it as the reason the step is optional.

• Prisma 7.0.0 release notes — Removal of implicit Prisma commands published 2025-11-19

  post-install hook would run prisma generate ... This behaviour has been removed in favor of explicitly requiring commands to be run by users.

"Generate a query-engine-free client (--no-engine on prisma generate) when pairing with Prisma Accelerate."

Unknown flag; the serverless build step fails.

• Prisma 7.0.0 release notes — Removal of prisma generate flags published 2025-11-19

  prisma generate --no-engine

"The correct query-engine binary for the container's OS/libc must be available. If the base image is Alpine (musl) ... you must add the right binaryTargets", and "make sure your bundler treats @prisma/client/the engine as external ... which tends to break the binary lookup".

Sends a team hunting a libc/OpenSSL mismatch that cannot occur on 7.x, and frames the engine-free client as an optimisation rather than the only client there is.

• Prisma 7.0.0 release notes — Removed Client Engines published 2025-11-19

  We've removed the following client engines: LibraryEngine (engineType = "library", the Node-API Client); BinaryEngine (engineType = "binary", the long-running executable binary)

"npx prisma migrate diff --from-url \"$DATABASE_URL\" --to-schema-datamodel prisma/schema.prisma --script", with a parenthetical listing the same removed flags as the general vocabulary of the command.

Unknown-flag error, and no version of the command in the answer works.

• Prisma 7.0.0 release notes — Removal of prisma migrate flags published 2025-11-19

  prisma --[from/to]-url , prisma --[from/to]-schema-datasource ... These are now replaced with --[from/to]-config-datasource

A full MongoDB schema and workflow with six caveats — replica sets, ObjectId mapping, emulated relations — and no mention that the current major does not support the database at all.

The one question in the battery where the correct answer is "pin to the previous major", answered as though nothing had changed.

• Prisma 7.0.0 release notes — MongoDB support in Prisma 7 published 2025-11-19

  Currently, MongoDB is not supported in Prisma 7. For folks using MongoDB, please stay on Prisma v6.

"First release I know only as a bare version number, with no real idea what shipped in it: anything after roughly 6.1 ... I have no reliable knowledge of anything resembling a Prisma 7."

A major version, a mandatory config file and the removal of the no-argument constructor all sit inside the blind spot, which is why this run produces fourteen findings rather than the two or three a near-current subject produces.

• npm registry metadata for `prisma` (time map)

  6.1.0: 2024-12-17