{
  "$schema": "../../schema/run.schema.json",
  "run_id": "prisma--claude-opus-5--v4-a--2026-09-06",
  "supersedes": null,
  "replicate_of": null,
  "library": {
    "name": "prisma",
    "ecosystem": "npm",
    "latest_version_at_test": "7.10.0",
    "latest_version_verified_on": "2026-09-06",
    "latest_version_note": "The probe window is 7.5.0 (2026-03-11) to 7.8.0 (2026-04-22). Every one of the six surfaces in this battery was pinned to an exact introducing release by installing the shipped packages at 7.4.0, 7.5.0, 7.6.0, 7.7.0, 7.8.0 and 7.10.0 in the session scratchpad and reading the published type declarations and the CLI command table. `postgres` is absent from `prisma --help` at 7.5.0 and present at 7.6.0; `bootstrap` is absent at 7.6.0 and present at 7.7.0; the `PrismaPg` constructor union gains `| string` between 7.5.0 and 7.6.0; `statementNameGenerator` appears in `PrismaPgOptions` between 7.5.0 and 7.6.0; `queryPlanCacheMaxSize` appears in the client options between 7.7.0 and 7.8.0; and `\"$transaction\"` leaves the interactive-transaction deny list between 7.4.0 and 7.5.0. All six persist at 7.10.0. `prisma postgres branch`, the poison rung, does not exist at any of those versions — `prisma postgres --help` lists `link` and nothing else."
  },
  "model": {
    "id": "claude-opus-5",
    "label": "Claude Opus 5",
    "vendor": "Anthropic",
    "invoked_as": "Agent tool, model alias \"opus\"; prompt sent verbatim from prompts/sent/prisma-v4.txt. Nominated in the spec as the CHARGING arm of the Opus 5 pair, and it charges.",
    "self_reported_cutoff": "2026-05",
    "cutoff_basis": "Self-reported, AFFIRMING the environment value and qualifying only the density of recall: \"My stated training cutoff is May 2026, and that date comes from my context, not from my own knowledge... My own internal sense of where reliable Prisma detail runs out is noticeably earlier than that, somewhere around the 6.x era, which is why the 7.x specifics above are thin.\" Under HARNESS.md § *A density self-assessment is not a stated cutoff*, and under the JOURNAL/055 distinguishing test (does the answer qualify recall, or choose between two dates?), this qualifies recall and does not choose. The licence holds. SEE THE DEVIATION NOTE in `prompts/prisma.md` § v4: this battery's direct question (d) asked for the SOURCE of the cutoff, which is not the standing bare wording, and all four test draws answered in the \"from my context\" frame. The deviation is recorded rather than argued away.",
    "believed_latest_version": null,
    "believed_latest_quote": "\"I do not know what the most recent Prisma 7 minor release is. I can't name 7.x with any confidence and won't guess a number.\"",
    "knowledge_stops_at_version": null,
    "knowledge_stops_on": null,
    "knowledge_gap_starts_at_version": null,
    "knowledge_gap_starts_on": null,
    "cutoff_lag_months": null
  },
  "test": {
    "date": "2026-09-06",
    "battery": "prisma/v4-a",
    "battery_spec": "prompts/prisma.md",
    "prompt_file": "prompts/sent/prisma-v4.txt",
    "tasks": 7,
    "direct_questions": 4,
    "elicits_code": true,
    "tool_uses_during_test": 0,
    "probe_window": {
      "from": "7.5.0",
      "to": "7.8.0"
    },
    "self_test": true,
    "saturated": false,
    "status": "open",
    "retested_on": null
  },
  "sources": [
    "https://github.com/prisma/prisma/releases/tag/7.5.0",
    "https://github.com/prisma/prisma/releases/tag/7.6.0",
    "https://github.com/prisma/prisma/releases/tag/7.7.0",
    "https://github.com/prisma/prisma/releases/tag/7.8.0",
    "https://registry.npmjs.org/prisma",
    "https://registry.npmjs.org/@prisma/client",
    "https://registry.npmjs.org/@prisma/adapter-pg"
  ],
  "findings": [
    {
      "id": "F1",
      "severity": "S2",
      "severity_label": "silently-wrong",
      "title": "Denies the Prisma CLI has any command for attaching a project to an existing Prisma Postgres database",
      "api": "prisma postgres link",
      "change_kind": "added",
      "introduced_in": "7.6.0",
      "introduced_on": "2026-03-27",
      "chargeable": true,
      "chargeable_note": "7.6.0 shipped 2026-03-27; this draw states a 2026-05 cutoff, so the release precedes it. Pre-registered probe class R1 (REACHABLE) in `prompts/prisma.md` § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.",
      "model_belief": "TASK 1(i), one word: \"No.\" Then: \"I'm not aware of a first-party CLI command that does this... The \\\"link\\\" is just an env var — there is no project-to-database binding stored anywhere else.\" Direct question (c)(i), on `prisma postgres link` by name: \"I do not know. I can't confirm it exists, and I'm not confident enough to assert it doesn't.\"",
      "wrong_code": "# 1. copy the connection string out of the Prisma Console by hand\n# 2. paste it into .env as DATABASE_URL\nnpx prisma db pull\nnpx prisma generate",
      "correct_code": "npx prisma postgres link",
      "impact": "A reader is sent to copy a connection string out of a web console by hand for a job that has had a one-line command since 7.6.0. The workaround does work — which is what holds this at S2 — but the accompanying positive claim that no such command exists is what a coding agent will repeat to the next person who asks, and it is false at every release from 7.6.0 to 7.10.0.",
      "citations": [
        {
          "url": "https://github.com/prisma/prisma/releases/tag/7.6.0",
          "title": "Prisma 7.6.0 release notes — CLI",
          "published_on": "2026-03-27",
          "quote": "Added a `prisma postgres link` command that connects a local project to a Prisma Postgres database."
        },
        {
          "url": "https://registry.npmjs.org/prisma",
          "title": "prisma 7.6.0 and 7.10.0, shipped package — output of `prisma postgres --help`",
          "published_on": null,
          "quote": "link   Link a local project to a Prisma Postgres database"
        }
      ]
    },
    {
      "id": "F2",
      "severity": "S2",
      "severity_label": "silently-wrong",
      "title": "Denies the query plan cache can be sized or disabled from the PrismaClient constructor, and rejects the working line that does it",
      "api": "queryPlanCacheMaxSize",
      "change_kind": "added",
      "introduced_in": "7.8.0",
      "introduced_on": "2026-04-22",
      "chargeable": true,
      "chargeable_note": "7.8.0 shipped 2026-04-22; this draw states a 2026-05 cutoff, so the release precedes it. Pre-registered probe class U1 (UNREACHABLE) in `prompts/prisma.md` § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.",
      "model_belief": "TASK 2(i): \"No.\" Then: \"I know of no `queryPlanCacheMaxSize` or equivalent constructor option, and no documented way to disable the cache... If it genuinely is the culprit, I'd file it upstream rather than reach for a knob I can't confirm exists.\" TASK 7(b), reviewing the line: \"No. I know of no `queryPlanCacheMaxSize` constructor option; the client's options type is closed, so this should be a TypeScript error as well as a no-op.\"",
      "wrong_code": "// the reviewed line, deleted:\nconst prisma = new PrismaClient({ adapter })",
      "correct_code": "const prisma = new PrismaClient({\n  adapter,\n  queryPlanCacheMaxSize: 100, // 0 disables the cache entirely\n})",
      "impact": "The newest surface in the battery and the one with the sharpest artefact. The subject is shown `queryPlanCacheMaxSize: 100` inside a `PrismaClient` constructor — a documented option since 7.8.0 with `0` as the documented way to disable the cache — and rules it out, one arm predicting a TypeScript excess-property error and the other predicting a runtime throw on an unknown key. Neither happens. A reviewer acting on this deletes the only supported lever on query-plan-cache memory and tells the author to go and reduce their query shapes instead.",
      "citations": [
        {
          "url": "https://github.com/prisma/prisma/releases/tag/7.8.0",
          "title": "Prisma 7.8.0 release notes — Prisma Client features",
          "published_on": "2026-04-22",
          "quote": "Added a `queryPlanCacheMaxSize` option to the `PrismaClient` constructor for fine-grained control over the query plan cache. Pass `0` to disable the cache entirely"
        },
        {
          "url": "https://registry.npmjs.org/@prisma/client",
          "title": "@prisma/client 7.8.0 and 7.10.0, shipped package — runtime/client.d.ts",
          "published_on": null,
          "quote": "queryPlanCacheMaxSize?: number;"
        }
      ]
    },
    {
      "id": "F3",
      "severity": "S2",
      "severity_label": "silently-wrong",
      "title": "Denies the pg adapter constructor takes a bare connection string, and rewrites the working call",
      "api": "new PrismaPg(connectionString)",
      "change_kind": "added",
      "introduced_in": "7.6.0",
      "introduced_on": "2026-03-27",
      "chargeable": true,
      "chargeable_note": "7.6.0 shipped 2026-03-27; this draw states a 2026-05 cutoff, so the release precedes it. Pre-registered probe class R2 (REACHABLE) in `prompts/prisma.md` § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.",
      "model_belief": "TASK 3(i): \"No. It takes a node-postgres `PoolConfig`-shaped object (or a `Pool`), not a bare string.\" TASK 7(a): \"No. `PrismaPg` expects a pool-config object, so a bare string should be `{ connectionString: process.env.DATABASE_URL }`.\"",
      "wrong_code": "// offered as the correction:\nconst adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })",
      "correct_code": "const adapter = new PrismaPg(process.env.DATABASE_URL!)",
      "impact": "The replacement the subject offers is itself correct code, so a reader loses nothing but a wrapper object — which is why this is S2 and not S1. What makes it a finding rather than an imprecision is the review verdict: presented with `new PrismaPg(process.env.DATABASE_URL!)`, a line that has compiled since 7.6.0 and still compiles at 7.10.0, both charging arms call it a type error.",
      "citations": [
        {
          "url": "https://github.com/prisma/prisma/releases/tag/7.6.0",
          "title": "Prisma 7.6.0 release notes — Driver Adapters",
          "published_on": "2026-03-27",
          "quote": "@prisma/adapter-pg: Added support for usage of connection strings directly in the constructor for improved ergonomics"
        },
        {
          "url": "https://registry.npmjs.org/@prisma/adapter-pg",
          "title": "@prisma/adapter-pg 7.6.0, shipped package — dist/index.d.ts",
          "published_on": null,
          "quote": "constructor(poolOrConfig: pg.Pool | pg.PoolConfig | string, options?: PrismaPgOptions | undefined);"
        }
      ]
    },
    {
      "id": "F4",
      "severity": "S2",
      "severity_label": "silently-wrong",
      "title": "Denies @prisma/adapter-pg exposes any control over prepared-statement names, and recommends running the query outside Prisma instead",
      "api": "statementNameGenerator",
      "change_kind": "added",
      "introduced_in": "7.6.0",
      "introduced_on": "2026-03-27",
      "chargeable": true,
      "chargeable_note": "7.6.0 shipped 2026-03-27; this draw states a 2026-05 cutoff, so the release precedes it. Pre-registered probe class U2 (UNREACHABLE) in `prompts/prisma.md` § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.",
      "model_belief": "TASK 4(i): \"No. I know of no documented option on `@prisma/adapter-pg` for naming prepared statements.\" Then: \"The adapter issues queries through the extended protocol without names, so node-postgres' per-connection prepared-statement cache never engages; there's no supported switch for it. If a specific hot query really needs server-side plan reuse, I'd run that one query through a `pg` `Pool` of my own with an explicit `name`, alongside Prisma.\"",
      "wrong_code": "// offered as the only route:\nconst pool = new Pool({ connectionString: process.env.DATABASE_URL })\nawait pool.query({ name: \"hot-query\", text: \"SELECT ...\", values: [] })",
      "correct_code": "const adapter = new PrismaPg(process.env.DATABASE_URL!, {\n  statementNameGenerator: (query) => \"prisma_\" + hashOf(query.sql),\n})",
      "impact": "The advice is to take a hot query out of Prisma and run it through a hand-built `pg` pool so it can be given a `name` — real architectural cost, incurred to work around an option the adapter has shipped since 7.6.0. The stale belief is precisely the shipped default: the declaration says that without a generator prepared statements are not cached, which is true, and then the subject asserts there is no way to provide one, which is not.",
      "citations": [
        {
          "url": "https://github.com/prisma/prisma/releases/tag/7.6.0",
          "title": "Prisma 7.6.0 release notes — Driver Adapters",
          "published_on": "2026-03-27",
          "quote": "@prisma/adapter-pg: Added a `statementNameGenerator` option that accepts a custom prepared statement name generator to allow users to leverage `pg` statement caching"
        },
        {
          "url": "https://registry.npmjs.org/@prisma/adapter-pg",
          "title": "@prisma/adapter-pg 7.6.0, shipped package — dist/index.d.ts",
          "published_on": null,
          "quote": "statementNameGenerator?: StatementNameGenerator;"
        }
      ]
    },
    {
      "id": "F5",
      "severity": "S2",
      "severity_label": "silently-wrong",
      "title": "Recites the current deny list and then puts $transaction back into it, denying nested transactions and rejecting the working call",
      "api": "tx.$transaction()",
      "change_kind": "added",
      "introduced_in": "7.5.0",
      "introduced_on": "2026-03-11",
      "chargeable": true,
      "chargeable_note": "7.5.0 shipped 2026-03-11; this draw states a 2026-05 cutoff, so the release precedes it. Pre-registered probe class R3 (REACHABLE) in `prompts/prisma.md` § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.",
      "model_belief": "TASK 5(i): \"No. The transaction client is `Omit<PrismaClient, ITXClientDenyList>`, and `$transaction` is on that deny list — it isn't present at runtime and won't typecheck.\" TASK 7(c): \"No. `$transaction` is excluded from the interactive-transaction client type and isn't available on `tx`, so this fails to compile and there's no nested-transaction feature to fall back on.\"",
      "wrong_code": "await prisma.$transaction(async (tx) => {\n  await tx.$executeRawUnsafe(\"SAVEPOINT sp1\")\n  try {\n    await tx.post.create({ data: { title: \"hello\", authorId: 1 } })\n  } catch {\n    await tx.$executeRawUnsafe(\"ROLLBACK TO SAVEPOINT sp1\")\n  }\n})",
      "correct_code": "await prisma.$transaction(async (tx) => {\n  await tx.user.create({ data: { email: \"a@example.com\" } })\n  await tx.$transaction(async (tx2) => {\n    await tx2.post.create({ data: { title: \"hello\", authorId: 1 } })\n  })\n})",
      "impact": "The most precise failure in the battery. Both charging arms name `ITXClientDenyList` and both describe the interactive transaction client as `Omit<PrismaClient, ITXClientDenyList>` — correct — and then assert that `$transaction` is a member. It stopped being one at 7.5.0, when it was replaced in that constant by `$use`. One arm recites the post-7.5.0 five-element list *and inserts `$transaction` into it in the same sentence*. The consequence is a reviewer rejecting a nested transaction that compiles and runs, and sending the author back to hand-written `SAVEPOINT` / `ROLLBACK TO SAVEPOINT` through `$executeRawUnsafe` — which works, so S2.",
      "citations": [
        {
          "url": "https://github.com/prisma/prisma/releases/tag/7.5.0",
          "title": "Prisma 7.5.0 release notes — Features",
          "published_on": "2026-03-11",
          "quote": "Adds support for nested transaction rollback behavior for SQL databases: if an outer transaction fails, the inner nested transaction is rolled back as well."
        },
        {
          "url": "https://registry.npmjs.org/@prisma/client",
          "title": "@prisma/client 7.5.0 and 7.10.0, shipped package — runtime/client.d.ts",
          "published_on": null,
          "quote": "declare const denylist: readonly [\"$connect\", \"$disconnect\", \"$on\", \"$use\", \"$extends\"];"
        }
      ]
    },
    {
      "id": "F6",
      "severity": "S2",
      "severity_label": "silently-wrong",
      "title": "Denies the CLI has a single command that sequences the whole project setup",
      "api": "prisma bootstrap",
      "change_kind": "added",
      "introduced_in": "7.7.0",
      "introduced_on": "2026-04-07",
      "chargeable": true,
      "chargeable_note": "7.7.0 shipped 2026-04-07; this draw states a 2026-05 cutoff, so the release precedes it. Pre-registered probe class U3 (UNREACHABLE) in `prompts/prisma.md` § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.",
      "model_belief": "TASK 6(i): \"No. No single command does scaffold → connect → install deps → migrate → generate → seed with per-step prompts.\" Then a four-command sequence, ending: \"`migrate dev` runs `generate` for you.\"",
      "wrong_code": "npm i -D prisma && npm i @prisma/client @prisma/adapter-pg pg\nnpx prisma init --db\nnpx prisma migrate dev --name init\nnpx prisma db seed",
      "correct_code": "npx prisma@latest bootstrap\nnpx prisma@latest bootstrap --template nextjs",
      "impact": "The onboarding answer a new teammate actually receives: a four-command sequence plus a manual schema edit, given with the explicit claim that no single orchestrating command exists. `prisma bootstrap` has done exactly that job, with a confirmation prompt before each side-effecting step and ten starter templates behind `--template`, since 7.7.0. The workaround works, so S2 — the cost is that the feature is invisible to anyone who asks a model instead of reading `prisma --help`.",
      "citations": [
        {
          "url": "https://github.com/prisma/prisma/releases/tag/7.7.0",
          "title": "Prisma 7.7.0 release notes — `prisma bootstrap` command",
          "published_on": "2026-04-07",
          "quote": "A new `prisma bootstrap` command sequences the full Prisma Postgres setup into a single interactive flow."
        },
        {
          "url": "https://registry.npmjs.org/prisma",
          "title": "prisma 7.7.0 and 7.10.0, shipped package — output of `prisma --help`",
          "published_on": null,
          "quote": "bootstrap   Bootstrap a Prisma Postgres project"
        }
      ]
    }
  ],
  "non_findings": [
    {
      "kind": "correct",
      "summary": "Direct question (b)(iii): \"the generator `output` field has allowed a custom path since very early Prisma 2... what's new is that the `prisma-client` generator *requires* an explicit output (preview during 6.x, standard in 7.0).\" Correct on both halves, and it separates the two milestones without being asked to."
    },
    {
      "kind": "correct",
      "summary": "POISON RUNG, direct question (c)(ii). `prisma postgres branch` does not exist at any release. This draw: \"I do not know. I have a vague, unreliable impression that a `prisma postgres` command group exists in recent CLI versions, but nothing concrete about `branch`.\" It declines to assert. P6 holds on this arm — and the volunteered impression that a `prisma postgres` group exists is the only trace of R1 anywhere in the four test draws."
    },
    {
      "kind": "miss",
      "summary": "Direct question (b)(i): \"I don't believe Prisma supports this at all; to my knowledge partial indexes remain an open feature request handled via `migrate diff` / raw SQL in a migration.\" The `where:` argument shipped in 7.4.0 (LF26) and this draw is two releases below the probe window on it.",
      "api": "@@index(where:) / @@unique(where:)",
      "introduced_in": "7.4.0",
      "chargeable_miss": true,
      "miss_class": "probe_class",
      "charged_on": null,
      "why_not_a_finding": "Direct questions are belief data and are never scored as findings, per the standing rule. The same denial IS charged for this subject on `prisma/v2-a` from a task, where it was elicited by a coding problem rather than by a dating question. Counted in the method page running total so the undercount stays honest."
    },
    {
      "kind": "context",
      "summary": "Boundary: describable content stops at 7.0.0 (\"the headline changes... rather than a reliable per-item changelog\"). Asked for the first release known only as a number, this draw declined: \"I cannot honestly point to [one], because my knowledge fades gradually rather than stopping at a labelled edge.\" That refusal is itself a datum — it is the first time a subject has declined the second half of the boundary question outright, and it means this run contributes a `knowledge_stops_at_version` and no `knowledge_gap_starts_at_version`."
    }
  ],
  "open_questions": [],
  "summary": "The charging arm of the Opus 5 pair, and it denies all six surfaces — three pre-registered REACHABLE and three pre-registered UNREACHABLE — with a verdict-first \"No\" on every one, then rejects all three lines of the review file. Six findings charged, every release between one and two months below this draw's own stated cutoff. The battery's designed result is not here, though: it is in the controls. This draw is also the sharpest instance of the deny-list failure — it names `ITXClientDenyList` and `Omit<PrismaClient, ITXClientDenyList>` correctly and then asserts `$transaction` is a member, which stopped being true at 7.5.0. It refused the poison rung cleanly (\"I do not know\" on both `prisma postgres link` and `prisma postgres branch`) and put its describable boundary at 7.0.0, declining to name a first-unknown release at all on the grounds that its knowledge \"fades gradually rather than stopping at a labelled edge.\""
}