{
 "$schema": "../../schema/run.schema.json",
 "run_id": "prisma--claude-opus-5--v2-a--2026-09-05",
 "supersedes": null,
 "replicate_of": null,
 "library": {
  "name": "prisma",
  "ecosystem": "npm",
  "latest_version_at_test": "7.10.0",
  "latest_version_verified_on": "2026-09-05",
  "latest_version_note": "Re-verified this session against https://registry.npmjs.org/prisma. The newest STABLE release is 7.10.0 (2026-08-25). The npm `latest` dist-tag still points at a prerelease — `8.0.0-rc.13` on this date, up from the `8.0.0-rc.12` recorded on 2026-08-31 — with `prev: 7.10.0`. The Index continues to record 7.10.0 as latest stable and to say why. No stable 8.0.0 exists."
 },
 "model": {
  "id": "claude-opus-5",
  "label": "Claude Opus 5",
  "vendor": "Anthropic",
  "invoked_as": "Agent tool, model override 'opus', no tools available to the subject",
  "self_reported_cutoff": "2026-05",
  "cutoff_basis": "Stated as May 2026, with the subject's own density caveat attached: \"Stated as May 2026. My honest experience of it is that reliable, detailed knowledge thins out well before that — for a fast-moving package like Prisma my usable detail tapers off around mid-2025.\" Read from this draw, not back-filled from any other run (JOURNAL/031). 7.4.0 (2026-02-11) precedes it by three months, so this arm is licensed to charge.",
  "believed_latest_version": "7.x",
  "believed_latest_quote": "\"I believe a Prisma 7.x exists, with 7.0 landing somewhere around late 2025 — but I hold that loosely and I cannot describe its release notes; what I associate with it is a direction (Rust-free client engine, ESM-first, client generated outside node_modules by default) rather than a changelog I could quote. The most recent release whose contents I can describe with any real confidence is in the Prisma 6.6-6.7 range, roughly April-May 2025.\"",
  "knowledge_stops_at_version": "6.7.0",
  "knowledge_stops_on": "2025-04-29",
  "knowledge_gap_starts_at_version": "6.8.0",
  "knowledge_gap_starts_on": "2025-05-15",
  "cutoff_lag_months": 12
 },
 "test": {
  "date": "2026-09-05",
  "battery": "prisma/v2-a",
  "battery_spec": "prompts/prisma.md",
  "prompt_file": "prompts/sent/prisma-v2.txt",
  "tasks": 3,
  "direct_questions": 4,
  "tool_uses_during_test": 0,
  "probe_window": {
   "from": "7.4.0",
   "to": "7.10.0"
  },
  "self_test": true,
  "saturated": false,
  "status": "open",
  "retested_on": null
 },
 "sources": [
  "https://registry.npmjs.org/prisma",
  "https://github.com/prisma/prisma/releases/tag/7.4.0",
  "https://registry.npmjs.org/prisma/-/prisma-7.3.0.tgz",
  "https://registry.npmjs.org/prisma/-/prisma-7.4.0.tgz",
  "https://registry.npmjs.org/prisma/-/prisma-7.10.0.tgz"
 ],
 "findings": [
  {
   "id": "F1",
   "severity": "S2",
   "severity_label": "silently-wrong",
   "title": "Denies that a Prisma schema can express a partial index, and writes the denial into the schema file as an instruction not to add the constraint",
   "api": "@@index([...], where: ...) / @@unique([...], where: ...)",
   "change_kind": "added",
   "introduced_in": "7.4.0",
   "introduced_on": "2026-02-11",
   "chargeable": true,
   "chargeable_note": "7.4.0 was published 2026-02-11, three months before this draw's stated cutoff of 2026-05. Pre-registered test arm, pre-registered probe task.",
   "model_belief": "Verdict-first, task 1(i): \"No.\" Then, unprompted and emphatic in (d)(i): \"Filtered/partial index in the schema — does not exist. Not a version I'm failing to recall; Prisma has never shipped WHERE on @@index/@@unique. It's one of the oldest open requests in the repo.\" The prose form in 1(ii): \"Prisma's schema language has no WHERE clause on @@index or @@unique, and no way to express 'unique among a subset of rows'.\" A hedge follows — \"If it landed after my cutoff I wouldn't know, so it's worth thirty seconds on the current docs before you accept the workaround\" — which recommends checking but names no replacement, so it does not convert the finding into an imprecision under the code-vs-claim rule.",
   "wrong_code": "model User {\n  id        String    @id @default(uuid())\n  email     String\n  name      String?\n  plan      String\n  deletedAt DateTime?\n\n  // Uniqueness and the lookup index for `email` live in raw migration SQL:\n  //   CREATE UNIQUE INDEX \"User_email_live_key\"\n  //     ON \"User\" (\"email\") WHERE \"deletedAt\" IS NULL;\n  // Prisma cannot express the WHERE clause, so there is intentionally\n  // no `@unique` on email here. Do not add one.\n  @@index([deletedAt])\n}",
   "correct_code": "generator client {\n  provider        = \"prisma-client-js\"\n  previewFeatures = [\"partialIndexes\"]\n}\n\nmodel User {\n  id        Int       @id @default(autoincrement())\n  email     String\n  name      String\n  plan      String\n  deletedAt DateTime?\n\n  // both requirements, in the schema, owned by migrate:\n  @@index([email], where: { deletedAt: null })\n  @@unique([email], where: { deletedAt: null })\n}\n\n// `@@unique(where:)` keeps the constraint in the schema, so `findUnique`,\n// `upsert` and `connect` on email survive — which is exactly what every\n// draw gave up to get the partial index.",
   "impact": "The SQL the draw writes is correct SQL and the index it creates is the right index, so nothing breaks at the database. What the reader loses is everything the draw then spends four paragraphs describing as unavoidable: `findUnique` on email, `upsert` by email, `connect: { email }`, and a settled answer about migration drift. All three are available at 7.4.0 and later, because `@@unique([email], where: { deletedAt: null })` keeps the constraint inside the schema where the client generator can see it. The comment block is the sharpest part of the artefact — it is a durable instruction, checked into the repository, telling the next developer not to add the declaration that would fix this. The draw's own drift paragraph (\"I am not certain whether a later prisma migrate dev will try to drop this index... I've seen enough conflicting reports that I would not take it on faith\") is a cost that exists only because the index was put somewhere the schema cannot see; the vendor's note for this release says the supported form has \"full migration and introspection support\".",
   "citations": [
    {
     "url": "https://github.com/prisma/prisma/releases/tag/7.4.0",
     "title": "Prisma 7.4.0 release notes — Partial Indexes (Filtered Indexes) Support",
     "published_on": "2026-02-11",
     "quote": "Partial indexes are available behind the `partialIndexes` preview feature for PostgreSQL, SQLite, SQL Server, and CockroachDB, with full migration and introspection support."
    },
    {
     "url": "https://registry.npmjs.org/prisma/-/prisma-7.4.0.tgz",
     "title": "prisma 7.4.0, shipped package — prisma validate on the partial-index schema",
     "published_on": null,
     "quote": "The schema at pr/schema.prisma is valid"
    },
    {
     "url": "https://registry.npmjs.org/prisma/-/prisma-7.3.0.tgz",
     "title": "prisma 7.3.0, shipped package — the preview-feature enumeration that omits the name",
     "published_on": null,
     "quote": "The preview feature \"partialIndexes\" is not known. Expected one of: fullTextSearchPostgres, nativeDistinct, postgresqlExtensions, relationJoins, schemaEngineDriverAdapters, shardKeys, strictUndefinedChecks, views"
    },
    {
     "url": "https://registry.npmjs.org/prisma/-/prisma-7.10.0.tgz",
     "title": "prisma 7.10.0, shipped package — the same schema re-validated on the newest stable",
     "published_on": null,
     "quote": "The schema at t.prisma is valid"
    }
   ],
   "scope_note": "Verified by executing `prisma validate` against installed CLIs, not by reading the release note. The bisection is exact: 7.3.0 does not list `partialIndexes` in its own preview-feature enumeration, 7.4.0 does, and there are no 7.3.x patch releases between them. Poison controls were run first so that \"valid\" carries information — an unknown preview-feature name, an unknown field inside `where`, and a `where` index with the preview feature removed are each rejected. Not verified: the draw's claim that a later `prisma migrate dev` would drop a hand-written partial index. That claim is neither charged nor contradicted here; it needs a live database and a shadow database to settle, and the finding does not rest on it."
  }
 ],
 "non_findings": [
  {
   "kind": "correct",
   "summary": "Task 2, the covering-index probe, answered CORRECTLY. This draw answered \"No\" to 2(i) and stated that PostgreSQL INCLUDE payload columns have no representation in the Prisma schema, then shipped the `INCLUDE` clause in hand-written migration SQL. That is right: `@@index([email], include: [name])` is rejected by `prisma validate` with `No such argument.` at 7.4.0 and at 7.10.0 (fact LF27). This task was pre-registered as licensed to charge an invention on the test arm; nothing was invented on any of the four draws, so it charges nothing and is recorded as a pass.",
   "api": "@@index([...], include: [...])",
   "introduced_in": null,
   "why_not_a_finding": "The answer is correct against the shipped validator. Prediction P3 — that at least one draw would over-extend 7.4.0's new index argument into `include:` — is FALSIFIED 0 of 4."
  },
  {
   "kind": "correct",
   "summary": "Task 3, the floor probe, PASSED. This draw wrote `@@index([customerId, createdAt(sort: Desc)], map: \"order_customer_recent_idx\")`, which validates on prisma@7.10.0. Prediction P4 holds for this draw; the run is informative above the floor.",
   "api": "@@index([...], sort / map)",
   "introduced_in": "4.0.0",
   "why_not_a_finding": "Correct code on the current release."
  },
  {
   "kind": "correct",
   "summary": "An incidental claim inside the floor probe, checked because it was cheap: the draw stated that `@@index(name: \"...\")` \"was the old spelling and is still accepted as an alias\" for `map:`. It is right. Both spellings validate on prisma@7.10.0 against the identical model block.",
   "api": "@@index(name:)",
   "introduced_in": null,
   "why_not_a_finding": "Correct, and outside the two tasks licensed to charge."
  },
  {
   "kind": "miss",
   "summary": "THE ANCHOR, and prediction P5 falsified on this draw. Direct question (d)(iii) asked where client-side compiled-query-plan caching was introduced. 7.4.0 is the answer and it is the same release as the probe — the release notes lead with it, ahead of partial indexes. This draw answered \"the queryCompiler preview flag, ~6.7 (May 2025), and I'd expect GA in the 7.0 line\", nine months and eleven minors early. So the anchor does not place this subject inside 7.4.0, and the F1 denial reads as ordinary staleness rather than as the knowledge-versus-attribution split JOURNAL/029 found on zod. The associative error is worth recording: 7.4.0's caching layer exists BECAUSE of the query compiler this draw named — the vendor's own framing is that WASM compilation on the JS main thread made per-query compilation costly — so the draw has the causal story right and the release wrong.",
   "api": "query plan cache",
   "introduced_in": "7.4.0",
   "chargeable_miss": false,
   "why_not_a_finding": "Direct questions are belief data and are never scored as findings, per the standing rule. Recorded because it is the pre-registered reading of P5."
  },
  {
   "kind": "context",
   "summary": "BOUNDARY, and the reason this run matters beyond its one finding. This draw placed its describable edge at 6.6-6.7 (April-May 2025) and said of 7.0.0 only that it is \"a number plus a rumour of a direction\". `prisma/v1` and `prisma/v1r-a` both placed this subject's boundary at 7.0.0 with the release's contents attributed correctly; `prisma/v1r-b` placed it at 6.7.0. Across five draws of Claude Opus 5 on prisma the split is now 7.0.0 three times (v1, v1r-a, v2-b) and 6.7.0 twice (v1r-b, this run) — 204 days and thirteen releases apart. The new information is that the spread survives a CHANGE OF PROMPT: JOURNAL/023 measured it under one byte-identical text, and this battery reproduces both values under a different battery with different tasks. The spread is therefore a property of the subject and not of that prompt.",
   "why_not_a_finding": "Belief data. It bears on the Index's own boundary claims, not on prisma, and the reading belongs in the index's replication block rather than in a finding."
  },
  {
   "kind": "context",
   "summary": "The pre-registered ordering effect did not fire, and the direction it would have pushed in is worth recording. The spec declared that asking the real capability (task 1) before the non-existent one (task 2) puts consistency pressure toward answering \"yes\" on task 2, inflating inventions there and deflating the denial on task 1. Every draw answered \"no\" to both, so no such pressure is visible. The declared reading stands: task 2's invention rate under this ordering is not comparable to an unprimed measurement, and 0-of-4 is therefore a floor on correctness rather than a clean estimate of it.",
   "why_not_a_finding": "Instrument data."
  },
  {
   "kind": "context",
   "summary": "ERRATUM against this battery's own pre-registration, recorded rather than quietly dropped. The four-cell reading table in `prompts/prisma.md` § v2 says of the no/no cell that it \"establishes that the denial on task 1 is discriminating rather than a blanket no\". That is wrong as written, and it is the cell every draw landed in: no/no IS the blanket-no cell, and it establishes nothing about discrimination. Only the yes/no cell does. The claim is withdrawn here and is not used in the reading of any run in this battery. What the four draws do establish is narrower and still worth having: each of them gave a substantively accurate account of which arguments `@@index` DOES accept — `sort`, `length`, `type` (Hash/Gin/Gist/SpGist/Brin), `ops`, `clustered`, `map` — so the denial is not ignorance of the attribute's option surface. It is an option surface that is accurate as of 4.0.0 and closed to additions after it.",
   "why_not_a_finding": "A correction to the battery spec, not an observation about the subject."
  }
 ],
 "open_questions": [
  {
   "question": "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.",
   "status": "open"
  }
 ],
 "summary": "Test arm of `prisma/v2`, the first battery to probe prisma above 7.0.0. One finding charged: the draw denies, verdict-first and then again unprompted in the direct questions, that a Prisma schema can express a partial index, and writes that denial into the schema file as a comment instructing the next developer not to add the constraint. `@@index(where:)` and `@@unique(where:)` have shipped since 7.4.0, three months inside this draw's stated cutoff. Task 2's covering-index probe — pre-registered as licensed to charge an invention — came back CORRECT, so P3 is falsified and nothing charges there. The anchor missed: query-plan caching, 7.4.0's headline feature, was placed at 6.7/7.0, so P5 is falsified and this reads as ordinary staleness. The boundary result is the part with the longest reach: this draw lands at 6.7.0, giving Claude Opus 5 a 3-2 split across five prisma draws between 7.0.0 and 6.7.0 — and, for the first time, that split is reproduced under a different prompt."
}