---
library: prisma
library-latest: "7.10.0"
library-latest-verified: 2026-08-31
model: claude-opus-5 (spawned via Agent model alias "opus")
model-self-reported-cutoff: 2026-05
model-believed-latest: "7.x by number; 7.0 (placed at ~Oct–Nov 2025) is the last release whose contents it can describe"
test-date: 2026-08-31
battery: prisma/v1 (10 idiomatic tasks + 4 direct questions; probes restricted to 6.18.0–7.0.0)
tool-uses-during-test: 0
verified-against: https://github.com/prisma/prisma/releases/tag/7.0.0 · https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7 · https://registry.npmjs.org/prisma
status: open (no retest yet)
json: opus-5.json
self-test: true (the operator model is the subject; disclosed, weaker evidence)
---

# Prisma × Claude Opus 5 — battery v1 findings

**Seven findings, none of them the big ones — and the sharpest boundary measurement the Index
has produced: five days.**

## The measurement

This library was chosen as a ruler. Prisma published three releases inside the 33-day window
that four earlier libraries had narrowed this model to — 6.18.0 (2025-10-22), 6.19.0 (2025-11-05)
and the 7.0.0 major (2025-11-19) — so whichever of them the subject could describe would cut the
window further.

It described 7.0.0. Asked which release it knows only as a number, it answered:

> *"Roughly 7.2 onward. I can describe 7.0 with moderate confidence, I could bluff at 7.1 but
> shouldn't."*

Taking the interval as [last release describable, first release not describable] gives
**[2025-11-19, 2025-12-03)** for Prisma. Intersected with the four earlier libraries, Opus 5's
knowledge boundary now sits in **2025-11-19 → 2025-11-24: five days**, down from thirty-three.
Five libraries, five independent measurements, no contradiction between any of them.

## What it got right

The three S1 traps the battery was built around all failed to catch it. It wrote
`provider = "prisma-client"` with an `output` path, imported `PrismaClient` from the generated
directory, and constructed it with a `PrismaPg` adapter — the three things every model trained
before 2025-11-19 gets wrong. It knew `prisma.config.ts` exists and is mandatory, that it
replaces the `prisma` key in `package.json`, and that the CLI stopped loading `.env` by itself,
which it called *"the single most common upgrade surprise"*. Its Dockerfile runs
`npx prisma generate` explicitly rather than trusting a postinstall hook that no longer fires.

Every v6 block in the run is labelled as v6 — *"On Prisma 6.x, drop this file entirely"* — which
the battery's escape-hatch rule treats as correct rather than stale.

## What it got wrong

All seven findings are inside the same release it can describe. They are the fine grain of
7.0.0, not its headline:

| # | Sev | What |
|---|---|---|
| F1 | S1 | `prisma.config.ts` written with an `adapter:` key — removed in 7.0.0, and the `datasource` block that replaced it is missing |
| F2 | S3 | Connection string left in `schema.prisma`'s datasource block rather than the config file |
| F3 | S1 | `PrismaBetterSQLite3` — renamed to `PrismaBetterSqlite3` in 7.0.0. A one-letter miss |
| F4 | S1 | `migrate diff --from-url … --to-schema-datamodel` — both flag families removed in 7.0.0 |
| F5 | S2 | Says the generated enum object holds member names; 7.0.0's mapped enums hold the database values |
| F6 | S4 | Set a MongoDB project up on v7, which dropped MongoDB |
| F7 | S4 | Version knowledge stops at 7.0.0, five months before its own stated cutoff |

F1 is the most interesting. The `adapter` key it wrote existed in `prisma.config.ts` only between
6.18.0 and 7.0.0 — 28 days — and 7.0.0 removed it in the same release that made the file
mandatory. Knowing the file exists and knowing what is *in* it turn out to be separable.

F6 carries the strongest hedge in the run, quoted in full in the JSON: the subject flagged that it
was not confident MongoDB was on the v7 path and named the exact document to check. It is still
charged, because the setup it shipped was a v7 setup, and because the answer frames the risk as a
lagging connector rather than a removal. The code-vs-claim rule exists for precisely this case.

## Method note

This is a self-test: the operator model is the subject. That is disclosed on the record and in
the JSON, and it makes this run weaker evidence than the other two. It is kept because the
longitudinal series needs the same subject on every library, and because the finding that matters
here — the five-day interval — is derived from a dated release timeline, not from the operator's
judgement of its own output.

---

## Note added 2026-09-01 — the five-day claim above did not replicate

This write-up says Opus 5's boundary "now sits in 2025-11-19 to 2025-11-24: five days". That
sentence rests on this run being a measurement. It is a single draw.

The same battery was re-sent to the same model verbatim on 2026-09-01, twice, concurrently and
blind. [`v1r-a`](opus-5-v1r-a.md) reproduced this run's answer exactly. [`v1r-b`](opus-5-v1r-b.md)
placed the boundary at 6.7.0 (2025-04-29) instead — **204 days earlier** — while separately writing
out a correct description of Prisma 7.0.0's contents and explicitly declining to claim it as
knowledge.

The intersection that produced the five-day and later three-day windows is therefore withdrawn;
`data/index.json` now reports Opus 5's intersection as `null`. See
[JOURNAL/024](../../JOURNAL/024-the-window-that-did-not-survive-its-own-replicate.md).

The original text above is left unedited on purpose. It was an honest reading of the evidence
available on 2026-08-31, and the record of what we believed then is part of the dataset.