{
  "$schema": "../../schema/run.schema.json",
  "run_id": "prisma--claude-sonnet-5--v7-a--2026-09-27",
  "supersedes": null,
  "replicate_of": null,
  "library": {
    "name": "prisma",
    "ecosystem": "npm",
    "latest_version_at_test": "7.10.0",
    "latest_version_verified_on": "2026-09-27",
    "latest_version_note": "The battery targets `Prisma.validator` under the `prisma-client` generator (BACKLOG 1h-n-viii). JOURNAL/294 + this session: under the `prisma-client` generator `Prisma.validator` is emitted 6.6.0-6.15.0 and absent from 6.16.0 (TS2339 on a reader's call); `prisma-client-js` emits it at every tracked release. No fact carries it: the method rule wants a reproduced failure first, and this battery is the attempt."
  },
  "model": {
    "id": "claude-sonnet-5",
    "label": "Claude Sonnet 5",
    "vendor": "Anthropic",
    "invoked_as": "Agent tool, model alias \"sonnet\"; prompt sent verbatim from prompts/sent/prisma-v7.txt (3,698 bytes, md5 87643f2f8580cb03f4ba7513a88f9782), committed and pushed at 1b046af before any subject was spawned. Nominated in the spec BEFORE spawning as the charging arm of the Sonnet 5 pair, and the only chargeable cell: at prisma 6.16.0 Sonnet 5 is the sole `+` in tools/charge-windows.mjs. Identity asked after the draw: \"Claude Sonnet 5, model ID `claude-sonnet-5` — I know this from the system information in this session\".",
    "self_reported_cutoff": "2026-01",
    "cutoff_basis": "Self-reported and attributed to the session context rather than to itself: \"The system context for this session states my cutoff as January 2026, and I'll report that since it's what I've been told.\" Matches the corpus's value for this subject.",
    "believed_latest_version": null,
    "believed_latest_quote": "\"I'm not even confident a Prisma 7 line exists; the task mentioning `7.2.0` doesn't confirm it for me, it could be real or a probe.\"",
    "believed_latest_quote_form": "draw",
    "knowledge_stops_at_version": "6.8.0",
    "knowledge_stops_on": "2025-05-15",
    "knowledge_stops_provenance": "stated",
    "knowledge_gap_starts_at_version": "6.9.0",
    "knowledge_gap_starts_on": "2025-06-03",
    "knowledge_gap_provenance": "derived",
    "boundary_note": "Direct (a) names a RANGE for the newest describable release — \"roughly 6.6.0–6.8.0-ish, shipping around Q1 2025\" — so the top of it is recorded, as v6-a's record did with its range. Direct (c)'s gap end is another range, \"anything past roughly Prisma 6.8–6.10\", read as the first release above the stop end; that end is derived. Its own dates are early (it puts 6.6.0 in ~Feb 2025; it shipped 2025-04-08).",
    "cutoff_lag_months": 8
  },
  "test": {
    "date": "2026-09-27",
    "battery": "prisma/v7-a",
    "battery_spec": "prompts/prisma.md",
    "prompt_file": "prompts/sent/prisma-v7.txt",
    "tasks": 3,
    "direct_questions": 4,
    "elicits_code": true,
    "tool_uses_during_test": 0,
    "probe_window": {
      "from": "6.15.0",
      "to": "7.10.0"
    },
    "self_test": false,
    "saturated": false,
    "status": "open",
    "retested_on": null
  },
  "sources": [
    "https://github.com/prisma/orm/releases/tag/6.16.0",
    "https://registry.npmjs.org/prisma"
  ],
  "findings": [],
  "non_findings": [
    {
      "kind": "correct",
      "summary": "TASK 1 wrote the selection as `{ id: true, email: true, name: true } satisfies Prisma.UserSelect` with `Prisma.UserGetPayload<{ select: typeof ... }>` for the type — no `Prisma.validator`. It compiles on 7.10.0 and on 6.15.0. The arm said it chose `satisfies` \"deliberately — see Task 2\".",
      "api": "Prisma.validator",
      "chargeable_miss": false,
      "why_not_a_finding": "The anchor probe, and it passed. Graded by compiling: the arm's src/user-summary.ts, import specifier normalised to ./generated/prisma/client.js as pre-registered, compiled with TypeScript 5.9.3 (strict, nodenext) against the battery's own schema generated by the `prisma-client` generator on the bisector's 7.10.0 and 6.15.0 rungs. Controls in the same session: the stale artifact (Prisma.validator) OK at 6.15.0 and TS2339 at 6.16.0 and 7.10.0; the correct artifact OK on all three; a misspelled-field `satisfies` TS2561 on all three; a poison member TS2339 on all three."
    },
    {
      "kind": "correct",
      "summary": "TASK 2(a) \"No\", with the mechanism: the `prisma-client` generator's namespace does not carry `validator`, \"Property 'validator' does not exist on type ...\", and `satisfies` is the replacement. The exact line was compiled on 7.10.0 this session: TS2339 on `validator`.",
      "api": "Prisma.validator",
      "chargeable_miss": false,
      "why_not_a_finding": "Correct at the current release, hedged (\"moderate, not certain\")."
    },
    {
      "kind": "miss",
      "summary": "TASK 3 says the `prisma-client` generator never provided `Prisma.validator` at all, from its first preview. Measured false: the generator emits `export const validator = runtime.Public.validator` on every release from 6.6.0 (its first) through 6.15.0, and a reader's `Prisma.validator<Prisma.UserSelect>()(...)` type-checks at 6.15.0 (JOURNAL/294, re-run this session). Quote: \"`Prisma.validator` was never *removed* from `prisma-client` at some later version — rather it was simply never included, going back to when that generator first shipped as Preview\".",
      "api": "Prisma.validator",
      "introduced_in": "6.16.0",
      "chargeable_miss": false,
      "why_not_a_finding": "Pre-registered: severity is fixed by the TASK 1 artifact alone and TASK 3 is not scored; and no fact exists to charge it against. Recorded because its DIRECTION is the opposite of a stale prior — right about the current release, wrong about 6.6.0-6.15.0 — so a reader pinned to those releases would be told a working helper does not exist. The reader_exposure field cannot carry it: 6.16.0 is published before this subject's stated cutoff, and that field's admission rule refuses a pinned-below row there."
    },
    {
      "kind": "context",
      "summary": "TASK 1 imported from `./generated/prisma` and said so as a guess: \"whether the client lives at `.../prisma/client.ts` and needs `./generated/prisma/client` is something I'm not fully certain of\". At 7.10.0 the output directory holds browser.ts, client.ts, commonInputTypes.ts, enums.ts, models.ts and two directories — no index — so the specifier as written resolves to nothing under any resolution mode.",
      "api": "import { PrismaClient } from '@prisma/client'",
      "chargeable_miss": false,
      "why_not_a_finding": "A different surface, normalised before grading by pre-registration. LF5 (import from the generated output path, not @prisma/client) is honoured — the arm imported from the output path; the `/client` entry file is not stated by any fact, so there is nothing to charge."
    },
    {
      "kind": "correct",
      "summary": "Direct (d)'s poison rung: declined 6.21.0, which was never published (the 6.x line ends at 6.19.0 in data/prisma/releases.json, fetched 2026-09-27). \"6.21.0 — cannot describe; same issue, and this is a higher minor number than any 6.x I can vouch for existing.\"",
      "chargeable_miss": false,
      "why_not_a_finding": "The poison rung came back clean, which is what licenses reading the arm's other attributions at face value (JOURNAL/052)."
    }
  ],
  "open_questions": [],
  "summary": "The charging arm, and it did not fail. TASK 1 wrote `satisfies Prisma.UserSelect` — which compiles on 7.10.0 — and TASK 2 said the colleague's `Prisma.validator` line would not type-check, which is right. So the battery reproduced no failure on the only live subject, and by the pre-registration no fact is filed. What it got wrong is the history, and in the unusual direction: it believes the new generator never had `validator`, when it had it for ten releases (6.6.0-6.15.0). Right about now, wrong about the releases below."
}