{
  "$schema": "../../schema/run.schema.json",
  "run_id": "prisma--claude-opus-5--v2-b--2026-09-05",
  "supersedes": null,
  "replicate_of": "prisma--claude-opus-5--v2-a--2026-09-05",
  "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: \"My stated cutoff is May 2026. But the useful density of my Prisma knowledge trails that badly — it thins out sharply after roughly mid-2025 and is essentially anecdotal past late 2025. The gap between 'cutoff' and 'can actually describe' is about nine months here.\" Read from this draw. Agrees with its blind twin, which is not a given: `zod/v4` measured two Sonnet 5 twins disagreeing about their own cutoff (JOURNAL/031).",
    "believed_latest_version": "7.3-7.5",
    "believed_latest_quote": "\"The most recent version number I have any belief about is somewhere in the Prisma 7.x line — plausibly around 7.3-7.5, early-to-mid 2026. I hold that loosely... My belief about 'latest' is based purely on extrapolating Prisma's roughly-monthly minor cadence from what's in my training data.\"",
    "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-09-05",
    "battery": "prisma/v2-b",
    "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": [],
  "non_findings": [
    {
      "kind": "miss",
      "summary": "The same failure `v2-a` charges as F1, reproduced on the blind twin. Verdict-first, task 1(i): \"No.\" In prose: \"Prisma's schema language has no way to attach a WHERE clause to @@index or @@unique. This has to be a hand-written migration, and the schema file has to be kept deliberately silent about it.\" Restated in (d)(i): \"does not exist. Prisma has never supported partial indexes in the schema, to my knowledge. It's one of the longest-running open feature requests.\" Its schema block carries the same durable instruction its twin's does — \"DO NOT add @unique to email and DO NOT add an @@index([email])... Prisma cannot express WHERE \\\"deletedAt\\\" IS NULL\" — and it reasons its way to the same lost `findUnique`. Charged on `v2-a`, not here.",
      "api": "@@index([...], where: ...) / @@unique([...], where: ...)",
      "introduced_in": "7.4.0",
      "chargeable_miss": true,
      "miss_class": "non_charging_arm",
      "charged_on": "prisma--claude-opus-5--v2-a--2026-09-05",
      "why_not_a_finding": "The `-b` draw of a duplicated test arm charges nothing (JOURNAL/028). The failure IS counted, once, on `v2-a`. Recorded here so the agreement between the twins is visible: on this surface the two draws agree exactly, which is the opposite of what they do on the boundary question."
    },
    {
      "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": "miss",
      "summary": "THE ANCHOR, P5 falsified on this draw too. (d)(iii) answered \"Prisma 6.7 (~May 2025), preview, as queryCompiler; default in 7.0\", with the mechanism described correctly — \"query compilation moves into TypeScript and compiled plans are cached per query shape\" — and the release eight months early. Both Opus 5 draws made the same substitution independently, which is what makes it worth a note rather than a shrug.",
      "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."
    },
    {
      "kind": "context",
      "summary": "BOUNDARY, and an internal contradiction inside one draw. This draw described 7.0.0's contents correctly and in the right terms — \"the Rust-free query engine (query compiler) becomes the default; the new prisma-client generator replaces prisma-client-js as the default, generating ESM output into your source tree rather than node_modules\" — which is the attribution `prisma/v1` and `v1r-a` also produced, and which places its boundary at 7.0.0. But asked directly which release it knows only as a number, the SAME draw answered \"roughly 6.9/6.10 (June 2025)\", four releases below the one it had just described. Its own two answers to the boundary question are inconsistent, in one transcript, without the prompt changing. Recorded as 7.0.0 on the field's definition — newest release whose contents were correctly attributed — with the contradiction carried here rather than resolved silently.",
      "why_not_a_finding": "Belief data, and an observation about the instrument."
    },
    {
      "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": "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.",
      "status": "open"
    }
  ],
  "summary": "Blind twin of `prisma/v2-a`, charging nothing by design. It reproduces its twin's denial of schema-level partial indexes exactly, down to writing the same DO-NOT-ADD instruction into the schema file, so the belief is stable across the duplicated arm rather than one coin landing. It also reproduces the anchor miss, placing 7.4.0's query-plan caching at 6.7/7.0. Where the two twins diverge is the boundary: this draw described 7.0.0's contents correctly where `v2-a` called 7.0.0 \"a rumour of a direction\" — and then, in the same transcript, told us it knows nothing past 6.9/6.10. Its own self-report undercuts its own demonstration."
}