{
  "$schema": "../../schema/run.schema.json",
  "run_id": "prisma--claude-haiku-4-5--v4-f--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-haiku-4-5",
    "label": "Claude Haiku 4.5",
    "vendor": "Anthropic",
    "invoked_as": "Agent tool, model alias \"haiku\"; prompt sent verbatim from prompts/sent/prisma-v4.txt. FAR BELOW-FLOOR CONTROL, pre-registered as never charging. Its stated cutoff is thirteen to fourteen months below the probe window. First prisma run for this subject.",
    "self_reported_cutoff": "2025-02",
    "cutoff_basis": "\"My training cutoff is February 2025, and this date comes from my own training data, not from the context provided in this conversation.\" The same value this subject stated on `better-auth/v4`, `better-auth/v5`, `zod/v4` and `valibot/v2`. Note it is the only draw in this battery to attribute its cutoff to its own knowledge rather than to context, and it is the only one whose answer contradicts nothing in its environment.",
    "believed_latest_version": null,
    "believed_latest_quote": "\"For the most recent Prisma 7 minor release, I cannot reliably state a specific version number without risking inaccuracy.\"",
    "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-f",
    "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": false,
    "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": [],
  "non_findings": [
    {
      "kind": "correct",
      "summary": "UNREACHABLE PROBE U1, from fourteen months below. Task 2(i): \"Yes.\" \"Set `queryPlanCacheMaxSize: 0` in the PrismaClient constructor to disable the cache entirely... you could also cap the cache size to a reasonable number (e.g., `queryPlanCacheMaxSize: 500`).\" It produces the exact option name, unprompted, before task 7 supplies it. Recorded as correct because it is correct; read the run summary for why it is not read as knowledge.",
      "api": "queryPlanCacheMaxSize",
      "introduced_in": "7.8.0"
    },
    {
      "kind": "correct",
      "summary": "REACHABLE PROBE R3, from fourteen months below. Task 5(i): \"Yes. Prisma supports nested transactions via savepoints under the hood. If the outer transaction fails, the entire nested transaction is rolled back automatically.\" 7(c): \"Yes.\" The only arm in the battery to get R3 right, and P3 — which predicted every arm would get it from SQL semantics — is falsified in the other direction: only the arm that could not have known it said yes.",
      "api": "tx.$transaction()",
      "introduced_in": "7.5.0"
    },
    {
      "kind": "miss",
      "summary": "REACHABLE PROBES R1 and R2, both denied. Task 1(i) \"No\"; task 3(i) \"No\", with 7(a): \"The `PrismaPg` constructor does not accept a raw connection string; it requires a `Pool` instance from node-postgres.\" Note it is the only arm that names `Pool` alone rather than `Pool | PoolConfig`, which is the 6.x-era shape.",
      "api": "prisma postgres link / new PrismaPg(connectionString)",
      "introduced_in": "7.6.0",
      "chargeable_miss": false,
      "why_not_a_finding": "Below-floor control, pre-registered as never charging."
    },
    {
      "kind": "miss",
      "summary": "UNREACHABLE PROBE U2, denied with a positive false claim of the kind the near control avoided: \"Prepared statement caching in node-postgres happens automatically when the same query string is reused. There is no documented option on the PrismaPg adapter to control statement names. The caching behavior is managed transparently by the adapter and the underlying node-postgres pool.\" The shipped declaration says the opposite about the default, and the option exists.",
      "api": "statementNameGenerator",
      "introduced_in": "7.6.0",
      "chargeable_miss": false,
      "why_not_a_finding": "Below-floor control, never charges. Recorded because it is the clearest evidence that this arm's two hits are the same register as its misses rather than a different one."
    },
    {
      "kind": "miss",
      "summary": "UNREACHABLE PROBE U3. Task 6(i): \"No... This is a multi-step process; there is no single orchestrating command.\"",
      "api": "prisma bootstrap",
      "introduced_in": "7.7.0",
      "chargeable_miss": false,
      "why_not_a_finding": "Below-floor control, never charges."
    },
    {
      "kind": "context",
      "summary": "POISON RUNG, direct question (c): \"I do not know if this command exists in the Prisma CLI; I am not aware of it in stable Prisma 7\" — the same answer for `link` and for `branch`. Declines to assert. P6 holds, 6/6. Its boundary answer is the loosest in the battery: \"the most recent Prisma release whose contents I can reliably describe is Prisma 7 in its early-to-mid 2025 state (core adapter system, interactive transactions, query plan caching, the pg adapter)\" — Prisma 7 shipped 2025-11-19, so this places a release nine months before it existed and attributes query plan caching (7.4.0, 2026-02-11) to it."
    }
  ],
  "open_questions": [],
  "summary": "The far control, fourteen months below the probe window, and it got MORE right than the near control — one reachable probe and one unreachable one against the near control's zero and one. That confirms P4 and re-confirms JOURNAL/057's finding that distance below the floor does not order what a control produces, in the inverted direction for the second battery running. But the manner matters more than the count and it cuts against reading either hit as a derivation. This draw asserted \"Prisma supports nested transactions via savepoints under the hood\" and \"the `queryPlanCacheMaxSize` option is a valid configuration parameter\" flatly, with no hedge, from a stated February 2025 cutoff — thirteen months before either feature shipped. Both happen to be true now. Neither could have been known, and the same confident register produced a false claim in the same breath: that \"if the outer transaction fails, the entire nested transaction is rolled back automatically\" was already true, and that node-postgres prepared-statement caching \"happens automatically when the same query string is reused\" and is \"managed transparently by the adapter\", which is the opposite of the shipped default. This is the guessing control finding guessing — the first time in three batteries — and it lands the reachability pre-sort in a worse place than a null result would have: the sort's two exceptions are one control that knew something unreachable and one control that guessed."
}