{ "$schema": "../../schema/run.schema.json", "run_id": "prisma--claude-opus-5--v1--2026-08-31", "supersedes": null, "library": { "name": "prisma", "ecosystem": "npm", "latest_version_at_test": "7.10.0", "latest_version_verified_on": "2026-08-31", "latest_version_note": "Latest stable. On the same date the `prisma` package's npm `latest` dist-tag resolved to the prerelease 8.0.0-rc.12 (with `prev: 7.10.0`); no stable 8.0.0 exists on npm or in the GitHub releases list. `@prisma/client` latest resolved to 7.10.0 (2026-08-25)." }, "model": { "id": "claude-opus-5", "label": "Claude Opus 5", "vendor": "Anthropic", "invoked_as": "Agent tool, model alias \"opus\"", "self_reported_cutoff": "2026-05", "cutoff_basis": "Self-reported: \"My stated cutoff is May 2026.\"", "believed_latest_version": "7.x", "believed_latest_quote": "\"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.\"", "knowledge_stops_at_version": "7.0.0", "knowledge_stops_on": "2025-11-19", "knowledge_gap_starts_at_version": "7.1.0", "knowledge_gap_starts_on": "2025-12-03", "cutoff_lag_months": 5 }, "test": { "date": "2026-08-31", "battery": "prisma/v1", "battery_spec": "prompts/prisma.md", "prompt_file": null, "tasks": 10, "direct_questions": 4, "tool_uses_during_test": 0, "probe_window": { "from": "6.18.0", "to": "7.0.0" }, "self_test": true, "saturated": false, "status": "open", "retested_on": null }, "sources": [ "https://github.com/prisma/prisma/releases/tag/7.0.0", "https://github.com/prisma/prisma/releases/tag/6.18.0", "https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7", "https://registry.npmjs.org/prisma", "https://registry.npmjs.org/@prisma/client" ], "findings": [ { "id": "F1", "severity": "S1", "severity_label": "breaks-build", "title": "prisma.config.ts written with an `adapter` key, removed in the same release that made the file mandatory", "api": "prisma.config.ts adapter key", "change_kind": "removed", "introduced_in": "7.0.0", "introduced_on": "2025-11-19", "chargeable": true, "model_belief": "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\".", "wrong_code": "export default defineConfig({\n schema: 'prisma/schema.prisma',\n migrations: { path: 'prisma/migrations', seed: 'tsx prisma/seed.ts' },\n adapter: () => new PrismaPg({ connectionString: process.env.DATABASE_URL! }),\n})", "correct_code": "export default defineConfig({\n schema: 'prisma/schema.prisma',\n migrations: { path: 'prisma/migrations', seed: 'tsx prisma/seed.ts' },\n datasource: { url: env('DATABASE_URL') },\n})", "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.", "citations": [ { "url": "https://github.com/prisma/prisma/releases/tag/7.0.0", "title": "Prisma 7.0.0 release notes — Schema and config file updates", "published_on": "2025-11-19", "quote": "For early adopters of the config file, a few things have been removed with this release: engine: 'js'| 'classic' has been removed; adapter has been removed" } ] }, { "id": "F2", "severity": "S3", "severity_label": "deprecated", "title": "Connection string left in the schema's datasource block rather than the config file", "api": "datasource url", "change_kind": "removed", "introduced_in": "7.0.0", "introduced_on": "2025-11-19", "chargeable": true, "model_belief": "\"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.", "wrong_code": "datasource db {\n provider = \"postgresql\"\n url = env(\"DATABASE_URL\")\n // shadowDatabaseUrl = env(\"SHADOW_DATABASE_URL\")\n}", "correct_code": "datasource db {\n provider = \"postgresql\"\n}\n\n// prisma.config.ts\n// 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.", "citations": [ { "url": "https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7", "title": "Upgrade to Prisma ORM 7 — Schema changes", "quote": "other fields such as url , directUrl , and shadowDatabaseUrl in the datasource block are deprecated. You can configure them in the Prisma Config" }, { "url": "https://github.com/prisma/prisma/releases/tag/7.0.0", "title": "Prisma 7.0.0 release notes — Schema changes", "published_on": "2025-11-19", "quote": "datasource.url is now configured in the config file" } ] }, { "id": "F3", "severity": "S1", "severity_label": "breaks-build", "title": "SQLite adapter imported under its pre-7.0.0 class name", "api": "PrismaBetterSQLite3", "change_kind": "renamed", "introduced_in": "7.0.0", "introduced_on": "2025-11-19", "chargeable": true, "model_belief": "\"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\".", "wrong_code": "import { PrismaBetterSQLite3 } from '@prisma/adapter-better-sqlite3'", "correct_code": "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.", "citations": [ { "url": "https://github.com/prisma/prisma/releases/tag/7.0.0", "title": "Prisma 7.0.0 release notes — Driver Adapter naming updates", "published_on": "2025-11-19", "quote": "PrismaBetterSQLite3 ⇒ PrismaBetterSqlite3" } ] }, { "id": "F4", "severity": "S1", "severity_label": "breaks-build", "title": "migrate diff invoked with both removed flag families", "api": "prisma migrate diff", "change_kind": "renamed", "introduced_in": "7.0.0", "introduced_on": "2025-11-19", "chargeable": true, "model_belief": "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.", "wrong_code": "npx prisma migrate diff \\\n --from-url \"$DATABASE_URL\" \\\n --to-schema-datamodel prisma/schema.prisma \\\n --script", "correct_code": "npx prisma migrate diff \\\n --from-config-datasource \\\n --to-schema prisma/schema.prisma \\\n --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.", "citations": [ { "url": "https://github.com/prisma/prisma/releases/tag/7.0.0", "title": "Prisma 7.0.0 release notes — Removal of prisma migrate flags", "published_on": "2025-11-19", "quote": "For prisma migrate diff , we've removed the following flags: prisma --[from/to]-schema-datamodel ... prisma --[from/to]-url" } ] }, { "id": "F5", "severity": "S2", "severity_label": "silently-wrong", "title": "Claims the generated enum object holds member names, not the mapped database values", "api": "generated enum values", "change_kind": "behavior-changed", "introduced_in": "7.0.0", "introduced_on": "2025-11-19", "chargeable": true, "model_belief": "\"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.", "wrong_code": "export const PaymentProvider = {\n MixplatSms: 'MixplatSms',\n InternalToken: 'InternalToken',\n} as const", "correct_code": "export const PaymentProvider: {\n MixplatSMS: 'mixplat/sms'\n InternalToken: 'internal/token'\n}", "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.", "withdrawn": { "on": "2026-09-03", "reason": "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.", "journal": "JOURNAL/048" }, "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.", "citations": [ { "url": "https://github.com/prisma/prisma/releases/tag/7.0.0", "title": "Prisma 7.0.0 release notes — Mapped enums", "published_on": "2025-11-19", "quote": "We now support the @map attribute for enum members, which can be used to set their expected runtime values" } ] }, { "id": "F6", "severity": "S4", "severity_label": "wrong-metadata", "title": "Set a MongoDB project up on the version that dropped MongoDB", "api": "MongoDB support", "change_kind": "removed", "introduced_in": "7.0.0", "introduced_on": "2025-11-19", "chargeable": true, "model_belief": "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.\"", "wrong_code": "generator client {\n provider = \"prisma-client\"\n output = \"../src/generated/prisma\"\n}\n\ndatasource db {\n provider = \"mongodb\"\n url = env(\"DATABASE_URL\")\n}", "correct_code": "// Stay on Prisma 6 for MongoDB:\n// npm i -D prisma@6\n// 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.", "citations": [ { "url": "https://github.com/prisma/prisma/releases/tag/7.0.0", "title": "Prisma 7.0.0 release notes — MongoDB support in Prisma 7", "published_on": "2025-11-19", "quote": "Currently, MongoDB is not supported in Prisma 7. For folks using MongoDB, please stay on Prisma v6." } ] }, { "id": "F7", "severity": "S4", "severity_label": "wrong-metadata", "title": "Version knowledge stops at 7.0.0, five months before its own stated cutoff", "api": null, "change_kind": "version-fact", "introduced_in": "7.1.0", "introduced_on": "2025-12-03", "chargeable": true, "chargeable_note": "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).", "model_belief": "\"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.", "citations": [ { "url": "https://registry.npmjs.org/prisma", "title": "npm registry metadata for `prisma` (time map)", "quote": "7.1.0: 2025-12-03" } ] } ], "non_findings": [ { "kind": "correct", "summary": "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.", "api": "generator client { output }", "introduced_in": "7.0.0" }, { "kind": "correct", "summary": "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).", "api": "prisma.config.ts", "introduced_in": "7.0.0" }, { "kind": "correct", "summary": "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.", "api": "postinstall prisma generate", "introduced_in": "7.0.0" }, { "kind": "imprecision", "summary": "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.\"", "api": "new PrismaClient({ datasourceUrl })", "introduced_in": "7.0.0", "why_not_a_finding": "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." }, { "kind": "context", "summary": "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.", "why_not_a_finding": "Correctly scoped to the version it belongs to." } ], "open_questions": [ { "question": "Does the `prisma-client` generator accept a `runtime` key with values such as \"vercel-edge\" and \"workerd\", as the serverless answer claims?", "status": "open", "resolution": "Not verified against a primary source in this run; `moduleFormat` (cjs|esm) is documented for this generator, `runtime` was not located. Nothing was charged either way." } ], "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.", "markdown": "data/prisma/opus-5.md" }