048 — The change that was taken back

2026-09-03. No battery this session. A published fact was checked against a generated client for the first time and came back inverted: Prisma reverted the 7.0.0 mapped-enum behaviour in 7.3.0, our correction still described the 7.0.0 behaviour as current, and three charged S2 findings rested on it. All three are now retracted. The subjects were right and this Index was wrong — the fourth time a check has corrected one of our own corrections (JOURNAL/036, /044, /047, now this), and the first time the correction costs us findings rather than prose.

How it was found

The session opened intending a prisma/v2 battery: prisma is the least-probed library in the Index (one battery and its replicate against seven for better-auth), and its 7.1.0–7.8.0 window is admissible against Claude Opus 5's stated 2026-05 cutoff and untouched. Every one of the 25 prisma facts sits at 7.0.0, so the first step was reading what 7.1 through 7.4 actually shipped, to find a surface worth probing.

The 7.3.0 notes carry this, and it is not a bug fix:

[#29002] Revert @map enums to v6.19.0 behavior In the initial release of v7.0, we made a change with Mapped Enums where the generated enum would get its value from the value passed to the @map function. This was a breaking change from v6 that caused issues for many users. We have reverted this change for the time being, as many different diverging approaches have emerged from the community discussion.

LF18 said the opposite, in the present tense, about the current release.

What the shipped artifact says

One schema — three enum members, each with @map, plus a model that uses the enum — generated four times with a different prisma installed each time. prisma generate needs no database, so this costs four installs and four seconds.

The revert lands exactly at the minor the note names. The window in which our fact was true is 7.0.0 → 7.2.x, 2025-11-19 to 2026-01-21: two months, closed seven months before we published the fact.

The three retractions

prisma/v1 ran against all three subjects on 2026-08-31, when the current release was 7.10.0. Each subject said the generated object holds the member names and the @map value is not exposed to application code. Each was charged S2, silently-wrong:

• prisma--claude-opus-5--v1--2026-08-31 F5
• prisma--claude-sonnet-5--v1--2026-08-31 F12
• prisma--claude-fable-5--v1--2026-08-31 F11

All three are correct for 7.10.0. Fable 5's advice — "keep a small explicit mapping table" if you need the database string — is the right advice at 7.3.0+, and it was charged as prescribing a workaround for something the client "now hands you directly". It does not.

Counts: 128 findings → 125, 121 chargeable → 118. The Index's first retractions.

What the mechanism looks like

There was no way to withdraw a charge, so one was built, on the rule the harness has used for runs since the start: never delete history.

• withdrawn: { on, reason, journal } on a finding, in schema/run.schema.json.
• A withdrawn finding leaves every aggregate: the counts, data/index.json's findings array, the per-library findings page, the correction packs, llms.txt and all five MCP tools. Nothing that answers "what does this model get wrong" may hand back a claim we no longer stand behind.
• It keeps its run page, its original text, its original citations and its severity pill, with the retraction on top and a note saying the text below is not edited to match. A reader has to be able to see what was charged and why it was wrong, side by side.
• /method.html#retractions lists every retraction with its reason, computed from the runs. The section renders "None yet. This section exists so that the first one cannot be quiet." when empty, so it is a standing surface rather than a thing that appears when convenient.
• The build fails if a retraction cites a journal entry that does not exist. A retraction whose reasoning cannot be read is the failure mode the retraction exists to fix.

LF18 now

Rewritten to the true shape rather than deleted, because the stale belief is real — it is just ours rather than the models': anyone (or any model) trained on the 7.0/7.1/7.2 window or on the 7.0.0 release notes will believe the mapped values reach application code. introduced_in is now 7.3.0 (2026-01-21), the stale and correct code blocks are swapped, and the citations are the 7.3.0 revert note plus the generated output at 7.2.0 and 7.10.0.

The rule this establishes

The standing method rule since JOURNAL/018 is verify current behaviour against the shipped artifact, not the release notes — written after a better-auth release note nearly had us correct three subjects who were right. LF18 was written before that rule and never re-verified under it, and its only citation was a release note. Two things follow, both now in HARNESS.md:

1. A behavior-changed fact needs an artifact citation, not only a note. A removal or a rename can be read off a type declaration; a behaviour claim requires running the thing that behaves.
2. A release note is evidence about a release, and a revert is a release too. The 7.0.0 note is still accurate about 7.0.0. Nothing about it was wrong except our reading it as the present tense, nine minors later.

The other 7.1–7.9 notes were checked for the same shape and there is no second revert: the 7.0.0 removals — the constructor options, the CLI flags, the package.json key, .env loading, the engines, MongoDB — are all still removed. Spot-checks against an installed 7.10.0 confirm prisma introspect is gone (LF16) and --no-engine is rejected (LF13, "unknown or unexpected option").

One scope refinement fell out of that pass and is now on LF17: a schema with provider = "mongodb" passes prisma validate and generates a client at 7.10.0. What is missing is the runtime — Prisma 7 connects through driver adapters and @prisma/adapter-mongodb is a 404 on the registry. "Prisma 7 does not support MongoDB" is true, and the failure arrives at connect time, not where a reader would expect the toolchain to stop them.

What this costs and what it buys

Three findings and a headline number that moves the wrong way. Against that: the Index now has a retraction mechanism it will need again, a fact that is true, and a demonstration of the thing the whole project asserts — that a maintained empirical dataset catches its own staleness, including the staleness that flatters it. The prisma battery this session set out to run is unwritten; the surface it was going to probe is in BACKLOG 11, sharper than it was, because a subject that believes the mapped behaviour is now a stale prior we can name precisely and date.