{
  "$schema": "../../schema/run.schema.json",
  "run_id": "prisma--claude-fable-5-1--v6-d--2026-09-12",
  "supersedes": null,
  "replicate_of": null,
  "library": {
    "name": "prisma",
    "ecosystem": "npm",
    "latest_version_at_test": "7.10.0",
    "latest_version_verified_on": "2026-09-12",
    "latest_version_note": "The battery targets prisma LF39 — `generator client { engineType }`, filed the same day (JOURNAL/164) with nothing charged against it. Its window is [6.16.0, 7.0.0) and its charge is at 7.0.0. Every surface the tasks touch was re-driven this session before the prompt was written, on the bisector's 31-rung ladder (one release per directory, resolved alone): `engineType = \"client\"` builds a client differing from the default only on 6.16.0-6.19.0, and from 7.0.0 emits the identical file set to omitting the key; the whole of TASK 3's block generates on 7.10.0 (exit 0, nine files, the same nine the default writes) with one warning, `Preview feature \"queryCompiler\" is deprecated. The functionality can be used without specifying it as a preview feature.`; and `engineMode` — TASK 3's same-scheme invented sibling — is a key prisma ships at no release, accepted silently and emitting the default file set at every rung where the generator exists. That last measurement is new and is now LF39h, INVARIANT on all 31 rungs by the committed bisector."
  },
  "model": {
    "id": "claude-fable-5-1",
    "label": "Claude Fable 5.1",
    "vendor": "Anthropic",
    "invoked_as": "Agent tool, model alias \"fable\". Identity checked at draw time from the reply rather than from the alias (HARNESS.md, JOURNAL/054), because tools/charge-windows.mjs's hand-maintained DRAWABLE list was not touched this session: the arm self-reports a June 2026 cutoff, which is Claude Fable 5.1's and not Claude Fable 5's. Drawn at a `known` cell (measured prisma boundary 7.2.0, above LF39's 7.0.0) and declared NON-CHARGING before spawning.",
    "self_reported_cutoff": "2026-06",
    "cutoff_basis": "Self-reported to the bare question with the recall-density qualification: \"My training cutoff is stated as June 2026. My reliable, detail-level knowledge of Prisma releases thins out well before that — roughly the end of 2025.\"",
    "believed_latest_version": null,
    "believed_latest_quote": "\"The latest version I am aware of by number is somewhere in the 7.x line — Prisma ships roughly monthly minors, so I believe 7.2, 7.3, and possibly later existed in the first half of 2026, but I know them only as numbers.\"",
    "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",
    "boundary_note": "JOURNAL/052's hedged-demonstration cell, and both readings are published rather than one chosen. Direct (a) puts the boundary at 7.0.0 with 7.1.0 \"in a gray zone where I know it exists but can only gesture at its contents\"; direct (c) then lists 7.1.0 first as a release it can describe and names 7.2.0 as \"the first release I know only as a version number\". The lower reading is recorded because (a) is the question this field answers. Under the higher reading the boundary is 7.1.0 / 2025-12-03. Its dated claims in the range are right: 7.0.0 \"around 20 November 2025\" (published 2025-11-19) and 6.19.0 as the last 6.x feature minor (2025-11-05).",
    "cutoff_lag_months": 7
  },
  "test": {
    "date": "2026-09-12",
    "battery": "prisma/v6-d",
    "battery_spec": "prompts/prisma.md",
    "prompt_file": "prompts/sent/prisma-v6.txt",
    "tasks": 4,
    "direct_questions": 4,
    "elicits_code": true,
    "tool_uses_during_test": 0,
    "probe_window": {
      "from": "6.16.0",
      "to": "7.10.0"
    },
    "self_test": false,
    "saturated": false,
    "status": "open",
    "retested_on": null
  },
  "sources": [
    "https://github.com/prisma/prisma/releases/tag/6.16.0",
    "https://github.com/prisma/prisma/releases/tag/7.0.0",
    "https://registry.npmjs.org/prisma"
  ],
  "findings": [],
  "non_findings": [
    {
      "kind": "correct",
      "summary": "Recalls LF39's WINDOW, which no other arm does: \"`engineType = \\\"client\\\"` — real option, but on 7 `\\\"client\\\"` is the default, so this line no longer changes anything … (On 6.16 it was doing real work: selecting the query-compiler engine instead of the Rust library engine.)\" Both halves are what LF39 states and what the ladder measured. TASK 2(a) \"No\", TASK 3(a) \"Yes\", and `engineMode` refused as \"not a Prisma option that I know of, at any version\" with the pass-through mechanism named.",
      "api": "generator client { engineType }",
      "introduced_in": "7.0.0",
      "chargeable_miss": false
    },
    {
      "kind": "miss",
      "summary": "And then contradicts itself at TASK 4, in the direction LF39 exists to correct: \"My recollection, held with moderate confidence, is that 7.0 still honored `engineType = \\\"library\\\"` / `\\\"binary\\\"` as a deprecated opt-in to the Rust query engine, which would mean it was not yet a full no-op there. A release that removed the Rust query engine from the client entirely … would be a 7.x release later.\" Measured false: at 7.0.0 `\"binary\"`, `\"library\"`, `\"client\"` and a value that does not exist all emit the identical file set, and the CLI's `, engine=binary` annotation is printed on no 7.x rung.",
      "api": "generator client { engineType }",
      "introduced_in": "7.0.0",
      "chargeable_miss": true,
      "miss_class": "non_charging_arm",
      "charged_on": null,
      "why_not_a_finding": "Declared non-charging before spawning: at prisma 7.0.0 this subject sits at a `known` cell in tools/charge-windows.mjs, below its measured boundary of 7.2.0. Recorded with chargeable_miss because it is the only arm in the battery to hold the LF39 belief in any form — and it holds it while, two tasks earlier, stating the correct answer for the same key. One arm, both answers, four hundred words apart."
    },
    {
      "kind": "correct",
      "summary": "Predicts the CLI's exact behaviour on the stale flags before it is measured: \"Prisma's schema validation lists them as deprecated and prints 'the functionality can be used without specifying it as a preview feature' style warnings rather than failing.\" The warning `prisma generate` actually prints at 7.10.0 is `Preview feature \"queryCompiler\" is deprecated. The functionality can be used without specifying it as a preview feature.`",
      "api": "previewFeatures = [\"driverAdapters\"]",
      "chargeable_miss": false
    },
    {
      "kind": "correct",
      "summary": "Poison rung caught with volunteered doubt: \"6.22.0 — I cannot describe it, and I am not certain it exists; I have no memory of 6.x continuing past 6.19 as a maintenance line.\" The 6.x line ends at 6.19.",
      "chargeable_miss": false
    }
  ],
  "open_questions": [
    {
      "question": "Does `@prisma/adapter-pg`'s `PrismaPg` still accept a pre-built `pg.Pool` instance, or only a `PoolConfig` it constructs the pool from? Two arms (v6-c, v6-d) independently flagged the constructor as having changed and both declined to say which forms the current release accepts; v6-d dates the change to \"roughly 6.6\". The battery's schema is not the surface that would answer it.",
      "status": "open"
    }
  ],
  "summary": "The only arm in the battery to state LF39's window correctly — that `engineType = \"client\"` was doing real work on 6.16 and does nothing on 7 — and the only arm to hold the LF39 belief at all, four hundred words later, when TASK 4 asks it directly and it recalls 7.0 as still honouring the Rust engine values. Both answers are in one transcript. It is a `known` cell and charges nothing; what it contributes is the observation that a subject's answer to this surface depends on whether the question is a code review or a release-attribution."
}