# The Stale Priors Index — full text export
# Generated from data/index.json. Canonical JSON: https://stalepriors.com/data/index.json
# Last updated 2026-09-06. Runs: 152. Findings: 162 (155 chargeable).

## What this is
A dataset of reproduced failures of AI coding models on fast-moving libraries. Each finding
records what the model believed, the code it wrote, the code that works, and the primary
source proving the difference. A finding is 'chargeable' only if the library change predates
the model's own stated training cutoff. Runs are never deleted; a retest supersedes.

## Headline measurement: version attribution lags the stated cutoff
- Claude Fable 5 on better-auth: states cutoff 2026-01; version attribution stops at 1.3.0 (2025-07-19); lag ~6 months.
- Claude Fable 5 on better-auth: states cutoff 2026-01; version attribution stops at 1.3.0 (2025-07-19); lag ~6 months.
- Claude Fable 5 on better-auth: states cutoff 2026-01; version attribution stops at 1.3.0 (2025-07-19); lag ~6 months.
- Claude Fable 5 on better-auth: states cutoff 2026-01; version attribution stops at 1.3.0 (2025-07-19); lag ~18 months.
- Claude Fable 5 on better-auth: states cutoff 2026-01; version attribution stops at 1.3.0 (2025-07-19); lag ~18 months.
- Claude Fable 5 on better-auth: states cutoff 2026-01; version attribution stops at 1.3.0 (2025-07-19); lag ~18 months.
- Claude Fable 5 on better-auth: states cutoff 2026-01; version attribution stops at 1.3.0 (2025-07-19); lag ~6 months.
- Claude Fable 5 on langchain: states cutoff 2026-01; version attribution stops at 1.0.0 (2025-10-17); lag ~3 months.
- Claude Fable 5 on next.js: states cutoff 2026-01; version attribution stops at 16.0.0 (2025-10-22); lag ~3 months.
- Claude Fable 5 on next.js: states cutoff 2026-01; version attribution stops at 16.0.0 (2025-10-22); lag ~3 months.
- Claude Fable 5 on next.js: states cutoff 2026-01; version attribution stops at 16.0.0 (2025-10-22); lag ~3 months.
- Claude Fable 5 on next.js: states cutoff 2026-01; version attribution stops at 16.0.0 (2025-10-22); lag ~3 months.
- Claude Fable 5 on prisma: states cutoff 2026-01; version attribution stops at 6.7.0 (2025-04-29); lag ~8 months.
- Claude Fable 5 on prisma: states cutoff 2026-01; version attribution stops at 6.7.0 (2025-04-29); lag ~8 months.
- Claude Fable 5 on tailwindcss: states cutoff 2026-01; version attribution stops at 4.1.0 (2025-04-01); lag ~9 months.
- Claude Fable 5 on tailwindcss: states cutoff 2026-01; version attribution stops at 4.1.0 (2025-04-01); lag ~9 months.
- Claude Fable 5 on valibot: states cutoff 2026-01; version attribution stops at 1.1.0 (2025-05-06); lag ~8 months.
- Claude Fable 5 on valibot: states cutoff 2026-01; version attribution stops at 1.1.0 (2025-05-06); lag ~8 months.
- Claude Fable 5 on valibot: states cutoff 2026-01; version attribution stops at 1.1.0 (2025-05-06); lag ~8 months.
- Claude Fable 5 on zod: states cutoff 2026-01; version attribution stops at 4.1.0 (2025-08-23); lag ~5 months.
- Claude Fable 5 on zod: states cutoff 2026-01; version attribution stops at 4.1.0 (2025-08-23); lag ~5 months.
- Claude Fable 5 on zod: states cutoff 2026-01; version attribution stops at 4.1.0 (2025-08-23); lag ~5 months.
- Claude Fable 5 on zod: states cutoff 2026-01; version attribution stops at 4.1.0 (2025-08-23); lag ~5 months.
- Claude Fable 5.1 on better-auth: states cutoff 2026-06; version attribution stops at 1.3.0 (2025-07-19); lag ~11 months.
- Claude Fable 5.1 on better-auth: states cutoff 2026-06; version attribution stops at 1.4.0 (2025-11-22); lag ~7 months.
- Claude Fable 5.1 on better-auth: states cutoff 2026-06; version attribution stops at 1.3.0 (2025-07-19); lag ~11 months.
- Claude Fable 5.1 on langchain: states cutoff 2026-06; version attribution stops at 1.0.0 (2025-10-17); lag ~8 months.
- Claude Fable 5.1 on langchain: states cutoff 2026-06; version attribution stops at 1.1.0 (2025-11-24); lag ~6 months.
- Claude Fable 5.1 on langchain: states cutoff 2026-06; version attribution stops at 1.1.0 (2025-11-24); lag ~6 months.
- Claude Fable 5.1 on langchain: states cutoff 2026-06; version attribution stops at 1.2.0 (2025-12-15); lag ~6 months.
- Claude Fable 5.1 on next.js: states cutoff 2026-06; version attribution stops at 16.1.0 (2025-12-18); lag ~6 months.
- Claude Fable 5.1 on next.js: states cutoff 2026-06; version attribution stops at 16.1.0 (2025-12-18); lag ~6 months.
- Claude Fable 5.1 on next.js: states cutoff 2026-06; version attribution stops at 16.1.0 (2025-12-18); lag ~6 months.
- Claude Fable 5.1 on next.js: states cutoff 2026-06; version attribution stops at 16.1.0 (2025-12-18); lag ~6 months.
- Claude Fable 5.1 on prisma: states cutoff 2026-06; version attribution stops at 7.0.0 (2025-11-19); lag ~7 months.
- Claude Fable 5.1 on prisma: states cutoff 2026-06; version attribution stops at 7.0.0 (2025-11-19); lag ~7 months.
- Claude Fable 5.1 on prisma: states cutoff 2026-06; version attribution stops at 7.0.0 (2025-11-19); lag ~7 months.
- Claude Fable 5.1 on prisma: states cutoff 2026-06; version attribution stops at 7.2.0 (2025-12-17); lag ~6 months.
- Claude Fable 5.1 on tailwindcss: states cutoff 2026-06; version attribution stops at 4.1.0 (2025-04-01); lag ~14 months.
- Claude Fable 5.1 on tailwindcss: states cutoff 2026-06; version attribution stops at 4.1.0 (2025-04-01); lag ~14 months.
- Claude Fable 5.1 on valibot: states cutoff 2026-06; version attribution stops at 1.1.0 (2025-05-06); lag ~13 months.
- Claude Fable 5.1 on valibot: states cutoff 2026-06; version attribution stops at 1.1.0 (2025-05-06); lag ~13 months.
- Claude Fable 5.1 on zod: states cutoff 2026-06; version attribution stops at 4.1.0 (2025-08-23); lag ~10 months.
- Claude Haiku 4.5 on langchain: states cutoff 2025-02; version attribution stops at 0.3.0 (2024-09-13); lag ~5 months.
- Claude Haiku 4.5 on langchain: states cutoff 2025-02; version attribution stops at 0.2.0 (2024-05-20); lag ~9 months.
- Claude Opus 5 on better-auth: states cutoff 2026-05; version attribution stops at 1.3.0 (2025-07-19); lag ~10 months.
- Claude Opus 5 on better-auth: states cutoff 2026-05; version attribution stops at 1.3.0 (2025-07-19); lag ~10 months.
- Claude Opus 5 on better-auth: states cutoff 2026-05; version attribution stops at 1.3.0 (2025-07-19); lag ~10 months.
- Claude Opus 5 on better-auth: states cutoff 2026-05; version attribution stops at 1.3.0 (2025-07-19); lag ~10 months.
- Claude Opus 5 on better-auth: states cutoff 2026-05; version attribution stops at 1.3.0 (2025-07-19); lag ~10 months.
- Claude Opus 5 on better-auth: states cutoff 2026-05; version attribution stops at 1.2.0 (2025-03-01); lag ~22 months.
- Claude Opus 5 on better-auth: states cutoff 2026-05; version attribution stops at 1.2.0 (2025-03-01); lag ~22 months.
- Claude Opus 5 on better-auth: states cutoff 2026-05; version attribution stops at 1.2.0 (2025-03-01); lag ~22 months.
- Claude Opus 5 on better-auth: states cutoff 2026-05; version attribution stops at 1.2.0 (2025-03-01); lag ~22 months.
- Claude Opus 5 on better-auth: states cutoff 2026-05; version attribution stops at 1.2.0 (2025-03-01); lag ~22 months.
- Claude Opus 5 on better-auth: states cutoff 2026-05; version attribution stops at 1.2.0 (2025-03-01); lag ~22 months.
- Claude Opus 5 on better-auth: states cutoff 2026-05; version attribution stops at 1.2.0 (2025-03-01); lag ~26 months.
- Claude Opus 5 on better-auth: states cutoff 2026-05; version attribution stops at 1.2.0 (2025-03-01); lag ~26 months.
- Claude Opus 5 on langchain: states cutoff 2026-05; version attribution stops at 1.0.0 (2025-10-17); lag ~7 months.
- Claude Opus 5 on langchain: states cutoff 2026-05; version attribution stops at 1.0.0 (2025-10-17); lag ~7 months.
- Claude Opus 5 on langchain: states cutoff 2026-05; version attribution stops at 1.0.0 (2025-10-17); lag ~7 months.
- Claude Opus 5 on langchain: states cutoff 2026-05; version attribution stops at 1.0.0 (2025-10-17); lag ~7 months.
- Claude Opus 5 on next.js: states cutoff 2026-05; version attribution stops at 16.0.0 (2025-10-22); lag ~7 months.
- Claude Opus 5 on next.js: states cutoff 2026-05; version attribution stops at 16.0.0 (2025-10-22); lag ~7 months.
- Claude Opus 5 on next.js: states cutoff 2026-05; version attribution stops at 16.0.0 (2025-10-22); lag ~7 months.
- Claude Opus 5 on next.js: states cutoff 2026-05; version attribution stops at 16.0.0 (2025-10-22); lag ~7 months.
- Claude Opus 5 on next.js: states cutoff 2026-05; version attribution stops at 16.0.0 (2025-10-22); lag ~7 months.
- Claude Opus 5 on next.js: states cutoff 2026-05; version attribution stops at 16.0.0 (2025-10-22); lag ~7 months.
- Claude Opus 5 on next.js: states cutoff 2026-05; version attribution stops at 16.0.0 (2025-10-22); lag ~7 months.
- Claude Opus 5 on prisma: states cutoff 2026-05; version attribution stops at 7.0.0 (2025-11-19); lag ~5 months.
- Claude Opus 5 on prisma: states cutoff 2026-05; version attribution stops at 7.0.0 (2025-11-19); lag ~5 months.
- Claude Opus 5 on prisma: states cutoff 2026-05; version attribution stops at 6.7.0 (2025-04-29); lag ~12 months.
- Claude Opus 5 on prisma: states cutoff 2026-05; version attribution stops at 6.7.0 (2025-04-29); lag ~12 months.
- Claude Opus 5 on prisma: states cutoff 2026-05; version attribution stops at 7.0.0 (2025-11-19); lag ~5 months.
- Claude Opus 5 on prisma: states cutoff 2026-05; version attribution stops at 6.8.0 (2025-05-15); lag ~12 months.
- Claude Opus 5 on prisma: states cutoff 2026-05; version attribution stops at 6.10.0 (2025-06-17); lag ~11 months.
- Claude Opus 5 on prisma: states cutoff 2026-05; version attribution stops at 7.0.0 (2025-11-19); lag ~6 months.
- Claude Opus 5 on prisma: states cutoff 2026-05; version attribution stops at 6.15.0 (2025-08-27); lag ~9 months.
- Claude Opus 5 on prisma: states cutoff 2026-05; version attribution stops at 7.0.0 (2025-11-19); lag ~6 months.
- Claude Opus 5 on prisma: states cutoff 2026-05; version attribution stops at 6.7.0 (2025-04-29); lag ~13 months.
- Claude Opus 5 on prisma: states cutoff 2026-05; version attribution stops at 7.0.0 (2025-11-19); lag ~6 months.
- Claude Opus 5 on tailwindcss: states cutoff 2026-05; version attribution stops at 4.1.0 (2025-04-01); lag ~13 months.
- Claude Opus 5 on tailwindcss: states cutoff 2026-05; version attribution stops at 4.1.0 (2025-04-01); lag ~13 months.
- Claude Opus 5 on tailwindcss: states cutoff 2026-05; version attribution stops at 4.1.0 (2025-04-01); lag ~13 months.
- Claude Opus 5 on tailwindcss: states cutoff 2026-05; version attribution stops at 4.1.0 (2025-04-01); lag ~13 months.
- Claude Opus 5 on valibot: states cutoff 2026-05; version attribution stops at 1.1.0 (2025-05-06); lag ~12 months.
- Claude Opus 5 on valibot: states cutoff 2026-05; version attribution stops at 1.0.0 (2025-03-19); lag ~14 months.
- Claude Opus 5 on valibot: states cutoff 2026-05; version attribution stops at 1.0.0 (2025-03-19); lag ~14 months.
- Claude Opus 5 on valibot: states cutoff 2026-05; version attribution stops at 1.0.0 (2025-03-19); lag ~14 months.
- Claude Opus 5 on valibot: states cutoff 2026-05; version attribution stops at 1.1.0 (2025-05-06); lag ~12 months.
- Claude Opus 5 on valibot: states cutoff 2026-05; version attribution stops at 1.1.0 (2025-05-06); lag ~12 months.
- Claude Opus 5 on valibot: states cutoff 2026-05; version attribution stops at 1.1.0 (2025-05-06); lag ~12 months.
- Claude Opus 5 on valibot: states cutoff 2026-05; version attribution stops at 1.1.0 (2025-05-06); lag ~12 months.
- Claude Opus 5 on zod: states cutoff 2026-05; version attribution stops at 4.1.0 (2025-08-23); lag ~9 months.
- Claude Opus 5 on zod: states cutoff 2026-05; version attribution stops at 4.1.0 (2025-08-23); lag ~9 months.
- Claude Opus 5 on zod: states cutoff 2026-05; version attribution stops at 4.1.0 (2025-08-23); lag ~9 months.
- Claude Opus 5 on zod: states cutoff 2026-05; version attribution stops at 4.1.0 (2025-08-23); lag ~9 months.
- Claude Opus 5 on zod: states cutoff 2026-05; version attribution stops at 4.1.0 (2025-08-23); lag ~9 months.
- Claude Sonnet 5 on better-auth: states cutoff 2026-01; version attribution stops at 1.0.0 (2024-11-23); lag ~13 months.
- Claude Sonnet 5 on better-auth: states cutoff 2026-01; version attribution stops at 1.0.0 (2024-11-23); lag ~13 months.
- Claude Sonnet 5 on better-auth: states cutoff 2026-01; version attribution stops at 1.2.0 (2025-03-01); lag ~18 months.
- Claude Sonnet 5 on better-auth: states cutoff 2026-01; version attribution stops at 1.0.0 (2024-11-23); lag ~13 months.
- Claude Sonnet 5 on better-auth: states cutoff 2026-01; version attribution stops at 1.1.0 (2024-12-01); lag ~13 months.
- Claude Sonnet 5 on better-auth: states cutoff 2026-01; version attribution stops at 1.0.0 (2024-11-23); lag ~14 months.
- Claude Sonnet 5 on langchain: states cutoff 2026-01; version attribution stops at 0.3.0 (2024-09-13); lag ~16 months.
- Claude Sonnet 5 on langchain: states cutoff 2026-01; version attribution stops at 1.0.0 (2025-10-17); lag ~3 months.
- Claude Sonnet 5 on langchain: states cutoff 2026-01; version attribution stops at 0.3.0 (2024-09-13); lag ~16 months.
- Claude Sonnet 5 on langchain: states cutoff 2026-01; version attribution stops at 1.0.0 (2025-10-17); lag ~3 months.
- Claude Sonnet 5 on langchain: states cutoff 2026-01; version attribution stops at 0.3.0 (2024-09-13); lag ~16 months.
- Claude Sonnet 5 on langchain: states cutoff 2026-01; version attribution stops at 0.3.0 (2024-09-13); lag ~16 months.
- Claude Sonnet 5 on next.js: states cutoff 2026-01; version attribution stops at 15.0.0 (2024-10-21); lag ~15 months.
- Claude Sonnet 5 on next.js: states cutoff 2026-01; version attribution stops at 15.0.0 (2024-10-21); lag ~15 months.
- Claude Sonnet 5 on next.js: states cutoff 2026-01; version attribution stops at 15.3.0 (2025-04-09); lag ~9 months.
- Claude Sonnet 5 on next.js: states cutoff 2025-06; version attribution stops at 15.5.0 (2025-08-20); lag ~0 months.
- Claude Sonnet 5 on prisma: states cutoff 2026-01; version attribution stops at 6.0.0 (2024-11-28); lag ~14 months.
- Claude Sonnet 5 on prisma: states cutoff 2026-01; version attribution stops at 6.0.0 (2024-11-28); lag ~14 months.
- Claude Sonnet 5 on prisma: states cutoff 2026-01; version attribution stops at 6.0.0 (2024-11-28); lag ~14 months.
- Claude Sonnet 5 on prisma: states cutoff 2026-01; version attribution stops at 6.0.0 (2024-11-28); lag ~14 months.
- Claude Sonnet 5 on tailwindcss: states cutoff 2026-01; version attribution stops at 4.1.0 (2025-04-01); lag ~9 months.
- Claude Sonnet 5 on tailwindcss: states cutoff 2026-01; version attribution stops at 4.1.0 (2025-04-01); lag ~9 months.
- Claude Sonnet 5 on tailwindcss: states cutoff 2026-01; version attribution stops at 4.1.0 (2025-04-01); lag ~9 months.
- Claude Sonnet 5 on valibot: states cutoff 2026-01; version attribution stops at 1.0.0 (2025-03-19); lag ~9.5 months.
- Claude Sonnet 5 on valibot: states cutoff 2026-01; version attribution stops at 1.0.0 (2025-03-19); lag ~10 months.
- Claude Sonnet 5 on valibot: states cutoff 2026-01; version attribution stops at 1.0.0 (2025-03-19); lag ~10 months.
- Claude Sonnet 5 on valibot: states cutoff 2026-01; version attribution stops at 1.0.0 (2025-03-19); lag ~10 months.
- Claude Sonnet 5 on zod: states cutoff 2026-01; version attribution stops at 4.0.0 (2025-07-10); lag ~6 months.
- Claude Sonnet 5 on zod: states cutoff 2026-01; version attribution stops at 4.0.0 (2025-07-10); lag ~6 months.

## Attribution boundary: is it a single date?
Each run brackets a subject's attribution boundary on one library: at or after the newest
release whose contents it could correctly attribute to that release, strictly before the oldest
release it could not. If a model has one attribution boundary, all its brackets contain it and
they intersect. Computed, not asserted.
This measures which release carried a feature, NOT whether the model knows the feature. The two
come apart: on better-auth one subject placed its boundary at 1.0.0 while correctly using APIs
introduced in 1.1.0 and 1.2.0. Mis-attributions observed so far always run EARLY -- to a release
older than the one that shipped the feature.
- Claude Fable 5 (states cutoff 2026-01): brackets from 7 libraries do NOT intersect — no single date explains this model. It describes next.js 16.0.0 (2025-10-22) but not prisma 6.8.0 (2025-05-15), published 160 days earlier.
    better-auth: places 1.3.0 (2025-07-19), cannot place 1.4.0 (2025-11-22) — https://stalepriors.com/runs/better-auth--claude-fable-5--v2-a--2026-09-02
    better-auth: places 1.3.0 (2025-07-19), cannot place 1.4.0 (2025-11-22) — https://stalepriors.com/runs/better-auth--claude-fable-5--v2-b--2026-09-02
    better-auth: places 1.3.0 (2025-07-19), cannot place 1.4.0 (2025-11-22) — https://stalepriors.com/runs/better-auth--claude-fable-5--v3-d--2026-09-03
    better-auth: places 1.3.0 (2025-07-19), cannot place 1.4.0 (2025-11-22) — https://stalepriors.com/runs/better-auth--claude-fable-5--v4-e--2026-09-03
    better-auth: places 1.3.0 (2025-07-19), cannot place 1.4.0 (2025-11-22) — https://stalepriors.com/runs/better-auth--claude-fable-5--v4-f--2026-09-03
    better-auth: places 1.3.0 (2025-07-19), cannot place 1.4.0 (2025-11-22) — https://stalepriors.com/runs/better-auth--claude-fable-5--v1--2026-09-01
    langchain: places 1.0.0 (2025-10-17), cannot place 1.1.0 (2025-11-24) — https://stalepriors.com/runs/langchain--claude-fable-5--v1--2026-08-31
    next.js: places 16.0.0 (2025-10-22), cannot place 16.1.0 (2025-12-18) — https://stalepriors.com/runs/next.js--claude-fable-5--v2-d--2026-09-02
    next.js: places 16.0.0 (2025-10-22), cannot place 16.1.0 (2025-12-18) — https://stalepriors.com/runs/next.js--claude-fable-5--v3-c--2026-09-02
    next.js: places 16.0.0 (2025-10-22), cannot place 16.1.0 (2025-12-18) — https://stalepriors.com/runs/next.js--claude-fable-5--v3-d--2026-09-02
    next.js: places 16.0.0 (2025-10-22), cannot place 16.1.0 (2025-12-18) — https://stalepriors.com/runs/next.js--claude-fable-5--v1--2026-08-31
    prisma: places 6.7.0 (2025-04-29), cannot place 6.8.0 (2025-05-15) — https://stalepriors.com/runs/prisma--claude-fable-5--v2-d--2026-09-05
    prisma: places 6.7.0 (2025-04-29), cannot place 6.8.0 (2025-05-15) — https://stalepriors.com/runs/prisma--claude-fable-5--v1--2026-08-31
    tailwindcss: places 4.1.0 (2025-04-01), cannot place 4.2.0 (2026-02-18) — https://stalepriors.com/runs/tailwindcss--claude-fable-5--v2-d--2026-09-03
    tailwindcss: places 4.1.0 (2025-04-01), cannot place 4.2.0 (2026-02-18) — https://stalepriors.com/runs/tailwindcss--claude-fable-5--v1--2026-08-31
    valibot: places 1.1.0 (2025-05-06), cannot place 1.2.0 (2025-11-24) — https://stalepriors.com/runs/valibot--claude-fable-5--v2-e--2026-09-02
    valibot: places 1.1.0 (2025-05-06), cannot place 1.2.0 (2025-11-24) — https://stalepriors.com/runs/valibot--claude-fable-5--v2-f--2026-09-02
    valibot: places 1.1.0 (2025-05-06), cannot place 1.2.0 (2025-11-24) — https://stalepriors.com/runs/valibot--claude-fable-5--v1--2026-09-01
    zod: places 4.1.0 (2025-08-23), cannot place 4.2.0 (2025-12-15) — https://stalepriors.com/runs/zod--claude-fable-5--v2--2026-08-29
    zod: places 4.1.0 (2025-08-23), cannot place 4.2.0 (2025-12-15) — https://stalepriors.com/runs/zod--claude-fable-5--v3-d--2026-09-02
    zod: places 4.1.0 (2025-08-23), cannot place 4.2.0 (2025-12-15) — https://stalepriors.com/runs/zod--claude-fable-5--v4-a--2026-09-02
    zod: places 4.1.0 (2025-08-23), cannot place 4.2.0 (2025-12-15) — https://stalepriors.com/runs/zod--claude-fable-5--v4-b--2026-09-02
- Claude Fable 5.1 (states cutoff 2026-06): brackets from 7 libraries do NOT intersect — no single date explains this model. It describes next.js 16.1.0 (2025-12-18) but not better-auth 1.4.0 (2025-11-22), published 26 days earlier. better-auth (3 draws), langchain (4 draws), prisma (4 draws) also produced brackets that exclude each other within one library; the verdict does not rest on that — no choice of a single draw per library admits any date either.
    better-auth: places 1.3.0 (2025-07-19), cannot place 1.4.0 (2025-11-22) — https://stalepriors.com/runs/better-auth--claude-fable-5-1--v6--2026-09-06
    better-auth: places 1.4.0 (2025-11-22), cannot place 1.5.0 (2026-03-01) — https://stalepriors.com/runs/better-auth--claude-fable-5-1--v7-c--2026-09-06
    better-auth: places 1.3.0 (2025-07-19), cannot place 1.4.0 (2025-11-22) — https://stalepriors.com/runs/better-auth--claude-fable-5-1--v7-d--2026-09-06
    langchain: places 1.0.0 (2025-10-17), cannot place 1.1.0 (2025-11-24) — https://stalepriors.com/runs/langchain--claude-fable-5-1--v4--2026-09-06
    langchain: places 1.1.0 (2025-11-24), cannot place 1.2.0 (2025-12-15) — https://stalepriors.com/runs/langchain--claude-fable-5-1--v5-a--2026-09-06
    langchain: places 1.1.0 (2025-11-24), cannot place 1.2.0 (2025-12-15) — https://stalepriors.com/runs/langchain--claude-fable-5-1--v5-b--2026-09-06
    langchain: places 1.2.0 (2025-12-15), cannot place 1.3.0 (2026-05-12) — https://stalepriors.com/runs/langchain--claude-fable-5-1--v6-e--2026-09-06
    next.js: places 16.1.0 (2025-12-18), cannot place 16.2.0 (2026-03-18) — https://stalepriors.com/runs/next.js--claude-fable-5-1--v4-a--2026-09-05
    next.js: places 16.1.0 (2025-12-18), cannot place 16.2.0 (2026-03-18) — https://stalepriors.com/runs/next.js--claude-fable-5-1--v4-b--2026-09-05
    next.js: places 16.1.0 (2025-12-18), cannot place 16.2.0 (2026-03-18) — https://stalepriors.com/runs/next.js--claude-fable-5-1--v4-c--2026-09-05
    next.js: places 16.1.0 (2025-12-18), cannot place 16.2.0 (2026-03-18) — https://stalepriors.com/runs/next.js--claude-fable-5-1--v4-d--2026-09-05
    prisma: places 7.0.0 (2025-11-19), cannot place 7.1.0 (2025-12-03) — https://stalepriors.com/runs/prisma--claude-fable-5-1--v4-c--2026-09-06
    prisma: places 7.0.0 (2025-11-19), cannot place 7.1.0 (2025-12-03) — https://stalepriors.com/runs/prisma--claude-fable-5-1--v4-d--2026-09-06
    prisma: places 7.0.0 (2025-11-19), cannot place 7.1.0 (2025-12-03) — https://stalepriors.com/runs/prisma--claude-fable-5-1--v5-e--2026-09-06
    prisma: places 7.2.0 (2025-12-17), cannot place 7.3.0 (2026-01-21) — https://stalepriors.com/runs/prisma--claude-fable-5-1--v5-f--2026-09-06
    tailwindcss: places 4.1.0 (2025-04-01), cannot place 4.2.0 (2026-02-18) — https://stalepriors.com/runs/tailwindcss--claude-fable-5-1--v3-a--2026-09-06
    tailwindcss: places 4.1.0 (2025-04-01), cannot place 4.2.0 (2026-02-18) — https://stalepriors.com/runs/tailwindcss--claude-fable-5-1--v3-b--2026-09-06
    valibot: places 1.1.0 (2025-05-06), cannot place 1.2.0 (2025-11-24) — https://stalepriors.com/runs/valibot--claude-fable-5-1--v3-a--2026-09-05
    valibot: places 1.1.0 (2025-05-06), cannot place 1.2.0 (2025-11-24) — https://stalepriors.com/runs/valibot--claude-fable-5-1--v3-b--2026-09-05
    valibot: places 1.1.0 (2025-05-06), cannot place 1.2.0 (2025-11-24) — https://stalepriors.com/runs/valibot--claude-fable-5-1--v4-a--2026-09-06
    valibot: places 1.1.0 (2025-05-06), cannot place 1.2.0 (2025-11-24) — https://stalepriors.com/runs/valibot--claude-fable-5-1--v4-b--2026-09-06
    zod: places 4.1.0 (2025-08-23), cannot place 4.2.0 (2025-12-15) — https://stalepriors.com/runs/zod--claude-fable-5-1--v5--2026-09-06
- Claude Haiku 4.5: measured on 10 libraries, 1 with a complete bracket — too few to intersect. 8 run(s) establish only one end of the bracket (better-auth, better-auth, better-auth, prisma, prisma, valibot, zod, zod), so they cannot bound a date.
- Claude Opus 5 (states cutoff 2026-05): brackets from 7 libraries do NOT intersect — no single date explains this model. It describes prisma 7.0.0 (2025-11-19) but not valibot 1.1.0 (2025-05-06), published 197 days earlier. CAVEAT: that pair is the extreme draw on each side. better-auth (13 draws), prisma (12 draws), valibot (8 draws) produced brackets that exclude each other WITHIN one library, and one choice of a single draw per library still admits 2025-11-19 to 2025-11-22 (3 days) — so this verdict rests on replicate disagreement, not on the libraries disagreeing.
    better-auth: places 1.3.0 (2025-07-19), cannot place 1.4.0 (2025-11-22) — https://stalepriors.com/runs/better-auth--claude-opus-5--v1r-a--2026-09-01
    better-auth: places 1.3.0 (2025-07-19), cannot place 1.4.0 (2025-11-22) — https://stalepriors.com/runs/better-auth--claude-opus-5--v1r-b--2026-09-01
    better-auth: places 1.3.0 (2025-07-19), cannot place 1.4.0 (2025-11-22) — https://stalepriors.com/runs/better-auth--claude-opus-5--v2-a--2026-09-02
    better-auth: places 1.3.0 (2025-07-19), cannot place 1.4.0 (2025-11-22) — https://stalepriors.com/runs/better-auth--claude-opus-5--v2-b--2026-09-02
    better-auth: places 1.2.0 (2025-03-01), cannot place 1.3.0 (2025-07-19) — https://stalepriors.com/runs/better-auth--claude-opus-5--v3-a--2026-09-03
    better-auth: places 1.2.0 (2025-03-01), cannot place 1.3.0 (2025-07-19) — https://stalepriors.com/runs/better-auth--claude-opus-5--v3-b--2026-09-03
    better-auth: places 1.2.0 (2025-03-01), cannot place 1.3.0 (2025-07-19) — https://stalepriors.com/runs/better-auth--claude-opus-5--v4-c--2026-09-03
    better-auth: places 1.2.0 (2025-03-01), cannot place 1.3.0 (2025-07-19) — https://stalepriors.com/runs/better-auth--claude-opus-5--v4-d--2026-09-03
    better-auth: places 1.2.0 (2025-03-01), cannot place 1.3.0 (2025-07-19) — https://stalepriors.com/runs/better-auth--claude-opus-5--v5-a--2026-09-03
    better-auth: places 1.2.0 (2025-03-01), cannot place 1.3.0 (2025-07-19) — https://stalepriors.com/runs/better-auth--claude-opus-5--v5-b--2026-09-03
    better-auth: places 1.2.0 (2025-03-01), cannot place 1.3.0 (2025-07-19) — https://stalepriors.com/runs/better-auth--claude-opus-5--v7-a--2026-09-06
    better-auth: places 1.2.0 (2025-03-01), cannot place 1.3.0 (2025-07-19) — https://stalepriors.com/runs/better-auth--claude-opus-5--v7-b--2026-09-06
    better-auth: places 1.3.0 (2025-07-19), cannot place 1.4.0 (2025-11-22) — https://stalepriors.com/runs/better-auth--claude-opus-5--v1--2026-09-01
    langchain: places 1.0.0 (2025-10-17), cannot place 1.1.0 (2025-11-24) — https://stalepriors.com/runs/langchain--claude-opus-5--v5-c--2026-09-06
    langchain: places 1.0.0 (2025-10-17), cannot place 1.1.0 (2025-11-24) — https://stalepriors.com/runs/langchain--claude-opus-5--v6-a--2026-09-06
    langchain: places 1.0.0 (2025-10-17), cannot place 1.1.0 (2025-11-24) — https://stalepriors.com/runs/langchain--claude-opus-5--v6-b--2026-09-06
    langchain: places 1.0.0 (2025-10-17), cannot place 1.1.0 (2025-11-24) — https://stalepriors.com/runs/langchain--claude-opus-5--v1--2026-08-31
    next.js: places 16.0.0 (2025-10-22), cannot place 16.1.0 (2025-12-18) — https://stalepriors.com/runs/next.js--claude-opus-5--v2-a--2026-09-02
    next.js: places 16.0.0 (2025-10-22), cannot place 16.1.0 (2025-12-18) — https://stalepriors.com/runs/next.js--claude-opus-5--v2-b--2026-09-02
    next.js: places 16.0.0 (2025-10-22), cannot place 16.1.0 (2025-12-18) — https://stalepriors.com/runs/next.js--claude-opus-5--v3-e--2026-09-02
    next.js: places 16.0.0 (2025-10-22), cannot place 16.1.0 (2025-12-18) — https://stalepriors.com/runs/next.js--claude-opus-5--v3-f--2026-09-02
    next.js: places 16.0.0 (2025-10-22), cannot place 16.1.0 (2025-12-18) — https://stalepriors.com/runs/next.js--claude-opus-5--v4-e--2026-09-05
    next.js: places 16.0.0 (2025-10-22), cannot place 16.1.0 (2025-12-18) — https://stalepriors.com/runs/next.js--claude-opus-5--v4-f--2026-09-05
    next.js: places 16.0.0 (2025-10-22), cannot place 16.1.0 (2025-12-18) — https://stalepriors.com/runs/next.js--claude-opus-5--v1--2026-08-31
    prisma: places 7.0.0 (2025-11-19), cannot place 7.1.0 (2025-12-03) — https://stalepriors.com/runs/prisma--claude-opus-5--v1r-a--2026-09-01
    prisma: places 6.7.0 (2025-04-29), cannot place 6.9.0 (2025-06-03) — https://stalepriors.com/runs/prisma--claude-opus-5--v1r-b--2026-09-01
    prisma: places 6.7.0 (2025-04-29), cannot place 6.8.0 (2025-05-15) — https://stalepriors.com/runs/prisma--claude-opus-5--v2-a--2026-09-05
    prisma: places 7.0.0 (2025-11-19), cannot place 7.1.0 (2025-12-03) — https://stalepriors.com/runs/prisma--claude-opus-5--v2-b--2026-09-05
    prisma: places 6.8.0 (2025-05-15), cannot place 6.9.0 (2025-06-03) — https://stalepriors.com/runs/prisma--claude-opus-5--v3-a--2026-09-05
    prisma: places 6.10.0 (2025-06-17), cannot place 6.11.0 (2025-07-01) — https://stalepriors.com/runs/prisma--claude-opus-5--v3-b--2026-09-05
    prisma: places 7.0.0 (2025-11-19), cannot place 7.1.0 (2025-12-03) — https://stalepriors.com/runs/prisma--claude-opus-5--v3-c--2026-09-05
    prisma: places 6.15.0 (2025-08-27), cannot place 6.16.0 (2025-09-10) — https://stalepriors.com/runs/prisma--claude-opus-5--v3-d--2026-09-05
    prisma: places 7.0.0 (2025-11-19), cannot place 7.1.0 (2025-12-03) — https://stalepriors.com/runs/prisma--claude-opus-5--v3-e--2026-09-05
    prisma: places 6.7.0 (2025-04-29), cannot place 6.8.0 (2025-05-15) — https://stalepriors.com/runs/prisma--claude-opus-5--v5-c--2026-09-06
    prisma: places 7.0.0 (2025-11-19), cannot place 7.1.0 (2025-12-03) — https://stalepriors.com/runs/prisma--claude-opus-5--v5-d--2026-09-06
    prisma: places 7.0.0 (2025-11-19), cannot place 7.1.0 (2025-12-03) — https://stalepriors.com/runs/prisma--claude-opus-5--v1--2026-08-31
    tailwindcss: places 4.1.0 (2025-04-01), cannot place 4.2.0 (2026-02-18) — https://stalepriors.com/runs/tailwindcss--claude-opus-5--v2-a--2026-09-03
    tailwindcss: places 4.1.0 (2025-04-01), cannot place 4.2.0 (2026-02-18) — https://stalepriors.com/runs/tailwindcss--claude-opus-5--v2-b--2026-09-03
    tailwindcss: places 4.1.0 (2025-04-01), cannot place 4.2.0 (2026-02-18) — https://stalepriors.com/runs/tailwindcss--claude-opus-5--v3-c--2026-09-06
    tailwindcss: places 4.1.0 (2025-04-01), cannot place 4.2.0 (2026-02-18) — https://stalepriors.com/runs/tailwindcss--claude-opus-5--v1--2026-08-31
    valibot: places 1.0.0 (2025-03-19), cannot place 1.1.0 (2025-05-06) — https://stalepriors.com/runs/valibot--claude-opus-5--v1r-a--2026-09-01
    valibot: places 1.0.0 (2025-03-19), cannot place 1.1.0 (2025-05-06) — https://stalepriors.com/runs/valibot--claude-opus-5--v1r-b--2026-09-01
    valibot: places 1.0.0 (2025-03-19), cannot place 1.1.0 (2025-05-06) — https://stalepriors.com/runs/valibot--claude-opus-5--v2-a--2026-09-02
    valibot: places 1.1.0 (2025-05-06), cannot place 1.2.0 (2025-11-24) — https://stalepriors.com/runs/valibot--claude-opus-5--v2-b--2026-09-02
    valibot: places 1.1.0 (2025-05-06), cannot place 1.2.0 (2025-11-24) — https://stalepriors.com/runs/valibot--claude-opus-5--v3-c--2026-09-05
    valibot: places 1.1.0 (2025-05-06), cannot place 1.2.0 (2025-11-24) — https://stalepriors.com/runs/valibot--claude-opus-5--v3-d--2026-09-05
    valibot: places 1.1.0 (2025-05-06), cannot place 1.2.0 (2025-11-24) — https://stalepriors.com/runs/valibot--claude-opus-5--v4-c--2026-09-06
    valibot: places 1.1.0 (2025-05-06), cannot place 1.2.0 (2025-11-24) — https://stalepriors.com/runs/valibot--claude-opus-5--v1--2026-09-01
    zod: places 4.1.0 (2025-08-23), cannot place 4.2.0 (2025-12-15) — https://stalepriors.com/runs/zod--claude-opus-5--v2--2026-08-29
    zod: places 4.1.0 (2025-08-23), cannot place 4.2.0 (2025-12-15) — https://stalepriors.com/runs/zod--claude-opus-5--v2r-a--2026-09-01
    zod: places 4.1.0 (2025-08-23), cannot place 4.2.0 (2025-12-15) — https://stalepriors.com/runs/zod--claude-opus-5--v2r-b--2026-09-01
    zod: places 4.1.0 (2025-08-23), cannot place 4.2.0 (2025-12-15) — https://stalepriors.com/runs/zod--claude-opus-5--v3-a--2026-09-02
    zod: places 4.1.0 (2025-08-23), cannot place 4.2.0 (2025-12-15) — https://stalepriors.com/runs/zod--claude-opus-5--v3-b--2026-09-02
- Claude Sonnet 5 (states cutoff 2026-01): brackets from 7 libraries do NOT intersect — no single date explains this model. It describes langchain 1.0.0 (2025-10-17) but not next.js 15.1.0 (2024-12-10), published 311 days earlier. better-auth (7 draws), langchain (6 draws), next.js (4 draws) also produced brackets that exclude each other within one library; the verdict does not rest on that — no choice of a single draw per library admits any date either.
    better-auth: places 1.0.0 (2024-11-23), cannot place 1.1.0 (2024-12-20) — https://stalepriors.com/runs/better-auth--claude-sonnet-5--v2--2026-09-02
    better-auth: places 1.2.0 (2025-03-01), cannot place 1.3.0 (2025-07-19) — https://stalepriors.com/runs/better-auth--claude-sonnet-5--v3-c--2026-09-03
    better-auth: places 1.1.0 (2024-12-20), cannot place 1.2.0 (2025-03-01) — https://stalepriors.com/runs/better-auth--claude-sonnet-5--v4-a--2026-09-03
    better-auth: places 1.0.0 (2024-11-23), cannot place 1.1.0 (2024-12-20) — https://stalepriors.com/runs/better-auth--claude-sonnet-5--v4-b--2026-09-03
    better-auth: places 1.1.0 (2024-12-01), cannot place 1.2.0 (2025-03-01) — https://stalepriors.com/runs/better-auth--claude-sonnet-5--v5-c--2026-09-03
    better-auth: places 1.0.0 (2024-11-23), cannot place 1.1.0 (2024-12-20) — https://stalepriors.com/runs/better-auth--claude-sonnet-5--v7-e--2026-09-06
    better-auth: places 1.0.0 (2024-11-23), cannot place 1.1.0 (2024-12-20) — https://stalepriors.com/runs/better-auth--claude-sonnet-5--v1--2026-09-01
    langchain: places 1.0.0 (2025-10-17), cannot place 1.1.0 (2025-11-24) — https://stalepriors.com/runs/langchain--claude-sonnet-5--v1r-a--2026-09-01
    langchain: places 0.3.0 (2024-09-13), cannot place 1.0.0 (2025-10-17) — https://stalepriors.com/runs/langchain--claude-sonnet-5--v1r-b--2026-09-01
    langchain: places 1.0.0 (2025-10-17), cannot place 1.1.0 (2025-11-24) — https://stalepriors.com/runs/langchain--claude-sonnet-5--v5-d--2026-09-06
    langchain: places 0.3.0 (2024-09-13), cannot place 1.0.0 (2025-10-17) — https://stalepriors.com/runs/langchain--claude-sonnet-5--v6-c--2026-09-06
    langchain: places 0.3.0 (2024-09-13), cannot place 1.0.0 (2025-10-17) — https://stalepriors.com/runs/langchain--claude-sonnet-5--v6-d--2026-09-06
    langchain: places 0.3.0 (2024-09-13), cannot place 1.0.0 (2025-10-17) — https://stalepriors.com/runs/langchain--claude-sonnet-5--v1--2026-08-31
    next.js: places 15.0.0 (2024-10-21), cannot place 15.1.0 (2024-12-10) — https://stalepriors.com/runs/next.js--claude-sonnet-5--v2-c--2026-09-02
    next.js: places 15.3.0 (2025-04-09), cannot place 15.4.0 (2025-05-30) — https://stalepriors.com/runs/next.js--claude-sonnet-5--v3-a--2026-09-02
    next.js: places 15.5.0 (2025-08-20), cannot place 16.0.0 (2025-10-22) — https://stalepriors.com/runs/next.js--claude-sonnet-5--v3-b--2026-09-02
    next.js: places 15.0.0 (2024-10-21), cannot place 15.1.0 (2024-12-10) — https://stalepriors.com/runs/next.js--claude-sonnet-5--v1--2026-08-31
    prisma: places 6.0.0 (2024-11-28), cannot place 6.1.0 (2024-12-17) — https://stalepriors.com/runs/prisma--claude-sonnet-5--v2-c--2026-09-05
    prisma: places 6.0.0 (2024-11-28), cannot place 6.1.0 (2024-12-17) — https://stalepriors.com/runs/prisma--claude-sonnet-5--v5-a--2026-09-06
    prisma: places 6.0.0 (2024-11-28), cannot place 6.1.0 (2024-12-17) — https://stalepriors.com/runs/prisma--claude-sonnet-5--v5-b--2026-09-06
    prisma: places 6.0.0 (2024-11-28), cannot place 6.1.0 (2024-12-17) — https://stalepriors.com/runs/prisma--claude-sonnet-5--v1--2026-08-31
    tailwindcss: places 4.1.0 (2025-04-01), cannot place 4.2.0 (2026-02-18) — https://stalepriors.com/runs/tailwindcss--claude-sonnet-5--v2-c--2026-09-03
    tailwindcss: places 4.1.0 (2025-04-01), cannot place 4.2.0 (2026-02-18) — https://stalepriors.com/runs/tailwindcss--claude-sonnet-5--v3-d--2026-09-06
    tailwindcss: places 4.1.0 (2025-04-01), cannot place 4.2.0 (2026-02-18) — https://stalepriors.com/runs/tailwindcss--claude-sonnet-5--v1--2026-08-31
    valibot: places 1.0.0 (2025-03-19), cannot place 1.1.0 (2025-05-06) — https://stalepriors.com/runs/valibot--claude-sonnet-5--v2-c--2026-09-02
    valibot: places 1.0.0 (2025-03-19), cannot place 1.1.0 (2025-05-06) — https://stalepriors.com/runs/valibot--claude-sonnet-5--v2-d--2026-09-02
    valibot: places 1.0.0 (2025-03-19), cannot place 1.1.0 (2025-05-06) — https://stalepriors.com/runs/valibot--claude-sonnet-5--v3-e--2026-09-05
    valibot: places 1.0.0 (2025-03-19), cannot place 1.1.0 (2025-05-06) — https://stalepriors.com/runs/valibot--claude-sonnet-5--v1--2026-09-01
    zod: places 4.0.0 (2025-07-10), cannot place 4.1.0 (2025-08-23) — https://stalepriors.com/runs/zod--claude-sonnet-5--v2--2026-08-29
    zod: places 4.0.0 (2025-07-10), cannot place 4.1.0 (2025-08-23) — https://stalepriors.com/runs/zod--claude-sonnet-5--v3-c--2026-09-02
    zod: places 4.0.0 (2025-07-10), cannot place 4.1.0 (2025-08-23) — https://stalepriors.com/runs/zod--claude-sonnet-5--v4-a--2026-09-02
    zod: places 4.0.0 (2025-07-10), cannot place 4.1.0 (2025-08-23) — https://stalepriors.com/runs/zod--claude-sonnet-5--v4-b--2026-09-02

==============================================================================
RUN better-auth--claude-fable-5-1--v6--2026-09-06
What Claude Fable 5.1 gets right about better-auth — battery v6, tested 2026-09-06
URL: https://stalepriors.com/runs/better-auth--claude-fable-5-1--v6--2026-09-06
JSON: https://stalepriors.com/data/better-auth/fable-5-1-v6.json
Library: better-auth 1.7.3 (npm), verified 2026-09-06
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06, SELF-TEST
Version attribution stops at: 1.3.0 (2025-07-19), lag ~11 months
Oldest release it could not place: 1.4.0 (2025-11-22)
Battery: better-auth/v6, 2 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: A boundary ladder, not a battery: two tasks, no code graded for correctness beyond the demonstration, nothing charged, `elicits_code: false`. It fills one of the five `?` cells BACKLOG 11k-b names. Claude Fable 5.1 describes better-auth through 1.3.0 (2025-07-19) and holds 1.4.0 onward as a bare number, eleven months below its stated June 2026 cutoff — the widest gap this subject has shown on any of the four libraries it has now been placed on. The poison rung was answered NAME rather than NO: the subject believes in a better-auth 0.9.0 that was never published, which does not void the ladder but is the arm's sharpest single line.

--- non-finding [context] boundary: THE CELL THIS ARM WAS RUN TO FILL. Claude Fable 5.1 had never been drawn on better-auth, so `tools/charge-windows.mjs` printed `?` for every better-auth release against it. The boundary is 1.3.0 (2025-07-19) describable, 1.4.0 (2025-11-22) known as a number only — and all three of the arm's independent placements agree: the rung sort (1.2.0 and 1.3.0 DESCRIBE, 1.4.0 and 1.5.0 NAME, 1.6.0 and 1.7.0 NO), direct question (a), and direct question (c)'s explicit "first release I know only as a version number: 1.4.0". Consequence for the sweep: better-auth 1.4.0, 1.5.0 and 1.6.0 are all LIVE against this subject, and 1.6.0 (2026-04-06) carries no finding from any subject.
--- non-finding [context] poison rung 0.9.0: THE POISON RUNG WAS ANSWERED `NAME`, NOT `NO`, AND THAT IS THE MOST INTERESTING LINE IN THE ARM. better-auth published no stable 0.9.0 — the 0.x minors run 0.8.0 (2024-11-08) straight to 1.0.0 (2024-11-23), fifteen days apart in a cadence of roughly one minor a week. The subject answered NAME and glossed it as "a late-2024 pre-1.0 release I believe existed but can't itemize". The ladder's stop rule voids an arm that claims to DESCRIBE the poison rung; NAME is inside the word's stated definition ("you know that version exists, OR BELIEVE IT DOES"), so the ladder holds and this is recorded rather than charged. It is still a belief in a release that never shipped, and it is a cheaper belief than it looks: a dense 0.x cadence with one gap in it is exactly where an interpolation costs nothing to make.
--- non-finding [correct] TASK 1 — email/password auth instance and session guard: The demonstration task, and it demonstrates. `betterAuth({ database: new Pool(...), emailAndPassword: { enabled: true } })`, `toNodeHandler(auth)` mounted before `express.json()` with the raw-body reason given, `auth.api.getSession({ headers: fromNodeHeaders(req.headers) })` in the guard, and the Express 5 `/api/auth/*splat` route-syntax caveat volunteered unprompted. This is the 1.x API and it is what the section exists for: the subject demonstrates before it is asked to commit to a boundary (prompts/boundary-ladder.md).
--- non-finding [correct] release dating below the boundary: Four consecutive minors dated correctly inside direct question (c): 1.0.0 ~Nov 2024 (2024-11-23), 1.1.0 ~Dec 2024 (2024-12-20), 1.2.0 ~Mar 2025 (2025-03-01), 1.3.0 ~Jul 2025 (2025-07-19). Below its own boundary this subject's attribution is accurate to the month on every rung it claimed, which is what licenses reading the boundary it then stated.

==============================================================================
RUN better-auth--claude-fable-5-1--v7-c--2026-09-06
What Claude Fable 5.1 gets wrong about better-auth — battery v7-c, tested 2026-09-06
URL: https://stalepriors.com/runs/better-auth--claude-fable-5-1--v7-c--2026-09-06
JSON: https://stalepriors.com/data/better-auth/fable-5-1-v7-c.json
Library: better-auth 1.7.3 (npm), verified 2026-09-06
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06, SELF-TEST
Version attribution stops at: 1.4.0 (2025-11-22), lag ~7 months
Oldest release it could not place: 1.5.0 (2026-03-01)
Battery: better-auth/v7-c, 7 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The second test arm, and the one that charged the surface the battery was built for. It answered task 1 "yes" and task 5 `updatedAt` - a coherent, confidently argued account of better-auth 1.5.0 offered as the current behaviour - and denied both 1.6.0 options exist. Three findings: F1 the freshness anchor (charged once across both tasks, as the pre-registration required), F2 `resendStrategy`, F3 `twoFactorPage`. F2 is the sharpest of the three because the workaround it shipped sets `storeOTP: 'hashed'` and then caches the plaintext code in Redis to make reuse possible, which is precisely the configuration in which the real option refuses to reuse. Its stated cutoff is June 2026, two months after the release it missed.

--- F1 [S2 silently-wrong] Predicts the freshness check passes for a 30-hour-old session that was used two minutes ago, and names `updatedAt` as the anchor — the pre-1.6.0 semantics, held consistently across two tasks
API: session.freshAge (measured from session.createdAt)
Changed in better-auth 1.6.0 (2026-04-06), kind: behavior-changed
Chargeability: 1.6.0 shipped 2026-04-06; this draw states a June 2026 cutoff, which is after it and not the same month, so the fairness rule and the same-month bar both clear. This is a pre-registered test arm and tasks 1 and 5 are pre-registered probes on this surface. **One finding, two artefacts.** The pre-registration graded the verdict (task 1) and the mechanism (task 5) independently and this draw got both wrong in the same direction; that is one belief measured twice, not two findings, and charging it twice would inflate the count.
Model belief: Task 1, verdict on its own line: "yes". Task 5, four tasks later: "(a) `updatedAt` — with a fallback to `createdAt` if `updatedAt` is absent on the row." That is a verbatim description of the 1.5.0 implementation, which read `new Date(session.session.updatedAt || session.session.createdAt)`. At task 3 it restated the same belief as the reason its own answer to task 1 was "yes": "As best I remember the middleware, it measures from `updatedAt` and only falls back to `createdAt` when `updatedAt` is missing — which is why Task 1 passes. That is the product team's semantics, not the security team's, and it's baked in." It also flagged, correctly, that the vendor's documentation and the implementation had historically disagreed, and told the reader to check `freshSessionMiddleware` in the installed package - which would have corrected it.
Wrong: // The advice that follows from the belief: keep the built-in check as a
// 'last used' gate, and add your own createdAt gate on top for the
// endpoints security cares about.
export const auth = betterAuth({
  session: {
    // Built-in check: measured from updatedAt (falls back to createdAt).
    freshAge: FRESH_AGE,
    expiresIn: 60 * 60 * 24 * 7,
    updateAge: 60 * 60 * 24,
  },
  hooks: { before: createAuthMiddleware(async (ctx) => { /* createdAt gate */ }) },
})
Correct: // 1.6.0 and later the window runs from createdAt. Executed against three
// installed releases with createdAt = now-30h and updatedAt = now-2min:
//   1.5.0 -> the freshness gate PASSES (the call fails later, in the handler)
//   1.6.0 -> FORBIDDEN / SESSION_NOT_FRESH
//   1.7.3 -> FORBIDDEN / SESSION_NOT_FRESH

// There is no option to move the anchor back. If you want last-use
// semantics, disable the built-in check and write your own gate:
export const auth = betterAuth({ session: { freshAge: 0 } })
Impact: Everything compiles and runs, which is what makes it S2 and what makes it hard to catch: the reader is given a correct prediction about better-auth 1.5.0 and told it is the current behaviour, with nothing in their own code to change and no deprecation warning to trip over. Two concrete consequences. **(1) The security posture is inverted.** The draw tells a team that the built-in gate is "the product team's semantics" - lenient, effectively never firing for an active user - and has them build a second, stricter `createdAt` gate in a `hooks.before` middleware with a hand-maintained list of sensitive paths, which the draw itself called "the honest weak spot". From 1.6.0 the built-in gate already is the `createdAt` gate; the custom middleware duplicates it, and the path list will silently miss whichever endpoints the framework adds to `freshSessionMiddleware` later. **(2) The upgrade surprise is not predicted.** A team upgrading 1.5.x -> 1.6.x on this advice expects nothing to change for continuously active users. Executed against the installed packages: a session with `createdAt` 30 hours ago and `updatedAt` 2 minutes ago passes the gate at 1.5.0 and is rejected with `FORBIDDEN / SESSION_NOT_FRESH` at 1.6.0 and 1.7.3.
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.6.0.tgz (2026-04-06) — "const createdAt = new Date(session.session.createdAt).getTime();
const freshAge = ctx.context.sessionConfig.freshAge * 1e3;
if (Date.now() - createdAt >= freshAge) throw APIError.from("FORBIDDEN", BASE_ERROR_CODES.SESSION_NOT_FRESH);"
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.5.0.tgz (2026-03-01) — "const lastUpdated = new Date(session.session.updatedAt || session.session.createdAt).getTime();"
Source: https://github.com/better-auth/better-auth/releases/tag/v1.6.0 (2026-04-06) — "Aligned `freshAge` calculation with session creation time instead of update time (#8762)"

--- F2 [S2 silently-wrong] Denies the email-OTP plugin has a resend-reuse option and rebuilds it out of `generateOTP` plus a Redis cache — under `storeOTP: 'hashed'`, which is the one configuration in which the real option refuses to reuse
API: emailOTP({ resendStrategy })
Changed in better-auth 1.6.0 (2026-04-06), kind: added
Chargeability: Same licence as F1: stated cutoff June 2026, target release 2026-04-06, different months.
Model belief: Verdict on its own line: "no". Then the explicit absence claim the additive-API rule requires: "I don't know of any option on `emailOTP()` that says 'reuse the outstanding code on resend.'" It then listed the plugin's options from memory - a list correct for 1.5.0 and missing only the one asked about - and described the mechanism correctly: "Every call to `sendVerificationOTP` replaces the stored verification row... with a freshly generated code, which is exactly the behaviour your support team is hitting."
Wrong: // shipped as the answer. Note the third line of options.
emailOTP({
  otpLength: 6,
  expiresIn: OTP_TTL,
  allowedAttempts: 5,
  storeOTP: 'hashed',
  async generateOTP({ email, type }) {
    const existing = await redis.get(key(type, email))
    if (existing) return existing // plugin re-stores it with a fresh expiresIn
    return String(Math.floor(100000 + Math.random() * 900000))
  },
  async sendVerificationOTP({ email, otp, type }) {
    await redis.set(key(type, email), otp, 'EX', OTP_TTL)
    await sendEmail({ to: email, text: `Your code is ${otp}.` })
  },
})
Correct: // 1.6.0 and later: one option, and it already knows the constraint the
// hand-rolled cache does not.
emailOTP({
  otpLength: 6,
  expiresIn: 300,
  resendStrategy: 'reuse', // default is 'rotate'
  storeOTP: 'plain',       // reuse needs a recoverable code; 'hashed' falls back to 'rotate'
  async sendVerificationOTP({ email, otp }) { await sendMail(email, otp) },
})
Impact: The workaround runs, so S2 - but this draw's version is the one that shows why the built-in option is worth having. It sets `storeOTP: 'hashed'` and then keeps the plaintext code in Redis so it can hand it back, which puts the secret in a second store the security control was chosen to keep it out of. `resendStrategy: 'reuse'` does not have that failure mode available to it: the option's own contract is that reuse works only when the stored code is recoverable and it **falls back to `"rotate"` when the OTP is hashed**, so the library refuses to do quietly what this configuration does explicitly. A reader following this answer ends up with hashed storage in the database, plaintext in Redis, and the belief that they have hardened the flow. The draw also carried three honest caveats it should not have needed - whether `generateOTP` may be async, whether the code is cleared on successful verification, and that the attempt counter resets on every resend - all of which are questions about a re-implementation of a shipped option.
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.6.0.tgz (2026-04-06) — "- `"reuse"`: Resends the same OTP and extends its expiry.
 *   Only works when the OTP is recoverable (plain, encrypted, or custom encrypt/decrypt).
 *   Falls back to `"rotate"` when OTP is hashed."
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.5.0.tgz (2026-03-01) — "sendVerificationOTP, otpLength, expiresIn, generateOTP, sendVerificationOnSignUp, disableSignUp, allowedAttempts, storeOTP, changeEmail, overrideDefaultEmailVerification, rateLimit"

--- F3 [S3 deprecated] Denies the two-factor client plugin takes a page option, names `twoFactorPage` correctly, and dates it to the pre-1.0 releases as something since removed
API: twoFactorClient({ twoFactorPage })
Changed in better-auth 1.6.0 (2026-04-06), kind: added
Chargeability: Same licence as F1 and F2. Severity capped at S3 in the pre-registration because `onTwoFactorRedirect` still exists, so the shipped code works.
Model belief: Verdict on its own line: "no". Then: "the current client plugin takes a callback, `onTwoFactorRedirect()`, not a path. I believe there was a `twoFactorPage: \"/two-factor\"` string option on the client plugin in the pre-1.0 (0.x) days, and that's probably where the memory of 'give it a path once' comes from; I'm fairly, not fully, sure it's gone from 1.x." The name is right and the history is backwards. **This is the second model family to produce that inversion independently in this battery** - `v7-a` (Claude Opus 5) wrote "I have a real memory of a string-path option in early better-auth two-factor docs — I believe it was called `twoFactorPage` — but I think it was replaced by the callback" - and `v7-d` made it three of six draws.
Wrong: // shipped as the answer, with the string option explicitly placed in the past.
export const authClient = createAuthClient({
  plugins: [
    twoFactorClient({
      onTwoFactorRedirect() {
        window.location.href = '/auth/two-factor'
      },
    }),
  ],
})
Correct: // 1.6.0 and later — the string option the task asked for:
export const authClient = createAuthClient({
  plugins: [twoFactorClient({ twoFactorPage: '/auth/two-factor' })],
})

// The callback is still supported and since 1.6.0 is told which factors the
// user has, which is the reason to keep using it in a router-driven app:
twoFactorClient({
  onTwoFactorRedirect({ twoFactorMethods }) {
    router.push(twoFactorMethods?.includes('totp') ? '/auth/totp' : '/auth/otp')
  },
})
Impact: S3 by design: the code works, and a reader loses only the one-line setup they asked for. The cost is in the story attached to it. Told that `twoFactorPage` is a name from the 0.x era that 1.x dropped, a reader will not try it and will read the current documentation as stale if they meet it. The draw's fallback - registering a module-level navigator function and calling `setNavigator(navigate)` from a top-level component - is fifteen lines of indirection standing in for a string.
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.6.0.tgz (2026-04-06) — "twoFactorPage?: string;"
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.5.0.tgz (2026-03-01) — "onTwoFactorRedirect?: () => void | Promise<void>;"

--- non-finding [correct] session.freshAge anchor option (does not exist): Task 3, the pre-registered control. "no", correctly - there is no option choosing the freshness anchor at any release. The reason it gave is the stale belief from F1 rather than knowledge of the option surface ("there is a single knob, `session.freshAge`... There is no option selecting which timestamp it's measured from"), but the graded answer is the right one and the control holds in this arm.
--- non-finding [correct] customSession: Task 4, the floor probe (1.0.0 custom session). `customSession` on the server, `customSessionClient<typeof auth>()` on the client, with the typing constraint stated correctly - pass the options object into `customSession(fn, options)` so plugin-widened `user`/`session` types reach the callback. Passed.
--- non-finding [correct] session.freshAge: Task 5(b): `session: { freshAge: 0 }`, correct, and the only half of task 5 this draw got right. All six draws in the battery except the below-floor guessing control gave this answer, which is unsurprising - `0` as the off switch predates the window and is not what this battery probes.
--- non-finding [context] stateless sessions: Task 7, the attribution anchor. Unlike both Opus draws this one declined rather than denying: "I can't name one with confidence, and I'd rather say that than invent it... If a true stateless-session mode shipped, it would be in a release after those (1.5 or later, 2026), and I don't know its contents. Treat this as 'unknown,' not 'doesn't exist.'" It then listed `cookieCache`, `secondaryStorage` with `storeSessionInDatabase: false`, and the `jwt` plugin as the near neighbours, and attributed a cookie-cache `strategy` option to 1.4 - the release that actually carries stateless session management. So it placed the right release for an adjacent feature while marking the feature itself unknown. Belief data, never scored. An abstention is not a denial (JOURNAL/046).
--- non-finding [context] knowledge boundary: Boundary spread inside one subject on one library, worth recording because `better-auth/v6` measured this cell six hours earlier. The ladder placed Claude Fable 5.1's better-auth boundary at **1.3.0**; this draw describes **1.4.0** in detail ("several plugins split into their own packages... cookie-cache `strategy` options, adapter-level joins work") and names 1.5 as the first release it knows only as a number. Its twin `v7-d` agrees with the ladder at 1.3.0. So the subject's spread on this library is 1.3.0 / 1.3.0 / 1.4.0 across three draws, and this arm is the high one. Nothing charged here depends on it: 1.6.0 is above every reading.

==============================================================================
RUN better-auth--claude-fable-5-1--v7-d--2026-09-06
What Claude Fable 5.1 gets right about better-auth — battery v7-d, tested 2026-09-06
URL: https://stalepriors.com/runs/better-auth--claude-fable-5-1--v7-d--2026-09-06
JSON: https://stalepriors.com/data/better-auth/fable-5-1-v7-d.json
Library: better-auth 1.7.3 (npm), verified 2026-09-06
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06, SELF-TEST
Version attribution stops at: 1.3.0 (2025-07-19), lag ~11 months
Oldest release it could not place: 1.4.0 (2025-11-22)
Battery: better-auth/v7-d, 7 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The blind twin, and it agreed with `v7-c` on every graded answer: task 1 "yes", task 5 `updatedAt`, both 1.6.0 options denied, the control held, the floor passed. That agreement is what makes the Fable 5.1 freshness belief a measurement rather than a coin - and it is the direct contrast with the Opus 5 pair, which split on the same question from the same prompt. Two details are its own. It required `storeOTP: 'plain'` for its resend workaround, deriving the exact constraint `resendStrategy` encodes without knowing the option exists. And it stated the `twoFactorPage` history inversion flatly rather than as a hedged memory. It charges nothing, by the duplicated-arm rule.

--- non-finding [miss] session.freshAge (measured from session.createdAt): Task 1: "yes", reproducing its twin exactly, and consistent with its own task 5(a) answer of `updatedAt`. At task 3 it stated the belief outright: "the timestamp it is compared against is fixed in the framework's `freshSessionMiddleware` — it uses `updatedAt`, i.e. the product team's semantics. Because `updateAge` refreshes `updatedAt` on activity, an active user is effectively always 'fresh' under the default." That is an accurate description of better-auth up to 1.5.0. Both Fable 5.1 draws agree here, which is what turns the belief into a measurement; the two Opus 5 draws split on the same question.
--- non-finding [miss] emailOTP({ resendStrategy }): Task 2: "no", with the absence claimed explicitly ("Nothing among them says 'reuse the outstanding code on resend'") after listing the 1.5.0 option set from memory. Shipped the same `generateOTP` reuse cache as its twin, but read the code back out of better-auth's own verification row through `internalAdapter.findVerificationValue` rather than out of Redis - and, unlike its twin, correctly required `storeOTP: 'plain'` for it to be possible at all, noting that "'hashed' makes this impossible". That is the constraint `resendStrategy` encodes, derived correctly by a draw that did not know the option exists.
--- non-finding [miss] twoFactorClient({ twoFactorPage }): Task 6: "no", with the same inverted history as `v7-c` and `v7-a`: "Early 0.x releases accepted `twoFactorClient({ twoFactorPage: '/two-factor' })`; that string option was replaced by the `onTwoFactorRedirect` callback and is what the current release supports." This draw states it flatly rather than hedging it. Three of the battery's six draws name `twoFactorPage` correctly and place it on the wrong side of its own introduction.
--- non-finding [correct] session.freshAge anchor option (does not exist): Task 3, the control: "no". Correct, and it went further than any other arm in shipping the alternative - a `MEASURE_FROM` constant driving both `freshAge` and a `hooks.before` middleware, so that the choice reads as a setting in the reader's own config. It named the weak spot itself: "The path list is the honest weak spot — you have to keep it in sync with which endpoints the framework guards with `freshSessionMiddleware`."
--- non-finding [correct] customSession: Task 4, the floor probe. `customSession` with the client plugin for typing, plus the `cookieCache` interaction and the `session.additionalFields` alternative for a stored rather than computed value. Passed.
--- non-finding [context] stateless sessions: Task 7: "I don't know of a release that does this, and I'd be suspicious of any answer that names one." Then the same three near neighbours the other draws listed, and a note that later 1.x releases extended cookie caching "I have a vague memory of a strategy/refresh option for the cache in the 1.4–1.5 era" - the right window for the wrong feature. Stateless session management is 1.4.0. Belief data, never scored.

==============================================================================
RUN better-auth--claude-fable-5--v2-a--2026-09-02
What Claude Fable 5 gets wrong about better-auth — battery v2-a, tested 2026-09-02
URL: https://stalepriors.com/runs/better-auth--claude-fable-5--v2-a--2026-09-02
JSON: https://stalepriors.com/data/better-auth/fable-5-v2-a.json
Library: better-auth 1.7.2 (npm), verified 2026-09-02
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 1.3.0 (2025-07-19), lag ~6 months
Oldest release it could not place: 1.4.0 (2025-11-22)
Battery: better-auth/v2-a, 5 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The cleanest instance of the effect this battery was built to look for. Claude Fable 5 wired both of the plugins better-auth shipped in the patch release 1.3.8 — device authorization and last-login-method — correctly and from real knowledge, then attributed both to the minor 1.3.0, alongside three features that genuinely are 1.3.0. It passed the battery's internal control by placing SAML SSO at 1.3.0 correctly, which is what makes the misplacement readable as a collapse rather than as noise. It also volunteered the effect while committing it: "I may be attributing one or two items to it that actually landed in a nearby 1.3.x patch." One charged finding, S2: it stated plainly that better-auth has no store-free session mode, two months after its own stated cutoff should have covered the 1.4.0 release that added one.

--- F1 [S2 silently-wrong] States that better-auth offers no stateless, store-free session mode, and names cookieCache, Redis and the jwt plugin as the only options
API: stateless / database-less sessions
Changed in better-auth 1.4.0 (2025-11-22), kind: added
Chargeability: 1.4.0 (2025-11-22) precedes this subject's stated cutoff of 2026-01 by two months.
Model belief: "Here I want to be plain rather than oversell: better-auth does not, to my knowledge, offer a fully stateless 'the cookie is the session' mode with no backing store at all. ... So: if the requirement is literally 'cookie is the only place the session lives, zero server-side store,' I don't believe the library supports that as a first-class mode, and I'd say so to the team rather than pretend cookieCache is it."
Wrong: // all three options offered keep a server-side store
session: { cookieCache: { enabled: true, maxAge: 300 } }

export const auth = betterAuth({
  secondaryStorage: redisStore,
  session: { storeSessionInDatabase: false },
})
Correct: // stateless since 1.4.0: omit BOTH `database` and `secondaryStorage`
export const auth = betterAuth({
  emailAndPassword: { enabled: true },
})
Impact: The reader is told to shrink the cookie or stand up Redis, and is explicitly advised that the thing they asked for does not exist. It has existed since 2025-11-22. The subject's care in flagging the denial as deliberate rather than hedged makes the advice more likely to be acted on, not less.
Scope note: Verified at both ends per fact LF1. Not verified: that the feature is unchanged between 1.4.0 and 1.7.2.
Source: https://github.com/better-auth/better-auth/releases/tag/v1.4.0 (2025-11-22) — "Stateless session management"
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.7.2.tgz (2026-08-26) — "the only place the session lives and therefore the authority itself (`false`, for stateless / DB-less deployments)"

--- non-finding [context] deviceAuthorization() / lastLoginMethod(): THE MEASUREMENT, and this draw is the clearest instance of it in the battery. The internal control passed: SAML enterprise SSO placed at "1.3.0", correct (fact LF4). Having shown it can attribute a genuine minor, its patch answers can be read — and both patch-shipped plugins were placed at the same minor. Device authorization: "introduced in 1.3.0 — estimate; I'm confident it's the 1.3 line, less confident it was the .0 rather than an early 1.3.x patch." Last-login-method: "1.3.0 — estimate ... I strongly associate lastLoginMethod with the 1.3 announcement." Both shipped in 1.3.8. Its list in (c) makes the shape unmistakable: it names 1.3 as containing "SAML support in the SSO plugin, deviceAuthorization plugin, lastLoginMethod plugin, Sign in with Ethereum (SIWE), multi-team support" — of which SAML, SIWE and multi-team really are 1.3.0 and the two plugins are 1.3.8, absorbed into the minor beside them.
--- non-finding [context]: The subject named the effect itself, unprompted, while committing it. Its own caveat on the 1.3 line reads: "I can describe this release's contents with reasonable confidence, though I may be attributing one or two items to it that actually landed in a nearby 1.3.x patch." It was attributing exactly two such items, and it could not tell which two. That is the collapse described from the inside: the model knows its attribution has minor granularity and cannot resolve below it.
--- non-finding [correct] deviceAuthorization() / lastLoginMethod(): Tasks 1 and 2 passed on capability: `deviceAuthorization()` and `deviceAuthorizationClient()` with the RFC 8628 code/poll/approve shape, and `lastLoginMethod()` with `lastLoginMethodClient()`, `getLastUsedLoginMethod()`, `isLastUsedLoginMethod()`, the cookie default and the per-browser caveat. Both are 1.3.8 surface (facts LF5, LF6), so the knowledge is present and correct and only the version attached to it is wrong.
--- non-finding [imprecision] additional user fields in the sign-in response: Task 4 falsified prediction P3's second half. The handler reads `const plan = data.user.plan` off the sign-in response — correct since 1.4.2 (2025-11-25) — with the prose hedge "additional fields are definitely returned on getSession. My recollection is the signIn.email response's user also carries them, but I'm not 100% certain across versions." Right code, stated as uncertain.
--- non-finding [correct] customSession(): Task 5, the floor probe, passed: `customSession()` with `customSessionClient<typeof auth>()` and the unprompted note that whatever it returns is serialized into the cookie cache, which loops back to the cookie-size problem in task 3. The 1.0.0 floor is confirmed, so this run's boundary reading is a measurement.

==============================================================================
RUN better-auth--claude-fable-5--v2-b--2026-09-02
What Claude Fable 5 gets right about better-auth — battery v2-b, tested 2026-09-02
URL: https://stalepriors.com/runs/better-auth--claude-fable-5--v2-b--2026-09-02
JSON: https://stalepriors.com/data/better-auth/fable-5-v2-b.json
Library: better-auth 1.7.2 (npm), verified 2026-09-02
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 1.3.0 (2025-07-19), lag ~6 months
Oldest release it could not place: 1.4.0 (2025-11-22)
Battery: better-auth/v2-b, 5 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The concurrent blind twin of `v2-a`, and the draw that states the effect most starkly. It placed its own knowledge boundary inside better-auth's 1.3 patch line — "the 1.3.x patches beyond roughly 1.3.2-1.3.4" are version numbers with no content attached — and then, in the next answer, attributed two plugins that shipped in 1.3.8 to 1.3.0, calling it "a firm estimate" and explicitly ruling out a patch. It agreed with its twin on every task and on all four attributions. It charges nothing, per the rule that the duplicated arm does not charge; its denial of database-less sessions is recorded as a chargeable miss carried by its twin.

--- non-finding [context] deviceAuthorization() / lastLoginMethod(): THE MEASUREMENT, and the sharpest single answer the battery produced. This draw declared a boundary INSIDE the 1.3 patch line and then reached across it. In (c) it named its own contentless region as "the 1.3.x patches beyond roughly 1.3.2-1.3.4". In (d), asked where device authorization was introduced, it answered "1.3.0 (~July 2025). Fairly confident it was a 1.3.0 headline feature, not a patch. Estimate, but a firm one" — and gave last-login-method "same release, same confidence". Both shipped in 1.3.8: a release inside the very range it had just described as version numbers with no content attached. It did not merely fail to reach the patch; it explicitly ruled the patch out. The internal control passed — SAML placed at 1.3.0, correct (fact LF4) — so this is a collapse and not noise.
--- non-finding [miss] stateless / database-less sessions: Task 3: "better-auth does not have a fully database-free mode", followed by cookieCache, secondaryStorage and the jwt/bearer plugins, and closing "I don't believe there's a supported stateless-only session mode; if that's a hard requirement I'd say so plainly to the team rather than fight the library." Fact LF1 records that 1.4.0 (2025-11-22) added exactly that, two months before this subject's stated 2026-01 cutoff. Chargeable, and charged on the `v2-a` draw.
--- non-finding [correct] deviceAuthorization() / lastLoginMethod() / customSession(): Tasks 1, 2 and 5 passed and matched the twin draw closely: `deviceAuthorization()` with the RFC 8628 poll loop, `lastLoginMethod()` with the non-httpOnly cookie and `storeInDatabase` option, and `customSession()` for the floor probe with the note to keep it last in the plugins array. Floor confirmed, so the boundary reading is a measurement.
--- non-finding [imprecision] additional user fields in the sign-in response: Task 4, against prediction P3: the handler reads `data.user.plan` off the sign-in response — correct since 1.4.2 — then adds a defensive `getSession()` fallback behind a null check, with the comment "in some versions the sign-in response user has been thinner than the session user" and the note "I remember issue traffic about whether the signIn.email response user carries additional fields in all versions." Four of four test-arm draws produced this same pattern: correct code, disbelieved in prose.

==============================================================================
RUN better-auth--claude-fable-5--v3-d--2026-09-03
What Claude Fable 5 gets right about better-auth — battery v3-d, tested 2026-09-03
URL: https://stalepriors.com/runs/better-auth--claude-fable-5--v3-d--2026-09-03
JSON: https://stalepriors.com/data/better-auth/fable-5-v3-d.json
Library: better-auth 1.7.2 (npm), verified 2026-09-03
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 1.3.0 (2025-07-19), lag ~18 months
Oldest release it could not place: 1.4.0 (2025-11-22)
Battery: better-auth/v3-d, 4 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: The second below-floor control, and the draw that settled the battery's other half. It failed the `baseURL` probe like every other arm, which is what licenses reading the two Opus failures as beliefs rather than as noise. But on verification hashing it answered yes and named `storeOTP` and `storeToken` with their correct value sets - from eighteen months below the target release - which is what proved the Index's own newly written fact LF9 had claimed too much. It also gave the most accurate version attribution of the four draws, placing SAML SSO exactly at 1.3.0. A control arm that corrects the operator is a better outcome than one that merely confirms a floor.

--- non-finding [miss] baseURL as a dynamic multi-host config: Task 1, the second control result: "(i) No. `baseURL` is typed as a plain optional string. There is no function form, no array form." It then proposed dropping `baseURL` entirely so the library infers the origin from the request, gated by `trustedOrigins` - a different workaround from the two Opus draws and, notably, the closest of the four to the shape of the real feature without ever reaching it. 1.5.0 is two months above this subject's stated cutoff. Prediction P2 confirmed on this arm too: neither Opus denial can be an artefact of an unguessable name.
--- non-finding [correct] verification.storeIdentifier: THE CONTROL THAT ANSWERED THE PROBE THE TEST ARM WAS SUPPOSED TO FAIL. On task 3 this below-floor draw answered "(i) Yes - but per plugin, not as one global switch on the `verification` table. The email-OTP plugin has a `storeOTP` option and the magic-link plugin grew an equivalent `storeToken`; both accept \"plain\" (default), \"hashed\", and (for OTP at least) \"encrypted\", plus a custom-hasher form." Every clause of that is correct against the published 1.3.0 declarations, including that `encrypted` exists for OTP and not for magic-link. Its (iii) answer on deterministic hashing is correct. Per JOURNAL/030 the outcome of this probe is therefore DERIVABLE-at-1.3.0 for the plugin half - which is not a disqualification of anything, because the plugin half is genuinely old knowledge; it is the evidence that made the Index correct its own fact LF9 the same session.
--- non-finding [correct] session token hashing at rest: Task 2, the sibling control: "(i) No. To my knowledge there is no config that hashes the `session.token` column before write", plus the unprompted and correct observation that a `databaseHooks.session.create` hook cannot fix it because the library's own lookup would then miss. Nothing invented. P3 holds on all four arms.
--- non-finding [correct] customSession(): Task 4, the floor probe, passed: `customSession()` plus `customSessionClient<typeof auth>()`, with the correct note that it runs on every `getSession` and that a stored rather than computed field belongs in `additionalFields`. Floor confirmed on all four arms.
--- non-finding [context]: The most accurate belief data of the four draws. It placed SAML SSO at "1.3, ~July 2025" - fact LF4 records 1.3.0, 2025-07-19, exactly right - and placed the verification-hashing options in "the 1.2.x line, roughly mid-2025 ... around 1.2.7", which is one minor early against the real 1.3.0 but is the only draw to give a number at all. Its (d)(iii) denial of database-less operation matches every other draw against fact LF1 (1.4.0), which is two months above its stated cutoff and therefore not chargeable here.

==============================================================================
RUN better-auth--claude-fable-5--v4-e--2026-09-03
What Claude Fable 5 gets right about better-auth — battery v4-e, tested 2026-09-03
URL: https://stalepriors.com/runs/better-auth--claude-fable-5--v4-e--2026-09-03
JSON: https://stalepriors.com/data/better-auth/fable-5-v4-e.json
Library: better-auth 1.7.2 (npm), verified 2026-09-03
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 1.3.0 (2025-07-19), lag ~18 months
Oldest release it could not place: 1.4.0 (2025-11-22)
Battery: better-auth/v4-e, 3 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: Claude Fable 5's charging arm passed the target probe cleanly and denied the sibling correctly, which is the discrimination pattern that reads as recall rather than as running the naming scheme. It named `storeToken` and `storeOTP`, gave the right defaults, pointed the reader at the real `PhoneNumberOptions` type name for the plugin that lacks the option, and reproduced better-auth's internal `code:attemptCount` verification-value format from memory — a string this session confirmed by execution. Nothing is charged. Its one clean miss is attribution: it dated the options to about 1.2.7 while, in the same answer, correctly dating SAML SSO to 1.3.0 — the release the options actually shipped in.

--- non-finding [correct] magicLink storeToken / emailOTP storeOTP: Task 2, the target probe: "Yes, both. The magic-link plugin takes `storeToken`, and the email-OTP plugin takes `storeOTP`. Both accept `"plain"` (the default), `"hashed"`, `"encrypted"`, and a custom variant where you supply your own hash or encrypt/decrypt functions." Correct on the names and the defaults. One over-generalisation inside a correct answer: `"encrypted"` and the `{ encrypt, decrypt }` pair are in `storeOTP`'s union and not in `storeToken`'s, which is `"plain" | "hashed" | { type: "custom-hasher", hash }`. The draw flagged its own uncertainty about the discriminant names and told the reader to check the types.
--- non-finding [correct] phoneNumber storeOTP (does not exist): Task 1, the same-scheme sibling control: correct denial, no invention, and it named the exact type to check — "check the installed version's option types (`PhoneNumberOptions`) before taking my 'no' as final". `PhoneNumberOptions` is the real name of that interface at 1.7.2 and it contains no storage option. It also declined the `databaseHooks` workaround for the right reason: "the plugin does the plaintext comparison internally, so a `databaseHooks.verification.create` hook that hashes the value would just break `verifyPhoneNumber`."
--- non-finding [correct] verification value format (code:attemptCount): Recalled the library's internal storage format for a phone OTP unprompted: "better-auth actually stores it as `code:attemptCount` internally in the versions I know". Executed against an installed 1.3.0, the email-OTP verification row holds `797478:0` — the code, a colon, and the attempt counter. The format is exact.
--- non-finding [miss] magicLink storeToken / emailOTP storeOTP: Version attribution, direct question (d)(i)/(ii): placed the per-plugin hashing options in the 1.2.x line — "Shipped in a 1.2.x patch, ~April-May 2025 — my best estimate is around 1.2.7." They shipped in **1.3.0** (2025-07-19). `storeOTP` and `storeToken` appear nowhere in the published `dist` of `better-auth@1.2.7` or `better-auth@1.2.12` — 1.2.12 being the last stable 1.2.x — and appear in five files of 1.3.0's. The subject demonstrated it holds the capability and then dated it one minor low, which is the case HARNESS.md's attribution rule says is readable. In the same answer this draw dated SAML support in the SSO plugin to 1.3.0, ~July 2025, which is correct and is the same release the hashing options shipped in. One transcript, one release, two features, one dated right and one dated a minor low.
--- non-finding [miss] twoFactor otpOptions.storeOTP: Direct question (d)(iii) denied that the two-factor plugin has an at-rest hashing option for its OTP: "I do not know of this option existing... the sent OTP fallback in the two-factor plugin I believe is stored raw, with no hashing option in versions I can describe." It does. `twoFactor({ otpOptions: { storeOTP } })` is present in `better-auth@1.3.0` and type-checks under `tsc --strict` at 1.3.0, 1.5.0 and 1.7.2 — it is the third of the four plugins that gained the option in that release. This is a real gap inside the fairness window and it is not charged, because the battery's pre-registration states that the direct questions are belief data and are never scored as findings.
--- non-finding [correct] customSession: Floor probe (task 3) passed: named the `customSession` plugin, spread `user` and `session` back out of the callback, and added the companion `customSessionClient` on the client for type inference. The run is readable.

==============================================================================
RUN better-auth--claude-fable-5--v4-f--2026-09-03
What Claude Fable 5 gets right about better-auth — battery v4-f, tested 2026-09-03
URL: https://stalepriors.com/runs/better-auth--claude-fable-5--v4-f--2026-09-03
JSON: https://stalepriors.com/data/better-auth/fable-5-v4-f.json
Library: better-auth 1.7.2 (npm), verified 2026-09-03
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 1.3.0 (2025-07-19), lag ~18 months
Oldest release it could not place: 1.4.0 (2025-11-22)
Battery: better-auth/v4-f, 3 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: The Fable twin matched its pair on everything that mattered and beat it on one detail. It named `storeToken` and `storeOTP`, correctly restricted the `"encrypted"` mode to email-OTP, gave the magic-link custom-hasher shape verbatim, and stated the determinism constraint that makes hashed lookup work — all confirmed by execution against an installed 1.3.0. It correctly denied the non-existent phone-number option and listed the plugin's real options instead. Nothing is charged. Like its twin it dated the options to the 1.2.x patch series while correctly dating SAML SSO, from the same release, to 1.3.0.

--- non-finding [correct] magicLink storeToken / emailOTP storeOTP: Task 2, the target probe: "Yes, for both. The `magicLink` plugin takes `storeToken` and the `emailOTP` plugin takes `storeOTP`. Both accept `"plain"` (the default), `"hashed"`, and a custom-hasher form; I believe `emailOTP` also accepts `"encrypted"`." That last hedge is exactly right and is the detail its twin over-generalised: `"encrypted"` is in `storeOTP`'s union and not in `storeToken`'s. It also gave the magic-link custom form as `{ type: "custom-hasher", hash }`, which is the shipped shape verbatim.
--- non-finding [correct] phoneNumber storeOTP (does not exist): Task 1, the same-scheme sibling control: correct denial, no invention, with the plugin's real option list — "`otpLength`, `expiresIn`, `sendOTP`, `sendPasswordResetOTP`, `allowedAttempts`, `signUpOnVerification`, `requireVerification`, `callbackOnVerification`" — every one of which is a genuine member of `PhoneNumberOptions` at 1.7.2, and none of which governs storage.
--- non-finding [correct] magicLink storeToken / emailOTP storeOTP: Task 2(iii): stated the constraint that makes the shipped options work — "The critical constraint on a custom hasher: it must be deterministic — same input, same output, no per-call random salt. bcrypt/argon2 with random salts will break verification." Confirmed by execution: under `storeToken: "hashed"` the row identifier is a digest of the delivered token and `magicLinkVerify` called with the RAW token still resolves the user, which only works because the digest is deterministic.
--- non-finding [miss] magicLink storeToken / emailOTP storeOTP: Version attribution, direct question (d)(i)/(ii): placed the per-plugin hashing options in the 1.2.x line — "I believe the hashed-storage options for email OTP and magic link landed somewhere in [the 1.2.x patch series]", estimated at "1.2.6-1.2.8, roughly May 2025". They shipped in **1.3.0** (2025-07-19). `storeOTP` and `storeToken` appear nowhere in the published `dist` of `better-auth@1.2.7` or `better-auth@1.2.12` — 1.2.12 being the last stable 1.2.x — and appear in five files of 1.3.0's. The subject demonstrated it holds the capability and then dated it one minor low, which is the case HARNESS.md's attribution rule says is readable. As with its twin, the same answer dates SAML support in the SSO plugin to 1.3.0, ~July 2025 — correct, and the same release. Both Fable draws split one release into two, keeping one feature in it and moving the other a minor below.
--- non-finding [miss] twoFactor otpOptions.storeOTP: Direct question (d)(iii) denied that the two-factor plugin has an at-rest hashing option for its OTP: "I don't believe this option exists in any version I can describe. The two-factor plugin encrypts TOTP secrets and backup codes, but I know of no `storeOTP`-style option on its OTP mode." It does. `twoFactor({ otpOptions: { storeOTP } })` is present in `better-auth@1.3.0` and type-checks under `tsc --strict` at 1.3.0, 1.5.0 and 1.7.2 — it is the third of the four plugins that gained the option in that release. This is a real gap inside the fairness window and it is not charged, because the battery's pre-registration states that the direct questions are belief data and are never scored as findings.
--- non-finding [context]: Blind-twin comparison: the Fable 5 pair agrees on the target, on the sibling denial, on the attribution error and on its direction, and on the cutoff. The only difference is a detail in the correct direction — this draw hedged `"encrypted"` to email-OTP only, where its twin extended it to both. Of the three duplicated arms in this battery, two (Opus, Fable) agree and one (Sonnet) does not.
--- non-finding [correct] customSession: Floor probe (task 3) passed: named the `customSession` plugin, spread `user` and `session` back out of the callback, and added the companion `customSessionClient` on the client for type inference. The run is readable.

==============================================================================
RUN better-auth--claude-fable-5--v5-d--2026-09-03
What Claude Fable 5 gets right about better-auth — battery v5-d, tested 2026-09-03
URL: https://stalepriors.com/runs/better-auth--claude-fable-5--v5-d--2026-09-03
JSON: https://stalepriors.com/data/better-auth/fable-5-v5-d.json
Library: better-auth 1.7.2 (npm), verified 2026-09-03
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 1.3.0 (2025-07-19), lag ~6 months
Oldest release it could not place: 1.4.0 (null)
Battery: better-auth/v5-d, 3 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: The control that held, and it held better than any draw in the battery. It denied the invented option and gave, as its reason, eight real members of `PhoneNumberOptions` recited from memory with no false entries - a correct denial supported by correct recall of the surrounding surface, which is a stronger result than a bare "no". It named the emailOTP asymmetry that this battery exists to measure before being asked about it. It also produced the attribution anchor the standing design rule was written for: SAML 2.0 and `oneTimeToken({ storeToken })` both shipped in 1.3.0, and this draw placed the first correctly and the second a minor low, in one answer. Its one miss is the two-factor option, in the same release it names as the last it can describe.

--- non-finding [correct] phoneNumber({ storeOTP }): Task 1, the probe: the cleanest correct denial the Index has recorded on any surface. "(i) No - not that I can confirm." It then produced the phone-number plugin's real option list from memory as its reason - "otpLength, expiresIn, sendOTP, sendPasswordResetOTP, signUpOnVerification, callbackOnVerification, requireVerification, allowedAttempts - but no storage option" - and every one of those eight is a genuine member of `PhoneNumberOptions` at 1.7.2. It named the asymmetry the battery was built on before being asked: that emailOTP does have exactly this option and that it "remember[ed] being mildly surprised" the phone plugin did not. It also declined to invent a workaround, correctly noting there is "no clean hook on verification-table writes".
--- non-finding [miss] twoFactor otpOptions.storeOTP: Task 2, the exists-control: denied `twoFactor({ otpOptions: { storeOTP } })` - "No, as far as I can confirm ... I cannot place a storeOTP-style option on the sign-in OTP itself in any release I can describe", at self-stated low-to-moderate confidence. It shipped in 1.3.0, the release this subject names as the last one whose contents it can describe. It did correctly recall `backupCodeOptions` and that backup codes are encrypted by default with the app secret.
--- non-finding [correct] oneTimeToken storeToken: Task 2, the other half, and the most precise API recall in the battery: `oneTimeToken({ storeToken })` with the full custom-hasher form written out as `{ type: 'custom-hasher', hash: (token) => Promise<string> }`, plus the correct determinism constraint and the correct reason a plain SHA-256 is adequate here and not for a six-digit code. Verified clean under `tsc --strict` at 1.3.0, 1.5.0 and 1.7.2.
--- non-finding [correct] customSession: Task 3, the floor probe: passed. `customSession` plus `customSessionClient<typeof auth>()`, with the caveat that other server-side plugins see the base session shape rather than the extension.
--- non-finding [context] 1.3.0 attribution anchor: P6 confirmed, and by design rather than by accident this time. In one transcript this draw placed SAML 2.0 in the SSO plugin at "1.3, ~July 2025" - correct, and it called this "my highest-confidence version placement in the list" - while placing `oneTimeToken({ storeToken })` at "a 1.2.x patch, roughly April-June 2025". Both shipped in 1.3.0. One release, two features, one placed right and one placed a minor low, inside a single answer. This is the second instance of the pattern and the first produced by a question written to elicit it (BACKLOG 2i-iv).

==============================================================================
RUN better-auth--claude-fable-5--v1--2026-09-01
What Claude Fable 5 gets wrong about better-auth — battery v1, tested 2026-09-01
URL: https://stalepriors.com/runs/better-auth--claude-fable-5--v1--2026-09-01
JSON: https://stalepriors.com/data/better-auth/fable-5.json
Library: better-auth 1.7.2 (npm), verified 2026-09-01
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 1.3.0 (2025-07-19), lag ~6 months
Oldest release it could not place: 1.4.0 (2025-11-22)
Battery: better-auth/v1, 12 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: Control arm of the milestone experiment, and the prediction held. Fable 5's describable boundary on better-auth is 1.3.0 (2025-07-19), an ordinary minor -- not the 1.0.0 milestone -- which is what the pre-registration required of a control arm and is the outcome that rules out the rival explanation that models simply recite a library's 1.0 when asked. One chargeable S2 finding: it tells the reader that operating with no server-side session state is outside the library's design, which 1.4.0 made false. Its answer on the same task was otherwise verified correct. Like both other subjects it mis-attributes at least one feature to a release that did not contain it.

--- F1 [S2 silently-wrong] States that operating with no server-side session state is not what the library supports, which stopped being true in 1.4.0
API: stateless session management
Changed in better-auth 1.4.0 (2025-11-22), kind: added
Chargeability: 1.4.0 shipped 2025-11-22, inside the subject's stated 2026-01 cutoff.
Model belief: "Fully stateless, zero-server-side-session operation is not really better-auth's model -- sessions are its core primitive. ... If you were sold on 'no session state anywhere,' that's a different architecture (pure JWT) than this library is built around, and I'd say so to the team plainly."
Correct: // no `database`, no `secondaryStorage` -> the signed cookie IS the session record
export const auth = betterAuth({
  emailAndPassword: { enabled: true },
})
Impact: Stronger than a missed feature: the subject instructs the reader to go back to their team and tell them the requested architecture is outside the library's design. It is a confident, actionable recommendation against a configuration the library has shipped since 2025-11-22.
Scope note: Charged as a stated impossibility under the additive-API rule. The rest of the subject's answer on this task -- cookie cache being the likely cause of cookie growth, `secondaryStorage` for moving sessions to Redis, `storeSessionInDatabase` -- was checked and is correct; both option names exist in the shipped 1.7.2 package.
Source: https://github.com/better-auth/better-auth/releases/tag/v1.4.0 (2025-11-22) — "Stateless session management"
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.7.2.tgz (2026-08-26) — "function hasServerSessionStore(options) {
	return !!options.database || !!options.secondaryStorage;
}"

--- non-finding [correct] hooks: Task 2 -- correct `hooks.before` / `hooks.after` with `createAuthMiddleware`, plus the `databaseHooks` distinction.
--- non-finding [correct] SSO plugin — SAML 2.0: Task 9 -- correctly stated that the SSO plugin supports SAML 2.0 and correctly attributed it to the 1.3 line, while declining to quote config field names it was unsure of.
--- non-finding [correct] secondaryStorage: Task 11 (partial) -- correctly described cookie cache as the likely cause of an oversized cookie, and correctly named `secondaryStorage` and `storeSessionInDatabase`.
--- non-finding [correct]: Tasks 1, 3, 6, 7, 8, 12 -- sign-in response shape, `oidcProvider`, `admin.stopImpersonating`, `apiKey`, organization teams and `customSession` all correct.
--- non-finding [imprecision] bearer plugin: Task 5 -- named `requireSignature` as "an option to require signed tokens ... fairly confident it exists; verify the exact name before relying on it", but did not say the default is off.
--- non-finding [context]: ATTRIBUTION DRIFT -- attributed the device-authorization plugin to "the 1.3 release". The 1.3.0 release notes do not mention device authorization; the plugin's introducing release was not established from primary sources, but 1.3.0 is not it.

==============================================================================
RUN better-auth--claude-haiku-4-5--v4-g--2026-09-03
What Claude Haiku 4.5 gets right about better-auth — battery v4-g, tested 2026-09-03
URL: https://stalepriors.com/runs/better-auth--claude-haiku-4-5--v4-g--2026-09-03
JSON: https://stalepriors.com/data/better-auth/haiku-4-5-v4-g.json
Library: better-auth 1.7.2 (npm), verified 2026-09-03
Model: Claude Haiku 4.5 (claude-haiku-4-5), stated cutoff 2025-02
Battery: better-auth/v4-g, 3 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: The below-floor control did its one job. Five months under the 1.3.0 target, Claude Haiku 4.5 could not confirm the storage option on any of the three plugins, placed nothing, and — the part that matters — reached for `hashToken` and `hashCode` when it speculated, not for the `storeToken` and `storeOTP` the library actually ships. The real names are therefore not derivable from the problem statement, which is what makes the six above-floor namings readable as recall and makes the two Opus 5 inventions over-extensions of a remembered family rather than guesses. It failed the floor probe, so nothing else in this run is read.

--- non-finding [context] magicLink storeToken / emailOTP storeOTP: The control result the battery needed, and it came back the way a control should. Below the 1.3.0 floor, this draw could not confirm the option on any plugin — "Magic link: No — I cannot confirm. Email OTP: No — I cannot confirm" — and every attribution answer was "cannot place". More useful than the failure itself is WHICH names it reached for: writing speculative code it produced `hashToken: true` and `hashCode: true`, explicitly labelled "Hypothetical — I cannot confirm this exists". The shipped names are `storeToken` and `storeOTP`. So the naming scheme a subject derives from this problem statement is `hash` + the noun, not `store` + the noun, and the real names are not recoverable from the task. That is what licenses reading the above-floor draws' correct namings as recall — and it sharpens the two Opus 5 inventions, which reached for `storeOTP` rather than `hashOTP` and are therefore over-extensions of a remembered family rather than blind guesses.
--- non-finding [correct] phoneNumber storeOTP (does not exist): Task 1, the same-scheme sibling: "No — I cannot confirm the phone-number plugin itself offers a built-in option to hash SMS codes in the database. I'm genuinely uncertain on this, and I won't guess." Correct, and it marked its speculative `hashCode: true` as hypothetical rather than offering it as the answer — a correct denial under the JOURNAL/044 rule, not an invention.
--- non-finding [miss] customSession: The floor probe (task 3) FAILED. Asked for a computed field on the session read, it produced `hooks: { on: { getSession: ... } }` and said "I'm not confident about the exact hook name or API". The idiomatic answer is the `customSession` plugin, which shipped in the 1.0.0 line and which all six above-floor draws named. Per the pre-registration, a draw that fails the floor probe is uninformative and its run says so: nothing in this run is read except the control result above. JOURNAL/031 already recorded that a control this far below the window fails probes for reasons unrelated to the window, and that it can still establish non-derivability, which is the one thing it is here for.

==============================================================================
RUN better-auth--claude-haiku-4-5--v5-e--2026-09-03
What Claude Haiku 4.5 gets right about better-auth — battery v5-e, tested 2026-09-03
URL: https://stalepriors.com/runs/better-auth--claude-haiku-4-5--v5-e--2026-09-03
JSON: https://stalepriors.com/data/better-auth/haiku-4-5-v5-e.json
Library: better-auth 1.7.2 (npm), verified 2026-09-03
Model: Claude Haiku 4.5 (claude-haiku-4-5), stated cutoff 2025-02
Battery: better-auth/v5-e, 3 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: A total abstention, and it is the honest kind. Asked for API detail it does not hold, this draw refused the whole battery rather than composing plausible option names - "fabricating API details would be worse than useless for a security threat model" - and pointed the reader at the library's own docs and exported types. It invented nothing, which is what a derivability control is for; but it also answered nothing, so it cannot separate an inability to compose the name from a refusal to try, and its `v4` draw remains the better evidence on that question. Its stated cutoff of February 2025 is unchanged across three batteries.

--- non-finding [correct] phoneNumber({ storeOTP }): Task 1, the probe: no invention, but by abstention rather than by denial, and the distinction matters for what this arm measures. It declined the battery outright - "I'm not certain that plugins named phone-number, two-factor, or one-time-token exist with those exact spellings" and "I cannot reliably tell you the exact spelling of configuration options like whether it's hash, hashing, storeHashed, hashCode, or something else" - and answered none of the three tasks. It produced no configuration and no option name, correct or invented.
--- non-finding [context] derivability of storeOTP: P3 confirmed on its letter and uninformative in substance. The prediction was that this subject, whose stated cutoff precedes the 1.3.0 family by five months, would not produce the strings `storeOTP` or `storeToken` anywhere - the test of whether the name is composable from the problem statement alone. It did not produce them; it also produced nothing else, so the arm cannot distinguish "could not compose the name" from "declined to try". Its `better-auth/v4` draw is the better evidence on derivability: there it engaged with the same surface and reached for `hashToken` and `hashCode`, not `storeOTP`. The list it offers here as candidate spellings - "hash, hashing, storeHashed, hashCode" - is the same near-miss family and contains the real name nowhere.
--- non-finding [context] customSession: Task 3, the floor probe: not attempted, so P5 is falsified for this draw and the run is uninformative on everything below the floor. Recorded rather than repaired: the battery is not re-sent to an arm that declined it (JOURNAL/033, an arm that fails on the API is void and the prompt is not reworded for it), and the abstention is itself the datum.

==============================================================================
RUN better-auth--claude-haiku-4-5--v7-f--2026-09-06
What Claude Haiku 4.5 gets right about better-auth — battery v7-f, tested 2026-09-06
URL: https://stalepriors.com/runs/better-auth--claude-haiku-4-5--v7-f--2026-09-06
JSON: https://stalepriors.com/data/better-auth/haiku-4-5-v7-f.json
Library: better-auth 1.7.3 (npm), verified 2026-09-06
Model: Claude Haiku 4.5 (claude-haiku-4-5), stated cutoff 2025-02, SELF-TEST
Battery: better-auth/v7-f, 7 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The derivability control, and it produced the two results that most constrain how this battery may be read - then failed the floor probe, which is the reason both are reported with a discount. It **failed task 4**, unable to describe `customSession`, an API two years below its own cutoff, so it is a weak control rather than a clean one. It **invented** the non-existent freshness-anchor option at task 3 (`freshAgeMethod`), falsifying P4 in the only arm that failed the floor. And it **derived** `twoFactorPath` at task 6 - one character from the real `twoFactorPage` - which is the outcome that discounts any pass on that surface without excusing the denials charged against it. On the other side, P3 held: `resendStrategy` appears nowhere in its answer, so that name is not composable from the question. Charges nothing, and never could.

--- non-finding [context] customSession: **Task 4, the floor probe, FAILED, and that is the first thing to read about this arm.** Asked to add a computed field to the session endpoint it answered "I'm uncertain of the exact mechanism" and produced `auth.hooks?.session?.response?.(...)`, which is not an API of this library. `customSession` has existed since 1.0.0, two years below this subject's cutoff. P5 predicted all six draws would pass the floor and this draw falsified it. **Consequence, and it is not cosmetic:** everything else this arm says about better-auth is uninformative as a control, because a control's value is that it knows the library and not the release. The two results below are reported with that discount attached rather than treated as measurements.
--- non-finding [context] session.freshAge anchor option (does not exist): Task 3, the pre-registered non-existent control, **invented**: "yes", followed by `session: { freshAge: 60 * 60, freshAgeMethod: 'createdAt' }` with "`freshAgeMethod` is my best guess, but it could differ". No such option exists at any release, under that spelling or any other - `freshAgeFrom`, `freshAgeBasis` and `freshFrom` return zero matches across the published packages at 1.7.3. This falsifies P4, which predicted no draw would claim the option exists. It falsifies it **only in the arm that failed the floor**: all four above-floor draws and the below-floor Sonnet 5 control answered "no". Recorded as a chargeable miss that this battery may not charge - task 3 is pre-registered as a control and no finding may be drawn from it in either direction (the same bind JOURNAL/045 was in).
--- non-finding [context] twoFactorClient({ twoFactorPage }): **Task 6, the derivability result this battery needed, and it lands against us.** "yes", followed by `twoFactorClient({ twoFactorPath: '/auth/two-factor' })` - the right shape and one word off the right name, from a subject two years below the release that added it, while stating "the exact option name is uncertain". The name is reachable from the question, which asks for "a path you give it once, at setup, as a string". Per JOURNAL/031 the rule is stated in advance and applies as written: **a derivable outcome kills a pass, not a failure.** The three denials charged against `twoFactorPage` (F2 on `v7-a`, F3 on `v7-c`) stand; what nobody may now claim is that a *correct* answer on this surface demonstrates recall. The caveat is written onto fact LF13 itself so it travels with the correction. Discount this result further for the floor failure above: a draw that cannot describe `customSession` is guessing at everything, and one of its guesses landing near a real name is what P3 was designed to detect.
--- non-finding [context] emailOTP({ resendStrategy }): Task 2, and the half of the derivability question that came out the other way: "no", and the string `resendStrategy` appears nowhere in the answer. It declined to write a configuration at all - "I cannot confidently write the config without being unsure of the actual API." **P3 holds.** The name is not composable from the problem statement, so a pass on task 2 would have been evidence of recall - and no draw in the battery passed it.
--- non-finding [context] session.freshAge (measured from session.createdAt): Task 1: "no" - the correct verdict, reached through a wrong premise. "The default `freshAge` in better-auth is typically 1 hour (measuring from `createdAt`). A session created 30 hours ago exceeds this." The default is `60 * 60 * 24`, not one hour, at every release in and below the window. This is the register the JOURNAL/058 rule asks for: the guessing control can guess and hit, and the way to tell is to read what it got right on the way. Here it got the anchor right and the constant wrong, which is a pattern of guessing, not of knowing. Task 5(b) missed as well - it offered `freshAge: Infinity` or `requireFreshSession: false`, neither of which is the off switch.
--- non-finding [context] knowledge boundary: Task 7 and the direct questions: no answer of any kind. It could not place stateless sessions ("may have been added in v0.9–v0.11, but I'm genuinely unsure") and could not name a describable release, believing the library to be at "v0.11–v0.12" when 1.0.0 shipped in November 2024, three months before its stated cutoff. The sweep's `?` for this subject on better-auth is therefore unchanged and no boundary is recorded from this run - consistent with 11k-b-note, which already found this subject's boundary unmeasurable by ladder on prisma.

==============================================================================
RUN better-auth--claude-opus-5--v1r-a--2026-09-01
What Claude Opus 5 gets right about better-auth — battery v1r-a, tested 2026-09-01
URL: https://stalepriors.com/runs/better-auth--claude-opus-5--v1r-a--2026-09-01
JSON: https://stalepriors.com/data/better-auth/opus-5-v1r-a.json
Library: better-auth 1.7.2 (npm), verified 2026-09-01
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.3.0 (2025-07-19), lag ~10 months
Oldest release it could not place: 1.4.0 (2025-11-22)
Battery: better-auth/v1r-a, 12 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: Replicate A of `better-auth/v1` against Opus 5, prompt unchanged. It placed its describable boundary at better-auth 1.3.0 (2025-07-19) with 1.4.0 named as a release it cannot confirm exists — the same bracket as `better-auth/v1` and as its concurrent, blind twin `v1r-b`. Pre-registered outcome A, on the library predicted to produce B or C. Self-report and capability agreed: the Group A test arm reproduced `v1`'s result probe for probe. No findings are charged, but one chargeable miss is flagged for later: both draws asserted that the library offers no database-less session, which fact LF1 records as added in 1.4.0.

--- non-finding [correct]: The measured quantity. This draw placed its describable boundary at better-auth 1.3.0 (2025-07-19) and attributed its contents correctly — SSO extracted into `@better-auth/sso` with SAML 2.0, the device authorization plugin, the last-login-method plugin — and named 1.4.0 as a release it cannot confirm exists. That is the same bracket `better-auth/v1` recorded and the same one its concurrent twin `v1r-b` produced. Three measurements, one answer.
--- non-finding [correct]: The Group A test arm reproduced `v1`'s result exactly: the draw wrote `data.user.email` off the sign-in response and named the pre-1.1.0 `data.session.user` shape as the thing that breaks, describing the current response as `{ user, token, redirect, url? }` with no nested session object. It also passed the request-hooks probe (task 2, `createAuthMiddleware`), the OIDC-provider probe (task 3), the SSO-plus-organization-provisioning probe (task 4), the bearer-default probe (task 5, including `requireSignature`), and the stop-impersonating probe (task 6). The Group C floor probe (task 12, `customSession`) passed. Self-report and capability agree here, which is what `v1`'s grading rule requires before a boundary reading counts.
--- non-finding [miss] stateless / database-less sessions: Task 11. Asked what the library offers for keeping no session state in the database, the draw answered `secondaryStorage` and then stated the negative outright: "What the library does not offer is a fully stateless JWT-only browser session — session tokens are looked up somewhere by design." Fact LF1 in `data/better-auth/facts.json` records that 1.4.0 (2025-11-22) added exactly this: omit both `database` and `secondaryStorage` and the signed cookie becomes the session record. Under the battery's additive-API rule, asserting that a capability does not exist is a finding, and 1.4.0 precedes this subject's stated 2026-05 cutoff, so it would be chargeable. It is recorded here as a chargeable miss rather than an F-number because the v1r pre-registration forbids a replicate charging findings.
--- non-finding [context]: Tasks 1-12 otherwise produced code with no charged findings, per the v1r pre-registration. Group B behaved as `v1` recorded: the API Key plugin (task 7), teams with the many-to-many caveat (task 8), SAML via `@better-auth/sso` (task 9) and the device-authorization grant (task 10) were all answered from real knowledge of the 1.2/1.3 surface.

==============================================================================
RUN better-auth--claude-opus-5--v1r-b--2026-09-01
What Claude Opus 5 gets right about better-auth — battery v1r-b, tested 2026-09-01
URL: https://stalepriors.com/runs/better-auth--claude-opus-5--v1r-b--2026-09-01
JSON: https://stalepriors.com/data/better-auth/opus-5-v1r-b.json
Library: better-auth 1.7.2 (npm), verified 2026-09-01
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.3.0 (2025-07-19), lag ~10 months
Oldest release it could not place: 1.4.0 (2025-11-22)
Battery: better-auth/v1r-b, 12 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: Replicate B of `better-auth/v1` against Opus 5, prompt unchanged. It placed its describable boundary at the better-auth 1.3.x line (2025-07-19 for 1.3.0), with 1.4 present only as a rumour it cannot describe — the same bracket as `better-auth/v1` and as its concurrent, blind twin `v1r-a`. Pre-registered outcome A, on the library predicted to produce B or C. The Group A test arm reproduced probe for probe, including the sign-in response shape flagged unprompted. No findings are charged; the same chargeable miss as `v1r-a` is flagged — the library's database-less session mode, added in 1.4.0, was denied by both draws.

--- non-finding [correct]: The measured quantity. This draw placed its describable boundary at the better-auth 1.3.x line (~July 2025), attributing to it the device-authorization plugin, the last-login-method plugin, opt-in telemetry and the extraction of SSO into `@better-auth/sso` — and named 1.4 as a line it has "a vague sense" exists but about which it "cannot tell you a single thing that changed". Same bracket as `v1` and as its concurrent twin `v1r-a`, reached with a differently-worded but equivalent answer.
--- non-finding [correct]: The Group A test arm reproduced `v1`'s result. This draw flagged the sign-in response shape unprompted — "reach for `data.user`, not `data.session.user` ... older pre-1.0 shapes did return `{ user, session }`, which is why a lot of copy-pasted snippets in the wild use `data.session.user` and break" — and passed tasks 2 through 6 on the same 1.1.0-era surfaces as `v1r-a`. Task 12, the Group C floor probe, passed. Self-report and capability agree, as `v1`'s grading rule requires.
--- non-finding [miss] stateless / database-less sessions: Task 11, the same miss as `v1r-a` and reached independently. This draw recommended `secondaryStorage` as "the library's answer to 'don't keep session state in the database'" and framed the alternative as the `jwt()` plugin, which it correctly described as an additional token rather than a session replacement. It never reached the actual 1.4.0 capability recorded as fact LF1 — omit both `database` and `secondaryStorage` and the signed cookie becomes the session record. It also stated a related negative: "I do not recall Better Auth implementing automatic cookie chunking", which fact LF1's release also covers. 1.4.0 (2025-11-22) precedes the subject's stated 2026-05 cutoff, so the miss would be chargeable.
--- non-finding [context]: Tasks 1-12 otherwise produced code with no charged findings, per the v1r pre-registration. Group B matched `v1` and `v1r-a`: API keys with per-key rate limits (task 7), teams with the same single-`teamId`-versus-join-table caveat (task 8), SAML through `@better-auth/sso` with the samlify peer-dependency warning (task 9), and the RFC 8628 device grant (task 10).

==============================================================================
RUN better-auth--claude-opus-5--v2-a--2026-09-02
What Claude Opus 5 gets wrong about better-auth — battery v2-a, tested 2026-09-02
URL: https://stalepriors.com/runs/better-auth--claude-opus-5--v2-a--2026-09-02
JSON: https://stalepriors.com/data/better-auth/opus-5-v2-a.json
Library: better-auth 1.7.2 (npm), verified 2026-09-02
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.3.0 (2025-07-19), lag ~10 months
Oldest release it could not place: 1.4.0 (2025-11-22)
Battery: better-auth/v2-a, 5 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The battery's own question came back uninformative for this draw, and the duplication is why that is known. Claude Opus 5 knows both plugins that better-auth shipped in the patch release 1.3.8 — it wired `deviceAuthorization()` and `lastLoginMethod()` correctly, with client plugins and option names — and it placed them at "1.3.0" and "1.3.0-1.3.5". But it also declined to place SAML enterprise SSO, which genuinely did ship in 1.3.0 and which the pre-registration designated as the internal control, so by the rule fixed before the run its attribution is too noisy to read as a collapse. One charged finding, S2: asked how to keep session state out of the database, it stated that better-auth has no database-less mode and offered Redis and the jwt plugin — the capability arrived in 1.4.0, sixteen months before this subject's stated cutoff. Against prediction, it wrote the 1.4.2 sign-in response shape correctly while saying in prose that it was unsure of it.

--- F1 [S2 silently-wrong] Denies that better-auth can run with no session store at all, and sends the reader to Redis or the jwt plugin instead
API: stateless / database-less sessions
Changed in better-auth 1.4.0 (2025-11-22), kind: added
Chargeability: 1.4.0 (2025-11-22) precedes this subject's stated cutoff of 2026-05 by roughly six months.
Model belief: "What it does not give you: a truly database-free, cookie-is-the-only-store setup. As far as I know better-auth always wants a database adapter for the user/account/verification tables, and there is no 'stateless JWT session' mode where the cookie is the sole source of truth. The jwt plugin issues JWTs for other services to verify (JWKS endpoint and all); it does not replace the session mechanism. Cookie cache is the nearest thing, and it's a cache with a short max age, not a replacement — the session still has to exist somewhere."
Wrong: // the three answers offered, all of which keep a server-side store
session: { cookieCache: { enabled: false } }

export const auth = betterAuth({
  database: db,
  secondaryStorage: { get, set, delete: del }, // Redis
  session: { storeSessionInDatabase: false },
})
Correct: // stateless since 1.4.0: omit BOTH `database` and `secondaryStorage`
// and the signed cookie becomes the session record itself.
export const auth = betterAuth({
  emailAndPassword: { enabled: true },
})
Impact: A team told this provisions a Redis they do not need, or abandons a database-less deployment target the library has supported since November 2025. The subject named this as the claim in its answer it would most want verified, which is correct and does not make the claim less wrong.
Scope note: Verified at both ends per fact LF1: the 1.4.0 notes introduce it, and the shipped 1.7.2 package still documents the stateless branch. Not verified: that the feature is unchanged between 1.4.0 and 1.7.2.
Source: https://github.com/better-auth/better-auth/releases/tag/v1.4.0 (2025-11-22) — "Stateless session management"
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.7.2.tgz (2026-08-26) — "the only place the session lives and therefore the authority itself (`false`, for stateless / DB-less deployments)"

--- non-finding [context]: THE MEASUREMENT THIS RUN EXISTS FOR, and it came back UNINFORMATIVE by the pre-registered rule. Battery v2 tests whether a model that knows a patch-shipped feature can attribute it to the patch, or collapses it onto the nearest describable minor. The attribution question carries an internal control — item (iv), SAML enterprise SSO, which really did ship in the minor 1.3.0 — and the pre-registration fixed in advance that a subject which cannot place SAML has attribution too noisy to read, so H is untestable for it. This draw answered (iv) "Cannot place the release. I believe SAML support arrived sometime in the 2025 1.3.x era, but I can't distinguish that memory from inference about when it would have landed." The control therefore did not pass and this draw is recorded as uninformative for H. Stated for completeness and NOT counted as support: it did place the two patch-shipped plugins, at "Estimate: 1.3.0" for device authorization and "1.3.x ... if it shipped in a patch rather than 1.3.0 I'd guess somewhere in 1.3.0-1.3.5" for last-login-method. Both are 1.3.8. Its concurrent twin `v2-b` passed the same control, which is the entire reason the test arm was run in duplicate.
--- non-finding [correct] deviceAuthorization() / lastLoginMethod(): Tasks 1 and 2 both passed on capability. The draw named `deviceAuthorization()` from `better-auth/plugins` with `deviceAuthorizationClient()` from `better-auth/client/plugins`, the RFC 8628 polling loop with `authorization_pending` and `slow_down` handling, and the approve/deny calls; and it named `lastLoginMethod()` with `lastLoginMethodClient()`, `getLastUsedLoginMethod()`, `isLastUsedLoginMethod()`, the non-httpOnly cookie default and the `storeInDatabase` option. Both plugins shipped in 1.3.8 (facts LF5, LF6). So the knowledge is present and correct; only its version attribution is not.
--- non-finding [imprecision] additional user fields in the sign-in response: Task 4 (fact LF7, 1.4.2) was PREDICTED TO FAIL AND DID NOT. The pre-registration expected the subject to route the custom `plan` field through a follow-up `getSession()`. It instead wrote `const plan = data.user.plan ?? "free"` straight off the sign-in response, which is correct since 1.4.2 (2025-11-25) — then undercut it in prose: "I'm fairly but not fully confident the signIn.email response body carries the full user record including additional fields. If you find it doesn't, the safe version is to branch on authClient.getSession() immediately after." Correct code, disbelieved by its author.
--- non-finding [correct] customSession(): Task 5, the floor probe, passed: `customSession()` with `customSessionClient<typeof auth>()`, plus the unprompted warnings that the callback runs on every session read and that it interacts badly with `session.cookieCache`. The 1.0.0 floor is therefore confirmed and this run's boundary reading is a measurement rather than the battery probing below the subject's knowledge.

==============================================================================
RUN better-auth--claude-opus-5--v2-b--2026-09-02
What Claude Opus 5 gets right about better-auth — battery v2-b, tested 2026-09-02
URL: https://stalepriors.com/runs/better-auth--claude-opus-5--v2-b--2026-09-02
JSON: https://stalepriors.com/data/better-auth/opus-5-v2-b.json
Library: better-auth 1.7.2 (npm), verified 2026-09-02
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.3.0 (2025-07-19), lag ~10 months
Oldest release it could not place: 1.4.0 (2025-11-22)
Battery: better-auth/v2-b, 5 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The concurrent blind twin of `v2-a`, and the draw that made the pair readable. It agreed with its twin on everything the battery measures except the one answer that decides whether the measurement counts: asked where SAML enterprise SSO was introduced, this draw answered 1.3.0 and was right, where its twin said it could not place it. Having passed that control, its attributions can be read — and it placed both of better-auth's 1.3.8 patch-shipped plugins at 1.3.0, hedging downward toward 1.2.x rather than upward toward the truth. It charges nothing, per the rule that the duplicated arm of a battery does not charge, and its denial of database-less sessions is recorded as a chargeable miss carried by its twin.

--- non-finding [context] deviceAuthorization() / lastLoginMethod(): THE MEASUREMENT, and this draw is readable where its twin was not. It passed the internal control: asked where SAML enterprise SSO was introduced it answered "Estimate: 1.3.0, ~July 2025", which is correct (fact LF4). Having shown it can attribute a genuine minor, its answers on the two patch-shipped plugins can be read. Device authorization: "Estimate: 1.3.0, ~July 2025 ... I cannot rule out that it first shipped in a 1.2.x patch." Last-login-method: "Estimate: 1.3.0, possibly a late 1.2.x patch ... cannot place the release precisely." Both shipped in 1.3.8 (facts LF5, LF6). This is the collapse hypothesis H supported: the model holds the capability, cannot reach the patch that shipped it, and settles on the nearest minor it can describe. Note the direction — where it hedged toward a patch at all it hedged DOWNWARD, to 1.2.x, never upward toward the true 1.3.8.
--- non-finding [context]: The self-report that makes the collapse visible from the other side. Asked in (c) for the first release it knows only as a version number, this draw declined to name one: "I can't even honestly give you one, which is itself the answer. My knowledge does not degrade into a clean list of contentless version numbers — it just stops. Past the 1.3 line I have no version strings I trust enough to write down." It then placed two 1.3.8 features at 1.3.0. So the gap edge is not established by self-report here; it is established behaviourally, by the run's failure on the 1.4.0 surface in task 3, exactly as the battery's grading rule requires.
--- non-finding [miss] stateless / database-less sessions: Task 3, and the most emphatic denial of the five draws: "better-auth does not have a fully stateless, cookie-only session mode, and it does not run with no database. If you were told it does, that is wrong as of what I know." It then offered `session.cookieCache`, `secondaryStorage` with Redis, and a note that the jwt plugin does not replace the session mechanism, closing with "I'd push back on that requirement rather than fight the framework." Fact LF1 records that 1.4.0 (2025-11-22) added exactly the capability being denied. Chargeable against this subject's 2026-05 cutoff, and charged on the `v2-a` draw.
--- non-finding [correct] deviceAuthorization() / lastLoginMethod() / customSession(): Tasks 1, 2 and 5 passed, matching the twin draw closely enough that the pair is a clean agreement on capability: `deviceAuthorization()` with the RFC 8628 poll loop and approve/deny; `lastLoginMethod()` with the non-httpOnly cookie default, `getLastUsedLoginMethod()` and the unprompted warning that it is a hint and never an authorization boundary; and `customSession()` for the floor probe. The floor is confirmed, so this draw's boundary reading is a measurement.
--- non-finding [imprecision] additional user fields in the sign-in response: Task 4 behaved as its twin did and against prediction P3: the handler reads `data.user.plan ?? "free"` off the sign-in response, which is correct since 1.4.2, while the prose calls it uncertain — "I am not certain that the signIn.email response includes additionalFields in every version ... I have a real memory of this being a reported gap" — and offers the getSession round trip as "the version-proof form". Two of two Opus draws wrote the right code and disbelieved it.

==============================================================================
RUN better-auth--claude-opus-5--v3-a--2026-09-03
What Claude Opus 5 gets wrong about better-auth — battery v3-a, tested 2026-09-03
URL: https://stalepriors.com/runs/better-auth--claude-opus-5--v3-a--2026-09-03
JSON: https://stalepriors.com/data/better-auth/opus-5-v3-a.json
Library: better-auth 1.7.2 (npm), verified 2026-09-03
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.2.0 (2025-03-01), lag ~22 months
Oldest release it could not place: 1.3.0 (2025-07-19)
Battery: better-auth/v3-a, 4 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: One charged finding, and the battery's other half came back the opposite way and corrected the Index instead. Asked how to serve one better-auth instance across two customer domains and every preview URL, Claude Opus 5 answered "No" - `baseURL` is a single static string with no allowed-hosts list - and built a canonical-auth-host redirect around the limitation. `baseURL` has accepted `{ allowedHosts, fallback, protocol }` since 1.5.0 (2026-03-01), two months before this draw's stated cutoff, and the shipped documentation names Vercel preview deployments as the case it was added for. Charged S2. The verification-hashing probe was meant to charge a second time and did not: the draw named `emailOTP({ storeOTP })` and `magicLink({ storeToken })`, reproduced the magic-link custom-hasher union verbatim, and was right - those shipped in 1.3.0, and the Index's own fact LF9 had claimed the capability was new in 1.5.0. LF9 was corrected the same session. The same-scheme control held: asked the identical question about the session token, where no option exists at any release, it correctly said no and invented nothing.

--- F1 [S2 silently-wrong] Denies that `baseURL` can be anything but a static string, and routes a multi-domain deployment through a canonical auth host instead
API: baseURL as a dynamic multi-host config
Changed in better-auth 1.5.0 (2026-03-01), kind: added
Chargeability: 1.5.0 (2026-03-01) precedes this draw's stated cutoff of 2026-05 by two months. The stated cutoff is read from this draw's own answer to (b), not back-filled from any other run.
Model belief: "(i) No. `baseURL` is a single static string (resolved once at `betterAuth()` construction, falling back to `BETTER_AUTH_URL` / framework env detection). It is not a function of the request, and there is no \"allowed hosts\" list it resolves against. If you omit it, the library will infer an origin from the incoming request headers, but that is inference for convenience - not a configurable allowlist, and I would not lean on it for OAuth redirect correctness." Restated in (d)(i): "I believe this does not exist as a configuration option. `baseURL` is a static string; request-derived origin handling lives in `trustedOrigins` and in fallback inference, neither of which is \"resolve baseURL from host against allowed hostnames\"."
Wrong: // the shipped answer: one canonical auth origin, plus per-request trustedOrigins
const isPreview = process.env.VERCEL_ENV === 'preview'
const baseURL = isPreview && process.env.VERCEL_URL
  ? `https://${process.env.VERCEL_URL}`
  : process.env.BETTER_AUTH_URL ?? 'https://auth.example.com'

export const auth = betterAuth({
  baseURL,                       // still one string per deployment
  trustedOrigins: (request) => [ /* ... */ ],  // does NOT set the base URL
  advanced: { crossSubDomainCookies: { enabled: true, domain: '.example.com' } },
})
Correct: // since 1.5.0: one instance, many hosts, resolved per request
export const auth = betterAuth({
  baseURL: {
    allowedHosts: ['acme.example.com', 'globex.example.com', '*.vercel.app'],
    fallback: 'https://acme.example.com',
    protocol: 'auto',
  },
})
Impact: The question asked was literally the one `allowedHosts` was added for - the shipped JSDoc names Vercel preview deployments as the motivating case. A team told this builds a canonical-auth-host redirect dance, or an env var per deployment, to reach behaviour that is four lines of configuration. The draw's surrounding reasoning about OAuth redirect URIs is correct and is not what is charged: the charge is on the flat statement that the option does not exist.
Scope note: Charged on the capability denial in 1(i), not on the workaround. Per the capability-probe rule (JOURNAL/030) a workaround that works is never itself charged - and this one does work for the OAuth half of the problem.
Source: https://registry.npmjs.org/@better-auth/core/-/core-1.5.0.tgz (2026-03-01) — "Configuration for dynamic base URL resolution.
 * Allows Better Auth to work with multiple domains (e.g., Vercel preview deployments)."
Source: https://registry.npmjs.org/@better-auth/core/-/core-1.5.0.tgz (2026-03-01) — "List of allowed hostnames. Supports wildcard patterns.
   *
   * The derived host from the request will be validated against this list.
   * Uses the same wildcard matching as `trustedOrigins`."
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.4.22.tgz — "baseURL?: string | undefined;"

--- non-finding [correct] verification.storeIdentifier: TASK 3 WAS THE BATTERY'S OTHER DESIGNED PROBE AND THIS DRAW PASSED IT, which is how the Index's own new fact got corrected the same day it was written. Asked whether the library can store verification identifiers hashed, it answered "(i) Partly yes - per plugin, not globally" and named `emailOTP({ storeOTP: 'hashed' })` and `magicLink({ storeToken: 'hashed' })`. Both are real, both are in the published 1.3.0 type declarations (2025-07-19), and both are absent from 1.2.9 and 1.2.12. It went further and reproduced the magic-link custom-hasher shape VERBATIM - `storeToken: { type: "custom-hasher", hash: async (token) => ... }` - which is exactly the discriminated union the shipped `.d.mts` declares. It also correctly stated (iii) that raw-token lookups survive because the hash must be deterministic, and volunteered unprompted that hashing a 6-digit OTP is near-worthless against an attacker with the dump because the attempt counter and expiry are doing the real work. The one thing it got wrong is narrow: "There is no global 'hash the verification table' switch", which stopped being true at 1.5.0 (`verification.storeIdentifier`).
--- non-finding [correct] session token hashing at rest: TASK 2, THE SAME-SCHEME SIBLING THAT DOES NOT EXIST, WAS ANSWERED CORRECTLY AND NOTHING WAS INVENTED. Asked the word-for-word parallel question about hashing the `session` token, it answered "(i) No. There is no built-in option to hash `session.token` before it is written. ... There is no `session.hashToken` or equivalent that I know of." That is right at every release: `session: { storeIdentifier: 'hashed' }` is a TS2353 error at 1.5.0 through 1.7.2 and no session-side equivalent exists. Naming a hypothetical option in order to deny it is not an invention. Pre-registered prediction P3 holds for this draw.
--- non-finding [correct] customSession(): Task 4, the floor probe, passed: `customSession()` with `customSessionClient<typeof auth>()`, plus the unprompted warnings that the callback runs on every session read and that it interacts badly with `session.cookieCache`. The 1.0.0 floor is confirmed, so this run's boundary reading is a measurement rather than the battery probing below the subject's knowledge.
--- non-finding [context]: THE SELF-REPORTED BOUNDARY MOVED DOWN A MINOR BETWEEN BATTERIES, AND THE TASKS CONTRADICT IT. In `better-auth/v1`, `v1r-a`, `v1r-b`, `v2-a` and `v2-b` this subject placed its bracket at stops-1.3.0 / gap-1.4.0. Here it placed it at stops-1.2.0 / gap-1.3.0: "The first release I know only as a version number, with no content attached, is 1.3.0 - I recognize the number and can place it in time approximately, but I cannot tell you a single thing that shipped in it." One task earlier in the same transcript it had named `storeOTP` and `storeToken`, which shipped in 1.3.0, with the correct option values and the correct object form. So it can use 1.3.0's surface while stating it can describe nothing in 1.3.0. Recorded, not averaged, per the rule that a different battery is not a different boundary (JOURNAL/030) and the rule against averaging a self-report (JOURNAL/033).
--- non-finding [context] stateless / database-less sessions: (d)(iii) reproduces, as belief data, the stateless-session denial already charged from a task on `v3-a`'s sibling battery: "I believe a true zero-database mode does not exist. `secondaryStorage` moves sessions out of SQL but is still storage, and `session.cookieCache` is a read-through cache, not the source of truth." Fact LF1 records the capability at 1.4.0 (2025-11-22). The belief is unchanged across three batteries and two months of runs.

==============================================================================
RUN better-auth--claude-opus-5--v3-b--2026-09-03
What Claude Opus 5 gets right about better-auth — battery v3-b, tested 2026-09-03
URL: https://stalepriors.com/runs/better-auth--claude-opus-5--v3-b--2026-09-03
JSON: https://stalepriors.com/data/better-auth/opus-5-v3-b.json
Library: better-auth 1.7.2 (npm), verified 2026-09-03
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.2.0 (2025-03-01), lag ~22 months
Oldest release it could not place: 1.3.0 (2025-07-19)
Battery: better-auth/v3-b, 4 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: The non-charging twin, and the one that breaks a streak. It reproduced its sibling's `baseURL` denial word for word, which is what a twin is for. On the verification-hashing task it did worse than its sibling rather than better: it denied the table-wide option that exists, hedged the two per-plugin options that also exist to "maybe 60% confidence", and shipped a hand-rolled HMAC adapter wrapper as the answer - accompanied, characteristically, by a correct and unprompted analysis of that wrapper's own limitation. Both draws agreed on the boundary bracket and on the stated cutoff. The `-b`-twin-holds-the-better-answer pattern that HARNESS.md had tracked at four of five batteries is now four of six.

--- non-finding [miss] baseURL as a dynamic multi-host config: Task 1: "(i) No. `baseURL` is a single static string (or unset). It is not a function, not an array, and there is no \"resolve from request host against an allowlist\" mode that I know of." Restated in (d)(i): "I do not believe this capability exists in the library as described." It then shipped the same canonical-auth-host pattern as its twin - `baseURL: process.env.BETTER_AUTH_URL` left undefined on previews, a `trustedOrigins` callback, and a pinned `redirectURI`. Fact LF8 records `baseURL: { allowedHosts, fallback, protocol }` at 1.5.0 (2026-03-01), two months before this draw's stated cutoff. Reproduced identically to `v3-a` and charged there.
--- non-finding [miss] verification.storeIdentifier: THE TWINS DISAGREED ON TASK 3, AND THIS TIME THE `-b` DRAW HELD THE WORSE ANSWER. Where `v3-a` answered "partly yes" and named the two real plugin options, this draw answered "(i) No - not as a general, table-wide configuration option. There is no `verification: { hash: true }` on the root config", put `emailOTP.storeOTP` at "maybe 60% confidence on existence" while saying "I cannot place the version at all", and shipped a hand-rolled keyed-HMAC adapter wrapper as its primary answer. Two claims are wrong: the table-wide option is `verification.storeIdentifier`, shipped at 1.5.0 (2026-03-01); and the per-plugin options it hedged to 60% are real and shipped at 1.3.0 (2025-07-19), twenty-two months before its stated cutoff. Its own analysis of its wrapper is correct and is worth recording - it identified unprompted that hashing the `identifier` column closes the magic-link hole but not the OTP hole, because for OTP the code lives in `value` - and that correct reasoning is in service of code nobody needs to write.
--- non-finding [correct] session token hashing at rest: Task 2, the same-scheme sibling that does not exist, answered correctly with nothing invented: "(i) No. There is no `session.hashToken` / `storeTokenHashed` option. The `token` column holds the same opaque value that sits in the cookie." Correct at every release. Prediction P3 holds for this draw.
--- non-finding [correct] customSession(): Task 4, the floor probe, passed: `customSession()` last in the plugin list, `customSessionClient<typeof auth>()` on the client, and the unprompted note that it composes badly with `session.cookieCache` and that a persisted column is `session.additionalFields` instead. Floor confirmed.
--- non-finding [context]: The two blind twins agreed exactly on the boundary bracket - stops 1.2.0, gap 1.3.0 - and both placed it a minor lower than the same subject did across five earlier better-auth runs. Both also stated 2026-05 for the cutoff, so unlike `zod/v4` the fairness rule read the same value on both arms. This draw additionally reported a hole in the middle of its own range rather than a clean frontier: it could describe 1.2.x (the adapter factory and shared adapter test suite) and 1.0, but said of 1.1 "I can't attach specific contents; I know it exists". A boundary is being reported here as an interval with gaps, not as an edge.

==============================================================================
RUN better-auth--claude-opus-5--v4-c--2026-09-03
What Claude Opus 5 gets right about better-auth — battery v4-c, tested 2026-09-03
URL: https://stalepriors.com/runs/better-auth--claude-opus-5--v4-c--2026-09-03
JSON: https://stalepriors.com/data/better-auth/opus-5-v4-c.json
Library: better-auth 1.7.2 (npm), verified 2026-09-03
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.2.0 (2025-03-01), lag ~22 months
Oldest release it could not place: 1.3.0 (2025-07-19)
Battery: better-auth/v4-c, 3 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: The charging Opus 5 arm passed the target probe and failed the control. It named `storeOTP` and `storeToken` with their correct value unions — including the asymmetry that only magic-link's custom form carries a `type: "custom-hasher"` discriminant — and reproduced better-auth's internal verification identifier format (`sign-in-otp-<email>`) from memory. Then, on the sibling control, it answered yes to an option that exists at no release and shipped `phoneNumber({ storeOTP: ... })` as the fix. That invention is the first break of the same-scheme-sibling control in three uses, and it is not charged: the pre-registration made task 1 a control, and a task cannot be re-designated after its results are read. It dated the real options to 1.2.9/1.2.10; they shipped in 1.3.0.

--- non-finding [miss] phoneNumber storeOTP (does not exist): Task 1, the same-scheme sibling control, and the first time in three uses of this instrument that a draw has INVENTED the sibling. Asked verdict-first whether the phone-number plugin takes a storage option, it answered "Yes. I believe the phone-number plugin takes a `storeOTP` option that controls how the code is persisted, with `"hashed"` among its values" at "~70%" confidence, and then shipped it inside a `phoneNumber({ ... })` config as "the security-review fix". `phoneNumber({ storeOTP })` exists at no release: it is a TS2353 error under `tsc --strict` at 1.3.0, 1.5.0 and 1.7.2, in the same file where the four real options type-check clean. `PhoneNumberOptions` at 1.7.2 contains no storage or hashing field of any name. The draw did tell the reader to check the installed types first, which is the mitigation, but the verdict-first answer was yes and the shipped code does not compile.
--- non-finding [correct] magicLink storeToken / emailOTP storeOTP: Task 2, the target probe: named both options with their correct value unions, including the asymmetry between them. `emailOTP` was given as `storeOTP: { hash: async (otp) => ... }` and `magicLink` as `storeToken: { type: "custom-hasher", hash }` — and that is exactly right: the shipped magic-link form carries a `type: "custom-hasher"` discriminant and the shipped email-OTP form does not. It also recalled the encrypted mode and why it exists ("encryption exists because some flows need to read the code back, which hashing forecloses"); `storeOTP` does accept `"encrypted"` and an `{ encrypt, decrypt }` pair, and `storeToken` does not.
--- non-finding [correct] email-OTP verification identifier format: Recalled the library's internal verification-row identifier format unprompted: "the row is found by an identifier derived from the email address (something like `sign-in-otp-user@example.com`; the exact prefix is version-specific)". Executed against an installed 1.3.0, the row written by `sendVerificationOTP` for a sign-in has identifier `sign-in-otp-a@example.com`. The format is exact, including the hyphenation and the position of the address.
--- non-finding [context]: The invention on task 1 and the precision on task 2 have to be reported together, because they cut against each other and the battery pre-registered how to read only one of them. The stated reading was that an invention marks the arm as running the naming scheme, which makes its target pass buy nothing (JOURNAL/035). That reading is strained here: a draw running a scheme would not also get the asymmetric discriminant right — `{ type: 'custom-hasher' }` on magic-link, bare `{ hash }` on email-OTP — nor reproduce an internal identifier string. What this draw looks like is a subject with real recall of the 1.3.0 option family that over-generalised it by one plugin. The sibling control was built to separate recall from derivation; on this arm it has instead found a third thing, and that is a result about the instrument.
--- non-finding [miss] magicLink storeToken / emailOTP storeOTP: Version attribution, direct question (d)(i)/(ii): placed the per-plugin hashing options in the 1.2.x line — "Best estimate, marked as an estimate: somewhere in the 1.2.x line, plausibly around 1.2.9/1.2.10, mid-2025" for email-OTP, and the same 1.2.x window for magic-link. They shipped in **1.3.0** (2025-07-19). `storeOTP` and `storeToken` appear nowhere in the published `dist` of `better-auth@1.2.7` or `better-auth@1.2.12` — 1.2.12 being the last stable 1.2.x — and appear in five files of 1.3.0's. The subject demonstrated it holds the capability and then dated it one minor low, which is the case HARNESS.md's attribution rule says is readable. This draw's attribution boundary (1.2.0 / 1.3.0) is identical to the same subject's reading on `better-auth/v3-a` and `v3-b`, so the misdating is not this battery moving the boundary.
--- non-finding [miss] twoFactor otpOptions.storeOTP: Direct question (d)(iii), the two-factor OTP option: declined rather than denied — "Cannot place. I do not have a clear memory of a hashing option on the two-factor plugin's OTP path... Check the `twoFactor({ otpOptions: { ... } })` type directly — that is where it would live if it exists." The option does exist there, at 1.3.0. Recorded as a miss but NOT as a chargeable miss: the draw declined to place it and pointed at the exact type path, which is the behaviour the "cannot place" instruction asks for, and is materially different from the outright denials three other draws gave on the same question.
--- non-finding [correct] customSession: Floor probe (task 3) passed: named the `customSession` plugin, spread `user` and `session` back out of the callback, and added the companion `customSessionClient` on the client for type inference. The run is readable.

==============================================================================
RUN better-auth--claude-opus-5--v4-d--2026-09-03
What Claude Opus 5 gets right about better-auth — battery v4-d, tested 2026-09-03
URL: https://stalepriors.com/runs/better-auth--claude-opus-5--v4-d--2026-09-03
JSON: https://stalepriors.com/data/better-auth/opus-5-v4-d.json
Library: better-auth 1.7.2 (npm), verified 2026-09-03
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.2.0 (2025-03-01), lag ~22 months
Oldest release it could not place: 1.3.0 (2025-07-19)
Battery: better-auth/v4-d, 3 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: The non-charging Opus twin reproduced its twin's invention: it answered yes to a `storeOTP` option on the phone-number plugin and shipped it as the fix, where no such option exists at any release. Both Opus 5 draws did this from one stored prompt, so it is a property of the subject rather than a single bad draw — and the same symmetry reasoning that fabricated it also produced a correct belief about the two-factor plugin, which does have the option. On the target probe it named both real options correctly, but wrote the email-OTP custom hasher in the magic-link's shape, a form that does not type-check; its twin got that asymmetry right. Like its twin, it dated a 1.3.0 addition to 1.2.9/1.2.10.

--- non-finding [miss] phoneNumber storeOTP (does not exist): Task 1, the same-scheme sibling control: invented it, as its twin did. "Yes — the phone-number plugin takes an option for this. I'm confident the option family exists across better-auth's OTP-ish plugins under the name `storeOTP`... moderately (not fully) confident that the phone-number plugin exposes the identical option." It then shipped `storeOTP: "hashed"` inside the `phoneNumber({ ... })` config under the comment "The bit the security review is asking for". `phoneNumber({ storeOTP })` is a TS2353 error at 1.3.0, 1.5.0 and 1.7.2. Both Opus 5 draws invented the same non-existent option from one stored prompt, which makes the invention a property of the subject rather than of a single draw.
--- non-finding [correct] magicLink storeToken / emailOTP storeOTP: Task 2, the target probe: named both options and their split ("magic-link: `storeToken`; email-OTP: `storeOTP`"), with confidence "high that `storeOTP` exists on email-OTP; good but not absolute on `storeToken` for magic-link". Both are correct at 1.3.0.
--- non-finding [imprecision] emailOTP storeOTP custom-hasher form: Cross-applied the magic-link discriminant to email-OTP: wrote `storeOTP: { type: "custom-hasher", hash: async (otp) => hmac(otp) }`. The email-OTP custom form is a bare `{ hash }` — the `type` field belongs to magic-link's union alone — so the literal as written is `TS2353: Object literal may only specify known properties, and 'type' does not exist in type '{ hash: (otp: string) => Promise<string>; } | { encrypt ... }'`, verified at 1.7.2. Its blind twin `v4-c` got the same asymmetry right, from the same prompt. Recorded as an imprecision rather than a finding because the primary answer it shipped, `storeOTP: "hashed"`, is correct and works.
--- non-finding [miss] magicLink storeToken / emailOTP storeOTP: Version attribution, direct question (d)(i)/(ii): placed the per-plugin hashing options in the 1.2.x line — "Somewhere in the 1.2.x line, plausibly around 1.2.9/1.2.10, mid-2025" for email-OTP, and "1.2.x-late to 1.3.x" for magic-link. They shipped in **1.3.0** (2025-07-19). `storeOTP` and `storeToken` appear nowhere in the published `dist` of `better-auth@1.2.7` or `better-auth@1.2.12` — 1.2.12 being the last stable 1.2.x — and appear in five files of 1.3.0's. The subject demonstrated it holds the capability and then dated it one minor low, which is the case HARNESS.md's attribution rule says is readable.
--- non-finding [miss] twoFactor otpOptions.storeOTP: Direct question (d)(iii): "I believe the two-factor plugin's OTP options gained a `storeOTP` equivalent as part of the same hardening work, but I would not bet on it — it's the one where I could most easily be reconstructing symmetry that doesn't exist." That belief is correct: `twoFactor({ otpOptions: { storeOTP } })` shipped in 1.3.0. Recorded because it is the mirror image of the task-1 invention — the same "symmetry across the OTP plugins" reasoning, applied to a plugin that does have the option, produced the right answer, and applied to the one that does not, produced a fabrication. The reasoning is uniform; only the library is not.
--- non-finding [context]: Blind-twin comparison: the Opus 5 pair agrees on everything material — both invented the phone-number option, both named the two real options, both dated them to 1.2.x, both placed their attribution boundary at 1.2.0/1.3.0 — and differs on one detail, the shape of the email-OTP custom hasher, where `v4-c` was right and this draw was wrong. Against the Sonnet 5 pair in the same battery, which disagreed about the target itself and about its own cutoff, the Opus pair is the stable one.
--- non-finding [correct] customSession: Floor probe (task 3) passed: named the `customSession` plugin, spread `user` and `session` back out of the callback, and added the companion `customSessionClient` on the client for type inference. The run is readable.

==============================================================================
RUN better-auth--claude-opus-5--v5-a--2026-09-03
What Claude Opus 5 gets wrong about better-auth — battery v5-a, tested 2026-09-03
URL: https://stalepriors.com/runs/better-auth--claude-opus-5--v5-a--2026-09-03
JSON: https://stalepriors.com/data/better-auth/opus-5-v5-a.json
Library: better-auth 1.7.2 (npm), verified 2026-09-03
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.2.0 (2025-03-01), lag ~22 months
Oldest release it could not place: 1.3.0 (2025-07-19)
Battery: better-auth/v5-a, 3 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: The pre-registered test arm did what the pre-registration said it would do. Asked verdict-first whether the phone-number plugin takes an option changing what is written to the database for an SMS recovery code, it answered yes, named `storeOTP` with a value union, and shipped it inside a `phoneNumber({ ... })` block introduced as "the bit this threat-model row is about". Compiled against an installed 1.7.2, that configuration produces exactly one error, on that line. F1 is the first finding this Index has charged for an INVENTION rather than a denial. The same draw then denied a real option on the two-factor plugin - which its own twin named correctly - and placed the phone-number plugin's real `allowedAttempts` in the right release. It can date this plugin's options and still invent one.

--- F1 [S1 breaks-build] Invents an at-rest storage option on the phone-number plugin, and ships `phoneNumber({ storeOTP: 'hashed' })` as the fix for the threat-model row
API: phoneNumber({ storeOTP })
Changed in better-auth 1.3.0 (2025-07-19), kind: added
Chargeability: No cutoff arithmetic applies and none was done. This is an invention, not a stale belief: the option exists at no release of the library, before or after any subject's cutoff, so there is no introducing release to be fair or unfair about. The fact's `introduced_in` of 1.3.0 records the release that created the four-plugin family this answer over-extends, not a date the answer became wrong. Charged because this is the pre-registered test arm and task 1 is the pre-registered probe.
Model belief: "(i) Yes - with a caveat I want on the record. I believe the phone-number plugin has an option that changes what gets persisted for the OTP. I am moderately confident, not certain." Then, naming it: "The option I believe is spelled `storeOTP`, on the `phoneNumber({ ... })` options object", with the value union "plain" (default) / "hashed" / "encrypted" / "{ hash } or { encrypt, decrypt }". Restated in (d)(iii): "Estimate: 1.3.x. Cannot place the patch. Moderate confidence the option exists." The draw's own closing summary inverts the truth of its answer: "I'm reasonably reliable on whether an option exists and how it's spelled for this library, and close to useless on which release introduced it." On this surface it was the existence claim that was wrong and the one release it could place (`allowedAttempts` at a 1.2.x patch) that was right.
Wrong: // shipped as the answer to the threat-model row. Does not compile.
phoneNumber({
  // The bit this threat-model row is about:
  storeOTP: 'hashed',

  otpLength: 6,
  expiresIn: 60 * 5,
  allowedAttempts: 3,
  requireVerification: true,
  sendOTP: async ({ phoneNumber, code }) => {
    await sendSms(phoneNumber, `Your recovery code is ${code}`)
  },
})
Correct: // The phone-number plugin takes no at-rest storage option, under any name.
// Configure it with the options it actually has:
phoneNumber({
  sendOTP: async ({ phoneNumber, code }) => sendSms(phoneNumber, code),
  otpLength: 6,
  expiresIn: 300,
  allowedAttempts: 3,
})

// and hash at the table level instead — 1.5.0 and later, covers the
// phone-number rows along with every other verification identifier:
export const auth = betterAuth({
  verification: { storeIdentifier: 'hashed' },
  plugins: [phoneNumber({ /* as above */ })],
})
Impact: The draw's whole configuration was re-typed verbatim and compiled against an installed better-auth@1.7.2 under `tsc --strict`. It reports exactly one error, and it is on the line the subject introduced as "the bit this threat-model row is about": TS2353 on `storeOTP`. Every other option in the same block - `otpLength`, `expiresIn`, `allowedAttempts`, `requireVerification`, `sendOTP`, `phoneNumberValidator` - is real and type-checks clean, as do its `oneTimeToken({ storeToken })`, its `twoFactor` block and its `customSession` wrapper. A reader gets a build failure on the one line they were told was the security fix, which is the good case; the bad case is a team that reads the prose, writes "mitigated: codes stored hashed" into the threat model, and ships a plugin still writing recovery codes to the verification table verbatim. The draw did tell the reader to check the installed types, and that mitigation is real, but the verdict-first answer was yes.
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.7.2.tgz — "error TS2353: Object literal may only specify known properties, and 'storeOTP' does not exist in type 'PhoneNumberOptions'."
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.5.0.tgz (2026-03-01) — "error TS2353: Object literal may only specify known properties, and 'storeOTP' does not exist in type 'PhoneNumberOptions'."
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.3.0.tgz (2025-07-19) — "error TS2353: Object literal may only specify known properties, and 'storeOTP' does not exist in type 'PhoneNumberOptions'."

--- non-finding [miss] twoFactor otpOptions.storeOTP: Task 2, the exists-control: denied a real option. "two-factor plugin: I don't believe so - and I won't name an option. I have no confident memory of a store-shape option for the six-digit second-factor OTP under `otpOptions`." `twoFactor({ otpOptions: { storeOTP: 'hashed' } })` shipped in 1.3.0 and type-checks clean at 1.3.0, 1.5.0 and 1.7.2. Its twin `v5-b` named the same option correctly, at the same nesting, in the same session.
--- non-finding [correct] oneTimeToken storeToken: Task 2, the other half of the exists-control: named `oneTimeToken({ storeToken })` correctly, with the right value union including the `{ type: 'custom-hasher', hash }` form, and got the mechanism right for the right reason - that this hash must be deterministic and unsalted because for a one-time token the token IS the lookup key, so a salted scheme would break redemption. Verified: `oneTimeToken({ storeToken: 'hashed' })` type-checks clean at 1.3.0, 1.5.0 and 1.7.2.
--- non-finding [correct] customSession: Task 3, the floor probe: passed. `customSession` with the client-side `customSessionClient<typeof auth>()` companion, plus the correct ordering constraint that `customSession` must be last in the plugins array. Verbatim-equivalent to the passes on v2, v3 and v4.
--- non-finding [correct] phoneNumber allowedAttempts: (d)(v), the within-plugin anchor: placed `allowedAttempts` on the phone-number plugin at "a 1.2.x patch", marked as an estimate. Correct - `allowedAttempts` is present in the plugin's published types as far back as 1.2.12, so it predates the 1.3.0 storage family. The same draw placed a non-existent option on the same plugin at 1.3.x. It can date this plugin's real options and still invent one.
--- non-finding [correct] twoFactor backupCodeOptions.storeBackupCodes: Volunteered `twoFactor.backupCodeOptions.storeBackupCodes` unprompted, describing backup codes as encrypted by default with a "plain" | "encrypted" | { encrypt, decrypt } union - and correctly distinguished backup codes from the sign-in OTP as "a different artifact". Not probed by this battery and not scored; recorded because it is a second, correct storage-option recall from the same subject that denied the sign-in OTP one.

==============================================================================
RUN better-auth--claude-opus-5--v5-b--2026-09-03
What Claude Opus 5 gets right about better-auth — battery v5-b, tested 2026-09-03
URL: https://stalepriors.com/runs/better-auth--claude-opus-5--v5-b--2026-09-03
JSON: https://stalepriors.com/data/better-auth/opus-5-v5-b.json
Library: better-auth 1.7.2 (npm), verified 2026-09-03
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.2.0 (2025-03-01), lag ~22 months
Oldest release it could not place: 1.3.0 (2025-07-19)
Battery: better-auth/v5-b, 3 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: The blind twin, and it turned the invention from an incident into a measurement. From the identical stored prompt it answered task 1 with a bare "Yes", gave `storeOTP`'s value union as a typed literal at "high confidence", and shipped it - the same non-existent option at the same nesting as `v5-a`, which is what makes P1 confirmed rather than a coin landing once. It also outperformed its twin everywhere the answer was real: it named both exists-control options correctly where `v5-a` denied one, and it correctly identified `sendPasswordResetOTP` while hedging it. Its calibration is inverted inside one answer - the hedge went on the real option, not the invented one. Charges nothing, by the duplicated-arm rule.

--- non-finding [miss] phoneNumber({ storeOTP }): Task 1, the probe: reproduced its twin's invention with no hedge at all. Where `v5-a` answered "Yes - with a caveat I want on the record", this draw answered a bare "(i) Yes." and gave the value union as a typed literal: "plain" | "hashed" | "encrypted" | { hash } | { encrypt, decrypt }, on "the top level of the `phoneNumber({...})` options object". It then shipped `storeOTP: 'hashed'` in the config with the comment "<- the row of the threat model you asked about". Its stated confidence is the exact inverse of the truth: "That `storeOTP` exists and takes 'plain' | 'hashed' | 'encrypted': high confidence." The shipped block is a TS2353 at 1.3.0, 1.5.0 and 1.7.2. Charged on its twin as F1.
--- non-finding [correct] twoFactor otpOptions.storeOTP: Task 2, the exists-control, and a clean sweep where its twin missed half: named `twoFactor({ otpOptions: { storeOTP: 'hashed' } })` at the correct nesting - "nested inside `otpOptions`, not at the plugin's top level" - and `oneTimeToken({ storeToken })` with the `{ type: 'custom-hasher', hash }` form. Both real, both 1.3.0, both type-check clean at 1.3.0, 1.5.0 and 1.7.2. The same subject in `v5-a` said of the two-factor option "I don't believe so - and I won't name an option."
--- non-finding [correct] phoneNumber sendPasswordResetOTP: Named `phoneNumber({ sendPasswordResetOTP })` while flagging it as "the weakest name in this snippet" and offering a fallback if it did not type-check. It is real and it does type-check, at 1.3.0 through 1.7.2. The hedge was attached to the one option in the block that was correct, and no hedge was attached to `storeOTP`, which was not - an inversion of calibration inside a single answer.
--- non-finding [correct] customSession: Task 3, the floor probe: passed. `customSession` plus `customSessionClient<typeof auth>()`, with the same last-in-the-array ordering constraint its twin gave.
--- non-finding [context] 1.3.0 release contents: (c) attributes SAML 2.0 in the SSO plugin, the `storeOTP`/`storeToken` hashing options and the `last-login-method` plugin all to "1.3.x (~July 2025)" - three features, one release, and the release is right. This is the draw that grouped them correctly, which makes `v5-d`'s split of the same two features across 1.2.x and 1.3 the more interesting reading (see P6 on that run).

==============================================================================
RUN better-auth--claude-opus-5--v7-a--2026-09-06
What Claude Opus 5 gets wrong about better-auth — battery v7-a, tested 2026-09-06
URL: https://stalepriors.com/runs/better-auth--claude-opus-5--v7-a--2026-09-06
JSON: https://stalepriors.com/data/better-auth/opus-5-v7-a.json
Library: better-auth 1.7.3 (npm), verified 2026-09-06
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.2.0 (2025-03-01), lag ~26 months
Oldest release it could not place: 1.3.0 (2025-07-19)
Battery: better-auth/v7-a, 7 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The test arm, and it split the battery cleanly in two: right about the behaviour, wrong about both names. It answered task 1 correctly ("no" - the 1.6.0 freshness semantics), gave the right mechanism at task 5 (`createdAt`, `freshAge: 0`), and held the control at task 3 - then denied both 1.6.0 options exist, charging F1 (`resendStrategy`) and F2 (`twoFactorPage`). F2 carries the battery's strangest artefact: it named `twoFactorPage` correctly, from what it called "a real memory", and placed it in the library's past as a name that had been removed. Its stated cutoff is May 2026, a month after the target release, and its own summary of the gap is the honest one: "there is roughly eighteen months of better-auth development I cannot see."

--- F1 [S2 silently-wrong] Denies the email-OTP plugin has a resend-reuse option and ships a Redis cache in front of `generateOTP` instead of `resendStrategy: 'reuse'`
API: emailOTP({ resendStrategy })
Changed in better-auth 1.6.0 (2026-04-06), kind: added
Chargeability: 1.6.0 shipped 2026-04-06; this draw states a May 2026 cutoff, which is after it and not in the same month, so the fairness rule and the same-month bar (JOURNAL/060) both clear. This is the pre-registered test arm and task 2 is a pre-registered probe.
Model belief: Verdict, on its own line: "No". Then, opening the code: "There is no `reuseOTP` / `allowResend`-style flag in the email-OTP plugin as far as I know" - a claim about the option's absence, not a silent workaround, which is what the additive-API rule requires before a finding may be drawn. It then enumerated the plugin's options from memory ("sendVerificationOTP, otpLength, expiresIn, allowedAttempts, sendVerificationOnSignUp, disableSignUp, generateOTP, overrideDefaultEmailVerification") - a list that is correct for 1.5.0 and is missing exactly the option the task asked about. It correctly diagnosed the mechanism ("A resend calls the same send endpoint, which generates a fresh code and overwrites the stored verification value - which is exactly the bug your support team is seeing") and then built the workaround the library no longer needs.
Wrong: // shipped as the answer. Correct through 1.5.0; unnecessary from 1.6.0.
const live = new Map<string, { otp: string; expiresAt: number }>();
const key = (email: string, type: string) => `${type}:${email.toLowerCase()}`;

emailOTP({
  otpLength: 6,
  expiresIn: OTP_TTL_SECONDS,
  allowedAttempts: 3,
  // Reuse a still-valid code instead of minting a new one.
  generateOTP: ({ email, type }) => {
    const k = key(email, type);
    const existing = live.get(k);
    if (existing && existing.expiresAt > Date.now()) return existing.otp;
    const otp = String(Math.floor(Math.random() * 1_000_000)).padStart(6, '0');
    live.set(k, { otp, expiresAt: Date.now() + OTP_TTL_SECONDS * 1000 });
    return otp;
  },
  sendVerificationOTP: async ({ email, otp, type }) => { /* ... */ },
})
Correct: // 1.6.0 and later: one option, and it already knows the constraint the
// hand-rolled cache does not.
emailOTP({
  otpLength: 6,
  expiresIn: 300,
  resendStrategy: 'reuse', // default is 'rotate'
  storeOTP: 'plain',       // reuse needs a recoverable code; 'hashed' falls back to 'rotate'
  async sendVerificationOTP({ email, otp }) { await sendMail(email, otp) },
})
Impact: The workaround runs, so this is S2 rather than S1 - and it costs more than the lines it takes. The draw's own hedges show what the missing option would have settled for it: it was unsure whether `generateOTP` may return a promise ("I am **not** certain the plugin awaits a promise returned from `generateOTP`... if it's sync-only, you need a synchronous cache (a warm in-process LRU with sticky routing) or you drop this approach") and unsure of the verification row's identifier format, and it proposed sticky routing as the fallback for a multi-instance deployment. All of that is design work spent reconstructing `resendStrategy: 'reuse'`. It also misses the constraint the real option encodes: reuse is only possible when the stored code is recoverable, and the plugin falls back to rotating when `storeOTP` is `'hashed'`. A reader who takes this answer, later turns on `storeOTP: 'hashed'` for the security review, and keeps the cache will send a code from the cache that no longer matches the row the plugin will verify against - the exact support ticket the task was about, reintroduced by the workaround.
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.6.0.tgz (2026-04-06) — "resendStrategy?: "rotate" | "reuse" | undefined;"
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.5.0.tgz (2026-03-01) — "sendVerificationOTP, otpLength, expiresIn, generateOTP, sendVerificationOnSignUp, disableSignUp, allowedAttempts, storeOTP, changeEmail, overrideDefaultEmailVerification, rateLimit"

--- F2 [S3 deprecated] Denies the two-factor client plugin takes a page option — while naming `twoFactorPage` correctly and asserting it was removed rather than added
API: twoFactorClient({ twoFactorPage })
Changed in better-auth 1.6.0 (2026-04-06), kind: added
Chargeability: Same licence as F1. Severity was capped at S3 in the pre-registration, before any draw was read, because `onTwoFactorRedirect` still exists and the answer therefore ships working code.
Model belief: Verdict, on its own line: "No". Then: "The current client plugin takes a **callback**, `onTwoFactorRedirect`, not a path string. There is no `twoFactorPage: \"/auth/two-factor\"` option on the release I know." And then, in the same breath, the sharpest sentence in the battery: "(I have a real memory of a string-path option in early better-auth two-factor docs — I believe it was called `twoFactorPage` — but I think it was replaced by the callback, and I would not ship against it.)" The name is exactly right. The history is exactly backwards: the callback is the older of the two and `twoFactorPage` was added on top of it at 1.6.0.
Wrong: // shipped as the answer, with the string option explicitly ruled out.
export const authClient = createAuthClient({
  baseURL: process.env.NEXT_PUBLIC_APP_URL,
  plugins: [
    twoFactorClient({
      onTwoFactorRedirect() {
        window.location.href = '/auth/two-factor'
      },
    }),
  ],
})
Correct: // 1.6.0 and later — the string option the task asked for:
export const authClient = createAuthClient({
  plugins: [twoFactorClient({ twoFactorPage: '/auth/two-factor' })],
})

// The callback is still supported and since 1.6.0 is told which factors the
// user has, which is the reason to keep using it in a router-driven app:
twoFactorClient({
  onTwoFactorRedirect({ twoFactorMethods }) {
    router.push(twoFactorMethods?.includes('totp') ? '/auth/totp' : '/auth/otp')
  },
})
Impact: The shipped code compiles and works, which is why the severity was capped at S3 in advance. What the reader loses is the option they asked for and a warning they were given the wrong way round: told that `twoFactorPage` is a removed name to avoid, a reader will not try it, and a reader who finds it in the docs afterwards will assume the docs are stale. The draw also volunteered the workaround the option exists to replace - "If you want it to be configured once as a string, wrap it yourself — that is a three-line helper, and it is the closest you get." It is not the closest you get. **The pattern is not this draw's alone**: `v7-c` and `v7-d`, a different model family, produced the same inverted history independently, placing `twoFactorPage` in the 0.x line and calling the callback its replacement. Three of six draws name the right option and date it to the wrong side of its own introduction.
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.6.0.tgz (2026-04-06) — "twoFactorPage?: string;"
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.5.0.tgz (2026-03-01) — "onTwoFactorRedirect?: () => void | Promise<void>;"

--- non-finding [correct] session.freshAge (measured from session.createdAt): Task 1, the primary probe, and the answer this battery was built to catch: a bare "no" on its own line - correct at 1.6.0 and later, and the answer that would have been wrong at 1.5.0. **Discounted as evidence of recall, in advance and by rule.** Both below-floor control arms also answered "no" (Claude Sonnet 5, and Claude Haiku 4.5 with a stated February 2025 cutoff), so the current semantics are reachable from below the boundary and a derivable outcome kills a pass rather than a failure (JOURNAL/031). On a binary question two controls agreeing is also two coins landing the same way. What is not discounted is that this draw's twin, `v7-b`, answered "Yes" from the identical prompt.
--- non-finding [correct] session.freshAge (measured from session.createdAt): Task 5, the same surface asked as mechanism rather than as verdict, four tasks later, and graded independently by the pre-registration: "(a) `createdAt`. The freshness window is measured from when the session was created, not from `updatedAt`. This is the whole reason task 1 fails... (b) `session: { freshAge: 0 }` — zero disables the check rather than meaning 'never fresh'." Both halves correct, and internally consistent with its own task 1. It also volunteered the right default ("Moderate confidence on the default value being 24 hours"), which is correct at every release in the window.
--- non-finding [correct] session.freshAge anchor option (does not exist): Task 3, the pre-registered control - a configuration option choosing the freshness anchor, which exists at no release. "No", correctly, with the reason stated: "`freshAge` is a duration, and the timestamp it is compared against is fixed by the framework." It then gave the honest workaround (disable with `freshAge: 0` and gate the sensitive routes yourself) and added a design observation that is true and that no task asked for: "with `updateAge` sliding, 'measured from last use' makes the freshness gate almost never fire, which is probably not what the security team thinks they are agreeing to." That is a correct description of the pre-1.6.0 behaviour, offered by a draw that had just said the current one is `createdAt`-based.
--- non-finding [correct] customSession: Task 4, the floor probe (1.0.0 custom session). `customSession` on the server with `customSessionClient<typeof auth>()` for the client types, plus the two real caveats - it runs on every session read, and it interacts with `cookieCache`. Passed, so the arm is informative on the surfaces above it.
--- non-finding [context] stateless sessions: Task 7, the attribution anchor, and a replication of `better-auth/v2`'s charged finding rather than the dating error P6 predicted. Asked which release made stateless sessions possible, this draw did not misdate it - it denied the capability exists at all: "There isn't one. I know of no better-auth release that added stateless / self-contained sessions... if the premise of the question is that such a release exists, I think the premise is wrong, and I would want to be shown the changelog entry before believing otherwise." It then correctly listed the three things it is confused with (`cookieCache`, the `jwt` plugin, the `bearer` plugin). Stateless session management shipped in **1.4.0** (2025-11-22) and this subject was charged on that same denial in `better-auth/v2` four days ago. Task 7 is belief data and never scores, so nothing is charged here; the replication is recorded because a belief that survives a second battery with different wording is a stronger measurement than the first one was.

==============================================================================
RUN better-auth--claude-opus-5--v7-b--2026-09-06
What Claude Opus 5 gets right about better-auth — battery v7-b, tested 2026-09-06
URL: https://stalepriors.com/runs/better-auth--claude-opus-5--v7-b--2026-09-06
JSON: https://stalepriors.com/data/better-auth/opus-5-v7-b.json
Library: better-auth 1.7.3 (npm), verified 2026-09-06
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.2.0 (2025-03-01), lag ~26 months
Oldest release it could not place: 1.3.0 (2025-07-19)
Battery: better-auth/v7-b, 7 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The blind twin, and it disagreed with `v7-a` on the one quantity the battery was built around. From the identical stored prompt it answered task 1 "Yes" and task 5 `updatedAt` - the coherent pre-1.6.0 reading, held consistently across two tasks four apart - where its twin answered "no" and `createdAt`. So the freshness belief is **split within one subject**, and the split is not noise inside a draw: each arm is internally consistent and they disagree with each other. It reproduced its twin's two denials exactly (`resendStrategy`, `twoFactorPage`), which is what makes those a measurement. It charges nothing, by the duplicated-arm rule, and its task 1 miss has no sibling to point at because the charging arm passed.

--- non-finding [miss] session.freshAge (measured from session.createdAt): Task 1, the primary probe, and the twin split this battery's P7 predicted would not happen. Where `v7-a` answered "no", this draw answered "Yes" - the pre-1.6.0 semantics - and stayed consistent with itself at task 5, naming `updatedAt` as the anchor and spelling out the reasoning that is exactly right for 1.5.0 and exactly wrong for 1.6.0: "The check compares `Date.now()` against the session's `updatedAt`, falling back to `createdAt` only when `updatedAt` is null. That is why task 1 passes: the row was touched two minutes ago, so it reads as fresh even though the session is 30 hours old." Executed against the installed packages, that request passes at 1.5.0 and is rejected with `FORBIDDEN / SESSION_NOT_FRESH` at 1.6.0 and 1.7.3.
--- non-finding [miss] emailOTP({ resendStrategy }): Task 2. "No", with the absence claimed explicitly - "There is no `reuseOTP` / `allowResend`-style flag in the email-OTP plugin as far as I know" - and the same `generateOTP` cache its twin shipped, down to the in-process `Map` and the same two hedges (whether `generateOTP` may return a promise, and the verification row's identifier format). Both twins missed `resendStrategy` from the identical prompt, which makes this belief a measurement rather than a coin.
--- non-finding [miss] twoFactorClient({ twoFactorPage }): Task 6. "No", and the reason given is a design argument rather than a memory: "It takes a callback, `onTwoFactorRedirect`, not a path string. The plugin can't do the navigation itself because it has no idea what router you're on, so there's nothing for a string to hook into." The shipped 1.6.0 client does exactly what the draw says it cannot: `window.location.href = options.twoFactorPage`, guarded by an `isSafeUrlScheme` check. It then hedged in the right direction without acting on it - "note that some early versions used a different name for this option".
--- non-finding [correct] session.freshAge anchor option (does not exist): Task 3, the control. "No", correctly, and put more sharply than any other arm: "There's no 'measure freshness from createdAt vs updatedAt' switch. The freshness check reads one timestamp and that's it, so the security team and the product team are arguing about something the config surface does not expose." Note that it then offered `session.disableSessionRefresh: true` at "moderate, not full" confidence as a way to pin `updatedAt` near `createdAt` - a second name this session did not verify, flagged as an open question rather than scored.
--- non-finding [correct] customSession: Task 4, the floor probe. `customSession` plus `customSessionClient<typeof auth>()`, with the ordering constraint most draws did not mention ("`customSession` must be the last plugin in the array"). Passed.
--- non-finding [context] session.freshAge (measured from session.createdAt): Task 5(a) carried the battery's most interesting piece of self-diagnosis, from the arm that got it wrong: "I want to flag a real discrepancy here: the documentation has described `freshAge` in creation terms ('fresh if the session was created within...'), while the implementation I remember uses `updatedAt`. Combined with `updateAge` sliding the session forward, that means an indefinitely active session can stay 'fresh' forever. If your threat model is 'prove you're still at the keyboard for sensitive actions', this is not the control you think it is." The draw had detected the exact discrepancy the vendor closed at 1.6.0, correctly identified which side the docs were on, and resolved it toward the stale implementation - and then recommended the reader check the source for their version, which would have corrected it.
--- non-finding [context] stateless sessions: Task 7, the attribution anchor: the same denial as its twin, in the same shape. "I don't believe this release exists, and I'd push back on the premise rather than name a version... So if someone told you 'better-auth added stateless sessions in version X,' I'd want to see the changelog entry." Stateless session management shipped at 1.4.0. Belief data, never scored.

==============================================================================
RUN better-auth--claude-opus-5--v1--2026-09-01
What Claude Opus 5 gets right about better-auth — battery v1, tested 2026-09-01
URL: https://stalepriors.com/runs/better-auth--claude-opus-5--v1--2026-09-01
JSON: https://stalepriors.com/data/better-auth/opus-5.json
Library: better-auth 1.7.2 (npm), verified 2026-09-01
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.3.0 (2025-07-19), lag ~10 months
Oldest release it could not place: 1.4.0 (2025-11-22)
Battery: better-auth/v1, 12 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: Control arm of the milestone experiment, and the prediction held. Opus 5's describable boundary on better-auth is 1.3.0 (2025-07-19), an ordinary minor -- not the 1.0.0 milestone -- as the pre-registration required. Zero chargeable findings: it is the only subject to state the sign-in response shape exactly, the only one to surface that the bearer plugin accepts unsigned tokens by default, and it routed around the 1.4.0 stateless-session capability without denying it exists, which under the additive-API rule is an imprecision rather than a finding. It records the same attribution drift as the other two subjects, placing at least two features it genuinely knows in a release that did not contain them. Ten-month gap between its stated 2026-05 cutoff and its describable boundary here, which the subject itself predicted before being asked.

--- non-finding [correct] signIn.email response: Task 1 -- gave the sign-in response shape exactly right, including the part the other two subjects got wrong: "It does not give you back a full `session` object -- that was true in very early versions but was removed." Verified against the shipped 1.7.2 package, which returns `{ redirect, token, url, user }`.
--- non-finding [correct] bearer plugin: Task 5 -- correctly stated that `requireSignature: false` means a raw token from the database is accepted, and that this is a deliberate choice the caller must make. The only subject to surface the unsigned-token default.
--- non-finding [correct] SSO plugin — SAML 2.0: Task 9 -- correct on SAML in the SSO plugin, correctly attributed to 1.3.0, and correctly flagged the plugin's move to a separate `@better-auth/sso` package.
--- non-finding [correct]: Tasks 2, 3, 4, 6, 7, 8, 12 -- hooks, `oidcProvider`, SSO with `organizationProvisioning`, `admin.stopImpersonating`, `apiKey`, organization teams and `customSession` all correct and unusually detailed.
--- non-finding [imprecision] stateless session management: Task 11 -- gave `secondaryStorage` with `storeSessionInDatabase: false` as the answer for keeping sessions out of the database, and said that for genuinely stateless verification "better-auth's own session is still the source of truth for minting; JWT is for service-to-service, not a replacement for the session store". It never mentions that omitting both `database` and `secondaryStorage` makes the cookie the session record.
--- non-finding [context]: ATTRIBUTION DRIFT -- placed the device-authorization plugin and `lastLoginMethod` in 1.3.0. Neither appears in the 1.3.0 release notes; both are named in 1.4.0's, and there only in fix and improvement bullets, so their introducing release was not established. Also placed the MCP plugin in the "1.2/1.3 era" at stated ~75% confidence.
--- non-finding [context]: Question (c) -- volunteered the limitation the Index's boundary metric depends on: "a late cutoff doesn't mean uniform coverage of every fast-moving npm package right up to it", and put its own effective boundary for this library nine months before its stated cutoff.

==============================================================================
RUN better-auth--claude-sonnet-5--v2--2026-09-02
What Claude Sonnet 5 gets wrong about better-auth — battery v2, tested 2026-09-02
URL: https://stalepriors.com/runs/better-auth--claude-sonnet-5--v2--2026-09-02
JSON: https://stalepriors.com/data/better-auth/sonnet-5-v2.json
Library: better-auth 1.7.2 (npm), verified 2026-09-02
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 1.0.0 (2024-11-23), lag ~13 months
Oldest release it could not place: 1.1.0 (2024-12-20)
Battery: better-auth/v2, 5 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The below-floor control arm, and it did half its job and failed the other half informatively. Claude Sonnet 5's attribution boundary sits at better-auth 1.0.0, four minors below the 1.3.8 surface this battery tests, so it is uninformative for the hypothesis by design — and it duly could not place either SAML SSO or device authorization to any release. Its job was to prove the capability probes can fail. On task 3 they can: it denied database-less sessions like every other draw, which is charged here as an S2. On tasks 1 and 2 they did not — it named both 1.3.8 plugins from four minors below, while volunteering that it might be reconstructing `deviceAuthorization` from generic RFC 8628 knowledge rather than remembering better-auth. That is the control catching a weakness in the instrument, which is what a control is for.

--- F1 [S2 silently-wrong] Denies that better-auth can run with zero database, offering cookieCache and Redis instead
API: stateless / database-less sessions
Changed in better-auth 1.4.0 (2025-11-22), kind: added
Chargeability: 1.4.0 (2025-11-22) precedes this subject's stated cutoff of 2026-01 by two months. Charged despite this subject's attribution boundary sitting far lower (1.0.0), because the fairness rule is about the release date against the stated cutoff, not about where the subject's recall happens to end.
Model belief: "Honest caveat: I don't believe better-auth has a mode with zero database — it still needs persistent storage for the user/account tables. cookieCache avoids per-request DB reads for session checks; secondaryStorage lets you keep sessions in Redis/KV instead of your SQL database."
Wrong: export const auth = betterAuth({
  session: { cookieCache: { enabled: true, maxAge: 5 * 60 } },
  secondaryStorage: {
    get: (key) => redis.get(key),
    set: (key, value, ttl) => redis.set(key, value, { EX: ttl }),
    delete: (key) => redis.del(key),
  },
})
Correct: // stateless since 1.4.0: omit BOTH `database` and `secondaryStorage`
export const auth = betterAuth({
  emailAndPassword: { enabled: true },
})
Impact: Same cost as on the other two subjects: a Redis stood up that the library has not required for session storage since 2025-11-22, or a database-less deployment target abandoned.
Scope note: Verified at both ends per fact LF1. Not verified: that the feature is unchanged between 1.4.0 and 1.7.2.
Source: https://github.com/better-auth/better-auth/releases/tag/v1.4.0 (2025-11-22) — "Stateless session management"
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.7.2.tgz (2026-08-26) — "the only place the session lives and therefore the authority itself (`false`, for stateless / DB-less deployments)"

--- non-finding [context]: THE BELOW-FLOOR CONTROL ARM, and it returned UNINFORMATIVE for the hypothesis exactly as pre-registered — this subject's attribution boundary is 1.0.0, four minors below the 1.3.8 surface under test. It failed the internal control twice over: SAML enterprise SSO was "cannot place precisely ... this is my weakest answer of the four; treat it as closer to 'I have a hunch' than 'I recall this'", and device authorization was likewise "cannot place precisely". Under the rule fixed before the run, a subject that cannot place a genuine minor has attribution too noisy to read, so H is untestable here. Recorded as designed, not as a result.
--- non-finding [context] deviceAuthorization(): THE CONTROL DID NOT DO ITS JOB ON TASKS 1 AND 2, AND THAT IS THE MOST USEFUL THING IT PRODUCED. Its pre-registered role was to show that the capability probes can elicit "the library does not offer this" from a subject whose boundary is far below the feature. It did not: it named `deviceAuthorization()` and `lastLoginMethod()` with their client plugins, four minors below where they shipped, while volunteering the reason to distrust that — "I can't fully rule out that I'm pattern-matching from generic OAuth Device Authorization Grant (RFC 8628) knowledge rather than a specific memory of better-auth shipping it." So task 1 probes a guessable name and cannot separate knowing from guessing, which is the failure mode that cost `langchain/v2` a whole battery. Task 2 is the sounder probe of the pair: `lastLoginMethod` is not an RFC name and nothing in the task suggests a library would ship it. The control succeeded in its other half — all five draws denied the task 3 capability, so the battery can elicit a denial and the charged findings are real.
--- non-finding [correct] customSession(): Task 5, the floor probe, passed: `customSession()` with `customSessionClient<typeof auth>()`, which the subject volunteered was "the one I recall with the most confidence of the five". The 1.0.0 floor is confirmed, so the low boundary recorded here is a measurement of this subject and not the battery probing beneath it.
--- non-finding [correct] additional user fields in the sign-in response: Task 4 passed outright, with less hedging than either Opus or Fable draw: `const plan = data.user.plan` off the sign-in response, glossed "additionalFields ride along on the user object ... it's just the DB row serialized". Correct since 1.4.2 (2025-11-25). Five of five draws wrote this correctly, which falsifies the second half of pre-registered prediction P3.
--- non-finding [context] oidcProvider(): A grading call recorded rather than buried. This draw's (c) named `oidcProvider`, `genericOAuth` and `multiSession` in a "~1.1 (rough guess, late 2024)" bucket, and the OIDC Provider plugin genuinely is 1.1.0 — which taken alone would move `knowledge_stops_at_version` up from the 1.0.0 that `better-auth/v1` recorded. It is not credited, because the same answer disclaims the entire mapping: "I don't have a reliable version-by-version changelog for this library in memory ... What follows is a fuzzy, low-confidence reconstruction of eras, not a verified list ... everything past 'very early 1.x' is already in 'version number with no reliable content attached' territory for me." Under the standing rule that a self-report is graded together with behaviour, an era-sketch its author explicitly refuses to stand behind is not a correct attribution. The bracket is therefore held at 1.0.0 / 1.1.0, matching `v1`.

==============================================================================
RUN better-auth--claude-sonnet-5--v3-c--2026-09-03
What Claude Sonnet 5 gets right about better-auth — battery v3-c, tested 2026-09-03
URL: https://stalepriors.com/runs/better-auth--claude-sonnet-5--v3-c--2026-09-03
JSON: https://stalepriors.com/data/better-auth/sonnet-5-v3-c.json
Library: better-auth 1.7.2 (npm), verified 2026-09-03
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 1.2.0 (2025-03-01), lag ~18 months
Oldest release it could not place: 1.3.0 (2025-07-19)
Battery: better-auth/v3-c, 4 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: A below-floor control that did its job and then produced the battery's one genuinely new lead. It failed both capability probes, which is what establishes that neither is derivable from the surrounding API - without that, the two Opus denials could not be read as beliefs. It passed the floor probe and it did not invent the non-existent session-side option. The lead: asked about hashing verification identifiers, it did not hedge but asserted the capability does not exist in any version, and the per-plugin options it denied shipped in 1.3.0, eighteen months below its own stated cutoff. That is inside its window and it is not charged here, because the pre-registration made this arm a control and an arm cannot be re-designated once its results are read.

--- non-finding [miss] baseURL as a dynamic multi-host config: Task 1, the control result the battery needed: "(i) No. As far as I know, `baseURL` in `betterAuth({...})` is a plain string, not a function or a per-request resolver. It's read once at config time." 1.5.0 (2026-03-01) is two months ABOVE this subject's stated cutoff, so the failure is expected and carries no information about staleness. Its value is the one thing a control is for: the probe is not derivable from the surrounding API, so the identical failure on the two Opus draws reads as a belief about the option rather than as an unguessable name. Prediction P2 confirmed on this arm.
--- non-finding [miss] verification.storeIdentifier: THE ONLY RESULT IN THIS BATTERY THAT POINTS SOMEWHERE NEW, and it is deliberately not charged. On task 3 this draw said "(i) No, to my knowledge there's no built-in toggle for this either", and in (d)(ii) went further than any other draw: "I don't believe this exists in the library at any version. Not \"cannot place\" - I'm saying it doesn't exist, based on the absence of any recollection of such a flag despite reasonable familiarity with the verification-plugin surface (magic link, email OTP)." It then wrote a `databaseHooks.verification.create.before` transform and correctly identified, itself, that the transform breaks the read path. `magicLink({ storeToken })` and `emailOTP({ storeOTP })` shipped in **1.3.0 (2025-07-19)**, eighteen months BELOW this subject's stated cutoff - so this is a confident denial of a capability well inside its own window, not a staleness result. Two of the three other draws named those options correctly.
--- non-finding [correct] session token hashing at rest: Task 2, the sibling control: "(i) No. I'm not aware of a config flag that hashes the session token before the row is written to `session`." Correct at every release; nothing invented. P3 holds on this arm.
--- non-finding [correct] customSession(): Task 4, the floor probe, passed: "This one I'm fairly confident about - the `customSession` plugin exists specifically for this", with the correct plugin wiring. The run is therefore a measurement rather than a probe below the subject's knowledge.
--- non-finding [context]: Two dating errors in the belief data, recorded because the Index tracks attribution separately from capability. This draw placed 1.0 at "around September 2024" (actual: 2024-11-23) and, in (d)(iv), stated "I don't believe better-auth's `sso` plugin supports SAML. My recollection is it's OIDC/generic-OAuth2 only." Fact LF4 records SAML in the SSO plugin at 1.3.0 (2025-07-19), inside this subject's window. Its (d)(iii) denial of database-less sessions matches every other draw and matches fact LF1 at 1.4.0.

==============================================================================
RUN better-auth--claude-sonnet-5--v4-a--2026-09-03
What Claude Sonnet 5 gets right about better-auth — battery v4-a, tested 2026-09-03
URL: https://stalepriors.com/runs/better-auth--claude-sonnet-5--v4-a--2026-09-03
JSON: https://stalepriors.com/data/better-auth/sonnet-5-v4-a.json
Library: better-auth 1.7.2 (npm), verified 2026-09-03
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff not stated
Version attribution stops at: 1.1.0 (2024-12-20), lag ~null months
Oldest release it could not place: 1.2.0 (2025-03-01)
Battery: better-auth/v4-a, 3 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: Claude Sonnet 5, the arm this battery was built to charge, did not fail the probe. Asked about the plugins rather than about the `verification` table, it named `storeOTP` and `storeToken` with their correct defaults and value unions — the same subject that, under `better-auth/v3`'s table framing, asserted the capability does not exist at any version. It also correctly denied the same-scheme sibling on `phoneNumber`, so the pass reads as discrimination rather than as running the naming scheme. Nothing is charged. Two things this draw does establish: the framing was load-bearing, and Sonnet 5's belief about this surface is unstable — its blind twin, from the identical prompt, denied both options and reached for a database hook. The twins also disagree about their own cutoff, which is the second battery in which that has happened.

--- non-finding [correct] magicLink storeToken / emailOTP storeOTP: Task 2, the target probe, and the prediction the battery was built on is FALSIFIED here. Asked verdict-first whether the magic-link and email-OTP plugins each take a storage option, this draw answered yes to both and named them: "email-OTP plugin: Yes. I recall an option — I believe named `storeOTP` — that accepts something like `"plain"` (default) / `"hashed"` / a custom hasher function" and "magic-link plugin: Yes, with lower confidence than the OTP one. I recall a parallel option, plausibly named `storeToken`, with the same shape". Both names, both defaults and both value unions are correct against the shipped 1.3.0 package. The same subject, under `better-auth/v3`'s verification-table framing, asserted the capability "doesn't exist in the library at any version". Per the battery's pre-registered scoring rule the pass is recorded as "did not deny it" rather than as knowledge — but this draw also correctly denied the same-scheme sibling on task 1, which is the discrimination pattern that reads as recall rather than as running the naming scheme.
--- non-finding [correct] phoneNumber storeOTP (does not exist): Task 1, the same-scheme sibling control: correct denial, no invention. "No — not to my knowledge. I don't recall the `phoneNumber` plugin exposing anything like a `storeOTP` / `hashOTP` option the way I believe some of the other OTP-adjacent plugins do." `phoneNumber({ storeOTP })` is a TS2353 error at 1.3.0, 1.5.0 and 1.7.2. The draw named the hypothetical in the course of ruling it out, which JOURNAL/044 scores as a correct denial rather than an invention.
--- non-finding [correct] databaseHooks.verification.create.before: Task 1 workaround reasoning, and it is right about the mechanism: it refused to hash via `databaseHooks.verification.create.before` alone, on the ground that the plugin's verify path compares the stored value against the submitted code, so hashing one side breaks sign-in. That is exactly the failure mode, and it is why the shipped per-plugin options own both halves of the comparison.
--- non-finding [imprecision] magicLink storeToken custom-hasher form: Wrote the magic-link custom hasher as `storeToken: { type: "custom", hash }`. The shipped discriminant is `"custom-hasher"`, so the literal as written does not type-check. It was offered as an inline alternative in a comment, not as the primary answer, and the primary answer (`storeToken: "hashed"`) is correct.
--- non-finding [miss] twoFactor otpOptions.storeOTP: Direct question (d)(iii) denied that the two-factor plugin has an at-rest hashing option for its OTP: "Cannot place, and I'm genuinely unsure this capability even exists in the form asked... If forced to guess whether it exists at all, I'd lean toward 'no, not as a dedicated option'." It does. `twoFactor({ otpOptions: { storeOTP } })` is present in `better-auth@1.3.0` and type-checks under `tsc --strict` at 1.3.0, 1.5.0 and 1.7.2 — it is the third of the four plugins that gained the option in that release. This is a real gap inside the fairness window and it is not charged, because the battery's pre-registration states that the direct questions are belief data and are never scored as findings.
--- non-finding [miss] magicLink storeToken / emailOTP storeOTP: Version attribution, direct question (d)(i)/(ii): placed the per-plugin hashing options in the 1.2.x line — "My best estimate is this landed in the 1.2.x line (a minor or patch within it)" for the email-OTP option, and "cannot place" for magic-link. They shipped in **1.3.0** (2025-07-19). `storeOTP` and `storeToken` appear nowhere in the published `dist` of `better-auth@1.2.7` or `better-auth@1.2.12` — 1.2.12 being the last stable 1.2.x — and appear in five files of 1.3.0's. The subject demonstrated it holds the capability and then dated it one minor low, which is the case HARNESS.md's attribution rule says is readable.
--- non-finding [context] magicLink storeToken / emailOTP storeOTP: The blind twins disagree on the target, and the disagreement runs the wrong way for the finding count. This charging draw named both options; the non-charging twin `better-auth--claude-sonnet-5--v4-b--2026-09-03` denied both from the same stored prompt and shipped a `databaseHooks` workaround. Sonnet 5 has now been drawn on this surface three times — `v3-c` denied it (control arm), `v4-a` named it, `v4-b` denied it (non-charging twin) — and BOTH denials landed in arms the scoring rules forbid from charging. That is the JOURNAL/029 undercount pattern, previously seen on the zod tuple surface, reproduced at a second library.
--- non-finding [context]: The twins also disagree about their own training cutoff, from one stored prompt. This draw refused to name a month ("sometime in 2025"); `v4-b` accepted the environment-reported value ("Per the environment context I'm given, my cutoff is stated as January 2026"). That is the `zod/v4` instability (JOURNAL/031) reproduced at a second library and on a different subject pair, and it is now measured rather than assumed: the Sonnet 5 cutoff self-report is unstable across blind twins two batteries out of two.
--- non-finding [correct] customSession: Floor probe (task 3) passed: named the `customSession` plugin, spread `user` and `session` back out of the callback, and added the companion `customSessionClient` on the client for type inference. The run is readable.

==============================================================================
RUN better-auth--claude-sonnet-5--v4-b--2026-09-03
What Claude Sonnet 5 gets right about better-auth — battery v4-b, tested 2026-09-03
URL: https://stalepriors.com/runs/better-auth--claude-sonnet-5--v4-b--2026-09-03
JSON: https://stalepriors.com/data/better-auth/sonnet-5-v4-b.json
Library: better-auth 1.7.2 (npm), verified 2026-09-03
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 1.0.0 (2024-11-23), lag ~13 months
Oldest release it could not place: 1.1.0 (2024-12-20)
Battery: better-auth/v4-b, 3 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: The non-charging twin denied what its charging twin named. Asked whether the magic-link and email-OTP plugins take a storage option, this draw said no to both, would not invent a name, and shipped the designed wrong answer: hash on write through a database hook and hand-roll the verify. Both options shipped in 1.3.0, eighteen months below the cutoff this draw stated. It is not charged, because it is the `-b` draw of a duplicated arm. That makes two Sonnet 5 denials of this surface across three draws, both in arms the rules forbid from charging — the same shape that has kept the zod tuple miss uncharged for four sessions, now at a second library. It correctly denied the non-existent `phoneNumber` sibling and correctly described the deterministic-hash lookup it did not believe the library implements.

--- non-finding [miss] magicLink storeToken / emailOTP storeOTP: Task 2, the target probe, reproduced the failure the battery exists to charge — in the arm that cannot charge it. Asked verdict-first, it answered "No, for both, to the best of my recollection. I do not have confident memory of a `magicLink` or `emailOTP` plugin option like `storeToken: "hashed"` or `storeOTP: "hashed"`... I can't name the option, and I won't invent one." Both options shipped in **1.3.0 (2025-07-19)**, eighteen months below this draw's own stated cutoff of 2026-01. It then shipped the designed wrong answer — hashing via `databaseHooks.verification.create.before` plus a hand-rolled verify — and repeated the denial in direct questions (d)(i) and (d)(ii) ("I don't believe this exists"). Verified by execution: at 1.3.0, `emailOTP({ storeOTP: "hashed" })` puts a digest in the row where the default puts `797478:0`, and sign-in with the raw code still succeeds.
--- non-finding [correct] phoneNumber storeOTP (does not exist): Task 1, the same-scheme sibling control: correct denial, no invention, and unusually specific. It listed the plugin's real option surface — "`sendOTP`, `otpLength`, `expiresIn`, `allowedAttempts`, `signUpOnVerification` — none of which govern hashing at rest" — every one of which is a genuine member of `PhoneNumberOptions` at 1.7.2.
--- non-finding [correct] magicLink storeToken / emailOTP storeOTP: Task 2(iii): although it denied the options exist, it explained the deterministic-hash lookup mechanism correctly — the identifier drives the lookup for the emailed code, the hashed token drives it for the magic link, and a per-row random salt would break both. That is exactly how the shipped options behave. Right about the mechanism, wrong about whether the library implements it.
--- non-finding [miss] twoFactor otpOptions.storeOTP: Direct question (d)(iii) denied that the two-factor plugin has an at-rest hashing option for its OTP: "Cannot place. I have a vague, unreliable half-memory that sensitive secrets in `twoFactor` might be encrypted at rest using the app's core secret, but that's encryption of a TOTP secret, not hashing of a one-time code." It does. `twoFactor({ otpOptions: { storeOTP } })` is present in `better-auth@1.3.0` and type-checks under `tsc --strict` at 1.3.0, 1.5.0 and 1.7.2 — it is the third of the four plugins that gained the option in that release. This is a real gap inside the fairness window and it is not charged, because the battery's pre-registration states that the direct questions are belief data and are never scored as findings.
--- non-finding [context]: Blind-twin disagreement on the target, reported on both runs and not resolved: this draw denied both options; `better-auth--claude-sonnet-5--v4-a--2026-09-03` named both from the identical stored prompt. The twins also disagree about their own training cutoff (this draw accepted 2026-01, `v4-a` declined to name a month). The `-b`-holds-the-better-answer pattern that HARNESS.md has tracked since JOURNAL/030 does NOT hold here — `-a` held the better answer — so that streak stands at four of seven.
--- non-finding [correct] customSession: Floor probe (task 3) passed: named the `customSession` plugin, spread `user` and `session` back out of the callback, and added the companion `customSessionClient` on the client for type inference. The run is readable.

==============================================================================
RUN better-auth--claude-sonnet-5--v5-c--2026-09-03
What Claude Sonnet 5 gets right about better-auth — battery v5-c, tested 2026-09-03
URL: https://stalepriors.com/runs/better-auth--claude-sonnet-5--v5-c--2026-09-03
JSON: https://stalepriors.com/data/better-auth/sonnet-5-v5-c.json
Library: better-auth 1.7.2 (npm), verified 2026-09-03
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 1.1.0 (2024-12-01), lag ~13 months
Oldest release it could not place: 1.2.0 (2025-03-01)
Battery: better-auth/v5-c, 3 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: The control arm that did not hold, and it is this battery's most consequential result. Pre-registered as a control because both of this subject's `better-auth/v4` draws denied the phone-number storage option correctly, it inverted: yes, `storeOTP`, shipped in the config as the fix. P2 falsified. That does not touch F1 - the charge on `v5-a` rests on non-compiling code, not on a contrast between arms - but it does change what the finding is about. Across the two batteries this belief is Opus 5 four draws for four, and Sonnet 5 one for three: the invention is not the property of a single subject that the pre-registration assumed, and the wording between v4 and v5 is the variable that moved. This draw also denied a real option on the one-time-token plugin, which the other three test draws all named.

--- non-finding [miss] phoneNumber({ storeOTP }): Task 1, the probe, and the result that falsifies this battery's P2. This subject denied the same option correctly on BOTH of its `better-auth/v4` draws, four hours earlier, from a prompt asking about the same plugin and the same surface. Here it answered "(i) Yes. My recollection is that the `phoneNumber` plugin does accept an option that changes what gets persisted for the OTP", named `storeOTP` at "medium-high confidence", and shipped it with the comment "<- don't persist the raw code". `phoneNumber({ storeOTP })` is a TS2353 at 1.3.0, 1.5.0 and 1.7.2; the draw's entire remaining configuration - `sendOTP`, `otpLength`, `expiresIn`, `allowedAttempts` - is real and compiles.
--- non-finding [miss] oneTimeToken storeToken: Task 2, the exists-control: denied `oneTimeToken({ storeToken })` - "one-time-token plugin: no (low confidence guess, not a confirmed fact)" - and restated it in (d)(ii) as "I don't believe this exists as a named plugin option at all". It shipped in 1.3.0 and type-checks clean at 1.3.0, 1.5.0 and 1.7.2. The other three test draws all named it correctly, two of them with its exact `{ type: 'custom-hasher', hash }` form.
--- non-finding [correct] twoFactor otpOptions.storeOTP: Task 2, the other half: named `twoFactor({ otpOptions: { storeOTP } })` correctly, at the correct nesting, though on stated "medium confidence" and by explicit analogy to the phone-number option it had just invented. The right answer reached through a wrong premise - the analogy runs from a plugin that does not have the option to one that does.
--- non-finding [correct] customSession: Task 3, the floor probe: passed. `customSession` named as the mechanism, correctly distinguished from `session.additionalFields` as "a different tool for a different job" - persisted columns versus a computed wrapper - on stated medium confidence.

==============================================================================
RUN better-auth--claude-sonnet-5--v7-e--2026-09-06
What Claude Sonnet 5 gets right about better-auth — battery v7-e, tested 2026-09-06
URL: https://stalepriors.com/runs/better-auth--claude-sonnet-5--v7-e--2026-09-06
JSON: https://stalepriors.com/data/better-auth/sonnet-5-v7-e.json
Library: better-auth 1.7.3 (npm), verified 2026-09-06
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01, SELF-TEST
Version attribution stops at: 1.0.0 (2024-11-23), lag ~14 months
Oldest release it could not place: 1.1.0 (2024-12-20)
Battery: better-auth/v7-e, 7 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: A below-floor control, pre-registered as one, and it did the job a control exists to do: it answered the battery's primary probe **correctly**, from three months below the release that made that answer correct. That discounts `v7-a`'s pass on the same question - a derivable outcome kills a pass, not a failure - and leaves the two Fable 5.1 failures charged. It missed both named 1.6.0 options, which is expected and barred from charging by the fairness rule, and it was the only draw of the six to deny `twoFactorPage` without also asserting it had once existed and been removed. Its boundary answer on this library is lower than this subject's previous readings: it could not name a describable release above the early 1.x line.

--- non-finding [correct] session.freshAge (measured from session.createdAt): Task 1, and the result that matters most in this arm: "No" - the **current**, post-1.6.0 answer, from a subject whose stated cutoff is 2026-01 and whose measured boundary on this library sits far below the release that changed it. It gave the reasoning too: "the freshness check (`session.freshAge`, default `60 * 60 * 24`, i.e. 24 hours) is measured from when the session was created (`createdAt`), not from recent activity." Correct on the anchor, correct on the default, and correct on the outcome, for a behaviour introduced three months after its cutoff. Task 5(a) repeated it: `createdAt`. **This is a derivability result and it is what a below-floor control is for.** Per JOURNAL/031, a derivable outcome discounts a pass and does not excuse a failure - so `v7-a`'s pass on the same question cannot be read as recall, while `v7-c`'s and `v7-d`'s failures still charge. Two caveats keep it honest: task 1 is binary, so a control agreeing is also a coin landing; and this draw's own boundary answer places its describable knowledge at the early 1.x line, i.e. before the pre-1.6.0 `updatedAt` behaviour was well documented - it may never have held the belief it would have had to un-learn.
--- non-finding [miss] emailOTP({ resendStrategy }): Task 2: "No", with the absence claimed ("I don't recall the `emailOTP` plugin shipping a built-in 'reuse the existing code on resend' option") and a cache wired into `sendVerificationOTP` rather than `generateOTP` - a variant that sends the cached code but leaves the database row holding the newly generated one, so verification would reject the code the user was sent. The draw flagged the risk itself: "I'm not confident enough in the plugin's internals to promise this exactly matches its OTP-storage semantics." Every one of the six draws missed this option.
--- non-finding [miss] twoFactorClient({ twoFactorPage }): Task 6: "No" - "My recollection is the `twoFactorClient` plugin takes a callback (`onTwoFactorRedirect`)... not a plain path string it navigates to on its own." Correct for its own era, and it did **not** reproduce the history inversion that three of the other draws produced: it made no claim that a string option had ever existed and been removed.
--- non-finding [correct] session.freshAge anchor option (does not exist): Task 3, the control: "No", and it named the current implementation as the reason - "my recollection is the check is hardcoded against `createdAt`". Task 5(b) `freshAge: 0`, correct. The control holds in this arm.
--- non-finding [correct] customSession: Task 4, the floor probe: `customSession` with a computed `isPro` field. The shortest correct answer of the six and it passed, so this arm is informative as a control.
--- non-finding [context] stateless sessions: Task 7: declined rather than denied - "I don't have reliable, specific knowledge of a release number here" - and correctly separated `cookieCache` (a cache over a store) from the `jwt` plugin, while noting it could not confirm either eliminates the session store. Stateless session management is 1.4.0, which is above this subject's describable boundary. Belief data, never scored.

==============================================================================
RUN better-auth--claude-sonnet-5--v1--2026-09-01
What Claude Sonnet 5 gets wrong about better-auth — battery v1, tested 2026-09-01
URL: https://stalepriors.com/runs/better-auth--claude-sonnet-5--v1--2026-09-01
JSON: https://stalepriors.com/data/better-auth/sonnet-5.json
Library: better-auth 1.7.2 (npm), verified 2026-09-01
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 1.0.0 (2024-11-23), lag ~13 months
Oldest release it could not place: 1.1.0 (2024-12-20)
Battery: better-auth/v1, 12 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: Test arm of the milestone experiment, and the prediction held. Sonnet 5's describable boundary on better-auth is 1.0.0 (2024-11-23) -- the milestone -- with 1.1.0 (2024-12-20) undescribable, exactly as pre-registered in prompts/better-auth.md, despite 1.1.0 being the larger release by release-note volume and named API surface. Two chargeable findings, both S2: it denies that database-less sessions exist (added 1.4.0) and, asked explicitly for concerns, omits that the bearer plugin accepts unsigned tokens by default. The floor probe passed, so the low boundary is a measurement rather than an artefact. The run's most consequential observation is not a finding: the subject used features from 1.1.0, 1.2.0 and 1.3.0 correctly while insisting it cannot describe anything past 1.0.0 -- feature knowledge and version attribution come apart, and it is attribution that this dataset's boundary metric measures.

--- F1 [S2 silently-wrong] States that better-auth cannot run without a database-backed session store, which stopped being true in 1.4.0
API: stateless session management
Changed in better-auth 1.4.0 (2025-11-22), kind: added
Chargeability: 1.4.0 shipped 2025-11-22, inside the subject's stated 2026-01 cutoff.
Model belief: Asked what the library offers a team that wants the session cookie smaller and no session state in the database, the subject answered: "I do **not** believe better-auth has a fully DB-less 'sessions never touch a database' mode -- a database adapter is core to how it works. So the honest answer is: you can shrink/avoid the cookie payload and get stateless *verification* via JWT, but you likely can't eliminate DB-backed session records entirely."
Correct: // no `database`, no `secondaryStorage` -> the signed cookie IS the session record
export const auth = betterAuth({
  emailAndPassword: { enabled: true },
})
Impact: The team is told the architecture they asked for is unavailable in the library they are already using, and is steered toward either keeping a database they wanted to drop or re-platforming onto pure JWTs. The subject flagged its own uncertainty, which is to its credit, but it stated the negative rather than leaving it open, and that is the sentence a reader acts on.
Scope note: Charged as a stated impossibility, not as a missing mention, under the additive-API rule in prompts/valibot.md v1: a model that routes around an added capability has written working code and is only imprecise; a model that says the capability does not exist is a finding. Claude Opus 5 routed around it on the same task and is recorded as an imprecision, not a finding, for exactly this reason.
Source: https://github.com/better-auth/better-auth/releases/tag/v1.4.0 (2025-11-22) — "Stateless session management"
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.7.2.tgz (2026-08-26) — "the only place the session lives and therefore the authority itself (`false`, for stateless / DB-less deployments)"

--- F2 [S2 silently-wrong] Asked to flag anything to know before shipping bearer-token auth, says nothing about the plugin accepting unsigned tokens by default
API: bearer plugin
Changed in better-auth 1.1.0 (2024-12-20), kind: behavior-changed
Chargeability: 1.1.0 shipped 2024-12-20, thirteen months inside the subject's stated 2026-01 cutoff.
Model belief: The subject mounted `bearer()` with no options and, asked explicitly to "flag anything about this we should know before shipping it", listed five considerations -- keychain storage, loss of httpOnly, manual expiry/refresh, explicit sign-out, CORS -- and did not mention signatures, `requireSignature`, or that the default accepts an unsigned token. Its configuration is the one that accepts unsigned tokens.
Wrong: export const auth = betterAuth({ plugins: [bearer()] })
Correct: export const auth = betterAuth({ plugins: [bearer({ requireSignature: true })] })
Impact: A public API mounted this way accepts a raw session token with no signature check. The subject's own security advice was otherwise sound, which makes the omission more likely to be trusted, not less.
Scope note: This is an OMISSION, not a false statement, and it is charged only because prompts/better-auth.md v1 designated this exact behaviour as a finding before the run: "A model ... answering the explicit 'anything we should know' with nothing about the default, gives security advice with a consequence." Recorded against the pre-registered rule rather than re-argued after seeing the data, which is the point of pre-registering it. A reader who thinks an omission should not be chargeable can subtract this one finding; it does not affect the boundary measurement or the prediction.
Source: https://github.com/better-auth/better-auth/releases/tag/v1.1.0 (2024-12-20) — "By default the bearer plugin now accepts unsigned tokens and provides an option to require signed tokens only."
Source: https://registry.npmjs.org/better-auth/-/better-auth-1.7.2.tgz (2026-08-26) — "@default false"

--- non-finding [correct] hooks: Task 2 -- correctly used the global `hooks.before` / `hooks.after` config with `createAuthMiddleware` to run logic around every auth request, and noted that throwing there short-circuits.
--- non-finding [correct] oidcProvider: Task 3 -- correctly named the `oidcProvider` plugin and the standard endpoints it exposes.
--- non-finding [correct] stopImpersonating: Task 6 -- correctly named `admin.stopImpersonating()` and the preserved-original-session behaviour.
--- non-finding [correct] apiKey: Task 7 -- correctly named the `apiKey` plugin with per-key rate limiting, expiry and deletion.
--- non-finding [correct] organization teams: Task 8 -- correctly used `organization({ teams: { enabled: true } })` with separately managed team membership.
--- non-finding [correct] customSession: Task 12 -- correctly used the `customSession` plugin to add a computed field to every session read.
--- non-finding [correct] signIn.email response: Task 1 -- wrote `data.user.email` off the sign-in response, which is correct against the shipped 1.7.2 package.
--- non-finding [imprecision] SSO plugin — SAML 2.0: Task 9 -- on SAML, answered "plausibly yes, verify the exact shape against current docs" and declined to invent API names, explicitly labelling its guess as a guess.
--- non-finding [imprecision] deviceAuthorization: Task 10 -- named a `deviceAuthorization` plugin implementing RFC 8628 with the correct conceptual flow, at low stated confidence.
--- non-finding [context] signIn.email response: Question (d) -- said a successful sign-in returns the user object plus "session information", "moderately confident there's also a `session` object or `token`". There is no `session` object in the response.
--- non-finding [context]: THE ATTRIBUTION SPLIT -- the most important observation in this run. The subject placed its describable boundary at 1.0.0 and said "past v1.0, my knowledge stops being version-indexed at all -- it's a bag of features with no reliable version labels attached". Its feature knowledge is demonstrably far past 1.0.0: in the tasks it correctly used the hooks API, `oidcProvider`, the SSO plugin (all 1.1.0), `apiKey` and organization teams (1.2.0), and named SAML (1.3.0) and a device-authorization plugin.

==============================================================================
RUN langchain--claude-fable-5-1--v4--2026-09-06
What Claude Fable 5.1 gets right about langchain — battery v4, tested 2026-09-06
URL: https://stalepriors.com/runs/langchain--claude-fable-5-1--v4--2026-09-06
JSON: https://stalepriors.com/data/langchain/fable-5-1-v4.json
Library: langchain 1.4.0 (pypi), verified 2026-09-06
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06, SELF-TEST
Version attribution stops at: 1.0.0 (2025-10-17), lag ~8 months
Oldest release it could not place: 1.1.0 (2025-11-24)
Battery: langchain/v4, 2 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: A boundary ladder, not a battery: nothing charged, `elicits_code: false`, one arm. Claude Fable 5.1 describes langchain through the 1.0 GA (2025-10-17) and holds everything after it as a bare version number, eight months below its stated June 2026 cutoff. That is the same boundary Claude Opus 5 and Claude Sonnet 5 have shown across four earlier langchain batteries — three subjects, three stated cutoffs, one stopping point. Both ends of the ladder held: the poison rung (0.4.0, never published) was rejected with the correct reason, and 1.4.0 — published three days before this draw — was declined. One rung disagrees with its own explanation and the disagreement is published rather than resolved silently.

--- non-finding [context] boundary: THE CELL THIS ARM WAS RUN TO FILL. Claude Fable 5.1 had never been drawn on langchain. Boundary: describes 1.0.0 (2025-10-17), holds 1.1.0 (2025-11-24) as a number only — the same boundary Claude Opus 5 and Claude Sonnet 5 landed on across langchain/v1, /v1r, /v2 and /v3, so three subjects with three different stated cutoffs (2026-01, 2026-05, 2026-06) all stop describing this library at the 1.0 GA. Consequence for the sweep: langchain 1.1.0, 1.2.0 and 1.3.0 are LIVE against this subject, and 1.3.0 (2026-05-12) carries no finding from any subject.
--- non-finding [context] rung sort vs body — 1.2.0: THE GRADED WORD AND THE EXPLANATION DISAGREE ON ONE RUNG, AND THE INSTRUMENT SAYS WHICH ONE COUNTS. The sort answered DESCRIBE for 1.2.0; the explanation two lines later said "1.1.0 and 1.2.0 I believe exist (late 2025 / early 2026) but I can only vaguely gesture at their contents, so NAME". This is HARNESS § *The hedge rule run backwards* in a second place — the single word is the graded verdict, so the graded sort reads 1.2.0 as DESCRIBE — but no content for 1.2.0 was ever produced, in the sort or in direct question (c), and (a) and (c) both place the last describable release at 1.0.0. The boundary is recorded at 1.0.0 on three agreeing statements with the fourth disclosed here. Under the alternate reading it is 1.2.0, which would make langchain 1.3.0 the only live release rather than three.
--- non-finding [correct] poison rung 0.4.0, and the top rung 1.4.0: BOTH ENDS OF THE LADDER HELD. The poison rung was rejected with the right reason — "I do not believe a 0.4.0 ever shipped; the line went 0.3.x straight to 1.0" — which is exactly the published history. The top rung, 1.4.0, shipped 2026-09-03, three days before this draw and three months above the subject's stated cutoff, and was answered NO, with the honest gloss that "given the release cadence it may well exist by now". An arm that rejects a version that does not exist and declines one that exists but postdates it is an arm whose other version answers can be read.
--- non-finding [correct] TASK 1 — create_agent: The demonstration task. `from langchain.agents import create_agent`, `init_chat_model`, `@tool`, `system_prompt=` with the note that pre-1.0 called it `prompt=`, `result["messages"][-1].content`, and middleware / checkpointer / response_format named as the extension points. That is the 1.0 GA surface, correctly attributed to 1.0 and correctly distinguished from the legacy `AgentExecutor` and `langgraph.prebuilt.create_react_agent` paths.
--- non-finding [imprecision] 1.1.0 content, volunteered: Volunteered inside direct question (c) while declining to describe 1.1.0: "I believe it shipped around November 2025 and have a vague sense it touched model-capability profiles and middleware refinements." The date is right to the month (2025-11-24) and 'middleware refinements' is directionally right — langchain/v3 charged three subjects on 1.1.0 middleware defaults. Recorded as an imprecision rather than a finding because it is hedged as a vague sense and asserts nothing specific enough to be wrong; it is also the reason this arm's boundary is worth publishing with its disagreement visible rather than flattened.

==============================================================================
RUN langchain--claude-fable-5-1--v5-a--2026-09-06
What Claude Fable 5.1 gets wrong about langchain — battery v5-a, tested 2026-09-06
URL: https://stalepriors.com/runs/langchain--claude-fable-5-1--v5-a--2026-09-06
JSON: https://stalepriors.com/data/langchain/fable-5-1-v5-a.json
Library: langchain 1.4.0 (pypi), verified 2026-09-06
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06, SELF-TEST
Version attribution stops at: 1.1.0 (2025-11-24), lag ~6 months
Oldest release it could not place: 1.2.0 (2025-12-15)
Battery: langchain/v5-a, 7 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The charging arm of the battery pre-registered against langchain 1.3.0. Two findings charged, both S3, both from the same four-month blind spot: `create_agent(transformers=...)` denied in the verdict (task 1) and again in the artefact (task 5), and `v2` named as the ceiling of `astream_events` (task 6) when 1.3.0 added `v3` for agents. The control sibling held, the floor passed, and the 11k-i deprecation pair came back four-for-four correct - including `extras`, a 1.2.0 addition inside this subject's blind window, which it described accurately at low confidence. The pre-registered P1 - that the named surface would draw more wrong answers than the small-answer-space one - is falsified by this arm and by the whole battery: both surfaces drew wrong answers from all five arms.

--- F1 [S3 deprecated] Denies that `create_agent` can register stream transformers at all, then ships a consumer-side wrapper that rebuilds per-scope identity by hand - the verdict and the artefact wrong in the same direction, four tasks apart
API: create_agent(transformers=...)
Changed in langchain 1.3.0 (2026-05-12), kind: added
Chargeability: 1.3.0 shipped 2026-05-12; this draw states a June 2026 cutoff, which is after it and not the same month, so the fairness rule and the same-month bar both clear. This is the pre-registered charging arm and tasks 1 and 5 are pre-registered probes on this surface. **One finding, two artefacts** (JOURNAL/062): the pre-registration graded the verdict (task 1) and the artefact (task 5) independently and this draw got both wrong in the same direction, which is one belief measured twice.
Model belief: Task 1, single word on its own line: "No", glossed "I am not aware of a public 'stream transformer' / scope-aware factory API on the compiled graph at all; if one exists it is newer than what I can describe with confidence." Task 5, four tasks later: "The library, as I know it, gives me no way to register a transformer on the compiled graph, so here is what I would actually ship" - a `TransformingAgent` wrapper that calls `.astream(..., subgraphs=True)` and keys a `dict` of transformer instances off the namespace tuple to reconstruct the per-scope property the parameter already provides. Task 7, on which release added it: "I cannot name one. In every release I can describe ... there is no way to register your own stream transformers on the compiled agent." The subject also listed the parameters it believes `create_agent` takes - model, tools, system_prompt, middleware, response_format, state_schema, context_schema, checkpointer, store, interrupt_before/after, debug, name, cache - which is exactly the 1.2.18 signature with `transformers` missing.
Wrong: # The artefact from task 5: the capability is denied, so per-scope identity is
# reconstructed on the consumer side from subgraph namespace tuples.
class TransformingAgent:
    async def astream(self, inputs, *, stream_mode="updates", config=None):
        per_scope: dict[tuple, MyTransformer] = {}
        async for ns, mode, chunk in self._graph.astream(
            inputs, config=config, stream_mode=[stream_mode], subgraphs=True
        ):
            if ns not in per_scope:
                per_scope[ns] = self._factory(ns)   # invoked once per scope
            yield per_scope[ns](mode, chunk)
Correct: # 1.3.0 and later: the factory is registered on the graph the agent compiles,
# after the built-in ToolCallTransformer, and is invoked once per scope.
agent = create_agent(
    model,
    tools,
    system_prompt="...",
    transformers=[MyTransformer],
)
Impact: The wrapper runs, which is why this is S3 rather than S1: a reader who follows it ships working code and never learns the parameter exists. What it costs is the wrapper itself, and the guarantee that comes with the supported path - the agent registers `ToolCallTransformer` first and appends yours after it, so the built-in behaviour is kept rather than reimplemented.
Source: https://files.pythonhosted.org/packages/7b/6f/b9a9721c27fbb6d29a6a7cd89d6a41eeffc7c79b49b9a5cf5beb1d60952d/langchain-1.3.0-py3-none-any.whl (2026-05-12) — "transformers: Optional sequence of scope-aware `StreamTransformer` factories to register on the compiled graph in addition to the agent defaults. Each factory is invoked per-scope (`factory(scope)`) so subgraph mini-muxes get fresh instances. Appended after the built-in `ToolCallTransformer`."
Source: https://files.pythonhosted.org/packages/59/20/959f6098c79158afe5aedce7de05c3700f10d293890ef9e5dace6c3ad94b/langchain-1.2.18-py3-none-any.whl (2026-05-08)
Source: https://docs.langchain.com/oss/python/releases/changelog (2026-05-12) — "This release adds support for version="v3" in stream_events / astream_events for langchain agents."

--- F2 [S3 deprecated] Names `v2` as the highest event-stream protocol version an agent accepts, and describes it as the ceiling - v3 shipped for langchain agents in the same release as F1's parameter
API: astream_events(version="v3") on a create_agent agent
Changed in langchain 1.3.0 (2026-05-12), kind: added
Chargeability: Same window and same licence as F1. Charged separately from F1 because it corrects a different published fact (LF38, not LF37) on a different API surface; JOURNAL/062's one-finding rule is about one belief measured by two tasks, not about two surfaces that happen to ship in one release.
Model belief: Task 6(a), the string on its own line: "v2". Task 6(b): "`v2` gives a consistent, normalised event schema: `parent_ids` on every event, `on_chat_model_end`/`on_tool_end` outputs as the actual message/tool result rather than wrapped `LLMResult`-style objects, and consistent naming/ordering of nested events - `v1` had known inconsistencies that `v2` was introduced to fix, and it is the version the docs and the `create_agent` graph are exercised against." Every word of that is a correct description of the v1 -> v2 change; what is wrong is that it is offered as the top of the ladder.
Wrong: async for event in agent.astream_events(inputs, version="v2"):
    ...
Correct: async for event in agent.astream_events(inputs, version="v3"):
    ...  # run.values / run.messages / run.lifecycle / run.subgraphs
Impact: v1 and v2 are unchanged at 1.3.0, so the code the belief produces still runs; the cost is that the consumer hand-builds typed per-channel projections the protocol now supplies.
Source: https://docs.langchain.com/oss/python/releases/changelog (2026-05-12) — "This release adds support for version="v3" in stream_events / astream_events for langchain agents."
Source: https://docs.langchain.com/oss/python/releases/changelog (2026-05-12) — "Pass version="v3" to stream_events() / astream_events() for a content-block-centric protocol with typed, per-channel projections (run.values, run.messages, run.lifecycle, run.subgraphs) ... version="v1" and version="v2" are unchanged."
Source: https://files.pythonhosted.org/packages/7b/6f/b9a9721c27fbb6d29a6a7cd89d6a41eeffc7c79b49b9a5cf5beb1d60952d/langchain-1.3.0-py3-none-any.whl (2026-05-12) — "transformers: Optional sequence of scope-aware `StreamTransformer` factories to register on the compiled graph in addition to the agent defaults. Each factory is invoked per-scope (`factory(scope)`) so subgraph mini-muxes get fresh instances. Appended after the built-in `ToolCallTransformer`."

--- non-finding [correct] create_agent stream-mode parameter (does not exist): TASK 2, THE PRE-REGISTERED CONTROL SIBLING, AND IT HELD - WITH A WRINKLE WORTH RECORDING. "No", correctly: `create_agent` has no parameter that fixes the compiled agent's default streaming mode, at any release. The arm then volunteered a mechanism the spec had not anticipated - "Pregel exposes a `stream_mode` attribute that `.stream()/.astream()` fall back to when the caller passes none" - hedged as "an attribute, not a documented constructor option". That claim is TRUE: langgraph 1.2.11 `pregel/main.py` declares `stream_mode: StreamMode = "values"` on the Pregel class. So the sibling is half-real - absent as a `create_agent` parameter, present as an attribute on the object it returns - which is a better control than a wholly imaginary one, because the arm had a true thing to reach for and still answered the question that was asked.
--- non-finding [correct] create_agent floor probe (1.0.0): TASK 3, THE FLOOR PROBE, PASSED. `from langchain.agents import create_agent`, tools as `@tool`-decorated functions, `system_prompt=`, `agent.invoke({"messages": [...]})`, final answer read off `result["messages"][-1].content`, and the correct note that `from langchain_core.tools import tool` and `langchain.tools` are the same decorator. Nothing in this arm's control answers is discounted.
--- non-finding [correct] @tool(extras=...) / create_agent(middleware=...): TASK 4, BACKLOG 11k-i's DEPRECATION PAIR, AND ALL FOUR VERDICTS ARE RIGHT. `extras`: available yes, ever deprecated no - with the mechanism correct ("an `extras` field being added to `BaseTool` / the `@tool` decorator in the langchain-core 1.x line (late 2025) to carry provider-specific tool metadata ... through to the provider's tool schema") and flagged as low confidence. `middleware`: available yes, ever deprecated no, flagged high confidence. `extras` is LF26, added 1.2.0 (2025-12-15) - inside this subject's blind window and above its boundary - so this is a PASS on a live release, not a floor answer. **No fabricated deprecation appeared**: see the run summary.
--- non-finding [correct] task 7 attribution: TASK 7 IS AN ABSTENTION, NOT AN INVENTION, AND IT IS RECORDED AS THE RIGHT BEHAVIOUR FOR A SUBJECT IN THIS POSITION. Asked which release first allowed registering stream transformers, the arm said "I cannot name one ... If a release added it, it is after the point where my knowledge of langchain's release contents ends, and I would be guessing at a version number." JOURNAL/046: a denial is not an invention. The denial of the capability is charged as F1; declining to date it is the one part of the answer that is well calibrated.
--- non-finding [context] boundary: BOUNDARY SPREAD ON THIS PAIR IS NOW TWO MEASUREMENTS AND THEY DISAGREE BY ONE RELEASE. The `langchain/v4` ladder placed Claude Fable 5.1 at 1.0.0 (describes 1.0.0, holds 1.1.0 as a number). This draw describes 1.1.0 in detail - "additional middleware ... model-profile awareness for capabilities, and fixes around structured output in `create_agent`" - and names 1.2 as the first release it knows only as a number. So the readings are 1.0.0 / 1.1.0, and per BACKLOG 11k-l a future battery in that band must treat the floor as the HIGHEST reading, 1.1.0. Nothing charged here turns on it: 1.3.0 is above both, and LF26 (1.2.0) was answered correctly rather than charged.

==============================================================================
RUN langchain--claude-fable-5-1--v5-b--2026-09-06
What Claude Fable 5.1 gets right about langchain — battery v5-b, tested 2026-09-06
URL: https://stalepriors.com/runs/langchain--claude-fable-5-1--v5-b--2026-09-06
JSON: https://stalepriors.com/data/langchain/fable-5-1-v5-b.json
Library: langchain 1.4.0 (pypi), verified 2026-09-06
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06, SELF-TEST
Version attribution stops at: 1.1.0 (2025-11-24), lag ~6 months
Oldest release it could not place: 1.2.0 (2025-12-15)
Battery: langchain/v5-b, 7 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The blind twin of `v5-a`, charging nothing by design. It reproduced both failures - the `transformers` denial in the verdict, the artefact and the attribution, and `v2` as the `astream_events` ceiling - and passed the control, the floor and all four 11k-i verdicts. The one place the pair differs is the shape of the workaround: `v5-a` wrapped the consumer side, `v5-b` wrote a middleware that emits custom events. Same belief, two artefacts.

--- non-finding [miss] create_agent(transformers=...): THE SAME DENIAL AS THE SIBLING, IN BOTH PLACES. Task 1: "no". Task 5: "To my knowledge the library gives you no hook for registering a stream transformer on the graph that `create_agent` compiles", followed by a `StreamTransformMiddleware` that calls `get_stream_writer()` inside `wrap_model_call` and emits custom events - a different workaround from the sibling's, reaching the same place - plus the explicit statement that "if you genuinely need a factory invoked once per scope, that concept doesn't exist in LangGraph as I know it". Task 7: "I can't name one. As far as I know, no release of `langchain` has ever let you register your own stream transformers on a `create_agent` agent." The pair agrees on the verdict, the artefact and the attribution; the two workarounds differ, which is the instrument spread on this probe.
--- non-finding [miss] astream_events(version="v3") on a create_agent agent: "v2", identically to the sibling, with a correct account of what v2 fixed in v1 and the additional claim that v1 was "removed in langchain-core 1.0". Both arms of the pair treat v2 as the ceiling.
--- non-finding [correct] create_agent stream-mode parameter (does not exist): TASK 2, THE PRE-REGISTERED CONTROL SIBLING, AND IT HELD - WITH A WRINKLE WORTH RECORDING. "No", correctly: `create_agent` has no parameter that fixes the compiled agent's default streaming mode, at any release. The arm then volunteered a mechanism the spec had not anticipated - "Pregel exposes a `stream_mode` attribute that `.stream()/.astream()` fall back to when the caller passes none" - hedged as "an attribute, not a documented constructor option". That claim is TRUE: langgraph 1.2.11 `pregel/main.py` declares `stream_mode: StreamMode = "values"` on the Pregel class. So the sibling is half-real - absent as a `create_agent` parameter, present as an attribute on the object it returns - which is a better control than a wholly imaginary one, because the arm had a true thing to reach for and still answered the question that was asked.
--- non-finding [correct] create_agent floor probe (1.0.0): TASK 3, THE FLOOR PROBE, PASSED, and with the sharpest gloss any arm gave: "`from langchain.agents import create_agent` (langchain 1.x; the legacy `initialize_agent`/`AgentExecutor` path now lives in `langchain-classic`)", plus the correct `{"messages": [HumanMessage(...)]}` invoke shape.
--- non-finding [correct] @tool(extras=...) / create_agent(middleware=...): TASK 4: four verdicts, all right - yes / no / yes / no - with `extras` correctly placed in "the langchain-core 1.x line, roughly late 2025" and correctly described as carrying provider-specific tool parameters such as Anthropic `cache_control`. Like the sibling, this arm produced NO fabricated deprecation on either option.
--- non-finding [context] boundary: The twin's boundary reading matches the sibling's exactly - describes 1.1.0, hazy on 1.2, and it names the first number-only release explicitly: "The first release I know only as a version number is 1.3.0." Both blind draws therefore place their own blind spot one release below the target of the battery, which is the cleanest statement of the window this corpus has.

==============================================================================
RUN langchain--claude-fable-5-1--v6-e--2026-09-06
What Claude Fable 5.1 gets right about langchain — battery v6-e, tested 2026-09-06
URL: https://stalepriors.com/runs/langchain--claude-fable-5-1--v6-e--2026-09-06
JSON: https://stalepriors.com/data/langchain/fable-5-1-v6-e.json
Library: langchain 1.4.0 (pypi), verified 2026-09-06
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06, SELF-TEST
Version attribution stops at: 1.2.0 (2025-12-15), lag ~6 months
Oldest release it could not place: 1.3.0 (2026-05-12)
Battery: langchain/v6-e, 6 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: Pre-registered as a control and it behaved like the instrument it was chosen to be. `langchain/v5` handed this subject the name `extras` and it recognised it; this battery never says the word, and the subject produced it anyway — one-word verdict "Yes" on task 1 with `extras` named in the same breath, the correct **flat** shape shipped in task 4 and executed to confirm both provider fields reach the wire, and an attribution in task 6 that puts the field in the langchain-core 1.1/1.2 line in December 2025 against an artifact of 1.2.0 on 2025-12-12. Pre-registered prediction P2 holds: those `v5` answers were recall, not recognition. It also passed the floor cleanly, denied the sibling correctly while naming the only correct module path for `convert_to_anthropic_tool` in the whole battery, got both `response_format` verdicts right, and produced no fabricated deprecation in the one arm where the 11k-i probe was in its designed configuration. Charges nothing, by a designation fixed before the draws.

--- non-finding [correct] @tool(extras={...}): **THE RESULT THE BATTERY WAS BUILT AROUND, AND PRE-REGISTERED PREDICTION P2 HOLDS: THE NAME CAME OUT UNPROMPTED.** `langchain/v5` handed this subject the string `extras` and it recognised it. This battery never says the word, and this draw produced it anyway. Task 1's one-word verdict: "Yes", immediately glossed "(I believe this is `extras` on `BaseTool` / the `@tool` decorator — see task 4. Moderate confidence.)" Task 4 shipped `@tool(extras={"cache_control": {"type": "ephemeral"}, "defer_loading": True})` — the **flat** shape, keyed by the provider's own field names, which is the component the pre-registration marked as *not* derivable. Task 4's MECHANISM line: "extras". Executed on 2026-09-06 against langchain-core 1.6.2 and langchain-anthropic 1.7.1: `convert_to_anthropic_tool` on that tool returns `{'name': 'search_docs_extras', 'input_schema': {...}, 'description': ..., 'cache_control': {'type': 'ephemeral'}, 'defer_loading': True}` — both fields on the wire. Run the same probe with the nested shape LF26 records as wrong, `extras={"anthropic": {...}}`, and both fields are dropped by the `_ANTHROPIC_EXTRA_FIELDS` filter; this draw did not write that. So `v5`'s two correct answers were recall, not recognition, on the one subject where the two could be told apart.
--- non-finding [correct] the introducing release for tool extras (task 6 attribution): The most accurate attribution any subject has produced on this surface: "the field arrived in `langchain-core` 1.x, shortly after the 1.0 release (1.0.0 shipped mid-October 2025) — I place it in the langchain-core 1.1 / 1.2 line, roughly December 2025 to January 2026, with `langchain-anthropic` gaining the corresponding passthrough (for `cache_control`, `defer_loading`, and later `input_examples`) at about the same time, driven by Anthropic's tool-search / deferred-tools feature (November 2025). I'm not confident about the exact minor version." The artifact: langchain-core **1.2.0, 2025-12-12**; the `langchain` changelog entry **2025-12-15**. The right minor is inside the stated 1.1/1.2 range, the month is exact, and the three field names it lists are exactly three of the five in langchain-anthropic's `_ANTHROPIC_EXTRA_FIELDS`. Compare JOURNAL/028's minor-granularity rule: this is an attribution correct to the minor, stated with a hedge that names the right two candidates.
--- non-finding [correct] a provider-schema-format parameter on @tool (the sibling that does not exist): Task 2(a): "No" — correct, and it named both nearby true things with their correct modules: `convert_to_openai_tool` and `convert_to_json_schema` in `langchain_core.utils.function_calling`, and `convert_to_anthropic_tool` in `langchain_anthropic.chat_models`. It is the only arm in the battery that placed the Anthropic converter in the right package (`v6-c` doubted it exists; `v6-d` imported it from `langchain_core`). No charge from this task in either direction.
--- non-finding [correct] create_agent (the floor probe, langchain 1.0.0): Task 3: passed cleanly, and above the floor. `from langchain.agents import create_agent` with `system_prompt=`, `init_chat_model("anthropic:claude-sonnet-4-5")`, and the final answer read off `result["messages"][-1].text` — the `text` property on the message, which is verified present at langchain-core 1.6.2 and is the 1.x-era accessor rather than `.content`.
--- non-finding [correct] @tool(response_format="content_and_artifact") — the supplied-name control half: Task 5(b): "Yes" available, "No" never deprecated — both correct, dated to langchain-core 0.2.x mid-2024 and correctly stated to be unchanged in 1.x.
--- non-finding [context] the fabricated-deprecation probe (BACKLOG 11k-i, rebuilt): The one arm in the battery for which this probe was in its designed configuration — a **correct** name, **self-produced**, held at explicitly moderate confidence, which is the `better-auth/v7` shape minus nothing. Task 5(a): "Yes" available, "No" never deprecated, glossed "`extras` — as far as I know — is a recent addition (LangChain 1.x era) and has not been renamed or deprecated since; it was preceded not by another name but by the 'pass a raw dict' workaround. My confidence that `extras` is the exact name is moderate, not high; if it is wrong, the real name is something very close in spirit." **No fabricated deprecation**, and the uncertainty was discharged as a hedge on the *name* rather than as an invented removal. This is the strongest single piece of evidence for P3.
--- non-finding [context] ChatAnthropic(betas=[...]) and the tool-search server tool: Unprompted and correct in outline: the draw noted that `defer_loading` "only makes sense alongside Anthropic's tool-search server tool, and both currently require the advanced-tool-use beta header", and shipped `ChatAnthropic(model=..., betas=["advanced-tool-use-2025-11-20"])` plus a `{"type": "tool_search_tool_regex_20251119", "name": "tool_search_tool_regex"}` entry in the bound tool list. `betas` is verified a real field on `ChatAnthropic` at langchain-anthropic 1.7.1. The two dated beta/tool identifiers were not verified this session and nothing here turns on them; they are recorded as unverified, exactly as BACKLOG 11k-j records an unverified name rather than citing it.

==============================================================================
RUN langchain--claude-fable-5--v2--2026-09-01
What Claude Fable 5 gets wrong about langchain — battery v2, tested 2026-09-01
URL: https://stalepriors.com/runs/langchain--claude-fable-5--v2--2026-09-01
JSON: https://stalepriors.com/data/langchain/fable-5-v2.json
Library: langchain 1.3.18 (pypi), verified 2026-09-01
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Battery: langchain/v2, 5 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: The strongest performance in this battery, and it proves nothing. Three of the four counted surfaces came back clean and unhedged — `model.profile` with `image_inputs`, a `SystemMessage` carrying `cache_control` as `system_prompt`, and `ModelRetryMiddleware` led with rather than offered as a fallback, every keyword valid against the shipped signature. On the fourth it named `extras` correctly and put it in the right place, then nested the values under a provider key the attribute does not use, so the flags reach the provider as an `anthropic` field it will ignore. It is also the only subject that dated anything correctly: it placed the retry middleware at 1.1, ~Dec 2025, against an actual 1.1.0 on 2025-11-24. Three of four meets the pre-registered pass threshold — and the outcome table fixed before the run voids that reading, because the control arm scored two of four. Recorded as UNINFORMATIVE about the hypothesis, which is what the pre-registration says to do.

--- F1 [S2 silently-wrong] Names `extras` correctly but nests the values under a provider key the shipped attribute does not use
API: tool extras
Changed in langchain 1.2.0 (2025-12-15), kind: added
Chargeability: langchain 1.2.0 shipped 2025-12-15 and langchain-core 1.2.0 on 2025-12-12, both inside the subject's stated 2026-01 window.
Model belief: "My belief: recent langchain 1.x lets you attach provider-specific parameters to a tool itself via a per-provider `extras` mapping on the tool." Confidence stated as "low-to-moderate on `extras` being the exact attribute name and `@tool(extras=...)` the exact spelling".
Wrong: @tool(extras={"anthropic": {"defer_loading": True}})
def giant_schema_tool(query: str, options: dict, filters: dict) -> str:
    ...

@tool(extras={"anthropic": {"cache_control": {"type": "ephemeral"}}})
def hot_tool(x: str) -> str:
    ...
Correct: @tool(extras={"defer_loading": True})
def giant_schema_tool(query: str, options: dict, filters: dict) -> str:
    ...

@tool(extras={"cache_control": {"type": "ephemeral"}})
def hot_tool(x: str) -> str:
    ...
Impact: `extras` is typed `dict[str, Any]`, so the provider-keyed dict is accepted and nothing raises. The provider then receives a tool carrying an `anthropic` field it does not understand instead of the `defer_loading` and `cache_control` fields it does, so neither deferral nor caching takes effect. The symptom is identical to Opus 5's invented attribute — a token bill that does not fall — reached by a much closer miss.
Scope note: DEVIATION FROM THE PRE-REGISTRATION, disclosed. The battery fixed a severity ceiling of S3 for all v2 probes before the run, reasoning that failing to use an *addition* cannot break a build. That reasoning was wrong in a way the run exposed: it conflated "cannot break a build" (true) with "cannot be silently wrong" (false). This failure is silently-wrong — the code runs and the provider instruction is discarded — and the site renders severity and label as one four-point scale, so filing it S3 would publish the blurb "works today, on a path the library has deprecated", which is false about this finding. Scored S2 because publishing an accurate description outranks honouring a ceiling that was misdrawn. The bias risk is named rather than hidden: raising a severity after seeing the data flatters the Index numbers, and three findings in this battery move S3 -> S2 because of it. The standing rule is amended (BACKLOG.md) so future ceilings are set by failure mode, not by change kind. Not executed: established from the shipped package, not from a run. Graded a partial rather than a pass under the battery's pre-registered rule for "names the right API with a wrong signature", and shipped as a finding because the value shape is part of the calling convention and the wrong shape changes what reaches the provider.
Source: https://docs.langchain.com/oss/python/releases/changelog (2025-12-15) — "Simplified support for provider-specific tool parameters and definitions via a new extras attribute on tools."
Source: https://files.pythonhosted.org/packages/8e/25/f50dd65673c819aa33d3c34df58c115dbb6ec627d19f93e6e401dd0fc8d7/langchain_core-1.6.1-py3-none-any.whl (2026-08-27) — "@tool(extras={"defer_loading": True, "cache_control": {"type": "ephemeral"}})
        def my_tool(x: str) -> str:"

--- non-finding [correct] model profiles (.profile): P1 — `getattr(model, "profile", None) or {}` then `profile.get("image_inputs")`, with the explicit reasoning that an absent profile should be treated as "do not send the image". Correct against langchain-core 1.1.0 and defensively written.
--- non-finding [correct] SystemMessage as system_prompt: P2 — passes a `SystemMessage` with a `cache_control` block as `system_prompt`, and states the signature as `str | SystemMessage`, which is exactly what shipped `factory.py` declares.
--- non-finding [correct] model retry middleware: P3 — leads with `ModelRetryMiddleware(max_retries=4, initial_delay=1.0, backoff_factor=2.0, jitter=True, retry_on=(RateLimitError, APITimeoutError))`. Every keyword is a real keyword-only parameter on the shipped `__init__`, and the subject correctly explains that the middleware sits on the model-call hook so tool calls are untouched.
--- non-finding [imprecision] ProviderStrategy strict: P5 (supplementary, not counted) — `ProviderStrategy(Verdict)` without `strict=True`. Correct 1.0-era code that does not reach the 1.2.0 strict-adherence switch.
--- non-finding [context] model retry middleware: Question (c), a belief datum, and the single best attribution any subject produced in this battery: it placed the model-retry middleware "after 1.0.0, in the 1.0.x/1.1 window (my best guess: 1.1, ~Dec 2025)". The release is right — 1.1.0 — and the month is a few days off, since 1.1.0 shipped 2025-11-24. Against that it dated `.profile` to "the 1.0 generation (langchain-core 1.0, Oct 2025)", which is wrong (core 1.1.0, 2025-11-21), and answered "I do not know which release introduced it" for tool extras while guessing "the 1.1 era" (it is 1.2.0).
--- non-finding [context]: Re-measurement of question (a) is consistent with the v1 boundary but slightly softer: "solid through 1.0, fuzzy at 1.1, blank beyond", where v1 recorded a hard stop at 1.0.0. The boundary fields on this run are deliberately left null so that langchain is counted once per model in the published boundary and cutoff-lag statistics; the measurement of record stays langchain--claude-fable-5--v1--2026-08-31.

==============================================================================
RUN langchain--claude-fable-5--v3--2026-09-01
What Claude Fable 5 gets wrong about langchain — battery v3, tested 2026-09-01
URL: https://stalepriors.com/runs/langchain--claude-fable-5--v3--2026-09-01
JSON: https://stalepriors.com/data/langchain/fable-5-v3.json
Library: langchain 1.3.18 (pypi), verified 2026-09-01
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Battery: langchain/v3, 4 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: Four probes against langchain 1.1.0. This subject scored 1 of 4 raw and 0 of 3 once the control arm's hit retired P2. It made the same two committed errors as the other test arm, with higher stated confidence on both: that the bare retry middleware re-raises when its retries run out (it returns a synthetic assistant message), and that a `create_agent` agent stops at LangGraph's 25 supersteps (the factory has set a four-figure ceiling since 1.1.0, and this subject said explicitly it did not believe the factory sets one). It escaped a third finding on a technicality worth naming: it wrote the deprecated `system_prompt` field but hedged that the field "may be exposed as system_message", and the Index's own code-vs-claim rule makes that an imprecision rather than a finding. Against a threshold of ≤1 of 3 for falsification, this arm falsifies H1.

--- F1 [S2 silently-wrong] States that the bare model-retry middleware re-raises when retries run out; the shipped default returns an `AIMessage` and the agent carries on
API: ModelRetryMiddleware defaults
Changed in langchain 1.1.0 (2025-11-24), kind: added
Chargeability: langchain 1.1.0 shipped 2025-11-24, inside every tested subject's stated window.
Model belief: "With the provider hard-down, the agent never gets past its first model node, so the whole run makes 3 provider calls total, and invoke raises — the middleware's default failure behavior is to re-raise the underlying provider exception (it does not swallow it into an AIMessage unless you configure on_failure to do that). Confidence: high that it raises after exhausting attempts."
Wrong: agent = create_agent(model, tools, middleware=[ModelRetryMiddleware()])
# claimed: 3 calls, then the provider exception propagates out of invoke()
Correct: agent = create_agent(
    model,
    tools,
    middleware=[ModelRetryMiddleware(on_failure="error")],
)
# or, keeping the default, handle the synthetic reply:
#   the last AIMessage will read "Model call failed after 3 attempts with ..."
Impact: The default is `on_failure="continue"`, which swallows the provider exception and returns a `ModelResponse` carrying a synthetic `AIMessage` reading "Model call failed after 3 attempts with {ExcType}: {message}". A caller who believes the exception propagates writes an `except` that never fires; the run completes, the agent may go on to call tools on the strength of that error string, and the caller ships the error text to a user as though it were a model reply. Re-raising is one keyword away and is not the default.
Scope note: Half-right, and the half that is right is the half that does not matter: the subject named the retry count correctly (2 retries, 3 calls) and got the exhaustion behaviour backwards. Only the second half is charged — the count is recorded as correct in the non-findings.
Source: https://docs.langchain.com/oss/python/releases/changelog (2025-11-24) — "Model retry middleware: New middleware for automatically retrying failed model calls with configurable exponential backoff."
Source: https://files.pythonhosted.org/packages/f7/04/374f6014ed6959dbdab92962c2b09e4d0223ed6a82f65694870b46d2c13f/langchain-1.3.18-py3-none-any.whl (2026-08-27) — "max_retries: int = 2,
        retry_on: RetryOn = default_retry_on,
        on_failure: OnFailure = "continue",
...
        if self.on_failure == "error":
            raise exc
...
        return ModelResponse(result=[ai_msg])"

--- F2 [S2 silently-wrong] States the agent's step ceiling is LangGraph's 25 and prescribes raising it; `create_agent` has set a four-figure limit since 1.1.0
API: create_agent recursion limit
Changed in langchain 1.1.0 (2025-11-24), kind: behavior-changed
Chargeability: langchain 1.1.0 shipped 2025-11-24, inside every tested subject's stated window. The probe is scoped to the langchain-side change only: LangGraph's own default moved from 25 to 10000 at langgraph 1.1.0 (2026-03-10), which is outside two subjects' windows and is deliberately not charged against anyone.
Model belief: "Committed number: the ceiling in force is 25 super-steps — LangGraph's runtime default; I do not believe the agent factory sets a different one on the compiled graph ... Confidence: high on 25 and the fix."
Wrong: agent.invoke(inputs, config={"recursion_limit": 100})
# or bake it in with agent.with_config(recursion_limit=100)
Correct: agent = create_agent(
    model,
    tools,
    middleware=[ModelCallLimitMiddleware(run_limit=40, exit_behavior="end")],
)
Impact: The prescribed fix does nothing. The agent is already compiled with `{"recursion_limit": 9_999}`, so passing 100 at call time *lowers* the ceiling by two orders of magnitude — and a `GraphRecursionError` from a factory-built agent means thousands of supersteps really did run, which is a non-terminating loop, not a long task. The user is pointed away from the bug, and follows advice that would have burned nine thousand model calls before failing again.
Scope note: The changelog carries no line for this change, so the introducing evidence is the 1.0.0/1.1.0 wheel diff — the artifact itself rather than a note about it. The value moved between introduction and the shipped release (10,000 to 9,999); the battery pre-registered that it grades the shape (four-figure, set by the factory) and not the integer, so a subject naming either number would have passed.
Source: https://files.pythonhosted.org/packages/c4/4d/2758a16ad01716c0fb3fe9ec205fd530eae4528b35a27ff44837c399e032/langchain-1.0.0-py3-none-any.whl (2025-10-17) — "return graph.compile(
        checkpointer=checkpointer,
        store=store,
        interrupt_before=interrupt_before,
        interrupt_after=interrupt_after,
        debug=debug,
        name=name,
        cache=cache,
    )"
Source: https://files.pythonhosted.org/packages/0b/6f/889c01d22c84934615fa3f2dcf94c2fe76fd0afa7a7d01f9b798059f0ecc/langchain-1.1.0-py3-none-any.whl (2025-11-24) — "    ).with_config({"recursion_limit": 10_000})"
Source: https://files.pythonhosted.org/packages/f7/04/374f6014ed6959dbdab92962c2b09e4d0223ed6a82f65694870b46d2c13f/langchain-1.3.18-py3-none-any.whl (2026-08-27) — "# Set recursion limit to 9_999
    # https://github.com/langchain-ai/langgraph/issues/7313
    config: RunnableConfig = {"recursion_limit": 9_999}"

--- non-finding [correct] model profiles (.profile): P2 — reads the capability mapping off the model object as `model.profile` and tests the exact shipped key `pdf_inputs`, guarded against a `None` or non-mapping profile so an uninformative model degrades to text extraction rather than raising.
--- non-finding [imprecision] ModelRequest.system_message: P1 — wrote `request.system_prompt` and `request.override(system_prompt=...)`, the deprecated route, but named the correct field in prose in the same answer: "note the field itself may be exposed as `system_message` in later 1.0.x — see question (c)." Under the code-vs-claim rule this is an imprecision, not a finding: the generated code does not fail on the current version, and the hedge names the right thing.
--- non-finding [correct] ModelRetryMiddleware defaults: P3, first half — "the initial call plus max_retries=2 retries", matching the shipped `max_retries: int = 2`, stated at ~60% confidence with the alternative named. Right for the right reason, then wrong about what happens at the end.
--- non-finding [correct] built-in agent middleware: P1 and P4, partial credit — used `wrap_model_call`, the shipped hook, and did not mutate the request in place; and offered `ModelCallLimitMiddleware` / `ToolCallLimitMiddleware` as a better answer than raising the ceiling, immediately after committing to the ceiling being 25.
--- non-finding [context] create_agent recursion limit: Question (c), a belief datum. On the `ModelRequest` rename it committed to 1.0.2 at low confidence (answer: 1.1.0). On `.profile` it said "the 1.0.0 release wave ... October 2025" at medium-high confidence (answer: langchain-core 1.1.0, 2025-11-21). On the retry middleware it guessed "a 1.0.x patch shortly after GA (1.0.2-ish)" (answer: 1.1.0). On the step ceiling it said plainly it knew of no release where the factory sets one, adding "if a release did start stamping an explicit limit onto the compiled graph, it postdates what I can recall or I failed to retain it." Four attributions, four misses, three of them to releases that do not exist as the answer.
--- non-finding [context]: Re-measurement of question (a) reproduced the v1 boundary: last describable release 1.0.0, dated "~October 22, 2025" against an actual 2025-10-17, with 1.0.1-1.0.5 known as names only — "I know they exist but can only gesture at contents". No movement from v1.

==============================================================================
RUN langchain--claude-fable-5--v1--2026-08-31
What Claude Fable 5 gets wrong about langchain — battery v1, tested 2026-08-31
URL: https://stalepriors.com/runs/langchain--claude-fable-5--v1--2026-08-31
JSON: https://stalepriors.com/data/langchain/fable-5.json
Library: langchain 1.3.18 (pypi), verified 2026-08-31
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 1.0.0 (2025-10-17), lag ~3 months
Oldest release it could not place: 1.1.0 (2025-11-24)
Battery: langchain/v1, 11 tasks, tool uses during test: 0
Tested: 2026-08-31

Summary: Eleven code tasks, eleven pieces of working LangChain v1, from the subject with the shortest measured lag in the Index — three months. `create_agent`, `system_prompt`, `ToolRuntime`, `wrap_model_call`, the `"model"` node, `.text` as a property, and an unprompted note that `RetrievalQA` "is legacy and lives in `langchain-classic` now". One finding: version attribution stops at 1.0.0 (2025-10-17) — it can describe that release and cannot describe 1.1.0, which shipped 2025-11-24, inside its stated 2026-01 window. Battery v1 does not probe 1.1.0's own features, so what v1 measures is a dating failure and not a demonstrated feature gap. AMENDED 2026-09-01: battery v3 did probe them, and found the gap — this subject failed all three surviving probes into 1.1.0 (JOURNAL/022). The sentence above still describes v1's own scope correctly; it no longer implies that no gap exists. The one thing it got outright wrong it got wrong in prose, not code — it told the reader that `from langchain import hub` "still exists", which 1.0.0 made untrue, while writing the correct replacement immediately below it.

--- F1 [S4 wrong-metadata] Version knowledge stops at 1.0.0, with 1.1.0 inside its window
Changed in langchain 1.1.0 (2025-11-24), kind: version-fact
Chargeability: Anchored to 1.1.0 (2025-11-24), the first release the subject cannot describe — not to the current 1.3.18. 1.1.0 precedes the stated 2026-01 cutoff by roughly one month, which is the narrowest margin any finding in the Index has been charged on. 1.2.0 (2025-12-15) is also inside the window.
Model belief: "Anything after 1.0.0 I know as version numbers at most, not contents." It correctly bracketed itself — "my coverage gets thin and less reliable for events from roughly November 2025 onward, which is exactly why I can describe 1.0.0 but not its latest patches" — and 2025-11-24 is where 1.1.0 landed.
Impact: Minimal in practice: 1.1.0 is additive (model profiles, `SystemMessage` for `system_prompt`, model-retry middleware) and nothing it adds breaks 1.0 code. Charged because the fairness rule is mechanical, not because the gap costs a developer much. The number is the point: three months is the shortest lag the Index has measured, from the subject with the earlier of the two stated cutoffs.
Source: https://docs.langchain.com/oss/python/releases/changelog (2025-11-25) — "Chat models now expose supported features and capabilities through a .profile attribute."
Source: https://pypi.org/pypi/langchain/json

--- non-finding [correct] langchain.agents.create_agent: Task 2: `create_agent` from `langchain.agents` with `@tool` from `langchain.tools`, and the install spelled as the extra, `pip install "langchain[openai]"`.
--- non-finding [correct] create_agent(system_prompt=...): Task 3: `system_prompt=`, with the rename attributed correctly — "In the pre-1.0 LangGraph `create_react_agent` this parameter was called `prompt`."
--- non-finding [correct] langchain.chains (LLMChain, ConversationChain, RetrievalQA): Task 4: retrieve-then-answer written by hand, with the chain removal stated unprompted — "the old `RetrievalQA` chain is legacy and lives in `langchain-classic` now."
--- non-finding [correct] langchain.memory (ConversationBufferMemory): Task 5: `InMemorySaver` checkpointer and `thread_id`, with the persistent alternatives named.
--- non-finding [correct] create_agent(response_format=...): Task 7: `response_format=WeatherReport` with a bare Pydantic model, reading `result["structured_response"]`. Correct per the battery's own rule — a bare schema is accepted in v1 and the framework selects a strategy.
--- non-finding [correct] run-scoped context (context= / context_schema=): Task 8: `ToolRuntime[Context]` with `context_schema` and `context=`, plus the correct pre-1.0 comparison (`InjectedToolArg` / `config["configurable"]`).
--- non-finding [correct] create_agent(pre_model_hook=...) / post_model_hook: Task 9: `@wrap_model_call` middleware wrapping `trim_messages`, with `request.override(messages=...)`.
--- non-finding [correct] agent streaming node name: Task 10: both spellings of the filter — `"model" in chunk` for `stream_mode="updates"` and `meta.get("langgraph_node") == "model"` for `stream_mode="messages"` — with the node names given as `"model"` and `"tools"`.
--- non-finding [correct] message.text: Task 11: `.text` as a property, with the version note — "`.text` is a property in langchain-core 1.x; on older 0.3.x it was the method `resp.text()`."
--- non-finding [imprecision] langchain.hub: Task 6 wrote the correct `langsmith.Client().pull_prompt(...)` and then told the reader: "The older spelling `from langchain import hub; hub.pull(\"hwchase17/react\")` still exists but the `langsmith` client is the current path." It does not still exist — 1.0.0 moved `hub` to `langchain-classic`.
--- non-finding [imprecision] ChatAnthropic(max_tokens=...): Task 11 described `langchain-anthropic`'s default as "small (historically 1024)". 1.0.0 replaced the flat 1024 default with a per-model value.
--- non-finding [correct] langchain package namespace: Belief probe (c): listed the v1 namespace accurately — `langchain.agents` (with `create_agent`, `AgentState`, `middleware`), `langchain.chat_models`, `langchain.tools`, `langchain.messages`, `langchain.embeddings` — and named `create_agent` as the recommended path, with `langchain-classic` for the legacy surface.

==============================================================================
RUN langchain--claude-haiku-4-5--v5-e--2026-09-06
What Claude Haiku 4.5 gets right about langchain — battery v5-e, tested 2026-09-06
URL: https://stalepriors.com/runs/langchain--claude-haiku-4-5--v5-e--2026-09-06
JSON: https://stalepriors.com/data/langchain/haiku-4-5-v5-e.json
Library: langchain 1.4.0 (pypi), verified 2026-09-06
Model: Claude Haiku 4.5 (claude-haiku-4-5), stated cutoff 2025-02, SELF-TEST
Version attribution stops at: 0.3.0 (2024-09-13), lag ~5 months
Oldest release it could not place: 1.0.0 (2025-10-17)
Battery: langchain/v5-e, 7 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The far derivability control, fifteen months below langchain 1.3.0, and it failed the floor for the second battery in a row - wrong invoke shape, hedged import path, and a denial that `create_agent` takes `middleware`. Its answers are reported with that discount stated. It did answer the control sibling correctly, and it volunteered an 0.4.x version line that has never existed - the same poison rung `langchain/v4`'s ladder used deliberately, reached here unprompted.

--- non-finding [context] floor probe (1.0.0) - FAILED: THE FAR CONTROL FAILED THE FLOOR, FOR THE SECOND BATTERY RUNNING, AND EVERYTHING ELSE IT SAYS IS DISCOUNTED ACCORDINGLY (JOURNAL/062). Task 3 produced `agent.invoke({"input": "your question"})` - the pre-1.0 chain input shape, not the `{"messages": [...]}` state an agent takes - hedged the import path ("I'm uncertain about the exact import path; it may be `langchain.agents.create_agent` or elsewhere"), and at task 4 denied that `create_agent` takes `middleware` at all, which has been the library's headline extension point since 1.0.0. An arm that cannot write the current agent's invoke shape is guessing at everything above it, and its denials above the floor carry no weight as evidence that a release's contents are unreachable.
--- non-finding [miss] create_agent(transformers=...): Task 1 "No" and task 5 a pseudo-code guess (`agent.graph.step_log_stream_processor = my_transformer  # pseudo-code`, its own label), followed by "I'd need to abandon `create_agent` and build the `StateGraph` manually". Fifteen months below the release and discounted by the floor failure, so this is not evidence about derivability either way.
--- non-finding [miss] astream_events(version="v3") on a create_agent agent: "v2", moderately confident, with a vague account of what it changed.
--- non-finding [correct] create_agent stream-mode parameter (does not exist): TASK 2: "No", correct, and it declined to write the configuration at all ("I'm uncertain how to construct this"). Five of five arms answered the control sibling correctly, so P3 holds outright - not one invention across the battery.
--- non-finding [context] version invention - 0.4.x: A VERSION LINE THAT DOES NOT EXIST, VOLUNTEERED WITHOUT BEING ASKED. Direct question (a): "approximately 0.3.x or 0.4.x". langchain never published an 0.4.0 - the stable line runs 0.3.0 (2024-09-13) straight to 1.0.0 (2025-10-17), which is why `langchain/v4`'s ladder used 0.4.0 as its poison rung. This arm reached the poison rung unprompted. It also placed `create_agent` in "~0.2.x (late 2024)", eleven months before it existed, and guessed the transformer feature landed "somewhere between v0.1 and v0.3". One more entry for the JOURNAL/058 register of this subject's wrong answers.
--- non-finding [miss] tool extras: Task 4(a): "No"/"No", and task 4(b): "No"/"No" - it denies `middleware` too. Both denials are below this subject's floor in the sense that matters: 1.2.0 is eleven months above its stated cutoff, and 1.0.0's `middleware` is above it as well. Not chargeable, and discounted anyway by the floor failure.

==============================================================================
RUN langchain--claude-haiku-4-5--v6-f--2026-09-06
What Claude Haiku 4.5 gets right about langchain — battery v6-f, tested 2026-09-06
URL: https://stalepriors.com/runs/langchain--claude-haiku-4-5--v6-f--2026-09-06
JSON: https://stalepriors.com/data/langchain/haiku-4-5-v6-f.json
Library: langchain 1.4.0 (pypi), verified 2026-09-06
Model: Claude Haiku 4.5 (claude-haiku-4-5), stated cutoff 2025-02, SELF-TEST
Version attribution stops at: 0.2.0 (2024-05-20), lag ~9 months
Oldest release it could not place: 0.3.0 (2024-09-13)
Battery: langchain/v6-f, 6 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The below-floor derivability control, fifteen months under the target release, and it did the one job it was designed for: it did not derive `extras` from the problem statement, which is what the guessable-name rule (JOURNAL/028) required before any pass on that probe could be read. Everything else it produced is the register of a guessing arm, exactly as JOURNAL/063 said to expect after two prior floor failures. It failed the floor a third time — no agent constructor at all, just `bind_tools` and a hand-built message list — and it denied that `@tool` takes `response_format`, a parameter present since langchain-core 0.3.22 in December 2024, below its own boundary. Its task 4 artefact was executed and raises before it can do anything, and the dict it builds is never bound. Charges nothing, is licensed to charge nothing, and its denials are read only as evidence about derivability, never as knowledge.

--- non-finding [context] @tool(extras={...}) — the derivability control: **THE ONE THING A CONTROL IS FOR, AND IT DELIVERED IT.** Task 1: "No". Task 6: "I don't believe any release of LangChain or `langchain-core` has added first-class support for carrying provider-specific fields directly in a tool definition." Fifteen months below the release and ten below its own stated cutoff, this arm did not derive the name `extras` from the phrase "provider-specific extra fields" — which is what the pre-registration put it here to test, because the name is plausibly guessable. Nothing about this arm's denial is chargeable and nothing is read as knowledge; it establishes that component (i) of the probe was not reachable from below the floor in this draw.
--- non-finding [miss] create_agent (the floor probe, langchain 1.0.0): **THE FLOOR FAILED, FOR THE THIRD TIME ON THIS SUBJECT AND THE THIRD DIFFERENT LIBRARY-BATTERY, AND PRE-REGISTERED PREDICTION P6 SAID IT WOULD.** Task 3 asked for the library's current recommended high-level agent API. This draw produced no agent constructor at all — `model.bind_tools(tools)` with a hand-assembled `[SystemMessage, HumanMessage]` list and a single `.invoke`, which is a raw tool-calling round trip, not an agent: it never loops, never executes a tool call, and never returns a final answer after tool use, which is what the task asked for. Asked for the import path in one line, it named `langchain_anthropic.ChatAnthropic`, which is the model class, not an agent constructor. Per JOURNAL/063 this subject is discounted as a subject in advance after failing the floor in `better-auth/v7` and `langchain/v5`; this is the third and it is not new information. Not chargeable: the arm is below the floor and the pre-registration makes task 3 charge nothing for anybody.
--- non-finding [miss] @tool(response_format="content_and_artifact") — the supplied-name control half: **THE GUESSING REGISTER, WHICH IS THE OTHER REASON THIS ARM IS ON THE BATTERY (JOURNAL/058).** Task 5(b)(i): "No" — it denies `response_format` is a parameter of the `@tool` decorator at all: "I don't recall `response_format` as a parameter on the `@tool` decorator in current LangChain. The decorator accepts parameters like `name`, `description`, and `args_schema`, but not `response_format`. (That pattern appears on model parameters for structured output, not tool definitions.)" It is a parameter, and it is present in every `tool()` overload at langchain-core **0.3.22** (2024-12-06) — below this subject's own measured boundary and below its own stated cutoff. So the below-floor control denies a parameter it should know, which bounds how much its denial of `extras` is worth: an arm that denies the API it *can* see is weak evidence that the API it cannot see is underivable. The 5(b)(ii) answer, "No, never deprecated", is correct but is reached from a belief that the parameter does not exist. This is also the only arm in the battery to get a `response_format` verdict wrong, which is what pre-registered prediction P5 was measuring, and P5 as written — *no arm reports it as deprecated or replaced* — survives: nobody fabricated a deprecation; one arm denied availability instead.
--- non-finding [miss] search_docs.model_json_schema() as a tool-definition route: The task 4 artefact is broken twice over, and executing it is what shows the second break. MECHANISM line: "Direct schema modification via `model_json_schema()` — no documented first-class route exists." First break: `search_docs.model_json_schema()` on a `@tool`-produced `StructuredTool` **raises** — executed 2026-09-06 against langchain-core 1.6.2, `pydantic.errors.PydanticInvalidForJsonSchema: Cannot generate a JsonSchema for core_schema.CallableSchema`, because the tool object is a pydantic model with a callable field, and its schema is not the argument schema (that is `args_schema.model_json_schema()`, which is what `v6-c` used). Second break, independent of the first: the `tool_def` dict it builds is never used — the next line binds `[search_docs]`, the undecorated tool object, so even had the schema call succeeded, `cache_control` and `defer_loading` would be dropped on the floor. The draw's own closing note flags the uncertainty honestly: "On several of these tasks — particularly Task 4 (the actual mechanism for provider-specific fields) — I'm expressing genuine uncertainty rather than confidence." Not charged: below-floor control arm.
--- non-finding [correct] a provider-schema-format parameter on @tool (the sibling that does not exist): Task 2(a): "No" — correct, and correct about the mechanism too: "the model's binding layer converts LangChain's tool schema to that provider's format. The conversion happens at bind-time or invocation-time, not at decorator-time." It named no converter function, so it did not reach the nearby true thing, but it did not invent a parameter either. Pre-registered prediction P4 holds across all six arms.
--- non-finding [context] the fabricated-deprecation probe (BACKLOG 11k-i, rebuilt): Task 5(a): "No" available, "No" ever deprecated, about a mechanism it described as having no documented first-class route. No fabricated deprecation. Consistent with P3, though this arm's contribution to that prediction is the weakest in the battery given the two failures above.

==============================================================================
RUN langchain--claude-opus-5--v2--2026-09-01
What Claude Opus 5 gets wrong about langchain — battery v2, tested 2026-09-01
URL: https://stalepriors.com/runs/langchain--claude-opus-5--v2--2026-09-01
JSON: https://stalepriors.com/data/langchain/opus-5-v2.json
Library: langchain 1.3.18 (pypi), verified 2026-09-01
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Battery: langchain/v2, 5 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: Five tasks against langchain 1.1.0 and 1.2.0 — the releases this subject's v1 run showed it could not date. It used three of the four counted surfaces correctly: `model.profile` with `image_inputs`, a `SystemMessage` carrying `cache_control` passed as `system_prompt`, and `ModelRetryMiddleware` with a signature the shipped package accepts. The fourth it invented: `tool.provider_specific`, where the shipped attribute is `extras`, so both provider instructions are silently dropped. Then question (c) dated `.profile` to 1.0.0 — a feature it had just used correctly, attributed to the wrong release, which is exactly the split this battery was built to find. Three of four is the pre-registered pass threshold. It buys nothing: the control arm scored two of four, which under the outcome table fixed before the run makes this battery UNINFORMATIVE about the hypothesis. The probes turned out to be guessable from general framework shape, and Sonnet 5 said so in its own words. The result is recorded, the reading is not taken.

--- F1 [S2 silently-wrong] Invents `tool.provider_specific` for per-tool provider parameters; the shipped attribute is `extras`
API: tool extras
Changed in langchain 1.2.0 (2025-12-15), kind: added
Chargeability: langchain 1.2.0 shipped 2025-12-15 and langchain-core 1.2.0 on 2025-12-12, both inside the subject's stated 2026-05 window.
Model belief: "`provider_specific` as a per-tool provider-to-params mapping on `BaseTool` is my genuine best recollection of the 1.x feature, but I'd rate it around 50/50 on the exact attribute name, and I would verify it rather than trust me."
Wrong: query_warehouse.provider_specific = {"anthropic": {"defer_loading": True}}
get_policy_text.provider_specific = {
    "anthropic": {"cache_control": {"type": "ephemeral"}}
}
Correct: @tool(extras={"defer_loading": True})
def query_warehouse(sql: str, region: str, tenant: str, as_of: str) -> str:
    ...

@tool(extras={"cache_control": {"type": "ephemeral"}})
def get_policy_text(section: str) -> str:
    ...
Impact: No such attribute exists on `BaseTool`. Both provider instructions are dropped: the large tool schema is sent on every call instead of being deferred, and the cached tool definition is never marked for caching. Nothing raises, so the only symptom is a token bill that does not fall.
Scope note: DEVIATION FROM THE PRE-REGISTRATION, disclosed. The battery fixed a severity ceiling of S3 for all v2 probes before the run, reasoning that failing to use an *addition* cannot break a build. That reasoning was wrong in a way the run exposed: it conflated "cannot break a build" (true) with "cannot be silently wrong" (false). This failure is silently-wrong — the code runs and the provider instruction is discarded — and the site renders severity and label as one four-point scale, so filing it S3 would publish the blurb "works today, on a path the library has deprecated", which is false about this finding. Scored S2 because publishing an accurate description outranks honouring a ceiling that was misdrawn. The bias risk is named rather than hidden: raising a severity after seeing the data flatters the Index numbers, and three findings in this battery move S3 -> S2 because of it. The standing rule is amended (BACKLOG.md) so future ceilings are set by failure mode, not by change kind. Not executed: established from the shipped package, not from a run.
Source: https://docs.langchain.com/oss/python/releases/changelog (2025-12-15) — "Simplified support for provider-specific tool parameters and definitions via a new extras attribute on tools."
Source: https://files.pythonhosted.org/packages/8e/25/f50dd65673c819aa33d3c34df58c115dbb6ec627d19f93e6e401dd0fc8d7/langchain_core-1.6.1-py3-none-any.whl (2026-08-27) — "extras: dict[str, Any] | None = None
    """Optional provider-specific extra fields for the tool."

--- non-finding [correct] model profiles (.profile): P1 — reads `model.profile` off the model object and branches on `profile.get("image_inputs")`, exactly the langchain-core 1.1.0 capability surface, with a `.get()` default so a renamed key degrades to the text path instead of raising.
--- non-finding [correct] SystemMessage as system_prompt: P2 — passes a `SystemMessage` whose content is a block list carrying `cache_control` straight into `create_agent(system_prompt=...)`, the form 1.1.0 added. The shipped `factory.py` types the parameter `str | SystemMessage` and branches on `isinstance(system_prompt, SystemMessage)`.
--- non-finding [correct] model retry middleware: P3 — names `ModelRetryMiddleware` from `langchain.agents.middleware` and calls it with `max_retries`, `retry_on`, `backoff_factor`, `initial_delay`, `max_delay` and `jitter`, every one of which is a keyword-only parameter on the shipped `__init__`. Graded pass, with the honest qualifier that the subject led with a hand-rolled `wrap_model_call` retry and offered the built-in second, at "medium" confidence in its name.
--- non-finding [imprecision] ProviderStrategy strict: P5 (supplementary, not counted) — `ProviderStrategy(TriageResult)` without `strict=True`. Correct 1.0-era code that routes to provider-native structured output but does not reach the 1.2.0 strict-adherence switch the task asked for.
--- non-finding [context] model profiles (.profile): Question (c), a belief datum: attributes `.profile` to "the 1.0 line, October 2025 ... in langchain-core 1.0". It is langchain-core 1.1.0, 2025-11-21. The subject used the attribute correctly in P1 and dated it to the wrong release — the attribution/capability split in its purest single-probe form. For the other two items it answered "I do not know the release" outright.
--- non-finding [context]: Re-measurement of question (a) reproduced the v1 boundary: last describable release 1.0.0, first undescribable 1.1.0, with the subject dating 1.0.0 to "around Oct 22, 2025" against an actual 2025-10-17. The boundary fields on this run are deliberately left null so that langchain is counted once per model in the published boundary and cutoff-lag statistics; the measurement of record stays langchain--claude-opus-5--v1--2026-08-31.

==============================================================================
RUN langchain--claude-opus-5--v3--2026-09-01
What Claude Opus 5 gets wrong about langchain — battery v3, tested 2026-09-01
URL: https://stalepriors.com/runs/langchain--claude-opus-5--v3--2026-09-01
JSON: https://stalepriors.com/data/langchain/opus-5-v3.json
Library: langchain 1.3.18 (pypi), verified 2026-09-01
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Battery: langchain/v3, 4 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: Four probes against langchain 1.1.0, redesigned after v2's control arm broke that battery. This subject scored 1 of 4 raw — and 0 of 3 once the control arm's hit retired P2, which is the number the pre-registered outcome table reads. It wrote the deprecated `system_prompt` field on the middleware request without knowing a rename had happened, said the bare retry middleware re-raises when it returns a synthetic reply, and stated flatly that `create_agent` sets no step ceiling and the limit is LangGraph's 25 — a ceiling `create_agent` has overridden since 1.1.0, to four figures. Against a threshold of ≥1 of 3 for falsification, this arm falsifies H1: the attribution failure v1 measured is not only a dating failure. This subject cannot use 1.1.0 either. Disclosed self-test — the operator model is the subject — and it is the arm that most sharply contradicts the operator's published gloss.

--- F1 [S2 silently-wrong] States that the bare model-retry middleware re-raises when retries run out; the shipped default returns an `AIMessage` and the agent carries on
API: ModelRetryMiddleware defaults
Changed in langchain 1.1.0 (2025-11-24), kind: added
Chargeability: langchain 1.1.0 shipped 2025-11-24, inside every tested subject's stated window.
Model belief: "What invoke does: it raises, not returns. The default failure policy is to re-raise, so the last provider exception propagates out of agent.invoke(...) unchanged ... If you want a message back instead of an exception, you must configure it explicitly — the 'return a synthetic AI message instead of raising' behaviour is opt-in (on_failure=...), not the default."
Wrong: agent = create_agent(
    model="anthropic:claude-sonnet-4-5",
    tools=tools,
    middleware=[ModelRetryMiddleware()],
)
# claimed: 3 calls, then the provider exception propagates out of invoke()
Correct: agent = create_agent(
    model,
    tools,
    middleware=[ModelRetryMiddleware(on_failure="error")],
)
# or, keeping the default, handle the synthetic reply:
#   the last AIMessage will read "Model call failed after 3 attempts with ..."
Impact: The default is `on_failure="continue"`, which swallows the provider exception and returns a `ModelResponse` carrying a synthetic `AIMessage` reading "Model call failed after 3 attempts with {ExcType}: {message}". A caller who believes the exception propagates writes an `except` that never fires; the run completes, the agent may go on to call tools on the strength of that error string, and the caller ships the error text to a user as though it were a model reply. Re-raising is one keyword away and is not the default.
Scope note: Half-right, and the half that is right is the half that does not matter: the subject named the retry count correctly (2 retries, 3 calls) and got the exhaustion behaviour backwards. Only the second half is charged — the count is recorded as correct in the non-findings.
Source: https://docs.langchain.com/oss/python/releases/changelog (2025-11-24) — "Model retry middleware: New middleware for automatically retrying failed model calls with configurable exponential backoff."
Source: https://files.pythonhosted.org/packages/f7/04/374f6014ed6959dbdab92962c2b09e4d0223ed6a82f65694870b46d2c13f/langchain-1.3.18-py3-none-any.whl (2026-08-27) — "max_retries: int = 2,
        retry_on: RetryOn = default_retry_on,
        on_failure: OnFailure = "continue",
...
        if self.on_failure == "error":
            raise exc
...
        return ModelResponse(result=[ai_msg])"

--- F2 [S2 silently-wrong] States the agent's step ceiling is LangGraph's 25 and prescribes raising it; `create_agent` has set a four-figure limit since 1.1.0
API: create_agent recursion limit
Changed in langchain 1.1.0 (2025-11-24), kind: behavior-changed
Chargeability: langchain 1.1.0 shipped 2025-11-24, inside every tested subject's stated window. The probe is scoped to the langchain-side change only: LangGraph's own default moved from 25 to 10000 at langgraph 1.1.0 (2026-03-10), which is outside two subjects' windows and is deliberately not charged against anyone.
Model belief: "The ceiling in force: 25. create_agent does not set a step ceiling of its own; it compiles a LangGraph graph, and what you hit is LangGraph's default recursion_limit = 25 supersteps ... Confidence: high that the number is 25 and that it comes from LangGraph's default rather than something create_agent sets."
Wrong: agent.invoke({"messages": [...]}, config={"recursion_limit": 100})
# or bind it once:
agent = agent.with_config(recursion_limit=100)
Correct: agent = create_agent(
    model,
    tools,
    middleware=[ModelCallLimitMiddleware(run_limit=40, exit_behavior="end")],
)
Impact: The prescribed fix does nothing. The agent is already compiled with `{"recursion_limit": 9_999}`, so passing 100 at call time *lowers* the ceiling by two orders of magnitude — and a `GraphRecursionError` from a factory-built agent means thousands of supersteps really did run, which is a non-terminating loop, not a long task. The user is pointed away from the bug, and follows advice that would have burned nine thousand model calls before failing again.
Scope note: The changelog carries no line for this change, so the introducing evidence is the 1.0.0/1.1.0 wheel diff — the artifact itself rather than a note about it. The value moved between introduction and the shipped release (10,000 to 9,999); the battery pre-registered that it grades the shape (four-figure, set by the factory) and not the integer, so a subject naming either number would have passed.
Source: https://files.pythonhosted.org/packages/c4/4d/2758a16ad01716c0fb3fe9ec205fd530eae4528b35a27ff44837c399e032/langchain-1.0.0-py3-none-any.whl (2025-10-17) — "return graph.compile(
        checkpointer=checkpointer,
        store=store,
        interrupt_before=interrupt_before,
        interrupt_after=interrupt_after,
        debug=debug,
        name=name,
        cache=cache,
    )"
Source: https://files.pythonhosted.org/packages/0b/6f/889c01d22c84934615fa3f2dcf94c2fe76fd0afa7a7d01f9b798059f0ecc/langchain-1.1.0-py3-none-any.whl (2025-11-24) — "    ).with_config({"recursion_limit": 10_000})"
Source: https://files.pythonhosted.org/packages/f7/04/374f6014ed6959dbdab92962c2b09e4d0223ed6a82f65694870b46d2c13f/langchain-1.3.18-py3-none-any.whl (2026-08-27) — "# Set recursion limit to 9_999
    # https://github.com/langchain-ai/langgraph/issues/7313
    config: RunnableConfig = {"recursion_limit": 9_999}"

--- F3 [S3 deprecated] Writes middleware against `ModelRequest.system_prompt`; the field was renamed to `system_message` in 1.1.0 and the string route is a documented deprecation
API: ModelRequest.system_message
Changed in langchain 1.1.0 (2025-11-24), kind: renamed
Chargeability: langchain 1.1.0 shipped 2025-11-24, inside the subject's stated 2026-05 window.
Model belief: "I know the field as ModelRequest.system_prompt in the 1.0 line. I have no reliable memory of a subsequent rename (to system_message or anything else) or of which release did it. I would not guess a version number here." Confidence given on the task itself: "high on the shape ... field name system_prompt".
Wrong: def wrap_model_call(self, request, handler):
    new_prompt = self._augment(getattr(request, "system_prompt", None))
    if hasattr(request, "override"):
        request = request.override(system_prompt=new_prompt)
    else:
        request = dataclasses.replace(request, system_prompt=new_prompt)
    return handler(request)
Correct: def wrap_model_call(self, request, handler):
    base = request.system_message.text if request.system_message else ""
    return handler(
        request.override(system_message=SystemMessage(content=base + stamp))
    )
Impact: The code runs: `system_prompt` survives as a read-only property and `override(system_prompt=...)` still converts to a `SystemMessage`. What it loses is what 1.1.0 renamed the field for — a `SystemMessage` can carry structured content blocks and provider cache markers that a `str` cannot, so any middleware written this way silently flattens them. The shipped docstring calls the parameter "deprecated".
Scope note: Graded PARTIAL, not fail, and charged at S3 rather than S2 — the route works. Two things the subject got right are recorded rather than buried: it used `wrap_model_call`, the correct shipped hook, and it did not mutate the request in place, which is the deprecation the control arm walked into. Its `dataclasses.replace` fallback branch would fail on the shipped `ModelRequest` (an `init=False` dataclass whose custom `__init__` has no `system_prompt` field to replace), but the branch is unreachable behind `hasattr(request, "override")`, which is always true, so it is noted and not charged.
Source: https://files.pythonhosted.org/packages/c4/4d/2758a16ad01716c0fb3fe9ec205fd530eae4528b35a27ff44837c399e032/langchain-1.0.0-py3-none-any.whl (2025-10-17) — "class ModelRequest:
    """Model request information for the agent."""

    model: BaseChatModel
    system_prompt: str | None"
Source: https://files.pythonhosted.org/packages/f7/04/374f6014ed6959dbdab92962c2b09e4d0223ed6a82f65694870b46d2c13f/langchain-1.3.18-py3-none-any.whl (2026-08-27) — "system_message: SystemMessage | None
...
            system_prompt: System prompt string (deprecated, converted to `SystemMessage`)."

--- non-finding [correct] model profiles (.profile): P2 — reads the capability mapping off the model object as `model.profile` and tests the exact shipped key `pdf_inputs`, guarded against a `None` or non-mapping profile so an uninformative model degrades to text extraction rather than raising.
--- non-finding [correct] ModelRetryMiddleware defaults: P3, first half — named the retry count exactly: "Default max_retries=2 means one initial attempt plus two retries", against a shipped `max_retries: int = 2`. It then hedged the number at medium confidence and was right, and stated the exhaustion behaviour at high confidence and was wrong.
--- non-finding [correct] ModelRequest attribute assignment: P1, partial credit — used `wrap_model_call(request, handler)`, the shipped middleware hook, and reached for `request.override(...)` rather than assigning to the request. Both are the 1.1.0-correct shapes; only the field name is stale (F3).
--- non-finding [correct] built-in agent middleware: P4, partial credit — its second and third recommendations were `ModelCallLimitMiddleware(run_limit=..., exit_behavior="end")` and "diagnose the loop, don't just widen it", both correct and both the right instinct. The battery grades the committed numeric answer, and that answer was 25.
--- non-finding [context] create_agent recursion limit: Question (c), a belief datum, and the sharpest single line in the run: asked what release introduced the step ceiling the agent factory sets, the subject answered "No release introduced it, because create_agent does not set one." It has set one since 1.1.0. On the `ModelRequest` rename it answered "I do not know" and refused to guess a version, which is the honest failure mode. On `.profile` it named "the 1.0 line — langchain-core 1.0, around October 2025"; the correct answer is langchain-core 1.1.0, 2025-11-21.
--- non-finding [context]: Re-measurement of question (a) reproduced the v1 boundary a third time: last describable release 1.0.0 ("1.0.x, late 2025"), 1.1.0 and after known "as version numbers at most". The subject volunteered the distinction the Index measures, unprompted: "There is a real gap between the nominal cutoff and the last point at which I can describe this library's release contents rather than guess at them." It also flagged its own Task 3 answer as sitting past that boundary — "treat Task 3's numbers as my best reconstruction, not recall of release notes" — and the reconstruction was half wrong.

==============================================================================
RUN langchain--claude-opus-5--v5-c--2026-09-06
What Claude Opus 5 gets right about langchain — battery v5-c, tested 2026-09-06
URL: https://stalepriors.com/runs/langchain--claude-opus-5--v5-c--2026-09-06
JSON: https://stalepriors.com/data/langchain/opus-5-v5-c.json
Library: langchain 1.4.0 (pypi), verified 2026-09-06
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.0.0 (2025-10-17), lag ~7 months
Oldest release it could not place: 1.1.0 (2025-11-24)
Battery: langchain/v5-c, 7 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: A control arm parked by the same-month bar: langchain 1.3.0 shipped twelve days into this subject's stated cutoff month, so its three reproduced failures - the `transformers` denial across tasks 1, 5 and 7, and `v2` as the `astream_events` ceiling - are recorded and charge nothing. It passed the floor and the control sibling, which is what makes its denials usable as evidence that 1.3.0's additions are not derivable. The battery's unplanned result is here: asked about `extras` (1.2.0, five months below its cutoff) this arm denied the parameter exists at all, which is a chargeable miss on a properly designated arm and is queued as one.

--- non-finding [miss] create_agent(transformers=...): A REPRODUCED FAILURE THAT NOTHING CHARGES, AND THE MOST EMPHATIC DENIAL IN THE BATTERY. Task 1: "no". Task 5: "There is no stream-transformer registration parameter on `create_agent`, and no scope-aware transformer-factory registry on the compiled graph that I'm aware of in any release I know." Task 7 goes furthest: "I can't name one, because as far as I know it never happened ... If you were told a specific release added this, I'd treat that claim as unverified." The arm then flagged its own exposure, unprompted: "my 'no' answers in tasks 1, 2(a), 4(a) and 7 are assertions that a thing does not exist, which is exactly the kind of claim a four-month knowledge gap can invalidate."
--- non-finding [miss] astream_events(version="v3") on a create_agent agent: "v2", with the explicit ceiling claim the other arms only implied: "I know of no `v3`, and if one shipped after my cutoff I would not know about it." A correctly bounded statement about its own ignorance attached to a wrong answer to the question asked.
--- non-finding [miss] tool extras: THE 11k-i PAIR FOUND A CHARGEABLE MISS THE BATTERY WAS NOT DESIGNED TO CHARGE. Task 4(a): "no" to `extras` existing, "no" to it having been deprecated - in the sense the arm spelled out itself, "nothing to deprecate". It then listed the `@tool` parameters it believes exist ("name_or_callable, description, return_direct, args_schema, infer_schema, response_format, parse_docstring, error_on_invalid_docstring") and said "I'd bet against it". `extras` is real, shipped 1.2.0, and is present and undeprecated in langchain-core 1.6.2 (`tools/base.py`, `extras: dict[str, Any] | None = None`, with the `@tool(extras={...})` example in its own docstring).
--- non-finding [correct] create_agent stream-mode parameter (does not exist): TASK 2, THE CONTROL SIBLING: "no", correct, with the same true-but-undocumented Pregel `stream_mode` attribute volunteered and correctly hedged ("isn't a documented part of the `create_agent` contract, so I would not ship it as the primary mechanism"). Three of five arms reached for that attribute independently and none of them mistook it for the parameter the question asked about.
--- non-finding [correct] create_agent floor probe (1.0.0): TASK 3, THE FLOOR PROBE, PASSED, including the detail that `model` also accepts a "provider:model-id" string and that `@tool` is importable from `langchain_core.tools` and re-exported as `langchain.tools`. TASK 4(b) `middleware` is also correct and richly described (hook decorators, `SummarizationMiddleware`, `HumanInTheLoopMiddleware`, `PIIMiddleware`, `ModelFallbackMiddleware`, GA late October 2025). This control is NOT discounted.

==============================================================================
RUN langchain--claude-opus-5--v6-a--2026-09-06
What Claude Opus 5 gets wrong about langchain — battery v6-a, tested 2026-09-06
URL: https://stalepriors.com/runs/langchain--claude-opus-5--v6-a--2026-09-06
JSON: https://stalepriors.com/data/langchain/opus-5-v6-a.json
Library: langchain 1.4.0 (pypi), verified 2026-09-06
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.0.0 (2025-10-17), lag ~7 months
Oldest release it could not place: 1.1.0 (2025-11-24)
Battery: langchain/v6-a, 6 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The pre-registered charging arm for the langchain 1.2.0 tool-`extras` window, and it charged. Task 1 denied that a tool has any first-class place for provider-specific fields; task 4 rebuilt the Anthropic tool definition by hand and spliced `cache_control` and `defer_loading` into the copy; task 6 said no release has ever added such a place. `extras` has existed since langchain-core 1.2.0 on 2025-12-12, five months below this arm's stated cutoff. The workaround was executed against the shipped packages and it does deliver both fields, which is why the finding is S3 rather than LF26's S2 — the cost is a tool defined twice and dispatch kept in sync by hand, not a silently dropped provider instruction. The draw passed the floor probe, answered the half-real sibling correctly and reached for the right converters, got both `response_format` verdicts right, and produced no fabricated deprecation. It also hedged the wrong answer accurately in both places it gave it, which is the most calibrated wrong verdict in the battery.

--- F1 [S3 deprecated] Denies that a LangChain tool has any place of its own for provider-specific fields, then rebuilds the tool definition by hand — the verdict, the artefact and the attribution all wrong in the same direction
API: @tool(extras={...})
Changed in langchain 1.2.0 (2025-12-15), kind: added
Chargeability: langchain 1.2.0 shipped 2025-12-15 (the artifact, langchain-core 1.2.0, on 2025-12-12); this draw states a May 2026 cutoff, five months later and not the same month, so the fairness rule and the same-month bar both clear. The surface is above this subject's measured boundary on this library (1.0.0, 2025-10-17). This is the pre-registered charging arm and tasks 1, 4 and 6 are pre-registered probes on this surface. **One finding, three artefacts** (JOURNAL/062): the pre-registration graded the verdict (task 1) and the artefact (task 4) independently, and the attribution question (task 6) asked the same belief a third way; all three came back wrong in the same direction, which is one belief measured three times. **Scored S3, not LF26's S2**, because the workaround this draw shipped was executed against the installed packages and it *works* — see `impact`.
Model belief: Task 1, single word on its own line: "no", glossed "To my knowledge there is no per-tool, first-class, documented slot for provider-specific fields. `BaseTool` has `metadata`, but that is callback/tracing metadata and is never serialized into the tool definition sent to the provider. The route people actually use is to hand `bind_tools` a raw dict instead of the tool object." Task 6, on which release first gave a tool such a place: "To my knowledge, no release has done so. Through everything I can describe, provider-specific fields reach the wire only by bypassing the tool object — a raw dict handed to `bind_tools`/`.bind`." The MECHANISM line the battery required at the end of task 4: "`bind_tools` (raw Anthropic tool dict passed through; `.bind(tools=...)` as the strict-passthrough fallback)". The draw hedged its own answer accurately in both places — "this is exactly the kind of thing that could have been added and that I would not reliably know about", and "if something like a `provider_extras` / `extra_body` slot on `BaseTool` or `@tool` landed after my reliable recall window, I would not know it, and given how much churn this area has seen I would not bet heavily against it" — which is a calibrated hedge attached to a wrong verdict, not a retraction of it.
Wrong: # The artefact from task 4: the capability is denied, so the tool definition is
# rebuilt by hand and the provider fields are spliced into the copy.
from langchain_core.utils.function_calling import convert_to_openai_tool

@tool
def search_docs(query: str) -> str:
    """Search the internal documentation and return matching passages."""
    return f"...results for {query}..."

fn = convert_to_openai_tool(search_docs)["function"]

anthropic_tool = {
    "name": fn["name"],
    "description": fn["description"],
    "input_schema": fn["parameters"],
    "cache_control": {"type": "ephemeral"},
    "defer_loading": True,
}

llm = ChatAnthropic(model="claude-sonnet-4-5-20250929").bind_tools([anthropic_tool])
ai = llm.invoke("What do the docs say about retry backoff?")

# The bound dict is only the schema; execution still goes through the @tool object.
tools_by_name = {search_docs.name: search_docs}
for call in ai.tool_calls:
    tool_message = tools_by_name[call["name"]].invoke(call)
Correct: @tool(extras={"cache_control": {"type": "ephemeral"}, "defer_loading": True})
def search_docs(query: str) -> str:
    """Search the internal documentation and return matching passages."""
    ...

llm = ChatAnthropic(model="claude-sonnet-4-5").bind_tools([search_docs])
Impact: Executed against the installed packages on 2026-09-06 (langchain-core 1.6.2, langchain-anthropic 1.7.1), and the result is why this is S3 rather than LF26's S2. `convert_to_anthropic_tool` on this draw's hand-built dict returns `{'name': 'search_docs', 'description': ..., 'input_schema': {...}, 'cache_control': {'type': 'ephemeral'}, 'defer_loading': True}` — both provider fields **do** reach the wire, because `AnthropicTool` is a `TypedDict` and an already-Anthropic-shaped dict is copied whole. So the denial does not silently drop the provider instruction the way LF26's three recorded wrong forms do (`@tool(extras={'anthropic': {...}})` was executed in the same session and both fields were dropped by the `_ANTHROPIC_EXTRA_FIELDS` filter). What the denial costs is the thing the draw itself spelled out: the tool is now defined twice, once as a callable and once as a schema, the `name` has to be kept in sync by hand or dispatch breaks, and a separate `tools_by_name` lookup is needed to execute the call the model returns — all of it replaced by ten characters of `extras=` since December 2025. The draw also predicted its own uncertainty about the passthrough ("whether `ChatAnthropic.bind_tools` passes unknown keys on an already-Anthropic-shaped dict through verbatim... if it strips them, the guaranteed-passthrough fallback is `model.bind(tools=[...])`"): it does pass them through.
Source: https://docs.langchain.com/oss/python/releases/changelog (2025-12-15) — "Simplified support for provider-specific tool parameters and definitions via a new extras attribute on tools."
Source: https://files.pythonhosted.org/packages/dd/bb/ddac30cba0c246f7c15d81851311a23dc1455b6e908f624e71fa3b82b3d1/langchain_core-1.2.0-py3-none-any.whl (2025-12-12) — "extras: dict[str, Any] | None = None"
Source: https://files.pythonhosted.org/packages/58/41/6db768d4b208a33b4f09d5415e617d489f68167bb5dd27f87c7a49d13caf/langchain_core-1.1.3-py3-none-any.whl (2025-12-09) — "response_format: Literal["content", "content_and_artifact"] = "content","
Source: https://files.pythonhosted.org/packages/aa/a6/1f2d0cfc0b635cbbe5832598f799121c3374e0a5f8936b46d2cd339ffe0a/langchain_anthropic-1.7.1-py3-none-any.whl (2026-09-03) — "for key, value in tool.extras.items():
                if key in _ANTHROPIC_EXTRA_FIELDS:
                    # all are populated top-level
                    anthropic_formatted[key] = value"

--- non-finding [correct] a provider-schema-format parameter on @tool (the sibling that does not exist): Task 2(a): "no" — correct, and no finding may be charged from this task in either direction. The draw then reached for the nearby true thing exactly as the half-real sibling was designed to test (JOURNAL/063): `convert_to_openai_tool` from `langchain_core.utils.function_calling`, `convert_to_anthropic_tool` in `langchain_anthropic` at "moderate but not full" confidence, and "each `ChatX.bind_tools()` also does this conversion internally for its own provider, so binding to that model *is* the format selection". Both converters were verified present at langchain-core 1.6.2 and langchain-anthropic 1.7.1, so the hedged one was right and the hedge was unnecessary.
--- non-finding [correct] create_agent (the floor probe, langchain 1.0.0): Task 3: passed. `from langchain.agents import create_agent`, `system_prompt=`, tools as `@tool`-decorated functions, invoked with `{"messages": [...]}`, and the import path named in one line as "LangChain 1.0's LangGraph-backed replacement for `AgentExecutor` / `create_tool_calling_agent`". It also volunteered the 1.0 middleware concept unprompted. One hedge that turned out to be unnecessary: "less confident whether the keyword is `system_prompt` or `prompt`" — it is `system_prompt`, and the draw wrote it.
--- non-finding [correct] @tool(response_format="content_and_artifact") — the supplied-name control half: Task 5(b): "yes" available, "no" never deprecated — both correct, verified present at langchain-core 0.3.22 (2024-12-06) and at 1.6.2. Dated to "langchain-core around 0.2.x (roughly mid-2024) alongside `ToolMessage.artifact`", which is right. The draw also flagged the collision with the unrelated chat-model `response_format`, unprompted. No finding may be charged from this surface in either direction.
--- non-finding [context] the fabricated-deprecation probe (BACKLOG 11k-i, rebuilt): Task 5(a), on the name this draw produced itself in task 4: "yes" available, "no" never deprecated. No fabrication. Consistent with pre-registered prediction P3 — the `better-auth/v7` shape needs a retrieved name that is *correct and unfamiliar*, and `bind_tools` is a name this subject believes in and is right about.

==============================================================================
RUN langchain--claude-opus-5--v6-b--2026-09-06
What Claude Opus 5 gets right about langchain — battery v6-b, tested 2026-09-06
URL: https://stalepriors.com/runs/langchain--claude-opus-5--v6-b--2026-09-06
JSON: https://stalepriors.com/data/langchain/opus-5-v6-b.json
Library: langchain 1.4.0 (pypi), verified 2026-09-06
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.0.0 (2025-10-17), lag ~7 months
Oldest release it could not place: 1.1.0 (2025-11-24)
Battery: langchain/v6-b, 6 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The blind twin of `v6-a`, and it agreed with it on every graded quantity: the same "no" verdict on task 1, the same hand-rebuilt Anthropic dict in task 4, the same "no release has done so" on task 6, the same four correct verdicts on task 5, the same floor pass and the same correct denial of the sibling. It stated the same May 2026 cutoff and the same 1.0.0 boundary. Its distinctive contribution is the artefact: an explicit enumeration of `BaseTool`'s fields that is exactly the pre-1.2.0 set with `extras` the only omission. Charges nothing; the failure is charged as F1 on `v6-a`.

--- non-finding [miss] @tool(extras={...}): THE SAME DENIAL AS THE SIBLING, IN ALL THREE PLACES, AND WITH THE SHARPEST ARTEFACT IN THE BATTERY. Task 1: "no". Task 6: "To my knowledge, no release has done so" — followed by an explicit enumeration of what it believes `BaseTool`'s fields to be: "`name`, `description`, `args_schema`, `return_direct`, `response_format`, `metadata`, `tags`, `callbacks`, `handle_tool_error`/`handle_validation_error` — `metadata` and `tags` are callback/tracing metadata and are not serialized into the tool definition sent to any provider. Provider-specific tool-definition fields have always had to be smuggled in as a raw dict through `bind_tools`." That list is the pre-1.2.0 field set with `extras` the only omission, which is the same shape as `v5-c`'s seven-parameter enumeration of `@tool`. Task 4's MECHANISM line: "bind_tools (raw provider-format dict passed through, not a tool attribute)", and the code is the same hand-rebuilt Anthropic dict as the sibling's, verified to deliver both fields. Like the sibling it hedged accurately — "This is the answer I'm least confident in... something like a `provider_extras` / `extra_body`-style per-tool field could plausibly have landed after my cutoff. Verify against the current `BaseTool` API reference before relying on my 'no.'" Both draws of this pair reached the same wrong verdict by the same route and flagged the same doubt about it.
--- non-finding [correct] a provider-schema-format parameter on @tool (the sibling that does not exist): Task 2(a): "no" — correct. Reached for both nearby true things by name, `convert_to_openai_tool` in `langchain_core.utils.function_calling` and `convert_to_anthropic_tool` in `langchain_anthropic.chat_models`, and stated the mechanism correctly: "There is no `@tool(format=\"anthropic\")` knob; the provider is chosen by which chat model you bind to." Both converters verified present. No charge from this task in either direction.
--- non-finding [correct] create_agent (the floor probe, langchain 1.0.0): Task 3: passed. `from langchain.agents import create_agent`, `system_prompt=`, and it volunteered both the plain-callable acceptance and the historical parameter names it replaced (`prompt` / `state_modifier` on `langgraph.prebuilt.create_react_agent`), plus the fact that the legacy path now lives in `langchain-classic`.
--- non-finding [correct] @tool(response_format="content_and_artifact") — the supplied-name control half: Task 5(b): "yes" available, "no" never deprecated — both correct. Dated to langchain-core 0.2.x, mid-2024, alongside `ToolMessage.artifact`; verified present at 0.3.22 and unchanged at 1.6.2. Flagged the same-name collision with the chat-model `response_format` unprompted.
--- non-finding [context] the fabricated-deprecation probe (BACKLOG 11k-i, rebuilt): Task 5(a), on the self-produced name `bind_tools`: "yes" available, "no" never deprecated, with a correct and unprompted distinction — "its *predecessors* — `bind_functions`, `ChatOpenAI(functions=...)` — were deprecated, but that's a different name." No fabrication. Consistent with P3.

==============================================================================
RUN langchain--claude-opus-5--v1--2026-08-31
What Claude Opus 5 gets wrong about langchain — battery v1, tested 2026-08-31
URL: https://stalepriors.com/runs/langchain--claude-opus-5--v1--2026-08-31
JSON: https://stalepriors.com/data/langchain/opus-5.json
Library: langchain 1.3.18 (pypi), verified 2026-08-31
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.0.0 (2025-10-17), lag ~7 months
Oldest release it could not place: 1.1.0 (2025-11-24)
Battery: langchain/v1, 11 tasks, tool uses during test: 0
Tested: 2026-08-31

Summary: Eleven code tasks, eleven pieces of working LangChain v1. `create_agent` with `system_prompt`, middleware via `wrap_model_call`, `ToolRuntime` for run-scoped context, `ToolStrategy` for structured output, the `"model"` node name in the stream filter, `.text` as a property, and a deliberate refusal to reach for `RetrievalQA` or the memory classes. One finding, and like Tailwind it is not about code: version attribution stops at 1.0.0 (2025-10-17) — it can describe that release and cannot describe 1.1.0 or 1.2.0, both of which shipped inside the subject's stated 2026-05 window. Battery v1 does not probe those releases' own features, so what v1 measures is a dating failure and not a demonstrated feature gap. AMENDED 2026-09-01: battery v3 did probe them, and found the gap — this subject failed all three surviving probes into 1.1.0 (JOURNAL/022). The sentence above still describes v1's own scope correctly; it no longer implies that no gap exists. Seven months of lag — its best result in the Index, on the library where the other subject with the same architecture family lands thirteen months behind it. Disclosed self-test — the operator model is the subject.

--- F1 [S4 wrong-metadata] Version knowledge stops at 1.0.0 while 1.1.0 and 1.2.0 shipped inside its window
Changed in langchain 1.1.0 (2025-11-24), kind: version-fact
Chargeability: Anchored to 1.1.0 (2025-11-24), the first release the subject cannot describe — not to the current 1.3.18. 1.1.0 precedes the stated 2026-05 cutoff by roughly six months, and 1.2.0 (2025-12-15) by five. The same finding would NOT be chargeable against a subject whose cutoff preceded 2025-11-24.
Model belief: "Version numbers I have seen referenced: the `1.0.x` line for certain, and I believe the line continued into `1.1.x` and possibly further during early 2026. I do not trust myself to name a specific latest patch number — if I said '1.2.3' I would be fabricating precision." It could describe 1.0.0's contents in accurate detail and nothing after it.
Impact: Low on its own — nothing in 1.1.0 or 1.2.0 breaks 1.0 code. Both are additive: model profiles on chat models, `SystemMessage` accepted for `system_prompt`, model-retry middleware, tool `extras`, strict schema adherence for `ProviderStrategy`. The value is diagnostic. This subject has the latest cutoff in the Index and, on this library, its smallest lag yet: seven months against thirteen on Tailwind and seven on Next.js.
Source: https://docs.langchain.com/oss/python/releases/changelog (2025-11-25) — "Chat models now expose supported features and capabilities through a .profile attribute."
Source: https://pypi.org/pypi/langchain/json

--- non-finding [correct] langchain.agents.create_agent: Task 2: `from langchain.agents import create_agent` and `from langchain.tools import tool`, with a note that the result is a compiled LangGraph graph whose state is `{"messages": [...]}`.
--- non-finding [correct] create_agent(system_prompt=...): Task 3: `system_prompt=`, with the migration history stated correctly — "in the older `langgraph.prebuilt.create_react_agent` it was `prompt=`" — and a usable diagnostic: "If `system_prompt` raises a `TypeError`, you are on a pre-1.0 install."
--- non-finding [correct] langchain.chains (LLMChain, ConversationChain, RetrievalQA): Task 4: hand-written retrieve-then-answer with `langchain_text_splitters` and `init_embeddings`, and an explicit refusal of the removed chains — "I did not reach for `RetrievalQA` or `ConversationalRetrievalChain` ... they live in `langchain-classic` if you truly need them."
--- non-finding [correct] langchain.memory (ConversationBufferMemory): Task 5: LangGraph checkpointer keyed by `thread_id`, with the mental model stated outright — "memory is a LangGraph checkpointer ... not a `ConversationBufferMemory` object hanging off a chain. The old `memory=` classes are gone from `langchain` 1.x."
--- non-finding [correct] langchain.hub: Task 6: `langsmith.Client().pull_prompt(...)`, with the removal called out — "the old `from langchain import hub; hub.pull(\"...\")` is the 0.x way and is not in `langchain` 1.x". The only subject to state the removal rather than trip over it.
--- non-finding [correct] create_agent(response_format=...): Task 7: `ToolStrategy(WeatherAnswer)` from `langchain.agents.structured_output`, the `result["structured_response"]` key, and the correct nuance that a bare schema also works and lets the framework pick.
--- non-finding [correct] run-scoped context (context= / context_schema=): Task 8: `ToolRuntime[Context]` from `langchain.tools` plus `context_schema` and `context=` at invoke time, with the security property stated correctly — the parameter is stripped from the schema shown to the model.
--- non-finding [correct] create_agent(pre_model_hook=...) / post_model_hook: Task 9: `@wrap_model_call` middleware, chosen over `before_model` for the stated reason that it shapes only what is sent and leaves persisted state intact — plus an orphaned-`ToolMessage` guard neither other subject produced.
--- non-finding [correct] agent streaming node name: Task 10: filters on `langgraph_node == "model"`, and names the trap explicitly — "in the older `langgraph.prebuilt.create_react_agent` it was `\"agent\"`".
--- non-finding [correct] message.text: Task 1 and 11: `.text` used as a property throughout, with the version history attached — "`response.text` is a property on `AIMessage` in 1.x ... if `.text` gives you a bound method, you're on an older version".
--- non-finding [imprecision] ChatAnthropic(max_tokens=...): Task 11 stated the Anthropic default as "a small default (1024 in the versions I know)". 1.0.0 changed that default to a per-model value.
--- non-finding [imprecision]: Dated the 1.0 GA as "roughly October 22, 2025"; PyPI has the files uploaded 2025-10-17 and the vendor changelog labels the entry Oct 20, 2025.
--- non-finding [context]: Asked for its cutoff, it separated the nominal date from the useful one unprompted: "my *reliable, detailed* knowledge of this particular library is noticeably older than that — it thins out sharply after the 1.0 launch in late 2025 ... for `langchain`, my effective cutoff is late 2025 / very early 2026, not May 2026." That is precisely what the measurement found, and it is the metric this dataset exists to produce.

==============================================================================
RUN langchain--claude-sonnet-5--v1r-a--2026-09-01
What Claude Sonnet 5 gets right about langchain — battery v1r-a, tested 2026-09-01
URL: https://stalepriors.com/runs/langchain--claude-sonnet-5--v1r-a--2026-09-01
JSON: https://stalepriors.com/data/langchain/sonnet-5-v1r-a.json
Library: langchain 1.3.18 (pypi), verified 2026-08-27
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 1.0.0 (2025-10-17), lag ~3 months
Oldest release it could not place: 1.1.0 (2025-11-24)
Battery: langchain/v1r-a, 11 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: Replicate A of `langchain/v1` against Sonnet 5, prompt unchanged. It placed its describable boundary at langchain 1.0.0 (2025-10-17) and described the 1.0 rework accurately — thirteen months later than `langchain/v1` recorded for the same model on the same battery one day earlier, and thirteen months later than its own concurrent twin `v1r-b`. Pre-registered outcome C: the two replicates disagree with each other. The instrument that produces every knowledge boundary in the Index is not single-valued under a fixed prompt. No findings are charged here; the code half is reported as prose because `langchain/v1` already carries this subject's findings. Worth noting against the alarm: the boundary self-report moved thirteen months while the generated code stayed largely stale in both draws — this draw still wrote `from langchain import hub` and `langgraph.prebuilt.create_react_agent`.

--- non-finding [correct]: Direct question (a), the measured quantity and the reason this run exists. This draw placed its describable boundary at langchain 1.0.0 (2025-10-17) and described the contents correctly: `langchain.agents.create_agent` as the primary agent constructor, `AgentExecutor`/`initialize_agent` deprecated, the top-level package slimmed with legacy code moved to `langchain-classic`, and a matching LangGraph 1.0. Every one of those is true of 1.0.0 per the vendor's own v1 release notes and migration guide, so this is content-level knowledge rather than a recognised version string.
--- non-finding [context]: Tasks 1-11 produced code but no charged findings, per the v1r pre-registration: `langchain--claude-sonnet-5--v1--2026-08-31` already carries this subject's langchain findings and counting the same failure twice would inflate the dataset. What the code did is still evidence and is reported in the markdown. In short: despite placing its boundary at 1.0.0, this draw still wrote `from langchain import hub` (task 6) and `langgraph.prebuilt.create_react_agent` (task 10), both moved or deprecated at 1.0.0, while avoiding `create_react_agent` in tasks 2, 3 and 5, where it hand-rolled a `bind_tools` loop and used `RunnableWithMessageHistory` instead.

==============================================================================
RUN langchain--claude-sonnet-5--v1r-b--2026-09-01
What Claude Sonnet 5 gets right about langchain — battery v1r-b, tested 2026-09-01
URL: https://stalepriors.com/runs/langchain--claude-sonnet-5--v1r-b--2026-09-01
JSON: https://stalepriors.com/data/langchain/sonnet-5-v1r-b.json
Library: langchain 1.3.18 (pypi), verified 2026-08-27
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 0.3.0 (2024-09-13), lag ~16 months
Oldest release it could not place: 1.0.0 (2025-10-17)
Battery: langchain/v1r-b, 11 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: Replicate B of `langchain/v1` against Sonnet 5, prompt unchanged. It reproduced `langchain/v1` exactly — boundary at 0.3 (2024-09-13), 1.0 known only as a name it cannot describe — and rewrote the same 0.3-era stack: `langgraph.prebuilt.create_react_agent` with `prompt=`, `pre_model_hook=`, `from langchain import hub`. Taken alone this run says the instrument is fine. Taken with its concurrent twin `v1r-a`, which placed the same model's boundary thirteen months later on the same prompt, it says the opposite: the boundary is a draw, not a measurement. One code-level divergence from v1 is also recorded — task 10's stream filter, v1's designed S2, did not reproduce here.

--- non-finding [correct]: Direct question (a), the measured quantity. This draw placed its describable boundary at langchain 0.3 (~September 2024) and named the 0.3 contents correctly (Pydantic v1 dropped, minimum Python raised, integrations split into `langchain-community` and partner packages). It described 1.0 as a name it has heard and cannot describe. That reproduces `langchain/v1` exactly: 0.3.0 (2024-09-13), first undescribable 1.0.0 (2025-10-17).
--- non-finding [context]: Tasks 1-11 produced code but no charged findings, per the v1r pre-registration. This draw reproduced the v1 stack closely: `langgraph.prebuilt.create_react_agent` with `prompt=` (tasks 2, 3), `pre_model_hook=` (task 9), `from langchain import hub` (task 6), and a `MemorySaver` checkpointer (task 5) -- the same 0.3-era shape `langchain/v1` charged. It diverged from v1 on task 10, filtering `astream_events` on `on_chat_model_stream` rather than on the `"agent"` node, so v1's designed S2 (the stream filter that silently matches nothing after the node rename) did not reproduce in this draw.

==============================================================================
RUN langchain--claude-sonnet-5--v2--2026-09-01
What Claude Sonnet 5 gets wrong about langchain — battery v2, tested 2026-09-01
URL: https://stalepriors.com/runs/langchain--claude-sonnet-5--v2--2026-09-01
JSON: https://stalepriors.com/data/langchain/sonnet-5-v2.json
Library: langchain 1.3.18 (pypi), verified 2026-09-01
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff not stated
Battery: langchain/v2, 5 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: The control arm, and it did its job by breaking the test. Sonnet 5's langchain knowledge stops before 1.0 — v1 measured it at 0.3.0, and here it said its reliable knowledge ends "early-to-mid 2025" and that it could not vouch for `ProviderStrategy`, `defer_loading` or "the exact shape of `.profile`" being real shipped names, calling them "my best reconstruction of what this would plausibly be called given the direction I saw." It then scored two of four: it produced `model.profile` with `image_inputs` and a `SystemMessage` carrying `cache_control` as `system_prompt`, both correct, both from a subject that cannot have known them. Two of four is the pre-registered threshold at which the whole battery is declared UNINFORMATIVE — the probes are answerable by inference from general framework shape, so the test arms' three-of-four scores are not evidence of knowledge. The hypothesis is neither supported nor falsified. The subject told us why, unprompted, in its own words.

--- F1 [S2 silently-wrong] Routes provider-specific tool parameters through `metadata=`, a real field whose documented destination is callback handlers, not the provider
API: tool extras
Changed in langchain 1.2.0 (2025-12-15), kind: added
Chargeability: Chargeable against the 2026-01 cutoff recorded for this subject in its v1 run. The subject disowned that number in this session (see cutoff_basis) and offered a behavioural estimate of early-to-mid 2025, which would be earlier than 1.2.0 and would make this non-chargeable. Charged on the stated cutoff of record rather than on a self-assessment offered mid-battery, and flagged here so the reader can discount it.
Model belief: "I don't know which release introduced this, or whether the mechanism I wrote (a `metadata` dict on `@tool`) is actually how it's implemented versus some other API. I'm giving it as my best-guess implementation, not a recalled fact."
Wrong: @tool(metadata={"cache_control": {"type": "ephemeral"}})
def account_lookup(account_id: str) -> str:
    ...

@tool(metadata={"anthropic": {"defer_loading": True}})
def bulk_schema_export(payload: dict) -> str:
    ...
Correct: @tool(extras={"cache_control": {"type": "ephemeral"}})
def account_lookup(account_id: str) -> str:
    ...

@tool(extras={"defer_loading": True})
def bulk_schema_export(payload: dict) -> str:
    ...
Impact: `metadata` is a genuine `BaseTool` field, which is what makes this worse than an invented name: the shipped docstring says it "will be associated with each call to this tool, and passed as arguments to the handlers defined in `callbacks`". It goes to callbacks, never to the provider payload. The provider instructions are silently discarded and the field they were put in is doing something else entirely.
Scope note: DEVIATION FROM THE PRE-REGISTRATION, disclosed. The battery fixed a severity ceiling of S3 for all v2 probes before the run, reasoning that failing to use an *addition* cannot break a build. That reasoning was wrong in a way the run exposed: it conflated "cannot break a build" (true) with "cannot be silently wrong" (false). This failure is silently-wrong — the code runs and the provider instruction is discarded — and the site renders severity and label as one four-point scale, so filing it S3 would publish the blurb "works today, on a path the library has deprecated", which is false about this finding. Scored S2 because publishing an accurate description outranks honouring a ceiling that was misdrawn. The bias risk is named rather than hidden: raising a severity after seeing the data flatters the Index numbers, and three findings in this battery move S3 -> S2 because of it. The standing rule is amended (BACKLOG.md) so future ceilings are set by failure mode, not by change kind. Not executed: established from the shipped package, not from a run.
Source: https://docs.langchain.com/oss/python/releases/changelog (2025-12-15) — "Simplified support for provider-specific tool parameters and definitions via a new extras attribute on tools."
Source: https://files.pythonhosted.org/packages/8e/25/f50dd65673c819aa33d3c34df58c115dbb6ec627d19f93e6e401dd0fc8d7/langchain_core-1.6.1-py3-none-any.whl (2026-08-27) — "This metadata will be associated with each call to this tool,
    and passed as arguments to the handlers defined in `callbacks`."

--- non-finding [correct] model profiles (.profile): P1 — `getattr(model, "profile", {}) or {}` then `profile.get("image_inputs")`. Graded a pass by the letter of the pre-registered rule, and it is the single most important result in this battery: the subject whose langchain knowledge demonstrably stops before 1.0 produced the langchain-core 1.1.0 capability API correctly, and then said in question (a) that it was not confident "the exact shape of `.profile`" was a real shipped name — that it was "my best reconstruction of what this would plausibly be called given the direction I saw". The pass is a guess that landed.
--- non-finding [correct] SystemMessage as system_prompt: P2 — passes a `SystemMessage` with a `cache_control` content block as `system_prompt`, correct against the shipped `str | SystemMessage` signature. A second guess that landed, from the same subject.
--- non-finding [imprecision] model retry middleware: P3 — reaches for `my_model.with_retry(retry_if_exception_type=(RateLimitError, APITimeoutError), wait_exponential_jitter=True, stop_after_attempt=5)` and passes the wrapped object to `create_agent`. Pre-registered as a partial: the LCEL `with_retry` route predates 1.1.0 and the subject correctly identified it as old. It never reaches `ModelRetryMiddleware`, and the subject said plainly it did not know whether a dedicated model-retry middleware exists.
--- non-finding [imprecision] ProviderStrategy strict: P5 (supplementary, not counted) — `ProviderStrategy(Verdict)` without `strict=True`, the same partial all three subjects produced.
--- non-finding [context] multimodal content blocks: P1's fallback path uses the provider-native `{"type": "image_url", "image_url": {"url": ...}}` block form, which langchain 1.0.0 replaced with a standard `{"type": "image", "url": ...}` block (fact LF17). That is a 1.0.0-era misbelief and this subject's v1 run already measures its 1.0.0 gap; v2 does not probe 1.0.0 and does not re-charge it.
--- non-finding [context]: Question (c), a belief datum: "I don't know" or low confidence on all three items, which is the honest answer and matches its measured position below the 1.0 floor. Notably it correctly identified `Runnable.with_retry()` as an LCEL-era method "present since roughly the 0.1.x/0.2.x days" — its accurate attributions are all about the era it actually knows.

==============================================================================
RUN langchain--claude-sonnet-5--v3--2026-09-01
What Claude Sonnet 5 gets wrong about langchain — battery v3, tested 2026-09-01
URL: https://stalepriors.com/runs/langchain--claude-sonnet-5--v3--2026-09-01
JSON: https://stalepriors.com/data/langchain/sonnet-5-v3.json
Library: langchain 1.3.18 (pypi), verified 2026-09-01
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Battery: langchain/v3, 4 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: The control arm, and it did its job — expensively for the battery and cheaply for the Index. Predicted 0 of 4; scored 1 of 4, and the one was P2, the model-capability key. Under the rule fixed before the run, a single control pass condemns the probe that produced it, so P2 was struck from all three arms and the battery re-read on three probes. On those three this subject failed all three: it built its middleware around `modify_model_request`, a hook that shipped in no released 1.x, so the middleware never fires; it said the bare retry middleware re-raises; and it committed to a 25-superstep ceiling. Two integrity notes are on the record rather than in a footnote: it stated a langchain boundary thirteen months later than its own v1 run, which weakens the floor this control was meant to provide; and it was the only subject of three to notice that the system-instruction field had been renamed at all, while being the only one whose code fails outright.

--- F1 [S2 silently-wrong] Builds middleware around `modify_model_request`, a hook that exists in no released langchain 1.x — the middleware is registered and never fires
API: AgentMiddleware.modify_model_request
Changed in langchain 1.0.0 (2025-10-17), kind: removed
Chargeability: The hook was gone by langchain 1.0.0 (2025-10-17), inside the subject's stated 2026-01 window. Not a duplicate of any v1 finding: `langchain/v1` charged this subject for `langgraph.prebuilt.create_react_agent` and `langchain.hub`, and never touched the middleware hook set.
Model belief: "I'm confident the hook-based middleware pattern and modify_model_request name are right in spirit; I'm less sure system_prompt is still the exact current field name."
Wrong: class DateStampedInstructionsMiddleware(AgentMiddleware):
    def modify_model_request(self, request: ModelRequest, state, runtime) -> ModelRequest:
        base = request.system_prompt or ""
        stamp = f"\n\nToday's date is {date.today().isoformat()}."
        request.system_prompt = base + stamp
        return request
Correct: class DateStampedInstructionsMiddleware(AgentMiddleware):
    def wrap_model_call(self, request, handler):
        base = request.system_message.text if request.system_message else ""
        stamp = f"\n\nToday's date is {date.today().isoformat()}."
        return handler(
            request.override(system_message=SystemMessage(content=base + stamp))
        )
Impact: Nothing raises. Python permits any method on a subclass, and `create_agent` only ever calls the hooks it knows about, so the middleware is constructed, passed in, listed in the agent's middleware, and never invoked. Every model call goes out without the date. The failure is invisible at construction, invisible at import, and only shows up as an agent that does not know what day it is.
Scope note: The same snippet contains a second stale belief — it assigns `request.system_prompt = ...` in place, which 1.1.0 deprecated in favour of `request.override(...)`. It is deliberately NOT charged as a separate finding: the assignment is unreachable, because the method it sits in is never called. Charging both would double-count one wrong answer, and the Index would rather under-count than pad. Recorded here so the second defect is on the record without being on the scoreboard.
Source: https://files.pythonhosted.org/packages/f7/04/374f6014ed6959dbdab92962c2b09e4d0223ed6a82f65694870b46d2c13f/langchain-1.3.18-py3-none-any.whl (2026-08-27) — "def before_agent(self, state: StateT, runtime: Runtime[ContextT]) -> dict[str, Any] | None:
...
    def before_model(self, state: StateT, runtime: Runtime[ContextT]) -> dict[str, Any] | None:
...
    def wrap_model_call(
...
    def after_model(self, state: StateT, runtime: Runtime[ContextT]) -> dict[str, Any] | None:"
Source: https://docs.langchain.com/oss/python/migrate/langchain-v1 (2025-10-17) — "The v1 middleware surface is the AgentMiddleware hook set used by create_agent; the alpha-era modify_model_request signature did not ship in the 1.0 release line."

--- F2 [S2 silently-wrong] States that the bare model-retry middleware re-raises when retries run out; the shipped default returns an `AIMessage` and the agent carries on
API: ModelRetryMiddleware defaults
Changed in langchain 1.1.0 (2025-11-24), kind: added
Chargeability: langchain 1.1.0 shipped 2025-11-24, inside every tested subject's stated window.
Model belief: "With defaults, I believe it retries a failed model call 2 additional times before giving up (3 total attempts at that single model-call node), then re-raises the underlying provider exception rather than swallowing it ... I'm fairly confident the shape (bounded retries → exception propagation, not a swallowed error) is right."
Wrong: create_agent(..., middleware=[ModelRetryMiddleware()])
# claimed: 3 calls, then the provider exception propagates out of .invoke()
Correct: agent = create_agent(
    model,
    tools,
    middleware=[ModelRetryMiddleware(on_failure="error")],
)
# or, keeping the default, handle the synthetic reply:
#   the last AIMessage will read "Model call failed after 3 attempts with ..."
Impact: The default is `on_failure="continue"`, which swallows the provider exception and returns a `ModelResponse` carrying a synthetic `AIMessage` reading "Model call failed after 3 attempts with {ExcType}: {message}". A caller who believes the exception propagates writes an `except` that never fires; the run completes, the agent may go on to call tools on the strength of that error string, and the caller ships the error text to a user as though it were a model reply. Re-raising is one keyword away and is not the default.
Scope note: Half-right, and the half that is right is the half that does not matter: the subject named the retry count correctly (2 retries, 3 calls) and got the exhaustion behaviour backwards. Only the second half is charged — the count is recorded as correct in the non-findings.
Source: https://docs.langchain.com/oss/python/releases/changelog (2025-11-24) — "Model retry middleware: New middleware for automatically retrying failed model calls with configurable exponential backoff."
Source: https://files.pythonhosted.org/packages/f7/04/374f6014ed6959dbdab92962c2b09e4d0223ed6a82f65694870b46d2c13f/langchain-1.3.18-py3-none-any.whl (2026-08-27) — "max_retries: int = 2,
        retry_on: RetryOn = default_retry_on,
        on_failure: OnFailure = "continue",
...
        if self.on_failure == "error":
            raise exc
...
        return ModelResponse(result=[ai_msg])"

--- F3 [S2 silently-wrong] States the agent's step ceiling is LangGraph's 25 and prescribes raising it; `create_agent` has set a four-figure limit since 1.1.0
API: create_agent recursion limit
Changed in langchain 1.1.0 (2025-11-24), kind: behavior-changed
Chargeability: langchain 1.1.0 shipped 2025-11-24, inside every tested subject's stated window. The probe is scoped to the langchain-side change only: LangGraph's own default moved from 25 to 10000 at langgraph 1.1.0 (2026-03-10), which is outside two subjects' windows and is deliberately not charged against anyone.
Model belief: "Numeric ceiling I believe is in force by default: 25 — this is the LangGraph recursion_limit default that create_agent's compiled graph inherits ... Confidence: medium-high on the number 25."
Wrong: agent.invoke({"messages": [...]}, config={"recursion_limit": 100})
Correct: agent = create_agent(
    model,
    tools,
    middleware=[ModelCallLimitMiddleware(run_limit=40, exit_behavior="end")],
)
Impact: The prescribed fix does nothing. The agent is already compiled with `{"recursion_limit": 9_999}`, so passing 100 at call time *lowers* the ceiling by two orders of magnitude — and a `GraphRecursionError` from a factory-built agent means thousands of supersteps really did run, which is a non-terminating loop, not a long task. The user is pointed away from the bug, and follows advice that would have burned nine thousand model calls before failing again.
Scope note: The changelog carries no line for this change, so the introducing evidence is the 1.0.0/1.1.0 wheel diff — the artifact itself rather than a note about it. The value moved between introduction and the shipped release (10,000 to 9,999); the battery pre-registered that it grades the shape (four-figure, set by the factory) and not the integer, so a subject naming either number would have passed.
Source: https://files.pythonhosted.org/packages/c4/4d/2758a16ad01716c0fb3fe9ec205fd530eae4528b35a27ff44837c399e032/langchain-1.0.0-py3-none-any.whl (2025-10-17) — "return graph.compile(
        checkpointer=checkpointer,
        store=store,
        interrupt_before=interrupt_before,
        interrupt_after=interrupt_after,
        debug=debug,
        name=name,
        cache=cache,
    )"
Source: https://files.pythonhosted.org/packages/0b/6f/889c01d22c84934615fa3f2dcf94c2fe76fd0afa7a7d01f9b798059f0ecc/langchain-1.1.0-py3-none-any.whl (2025-11-24) — "    ).with_config({"recursion_limit": 10_000})"
Source: https://files.pythonhosted.org/packages/f7/04/374f6014ed6959dbdab92962c2b09e4d0223ed6a82f65694870b46d2c13f/langchain-1.3.18-py3-none-any.whl (2026-08-27) — "# Set recursion limit to 9_999
    # https://github.com/langchain-ai/langgraph/issues/7313
    config: RunnableConfig = {"recursion_limit": 9_999}"

--- non-finding [correct] model profiles (.profile): P2 — the control-arm pass that retired the probe. Reads `getattr(model, "profile", None) or {}` and tests `profile.get("pdf_inputs", False)`: the exact attribute and the exact shipped key, with three layers of guard for a model that reports nothing. It arrived there while rating itself "medium-low on the exact attribute name (`model.profile`) and the exact key (`pdf_inputs`) — I'm confident v1 added *some* capability-descriptor object on chat models for exactly this purpose, less confident I have the literal spelling right." It named a release for it nowhere and got the spelling right anyway.
--- non-finding [correct] ModelRetryMiddleware defaults: P3, first half — "2 additional times before giving up (3 total attempts)", matching the shipped `max_retries: int = 2`. Correct, at low-medium stated confidence, from a subject that also could not name the middleware's release or be sure of its class name.
--- non-finding [context]: THE INTEGRITY NOTE ON THIS RUN. The battery designated this subject a below-floor control on the strength of its v1 measurement, where its langchain version attribution stopped at 0.3.0 (2024-09-13). On question (a) this time it placed itself at "an earlier 1.0 alpha/beta snapshot from roughly mid-2025" — thirteen months later than v1 recorded. The pre-registration said a moved boundary is run-to-run noise to be recorded and never quietly reconciled, so it is recorded: the control arm may sit closer to the test arms than the design assumed, which makes its P2 hit somewhat less surprising and its three misses somewhat less informative as a floor. It does not change the reading — the control condition was written as "a single control pass condemns that probe", and it did.
--- non-finding [context] create_agent recursion limit: Question (c), a belief datum. The subject answered "I do not know" to three of the four attributions and refused to guess version numbers, which is the honest failure mode and is recorded as such. On the fourth it was confidently wrong in the same way both test arms were: "this isn't really something langchain introduced — it's LangGraph's own recursion_limit default (25), which create_agent inherits." Notable against F1: on Task 1 it volunteered "I believe this field was renamed at some point and I'm not certain which side of the rename is current" — the only subject of the three to register that a rename had happened at all, while being the only one to write code that fails outright.
--- non-finding [context]: Question (a) is discussed in the integrity note above rather than here, because it moved. The boundary fields on this run are null and the measurement of record stays langchain--claude-sonnet-5--v1--2026-08-31.

==============================================================================
RUN langchain--claude-sonnet-5--v5-d--2026-09-06
What Claude Sonnet 5 gets right about langchain — battery v5-d, tested 2026-09-06
URL: https://stalepriors.com/runs/langchain--claude-sonnet-5--v5-d--2026-09-06
JSON: https://stalepriors.com/data/langchain/sonnet-5-v5-d.json
Library: langchain 1.4.0 (pypi), verified 2026-09-06
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01, SELF-TEST
Version attribution stops at: 1.0.0 (2025-10-17), lag ~3 months
Oldest release it could not place: 1.1.0 (2025-11-24)
Battery: langchain/v5-d, 7 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: A derivability control four months below langchain 1.3.0. It denied `transformers` in the verdict and refused to invent one in the artefact, and named `v2` as the ceiling - so neither of the release's additions is reachable from what was true before it. The floor and the control sibling both passed, so the control is at full strength. Its `extras` denial is a chargeable miss on a release one month below its own stated cutoff, uncharged only because this arm was designated a control before the draw.

--- non-finding [miss] create_agent(transformers=...): THE DERIVABILITY CONTROL DID NOT DERIVE IT. Task 1 "No", with the 1.0-era parameter list offered as the reason ("`model`, `tools`, `system_prompt`/`prompt`, `middleware`, `checkpointer`, `store`, `response_format`, `state_schema` - nothing that plugs a custom per-scope stream transformer into the graph"). Task 5 declines to invent: "I don't want to fabricate an API surface I'm not sure exists", and ships a callback-handler plus a consumer-side generator instead. Not a chargeable miss - 1.3.0 is four months above this subject's stated cutoff, which is exactly why it was drawn.
--- non-finding [miss] astream_events(version="v3") on a create_agent agent: "v2", with a correct account of the v1 -> v2 fixes. Below the floor, so this is control evidence rather than a miss that counts: no subject in the battery reached v3 by extrapolation, and the two arms furthest below the release did not either.
--- non-finding [miss] tool extras: The second half of the unplanned result. Task 4(a): "No" and "No" - "I'm not aware of an `extras` parameter on `@tool` at all - provider-specific tool parameters in LangChain are typically handled through `model.bind_tools(..., **kwargs)`, tool `metadata`/`tags`, or provider-specific `ToolMessage`/`InputSchema` fields, not a field called `extras`. Since I don't believe it ever existed, 'deprecated/renamed/replaced' doesn't apply." That is the stale belief LF26 was written to correct, reproduced by a second subject in the same battery as `v5-c`'s.
--- non-finding [correct] create_agent stream-mode parameter (does not exist): TASK 2: "No", correct, and the artefact - binding `stream_mode` with `functools.partial` onto the instance - is a working answer to the requirement rather than an invented parameter.
--- non-finding [correct] create_agent floor probe (1.0.0): TASK 3, THE FLOOR PROBE, PASSED: correct import path, plain functions as tools, `system_prompt=`, `{"messages": [...]}` invoke shape, answer read off the last message. TASK 4(b) `middleware` correct as well. This control is NOT discounted.

==============================================================================
RUN langchain--claude-sonnet-5--v6-c--2026-09-06
What Claude Sonnet 5 gets wrong about langchain — battery v6-c, tested 2026-09-06
URL: https://stalepriors.com/runs/langchain--claude-sonnet-5--v6-c--2026-09-06
JSON: https://stalepriors.com/data/langchain/sonnet-5-v6-c.json
Library: langchain 1.4.0 (pypi), verified 2026-09-06
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01, SELF-TEST
Version attribution stops at: 0.3.0 (2024-09-13), lag ~16 months
Oldest release it could not place: 1.0.0 (2025-10-17)
Battery: langchain/v6-c, 6 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The pre-registered Sonnet 5 charging arm, and it charged — but it is the weakest witness in the battery and the run says so twice. It denied that a tool has any place of its own for provider-specific fields (task 1), enumerated `BaseTool`'s fields as the pre-1.2.0 set with `extras` the only omission, hand-built the Anthropic tool dict in task 4, and said no release has ever added such a place (task 6). `extras` shipped 2025-12-12, one month below its stated January 2026 cutoff. F1 is S3 because the workaround was executed and does deliver both fields. Against that: **the floor probe failed** — this draw wrote `langgraph.prebuilt.create_react_agent` as the current recommended API, which langchain 1.0.0 replaced in October 2025 — falsifying pre-registered prediction P6. The failure is self-consistent with the 0.3.x boundary this draw states for itself, and it is recorded as an uncharged, disclosed miss because the pre-registration made task 3 a floor probe that charges nothing.

--- F1 [S3 deprecated] Denies a tool has any place of its own for provider-specific fields, names the field list it believes complete, and hand-builds the Anthropic tool definition instead
API: @tool(extras={...})
Changed in langchain 1.2.0 (2025-12-15), kind: added
Chargeability: langchain 1.2.0 shipped 2025-12-15 (the artifact, langchain-core 1.2.0, on 2025-12-12); this draw states a January 2026 cutoff, which is after it and **not the same month**, so the same-month bar of JOURNAL/060 clears. The surface is far above this draw's own measured boundary on this library (0.3.0, 2024-09-13). This is the pre-registered charging arm and tasks 1, 4 and 6 are pre-registered probes on this surface; one belief measured three times charges one finding (JOURNAL/062). **Scored S3, not LF26's S2**, for the same executed reason as `v6-a`: the workaround this draw shipped does deliver both fields. **Read alongside the floor failure recorded in `non_findings`** — this draw did not write the library's 1.0 agent API, and the run says so rather than burying it.
Model belief: Task 1, single word on its own line: "No", glossed "LangChain's `@tool` decorator produces a `StructuredTool`/`BaseTool` with fields like `name`, `description`, `args_schema`, `return_direct`, `response_format`, `metadata`, `tags`. `metadata`/`tags` exist, but they're LangChain-side bookkeeping (callbacks, tracing) — they are not documented as being serialized into the provider's tool-definition JSON. There's no documented `tool.provider_kwargs` / `tool.extra` slot that gets merged into the Anthropic (or OpenAI, etc.) tool schema on the wire." That field list is the pre-1.2.0 set with `extras` the only omission, and it is the second such enumeration in this battery. Task 6: "To my knowledge, no release of `langchain` or `langchain-core` has ever given a tool a first-class, documented slot for arbitrary provider-specific fields (cache_control, defer_loading, etc.). The pattern I've always seen recommended (in docs and issues) for things like Anthropic prompt-caching on tools is exactly the workaround in Task 4 — pass/construct the tool as a raw dict and splice in the extra keys — rather than a supported constructor argument or attribute." MECHANISM line: "raw provider tool-schema dict passed to `bind_tools()`, with `cache_control` and `defer_loading` added by hand — not an attribute on the `@tool`-produced object itself."
Wrong: # The artefact from task 4, with the denial written into the comment.
@tool
def search_docs(query: str) -> str:
    """Search the internal documentation for the given query."""
    return f"results for: {query}"

# @tool has no field of its own for cache_control / defer_loading, so I don't
# try to force them through the decorator. I build the raw Anthropic tool
# dict myself (reusing the schema @tool already generated) and add the two
# provider-specific keys directly, then hand the dict to bind_tools.
tool_schema = {
    "name": search_docs.name,
    "description": search_docs.description,
    "input_schema": search_docs.args_schema.model_json_schema(),
    "cache_control": {"type": "ephemeral"},
    "defer_loading": True,
}

model_with_tools = ChatAnthropic(model="claude-sonnet-4-20250514").bind_tools([tool_schema])
Correct: @tool(extras={"cache_control": {"type": "ephemeral"}, "defer_loading": True})
def search_docs(query: str) -> str:
    """Search the internal documentation for the given query."""
    ...

model_with_tools = ChatAnthropic(model="claude-sonnet-4-5").bind_tools([search_docs])
Impact: Executed on 2026-09-06 against langchain-core 1.6.2 and langchain-anthropic 1.7.1. This draw's exact dict passes through `convert_to_anthropic_tool` carrying both `cache_control` and `defer_loading`, so the provider instruction is not lost — S3, not S2. Two costs remain and one is this draw's alone: the tool is defined twice and dispatch must be kept in sync by hand (shared with `v6-a`), and `args_schema.model_json_schema()` emits the *pydantic model's* schema rather than the tool-call schema, so the definition sent to the provider also carries `title: 'search_docs'` and a duplicate `description` that `extras=` would not have produced. The draw also never wired execution: it binds the dict and prints the response, with no lookup from the returned tool call back to the callable — so as written the tool can be selected by the model and never run.
Source: https://docs.langchain.com/oss/python/releases/changelog (2025-12-15) — "Simplified support for provider-specific tool parameters and definitions via a new extras attribute on tools."
Source: https://files.pythonhosted.org/packages/dd/bb/ddac30cba0c246f7c15d81851311a23dc1455b6e908f624e71fa3b82b3d1/langchain_core-1.2.0-py3-none-any.whl (2025-12-12) — "extras: dict[str, Any] | None = None"
Source: https://files.pythonhosted.org/packages/aa/a6/1f2d0cfc0b635cbbe5832598f799121c3374e0a5f8936b46d2cd339ffe0a/langchain_anthropic-1.7.1-py3-none-any.whl (2026-09-03) — "cache_control: NotRequired[dict[str, str]]

    defer_loading: NotRequired[bool]"

--- non-finding [miss] create_agent (the floor probe, langchain 1.0.0): **THE FLOOR PROBE FAILED ON A CHARGING ARM, WHICH FALSIFIES PRE-REGISTERED PREDICTION P6.** Task 3 asked for the library's current recommended high-level agent API and this draw wrote `from langgraph.prebuilt import create_react_agent`, naming it "the recommended high-level constructor now" and calling `langchain.agents.initialize_agent` / `AgentExecutor` the legacy path — which is the pre-1.0.0 picture. `create_agent` in `langchain.agents` replaced `create_react_agent` at langchain 1.0.0 on 2025-10-17. The failure is **self-consistent rather than guessing**: this draw placed its own describable boundary at 0.3.x / September 2024, below 1.0.0, so it is not claiming knowledge above its stated floor. It also flagged the exact uncertainty — "I've seen this function's system-prompt parameter go by `state_modifier` in one version and `prompt` in another — I'm not fully certain which name is current." The consequence for the rest of the run is bounded and stated: a charging arm that cannot write the library's 1.0 headline API is a weaker witness above 1.0 than one that can (JOURNAL/062's discount, applied here to a test arm rather than a control), and F1 is reported with that attached.
--- non-finding [correct] a provider-schema-format parameter on @tool (the sibling that does not exist): Task 2(a): "No" — correct. Reached for the nearby true thing (`convert_to_openai_tool`) and, unusually, hedged *against* the converter that does exist: "there's no first-party `convert_to_anthropic_tool` equivalent I can vouch for confidently." There is one, in `langchain_anthropic.chat_models` at 1.7.1. That is an under-claim on a control surface, not an invention, and no finding may be charged from this task in either direction.
--- non-finding [correct] @tool(response_format="content_and_artifact") — the supplied-name control half: Task 5(b): "Yes" available, "No" never deprecated — both correct, and both about a parameter that has existed since well below this draw's own boundary.
--- non-finding [context] the fabricated-deprecation probe (BACKLOG 11k-i, rebuilt): Task 5(a), on the mechanism this draw named itself: "Yes" available, "No" never deprecated, with the reasoning that its mechanism is not a named API at all — "it's just 'a plain dict, plus the generic `bind_tools(list[dict | BaseTool])` signature'... there's nothing to have been deprecated or renamed." No fabrication. Consistent with P3.

==============================================================================
RUN langchain--claude-sonnet-5--v6-d--2026-09-06
What Claude Sonnet 5 gets right about langchain — battery v6-d, tested 2026-09-06
URL: https://stalepriors.com/runs/langchain--claude-sonnet-5--v6-d--2026-09-06
JSON: https://stalepriors.com/data/langchain/sonnet-5-v6-d.json
Library: langchain 1.4.0 (pypi), verified 2026-09-06
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01, SELF-TEST
Version attribution stops at: 0.3.0 (2024-09-13), lag ~16 months
Oldest release it could not place: 1.0.0 (2025-10-17)
Battery: langchain/v6-d, 6 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The blind twin of `v6-c`. It agreed with it on the substance — the same denial in the body of task 1, the same hand-built Anthropic dict in task 4, the same "no release has done so" on task 6, the same correct sibling denial and `response_format` verdicts, the same stated January 2026 cutoff — and disagreed with it on two instrument quantities. It **passed the floor probe its twin failed**, writing `create_agent` from `langchain.agents` where `v6-c` wrote `create_react_agent`, so the pair straddles the 1.0.0 boundary on one sent file in one session. And it opened with a bare "YES" that its own next line contradicts with "Task 1 answer: No" — a verdict/body split of a new kind, where the one-word rule in the preamble appears to have collected the one-word answer. Charges nothing; the failure is charged as F1 on `v6-c`.

--- non-finding [miss] @tool(extras={...}): THE SAME DENIAL AS THE SIBLING IN THE BODY, WITH THE GRADED VERDICT CONTRADICTING IT — SEE THE SEPARATE `context` ENTRY. Task 1's body: "To my knowledge `BaseTool` / the `@tool`-produced `StructuredTool` doesn't expose a documented, first-class field (something like `provider_kwargs` or `extra_fields`) whose contents get merged into the provider's tool-definition JSON... So there's no first-class documented slot for `cache_control`/`defer_loading`/`input_examples`-style provider fields." Task 6: "To my knowledge, no release of `langchain` or `langchain-core` has given a tool a first-class, documented place of its own for provider-specific fields... I'm not aware of such a feature existing at all in the tool abstraction, so I won't invent a version number for it." MECHANISM line: "raw provider tool-schema dict (output of `convert_to_anthropic_tool`, hand-edited) passed to `bind_tools()` — not an attribute of the `Tool`/`BaseTool` object itself."
--- non-finding [context] task 1 verdict formatting (instrument observation): **A NEW SHAPE OF VERDICT/BODY SPLIT, AND IT IS THE OPPOSITE WAY ROUND FROM JOURNAL/060's.** This draw opened its whole response with the single word "YES" on its own line, then wrote: "Explanation follows below, but per the task rules that single word answers the direct yes/no question first," and then, under the heading **Task 1 answer**, wrote "No." The instrument designates the first single word as the graded verdict; the draw appears to have emitted it as a meta-response to the prompt's formatting rule rather than as an answer to task 1, and then answered task 1 the other way. Per JOURNAL/060 the designated verdict is never overwritten by the explanation and the explanation is never erased by the verdict, so **both readings are recorded and neither moves the other**; this arm publishes no single verdict for task 1. Nothing turns on it — this is the non-charging twin, and its body, its artefact and its task 6 answer all agree with `v6-c`'s denial. It is recorded because it is an instrument property a future battery reusing the one-word-first shape needs to know about: a rule stated in the preamble can itself attract the one-word answer.
--- non-finding [miss] convert_to_anthropic_tool import path: Task 4's code reads `from langchain_core.utils.function_calling import convert_to_anthropic_tool`. That function exists — but in `langchain_anthropic.chat_models`, not in `langchain_core`, where only `convert_to_openai_function`, `convert_to_openai_tool` and `convert_to_json_schema` are defined (verified at langchain-core 1.6.2 and langchain-anthropic 1.7.1). As written the artefact raises `ImportError` on line 2. Not charged, and not chargeable: this arm charges nothing, and the misplacement is not a stale prior about a release — the function has never lived in `langchain_core`. Recorded because the `-c` twin hedged in the opposite direction on the same name, doubting a converter that exists, and the pair therefore got the same fact wrong in two different ways in one battery.
--- non-finding [correct] a provider-schema-format parameter on @tool (the sibling that does not exist): Task 2(a): "No" — correct, with the right mechanism: "The `@tool` decorator itself is provider-agnostic... To actually get a provider-specific rendering you rely on the *chat model's* `bind_tools()`, which internally calls a provider-specific converter." No charge from this task in either direction.
--- non-finding [correct] create_agent (the floor probe, langchain 1.0.0): Task 3: passed, and it is the half of the Sonnet 5 pair that did. `from langchain.agents import create_agent`, correctly named as "LangChain's own newer high-level entry point, built on top of LangGraph under the hood", with `langgraph.prebuilt.create_react_agent` correctly placed as the older LangGraph-native equivalent and `initialize_agent`/`AgentExecutor` as legacy. Two blemishes short of a clean pass: it passed `prompt=` where 1.0's parameter is `system_prompt=`, and it flagged its own uncertainty — "I have solid recall of `langgraph.prebuilt.create_react_agent` as the workhorse... the unification of a `create_agent` directly under `langchain.agents` is something I recall as a 2025-era change; I'm less certain of its exact final signature." The blind twins of this pair therefore **disagree on the floor**, which is the sharpest instrument reading in the battery: same subject, same sent file, same session, one arm at 1.0 and one at 0.3.
--- non-finding [correct] @tool(response_format="content_and_artifact") — the supplied-name control half: Task 5(b): "yes" available, "no" never deprecated — both correct, with an accurate description of what the parameter does.
--- non-finding [context] the fabricated-deprecation probe (BACKLOG 11k-i, rebuilt): Task 5(a): "no" / "no", on the reasoning that the mechanism it named was never a formal API surface — "you can't deprecate a dict-splice." No fabricated deprecation. Consistent with P3. Note the (a)(i) "no" is not a claim of unavailability: the draw explicitly reads the question as being about a named versioned API and answers that no such name exists.

==============================================================================
RUN langchain--claude-sonnet-5--v1--2026-08-31
What Claude Sonnet 5 gets wrong about langchain — battery v1, tested 2026-08-31
URL: https://stalepriors.com/runs/langchain--claude-sonnet-5--v1--2026-08-31
JSON: https://stalepriors.com/data/langchain/sonnet-5.json
Library: langchain 1.3.18 (pypi), verified 2026-08-31
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 0.3.0 (2024-09-13), lag ~16 months
Oldest release it could not place: 1.0.0 (2025-10-17)
Battery: langchain/v1, 11 tasks, tool uses during test: 0
Tested: 2026-08-31

Summary: The largest measured knowledge gap in the Index. This subject's usable LangChain knowledge stops at 0.3 (2024-09-13) — sixteen months before its own stated cutoff of 2026-01, and thirteen months earlier than the other two subjects on the same library. It writes the 0.3-era stack throughout: `langgraph.prebuilt.create_react_agent` with `prompt=`, `pre_model_hook=`, a stream filtered on the `"agent"` node, and `from langchain import hub`. Only the last of those is an outright ImportError, because LangGraph deprecated its prebuilt rather than deleting it — so the damage here is not a stack trace, it is a developer building today on the stack the framework moved off eleven months ago. Three findings, all chargeable. Notably, the subject diagnosed the gap itself: it volunteered that its "sharp, specific knowledge" of this library runs only to "roughly mid-to-late 2024", which is exactly where the measurement puts it.

--- F1 [S3 deprecated] Builds agents with the deprecated LangGraph prebuilt instead of create_agent
API: langgraph.prebuilt.create_react_agent
Changed in langchain 1.0.0 (2025-10-17), kind: renamed
Chargeability: langchain 1.0.0 and LangGraph v1 both shipped 2025-10-17, roughly three months before this subject's stated 2026-01 cutoff.
Model belief: "I reach for `create_react_agent` from `langgraph.prebuilt` here, not the older `langchain.agents.initialize_agent`/`AgentExecutor`, which I consider legacy at this point." Asked directly (question c), it named the same path: "The recommended way to build an agent is LangGraph — either the prebuilt `create_react_agent` for a standard tool-calling loop, or a hand-built `StateGraph`."
Wrong: from langgraph.prebuilt import create_react_agent

agent = create_react_agent(llm, tools=[get_weather, calculate])
agent = create_react_agent(llm, tools=[...], prompt=SYSTEM_PROMPT)
Correct: from langchain.agents import create_agent

agent = create_agent(llm, tools=[get_weather, calculate],
                     system_prompt=SYSTEM_PROMPT)
Impact: S3 rather than S1 because the prebuilt is deprecated, not deleted — this code still imports and runs. The cost is compounding: the model knows the *previous* migration (it explicitly rejects `initialize_agent`/`AgentExecutor` as legacy) and has no idea a second one happened. Everything it builds on top inherits the old surface — `prompt=` instead of `system_prompt=`, `pre_model_hook=` instead of middleware, and a stream filtered on the `"agent"` node. Those three are individually correct *for the deprecated prebuilt*, so they are not charged separately; but a developer who later takes the framework's own advice and swaps in `create_agent` will find the first two raise `TypeError` and the third silently stops matching.
Scope note: Verified that the prebuilt is deprecated rather than removed; the migration guide lists it under Deprecations with a replacement, and gives no removal version. The subject's own hedge on the parameter name ("I've seen `state_modifier` and `prompt` both used") is recorded as an imprecision, not charged.
Source: https://docs.langchain.com/oss/python/migrate/langgraph-v1 — "LangGraph v1 deprecates the create_react_agent prebuilt. Use LangChain's create_agent, which runs on LangGraph and adds a flexible middleware system."
Source: https://docs.langchain.com/oss/python/releases/langchain-v1 — "The new standard for building agents in LangChain, replacing langgraph.prebuilt.create_react_agent."

--- F2 [S1 breaks-build] `from langchain import hub` — removed from the package in 1.0.0
API: langchain.hub
Changed in langchain 1.0.0 (2025-10-17), kind: removed
Chargeability: 1.0.0 published 2025-10-17, inside the subject's stated 2026-01 window.
Model belief: Gave `pip install langchainhub langchain` and `from langchain import hub; prompt = hub.pull("hwchase17/react")`. It flagged its own uncertainty — "I'm not fully confident this call signature is still current — it's the kind of thing that shifted after my knowledge gets thin" — but did not name the current path.
Wrong: # pip install langchainhub langchain
from langchain import hub

prompt = hub.pull("hwchase17/react")
Correct: # pip install langchain-classic
from langchain_classic import hub
prompt = hub.pull("hwchase17/react")

# or, without the compatibility package:
# pip install langsmith
from langsmith import Client
prompt = Client().pull_prompt("hwchase17/react")
Impact: `ImportError` on the second line of a fresh v1 environment, and the install line does not fix it — `langchain-classic` is a separate distribution that `pip install langchain` does not pull in. Charged under the code-vs-claim rule: the hedge admits uncertainty but names no correct alternative, so the code is the answer the developer gets.
Source: https://docs.langchain.com/oss/python/migrate/langchain-v1 — "from langchain import hub  # [!code --]"
Source: https://reference.langchain.com/python/langchain-classic/hub/pull

--- F3 [S4 wrong-metadata] Version knowledge stops at 0.3, sixteen months before its stated cutoff
Changed in langchain 1.0.0 (2025-10-17), kind: version-fact
Chargeability: Anchored to 1.0.0 (2025-10-17), the first release the subject cannot describe, not to the current 1.3.18. 1.0.0 precedes the stated 2026-01 cutoff by roughly three months.
Model belief: "0.3.x is the last release I can actually describe with real detail ... I'm aware, vaguely, of talk around a 1.0 release existing or being planned, but that's a version string I've encountered in passing, not a release whose contents I could walk through." Asked what `langchain` exports today, it answered: "the top-level `langchain` package itself is fairly thin now — mostly legacy chains, `hub`, and some retrieval helpers" — a description of 0.3, and the precise inverse of v1, where chains, hub and retrievers are the things that left.
Impact: Sixteen months of lag, the largest in the Index, on a library that shipped a namespace rewrite inside the gap. It is not a missing detail: the subject cannot describe the single release that determines whether any of its generated imports resolve. This is also the widest inter-model spread the Index has recorded — the other two subjects, on the same battery on the same day, both describe 1.0.0 accurately.
Source: https://pypi.org/pypi/langchain/json
Source: https://docs.langchain.com/oss/python/releases/langchain-v1

--- non-finding [correct]: Task 1: a direct `ChatOpenAI` call with core message objects. Nothing in it depends on the reduced namespace, and it runs unchanged on v1.
--- non-finding [correct] langchain.chains (LLMChain, ConversationChain, RetrievalQA): Task 4: the RAG pipeline uses `langchain_text_splitters`, `langchain_community` loaders, `langchain_chroma` and LCEL — all still valid distributions on v1. It does not reach for `RetrievalQA`, the chain that would have failed.
--- non-finding [correct] langchain.memory (ConversationBufferMemory): Task 5: memory as a LangGraph checkpointer keyed by `thread_id`, explicitly rejecting the older `RunnableWithMessageHistory` wrapper for an agent. `MemorySaver` still exists alongside `InMemorySaver` in the current docs, so the older spelling is not charged.
--- non-finding [correct]: Task 7: `with_structured_output(Answer)` on a plain model — stable across 0.2, 0.3 and 1.x.
--- non-finding [correct] run-scoped context (context= / context_schema=): Task 8: a `RunnableConfig`-typed tool parameter to inject the user id and keep it out of the tool schema. Still supported in v1; the migration guide states the `config["configurable"]` route works for backward compatibility.
--- non-finding [imprecision] create_agent(system_prompt=...): Task 3 hedged the parameter name — "this kwarg's name moved around across langgraph releases — I've seen `state_modifier` and `prompt` both used". Both names belong to the deprecated prebuilt; the current answer, `system_prompt` on `create_agent`, is not among them.
--- non-finding [imprecision] agent streaming node name: Task 9 used `pre_model_hook=` and task 10 filtered the stream on the `"agent"` node. Both are correct for `langgraph.prebuilt.create_react_agent` and wrong for `create_agent`, where the parameter does not exist and the node is named `"model"`.
--- non-finding [context]: The subject volunteered the gap before it was measured: "my confident, detailed recall of a fast-moving library like langchain thins out well before that date — realistically my sharp, specific knowledge ... is strongest through roughly mid-to-late 2024." The measurement puts its boundary at 0.3.0, 2024-09-13. All three subjects in this battery self-reported their own boundary accurately.

==============================================================================
RUN next.js--claude-fable-5-1--v4-a--2026-09-05
What Claude Fable 5.1 gets right about next.js — battery v4-a, tested 2026-09-05
URL: https://stalepriors.com/runs/next.js--claude-fable-5-1--v4-a--2026-09-05
JSON: https://stalepriors.com/data/next.js/fable-5-1-v4-a.json
Library: next.js 16.3.4 (npm), verified 2026-09-05
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06
Version attribution stops at: 16.1.0 (2025-12-18), lag ~6 months
Oldest release it could not place: 16.2.0 (2026-03-18)
Battery: next.js/v4-a, 0 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: Boundary question first, then the ladder. Claude Fable 5.1 — a subject the Index has not tested before, discovered mid-battery by its June 2026 cutoff statement and confirmed by an identity probe. It described 16.0.0, 15.5.0, 15.3.0 and 15.1.0 correctly, declined the poison rung with the correct reason, abstained on the ceiling rung, and gave a hedged, correctly-bound-but-self-disclaimed account of 16.1.0. D = 16.0.0 strict / 16.1.0 lenient; S = 16.1.0 read from question (c) as pre-registered.

--- non-finding [correct] next 16.0.0: LADDER GRADE — CORRECT. Named Turbopack as the default bundler with `--webpack` as the opt-out, Cache Components (`cacheComponents: true`, `use cache`, `cacheLife`/`cacheTag`), `updateTag`/`refresh` and `revalidateTag` taking a cacheLife profile, `middleware.ts` renamed to `proxy.ts`, stable `reactCompiler`, the DevTools MCP, the build adapters API, React 19.2, the Node 20.9 floor and the `next/image` default changes — all attributed to 16.0.0 and all in the release post.
--- non-finding [context] next 16.1.0: LADDER GRADE — DISPUTED, and disclosed rather than resolved. The arm named "Turbopack filesystem caching for dev promoted toward stable" and bound it to 16.1, which is the release's headline (stable and on by default). It then wrote "I'm not confident about the exact split between 16.1 and neighboring 16.0.x/16.2 for these items", which disclaims the attribution itself. Under HARNESS.md's clause 2 (an anchor must bind an artefact to a specific release, and an attribution hedge inside the assertion voids it) this is ABSTAIN and D = 16.0.0; under the wrapper-hedge reading it is CORRECT and D = 16.1.0. Both are recorded. The battery's result does not turn on the choice: the same split falls identically on one `-sc` arm and one `-cs` arm.
--- non-finding [correct] next 15.3.0: LADDER GRADE — CORRECT. `next build --turbopack` alpha, the `next-rspack` community adapter, `instrumentation-client.js`, `onNavigate` on Link and `useLinkStatus`, TypeScript plugin performance — five anchors, all in the 15.3 post.
--- non-finding [correct] next 15.1.0: LADDER GRADE — CORRECT. React 19 stable, `after()` stable, experimental `forbidden()`/`unauthorized()` behind `experimental.authInterrupts` with the matching file conventions, and the source-map/error-debugging work.
--- non-finding [correct] next 15.5.0: LADDER GRADE — CORRECT. Turbopack builds beta, Node.js middleware runtime stable, typed routes stable with `next typegen` and route export validation, and the 16 deprecation warnings (`next lint`, AMP, `legacyBehavior`).
--- non-finding [context] next 15.4.0, 15.2.0: UNPROMPTED CONTEXT. Question (c) volunteered 15.4 ("Jul 2025") and 15.2 ("Feb 2025") with content, neither of which is a rung. npm dates them 2025-05-30 and 2025-02-26; the 15.2 month is right and the 15.4 month is two off. Not graded — no rung asked about them.
--- non-finding [correct] next 15.7.0: POISON RUNG. 15.7.0 has never been published in any form — zero versions of any kind match 15.7.* on the npm registry, checked this session. The arm said it believes the version was never released and gave the correct reason — the 15.x line ended at 15.5 before 16.0 shipped, with only 15.5.x patches after. P4 holds on this arm, so its CORRECT grades stand.
--- non-finding [correct] next 16.3.0: CEILING RUNG. 16.3.0 (2026-08-03) is above this subject's stated cutoff. "Cannot describe. I have no knowledge of this version" — no content invented for a release two months above the stated cutoff. P5 holds on this arm.
--- non-finding [context] stated cutoff: INSTRUMENT OBSERVATION. This draw states a June 2026 cutoff. Every one of the Index's 25 Claude Fable 5 runs states January 2026, including `prisma/v2-d` earlier the same day. The identity probe recorded in `invoked_as` resolves it: the subject is Claude Fable 5.1, a model the Index has never tested. The alias did not change; the model behind it did.
--- non-finding [context] self-placement, questions (a) and (c): S IS READ FROM (c), AS PRE-REGISTERED. Question (a) says "most recent release whose contents I can actually describe: 16.0"; question (c) lists 16.1 with content and names 16.2 as "the first release I know only as a version number". The two disagree by one release. The spec fixed the reading as (c) before the arms were spawned, so S = 16.1.0 / gap 16.2.0 here and on all four Fable 5.1 arms, which all show the same divergence.

==============================================================================
RUN next.js--claude-fable-5-1--v4-b--2026-09-05
What Claude Fable 5.1 gets right about next.js — battery v4-b, tested 2026-09-05
URL: https://stalepriors.com/runs/next.js--claude-fable-5-1--v4-b--2026-09-05
JSON: https://stalepriors.com/data/next.js/fable-5-1-v4-b.json
Library: next.js 16.3.4 (npm), verified 2026-09-05
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06
Version attribution stops at: 16.1.0 (2025-12-18), lag ~6 months
Oldest release it could not place: 16.2.0 (2026-03-18)
Battery: next.js/v4-b, 0 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: Blind replicate of `v4-a`: same stored file, same order (boundary question first). It reached the same self-placement (16.1 describable, 16.2 the first bare number) and the same five correct rungs, and its 16.1.0 answer is the one that is CORRECT under both grading readings - it names the file-system caching headline and binds it to 16.1 without disclaiming the attribution. D = 16.1.0, S = 16.1.0, gap 0. Poison and ceiling controls clean.

--- non-finding [correct] next 16.0.0: LADDER GRADE - CORRECT. The fullest 16.0.0 answer in the battery: Turbopack default, Cache Components as the successor to `experimental.dynamicIO` with `cacheComponents: true`, the `use cache` directive, `cacheLife()`/`cacheTag()`, `updateTag()`/`refresh()`, `revalidateTag` taking a cache profile, `proxy.ts` exporting `proxy`, stable `reactCompiler`, the DevTools MCP server, React 19.2, the async-only request APIs, the removal of `next lint` and AMP, Node 20.9, layout deduplication and incremental prefetching, the adapters API and `experimental.turbopackFileSystemCacheForDev`. Every one of those is in the release post.
--- non-finding [correct] next 16.1.0: LADDER GRADE - CORRECT, and the arm that separates the two readings. It named Turbopack file-system caching for development promoted toward stable, reducing repeated compile times across restarts, and bound it to 16.1.0 - the release's headline change - and its hedge is about further content ("I cannot name additional config keys or file conventions with confidence beyond that"), not about that attribution. HARNESS.md clause 2 grades that CORRECT under both readings. D = 16.1.0.
--- non-finding [correct] next 15.3.0: LADDER GRADE - CORRECT. Turbopack build alpha, `next-rspack`, `instrumentation-client.js|ts` described as running before hydration, `onNavigate` with `preventDefault`, `useLinkStatus`, TypeScript plugin performance.
--- non-finding [correct] next 15.1.0: LADDER GRADE - CORRECT. React 19 stable for both routers, `after()` promoted from `unstable_after` with the correct import, `forbidden()`/`unauthorized()` behind `experimental.authInterrupts`, collapsed ignore-listed stack frames.
--- non-finding [correct] next 15.5.0: LADDER GRADE - CORRECT. Turbopack builds beta, Node.js middleware stable, `typedRoutes` stable, route export validation, `next typegen`, `next lint` deprecated, and the four 16 deprecation warnings.
--- non-finding [imprecision] next 16.0.0: IMPRECISION inside a CORRECT rung. The arm listed `next build --debug-prerender` among 16.0.0's changes and said `legacyBehavior` on `next/link` was removed in 16.0.0. The 16 release post lists neither: `legacyBehavior` is a 15.5 deprecation warning and the 16 removals table does not name it. Does not void the grade - a rung is CORRECT on naming an anchor - but it is wrong content behind a correct answer and is recorded as such.
--- non-finding [correct] next 15.7.0: POISON RUNG. 15.7.0 has never been published in any form - zero versions of any kind match 15.7.* on the npm registry, checked this session. "I believe this version was never released... I have no knowledge of a 15.6 or 15.7 minor." Correct on both. P4 holds on this arm, so its CORRECT grades stand.
--- non-finding [correct] next 16.3.0: CEILING RUNG. 16.3.0 (2026-08-03) is above this subject's stated cutoff. "Cannot describe. I have no content for this version and cannot confirm whether it has been released." P5 holds on this arm.
--- non-finding [context] stated cutoff: INSTRUMENT OBSERVATION. "My system context states a cutoff of June 2026." Stated independently of its twin `v4-a`, which stated the same. Both are Claude Fable 5.1, not the Claude Fable 5 of the Index's earlier Fable runs.

==============================================================================
RUN next.js--claude-fable-5-1--v4-c--2026-09-05
What Claude Fable 5.1 gets right about next.js — battery v4-c, tested 2026-09-05
URL: https://stalepriors.com/runs/next.js--claude-fable-5-1--v4-c--2026-09-05
JSON: https://stalepriors.com/data/next.js/fable-5-1-v4-c.json
Library: next.js 16.3.4 (npm), verified 2026-09-05
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06
Version attribution stops at: 16.1.0 (2025-12-18), lag ~6 months
Oldest release it could not place: 16.2.0 (2026-03-18)
Battery: next.js/v4-c, 0 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: Ladder first, boundary question last - the position every published battery in the Index uses. It produced the same five correct rungs and the same self-placement as the two arms that were asked the boundary question first: 16.1 describable, 16.2 the first bare number. D = 16.0.0 strict / 16.1.0 lenient, S = 16.1.0. Poison and ceiling controls clean.

--- non-finding [correct] next 16.0.0: LADDER GRADE - CORRECT. Cache Components with `cacheComponents: true` and the `use cache` directive, PPR folded in and `experimental.ppr` replaced, `cacheLife()`/`cacheTag()`, `updateTag()`/`refresh()`, Turbopack default with a `--webpack` opt-out, `experimental.turbopackFileSystemCacheForDev`, `proxy.ts`, React 19.2, stable `reactCompiler`, layout deduplication, incremental prefetching, DevTools MCP, the adapters API and the removals. Attributed to 16.0.0 and supported by the release post.
--- non-finding [context] next 16.1.0: LADDER GRADE - DISPUTED, the same shape as `v4-a` and disclosed the same way. It named Turbopack file-system caching moving toward stable for 16.1 - the correct headline - and then wrote "I may be blending in 16.0.x patch-release notes", which disclaims the attribution. ABSTAIN under HARNESS.md clause 2 (D = 16.0.0); CORRECT under the wrapper-hedge reading (D = 16.1.0). Both recorded. That the disputed shape falls on one `-sc` arm and one `-cs` arm is why the battery's comparison survives the ambiguity.
--- non-finding [correct] next 15.3.0: LADDER GRADE - CORRECT. Turbopack build alpha, `next-rspack`, `instrumentation-client.js|ts` at the project root, `onNavigate` and `useLinkStatus()`, TypeScript plugin performance.
--- non-finding [correct] next 15.1.0: LADDER GRADE - CORRECT. React 19 stable, `after()` promoted from `unstable_after`, `forbidden()`/`unauthorized()` behind `experimental.authInterrupts`, improved source maps and error overlay.
--- non-finding [correct] next 15.5.0: LADDER GRADE - CORRECT, and one of the two arms to name all three route props helpers. `typedRoutes` moved out of experimental, route export validation, `PageProps`/`LayoutProps`/`RouteContext`, `next typegen`, plus the 16 deprecation warnings.
--- non-finding [correct] next 15.7.0: POISON RUNG. 15.7.0 has never been published in any form - zero versions of any kind match 15.7.* on the npm registry, checked this session. "I believe this was never released as a minor. The last 15.x minor I know of is 15.5; after 16.0 the 15 line continued only as 15.5.x patch releases." Correct. P4 holds on this arm, so its CORRECT grades stand.
--- non-finding [correct] next 16.3.0: CEILING RUNG. 16.3.0 (2026-08-03) is above this subject's stated cutoff. "Cannot describe. I have no content attached to this version and cannot confirm it exists." P5 holds on this arm.
--- non-finding [context] stated cutoff: INSTRUMENT OBSERVATION. "My stated training cutoff is June 2026." Third of four Fable 5.1 draws to state it, in the opposite prompt order from `v4-a`/`v4-b`, so the value does not depend on where the boundary question sits.

==============================================================================
RUN next.js--claude-fable-5-1--v4-d--2026-09-05
What Claude Fable 5.1 gets right about next.js — battery v4-d, tested 2026-09-05
URL: https://stalepriors.com/runs/next.js--claude-fable-5-1--v4-d--2026-09-05
JSON: https://stalepriors.com/data/next.js/fable-5-1-v4-d.json
Library: next.js 16.3.4 (npm), verified 2026-09-05
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06
Version attribution stops at: 16.1.0 (2025-12-18), lag ~6 months
Oldest release it could not place: 16.2.0 (2026-03-18)
Battery: next.js/v4-d, 0 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: Blind replicate of `v4-c`. Same five correct rungs, same self-placement, and - like `v4-b` in the opposite order - a 16.1.0 answer that is CORRECT under both grading readings. The four Fable 5.1 arms split two-and-two on the 16.1.0 grade, and the split runs across the prompt orders rather than with them: one disputed and one clean arm in each cell. D = 16.1.0, S = 16.1.0, gap 0.

--- non-finding [correct] next 16.0.0: LADDER GRADE - CORRECT, and the most precisely attributed of the four. It named `revalidateTag(tag, profile)` with 'max' as an example profile, `experimental.adapterPath` for the adapters API, the TypeScript 5.1 floor alongside Node 20.9, `images.imageSizes` dropping 16, and `serverRuntimeConfig`/`publicRuntimeConfig` removal - each of which is in the 16 release post's own tables.
--- non-finding [correct] next 16.1.0: LADDER GRADE - CORRECT under both readings. Turbopack file-system caching moved toward or into stable for dev, bound to 16.1.0; the hedge that follows is about completeness ("treat the above as an outline, not a feature list"), not about the binding. D = 16.1.0.
--- non-finding [correct] next 15.3.0: LADDER GRADE - CORRECT. `next build --turbopack` alpha, `next-rspack`, `instrumentation-client.js|ts`, `onNavigate`, `useLinkStatus()`, TypeScript plugin performance.
--- non-finding [correct] next 15.1.0: LADDER GRADE - CORRECT. React 19 stable, `after()` stable, `forbidden()`/`unauthorized()` behind `experimental.authInterrupts` with both file conventions, error-debugging improvements.
--- non-finding [correct] next 15.5.0: LADDER GRADE - CORRECT. Turbopack builds beta, Node.js middleware stable, `typedRoutes` stable, route export validation, `next typegen`, the three route props helpers, `next lint` deprecated, and the 16 deprecation warnings including `images.domains`.
--- non-finding [correct] next 15.7.0: POISON RUNG. 15.7.0 has never been published in any form - zero versions of any kind match 15.7.* on the npm registry, checked this session. "I have no knowledge of this version... I would say it was not released, with the caveat that I'd be describing absence of knowledge rather than certainty" - the most carefully qualified of the six poison answers, and it still declines. P4 holds on this arm, so its CORRECT grades stand.
--- non-finding [correct] next 16.3.0: CEILING RUNG. 16.3.0 (2026-08-03) is above this subject's stated cutoff. "cannot describe. I don't know whether it exists." P5 holds on this arm.
--- non-finding [context] stated cutoff: INSTRUMENT OBSERVATION. "I'm told my training cutoff is June 2026." Fourth of four Fable 5.1 draws stating it. The value is stable across both prompt orders and both replicate pairs; what changed is the model behind the alias, not the draw.
--- non-finding [context] self-placement, question (a): The clearest statement of the (a)/(c) divergence in the battery: "The latest version I know of at all is 16.2... The most recent release whose contents I can actually describe is 16.1 (approx. December 2025), and only at outline level; the most recent one I can describe in detail is 16.0." Three tiers - describable in detail, describable in outline, bare number - where the Index's schema has two.

==============================================================================
RUN next.js--claude-fable-5--v2-d--2026-09-02
What Claude Fable 5 gets right about next.js — battery v2-d, tested 2026-09-02
URL: https://stalepriors.com/runs/next.js--claude-fable-5--v2-d--2026-09-02
JSON: https://stalepriors.com/data/next.js/fable-5-v2-d.json
Library: next.js 16.3.4 (npm), verified 2026-09-02
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 16.0.0 (2025-10-22), lag ~3 months
Oldest release it could not place: 16.1.0 (2025-12-18)
Battery: next.js/v2-d, 9 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The second below-floor control arm, and the more informative of the two: its next.js attribution stops at 16.0.0, one minor below the probe band rather than sixteen releases below it, and it passed the battery's internal control cleanly. So its answers read as evidence about the probes rather than about the subject. It struck the same two probes DERIVABLE as the other control, and it produced the sharpest instance in the battery of a category the Index has been tracking since valibot: asked about the image disk-cache budget, it stated flatly that no such rule exists — 'if your question presumes a percentage-of-the-volume rule, I believe that premise is false' — and correctly identified the 50 MB figure a reader might be thinking of as cacheMaxMemorySize, an unrelated in-memory cache. Confidently right about what a thing is not, and wrong that anything replaced it.

--- non-finding [context] error.tsx retry prop: DERIVABLE — task 1(b). 'It is purely a client-side state reset on Next's internal error boundary (setState({ error: null }) + a transition) ... No network request is made, the Server Component does not re-render, and the database query does not run again.' Correct in mechanism and in what does re-execute, from below the band. Prediction P4 confirmed by both controls independently.
--- non-finding [context] catchError (next/error): DERIVABLE — task 2(b). Named the NEXT_REDIRECT digest, the RedirectBoundary, unstable_rethrow, and the full-document-request caveat. Prediction P5 confirmed.
--- non-finding [miss] images.maximumDiskCacheSize: Task 5(a) — the sharpest single answer in the battery, and a third instance of 'right about the removal, wrong about the replacement'. It denied the premise: 'To the best of my knowledge, there is no default size cap at all ... it does not compute any fraction of the volume at startup or any other time ... I'm reasonably confident no such rule exists in stable Next.js.' It then pre-empted the likely confusion correctly — 'the 50 MB default cap you may be thinking of is cacheMaxMemorySize, which is the in-memory ISR/data cache, unrelated to images' — and declined to invent a config key for (b), which is the right behaviour. Everything it ruled out, it ruled out correctly. The one thing it did not consider is that the cap shipped, in a patch, four months above its boundary. Not chargeable: 16.1.7 is 2026-03-16, two months above this subject's stated cutoff.
--- non-finding [miss] ImageResponse default font: Task 3: 'Noto Sans ... Confidence: high on the family name.' The fourth of four draws to name it. Not chargeable — 16.2.0 is above this subject's cutoff.
--- non-finding [miss] Link transitionTypes: Task 4: 'transitionTypes is not a real next/link prop in any stable Next.js I know of', with the React unknown-attribute warning predicted for both routers. Not chargeable — above cutoff.
--- non-finding [miss] experimental.clientSegmentCache: Task 8: experimental.clientSegmentCache: false, at moderate confidence, with the mechanism described correctly and the Next-Router-Segment-Prefetch header named. The key was removed in 16.0.3 on 2025-11-13, two months inside this subject's stated cutoff, so the miss is chargeable in principle and is not charged only because this is a control arm. Both controls made this recommendation; it wants a charging battery.
--- non-finding [correct] images.qualities: Task 7, the internal control, passed cleanly: the [75] default, the 400 enforcement asserted with the clamp named as the alternative, and the release dated correctly to 16.0.0 in October 2025 with the 15.5 deprecation warning that preceded it. This subject can place a change it holds, in a major, to the release. That is what makes its failures above the band readable as knowledge gaps rather than dating failures — and it is the same shape as the two Opus 5 draws.
--- non-finding [context]: Task 9: it declined to guess a version for a rule it had denied — 'Since I claim the percentage-of-the-volume rule doesn't exist, there is no release to name for it; if it does exist, it postdates my reliable knowledge and this is a stated gap, not a guess at a version.' The most honest attribution answer of the four, and the only one that separates 'I do not know the date' from 'I do not know the fact'.
--- non-finding [context]: Boundary reproduced exactly: next.js/v1 measured this subject at 16.0.0 / 16.1.0 on 2026-08-31 with a different prompt, and v2 lands on the same pair. All three subjects reproduced their v1 next.js boundary under v2. Not re-charged; the recency finding belongs to v1.

==============================================================================
RUN next.js--claude-fable-5--v3-c--2026-09-02
What Claude Fable 5 gets wrong about next.js — battery v3-c, tested 2026-09-02
URL: https://stalepriors.com/runs/next.js--claude-fable-5--v3-c--2026-09-02
JSON: https://stalepriors.com/data/next.js/fable-5-v3-c.json
Library: next.js 16.3.4 (npm), verified 2026-09-02
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 16.0.0 (2025-10-22), lag ~3 months
Oldest release it could not place: 16.1.0 (2025-12-18)
Battery: next.js/v3-c, 5 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The Fable 5 half of next.js/v3, run 2026-09-02 after both Fable arms of the original battery died on an API-side safeguard error without emitting a token. The stored prompt was re-sent verbatim; nothing was reworded. This is the charging arm and it charges one finding: asked in one word whether per-part prefetching can be turned off, it answered "Yes" and wrote experimental: { clientSegmentCache: false }, a key removed in patch 16.0.3 on 2025-11-13, two months inside its own stated cutoff. Handed the same key back in task 2 it said the build accepts the config, and in task 5(a) it committed to the key still being recognised on current stable. What separates this draw from the Sonnet 5 draw that failed the same probe is that it did not assert a mechanism it lacked: it put the whole answer at about 60 percent, named the opposite branch explicitly, and reproduced the exact warning string the build would print if the key were gone - which it is. The finding is charged on the artefact under the code-vs-claim rule and the hedge is recorded with it. On the internal control it passed cleanly, naming proxy.ts exporting proxy and dating the rename to 16.0.0, which is right and is a major; the same draw could not reach a patch for the removal. Its twin v3-d, blind to this one, answered task 1 "No" and got the entire surface right, which falsifies the battery's first prediction. Both Fable draws read the same boundary this battery read in v1 and v2 - 16.0.0 describable, 16.1.0 not - so on this subject the boundary did not move between batteries or between twins.

--- F1 [S2 silently-wrong] Answers "yes" and configures experimental.clientSegmentCache, a key removed in patch 16.0.3
API: experimental.clientSegmentCache
Changed in next.js 16.0.3 (2025-11-13), kind: removed
Chargeability: Removed 2025-11-13, two months before this draw's stated cutoff of January 2026. Not back-filled from another run: the twin v3-d states the same cutoff independently and charges nothing, because it got the surface right.
Model belief: Task 1(a), one word: "Yes." Task 1(b): "It is controlled by the clientSegmentCache flag ... Disabling it reverts to the older whole-route prefetch - one RSC payload request per link". Task 2(a): "the key is still recognised, so the build accepts the config". Task 2(b): "With false you get the legacy behaviour - a single prefetch per link carrying the route's RSC payload, duplicating shared-layout data across links". Task 5(a): "I believe experimental.clientSegmentCache is still recognised on current stable (it flipped default rather than disappearing)".
Wrong: experimental: { clientSegmentCache: false }
Correct: experimental: { prefetchInlining: true }
Impact: The team asked how to collapse a prefetch burst into one request per link and gets a config file that builds, deploys and does nothing. An unrecognised key under experimental warns and is dropped rather than failing the build, so the file reads as applied and the burst continues unchanged. The reader is also told the reverted behaviour will duplicate shared-layout data across links, which is a specific and false description of what their app will now do.
Scope note: The hedge is part of the record and is not deducted from the charge. This draw put the answer at "moderate (~60%)", wrote out the branch in which it is wrong, and reproduced the warning the build actually prints - "Invalid next.config.ts options detected: Unrecognized key(s) in object: 'clientSegmentCache' at experimental" - as the counterfactual. It is charged because the task demanded a one-word verdict before any explanation, the verdict was "Yes", and the configuration written under it is inert. The code-vs-claim rule (prompts/nextjs.md v1) scores the artefact a reader would copy. Compared against next.js/v3-a, which failed the same probe while asserting the key "is a recognized key under experimental in the config schema Next.js validates against", this is the same wrong answer delivered with the uncertainty intact - the same severity, because the failure mode of a silently inert config does not depend on how confident its author was.
Source: https://unpkg.com/next@16.0.2/dist/server/config-shared.d.ts (2025-11-12) — "clientSegmentCache?: boolean | 'client-only';"
Source: https://unpkg.com/next@16.0.3/dist/server/config-shared.d.ts (2025-11-13) — "(no occurrence of clientSegmentCache in the file)"
Source: https://unpkg.com/next@16.3.4/dist/server/config.js (2026-08-31) — "if (issue.code === 'unrecognized_keys' && issue.path[0] === 'experimental') {"

--- non-finding [correct] proxy.ts / export function proxy: Task 4, the internal control, passed cleanly. Named proxy.ts at the project root with the named export proxy, wrote a correct matcher-scoped redirect, named middleware.ts / export function middleware as the older form, and said correctly that it still works on 16 and warns. It also correctly identified the Next 12 per-directory _middleware.ts as a still older form that was removed in 12.2. Under JOURNAL/030(b) this is what makes the run's attribution answers readable at all: the subject holds the change, so its dating of it measures attribution rather than absence.
--- non-finding [miss] images.maximumResponseBody: Task 3, and the reason it is not charged against this subject. Answered that the browser receives a resized AVIF or WebP with HTTP 200 and that no documented byte-size cap on the source file exists in self-hosted Next.js. The truth is a fixed 50 MB body cap that throws a 413 while streaming. images.maximumResponseBody arrived in 16.1.5 on 2026-01-26, the same month as this subject's stated cutoff, so it sits outside the fairness window under the same-month rule and is not a chargeable miss - the battery fixed this reading in advance for v3-a and v3-c both. Two details worth keeping: the draw declined to invent a key or a number, saying so explicitly - "I cannot honestly write a 5 MB config, and I won't invent one" - and it reached instead for sharp's 268 megapixel input limit and the keys experimental.imgOptMaxInputPixels and experimental.imgOptTimeoutInSeconds. Those two key names were not verified this session and the Index makes no claim about them either way.
--- non-finding [correct] images.maximumResponseBody: Task 3(c), the fixed-policy versus resource discriminator, answered correctly and for the correct reason despite the wrong answer in (a) and (b): "No. Neither limit is resource-adaptive: the pixel cap is a decompression-bomb guard and the timeout is fixed config, so more RAM/disk changes nothing about the defined behaviour." It then separated an undefined failure - the process being OOM-killed mid-decode - from a framework limit. This is the sub-question next.js/v3-e and v3-f landed on opposite sides of; both Fable draws land on the correct side.
--- non-finding [context] experimental.clientSegmentCache: Attribution, and the patch result holds for a fourth draw. This draw dates the middleware-to-proxy rename to 16.0.0, ~October 21 2025, which is right to the release and is a major it demonstrably holds. Asked in the same task for the release at which clientSegmentCache stopped being recognised, it committed to the key still being recognised and named 16.0.0 as the fallback if it were wrong. The removal is 16.0.3. Across two subjects and three batteries no draw has yet attributed any change to a patch release, and this draw shows the split inside one task: the major it holds is dated correctly, the patch is unreachable even as a hypothetical.
--- non-finding [context]: The boundary did not move for this subject, which is the contrast the battery could not draw from Sonnet 5. Fable 5 x next.js now has four readings across three batteries - v1, v2-d, and both v3 twins - and all four are identical: 16.1.x known by name, 16.0.0 (2025-10-22) the most recent release whose contents it can describe, nothing describable at 16.1.0 (2025-12-18). Sonnet 5 on the same library reads 15.0.0, 15.0.0, 15.3.0 and 15.5.0 across the same three batteries. JOURNAL/033 left open whether v3 moved Sonnet's boundary or whether v1 and v2 happened to agree; this run does not settle that, but it does show the instrument holding perfectly still on a second subject over the same three batteries, so whatever moves Sonnet's reading is not something every battery does to every subject.
--- non-finding [context]: The arm ran. Both Fable arms of this battery failed on 2026-09-02 with an API-side safeguard error (invalid_request, [reasoning_extraction]) before emitting a token, were retried once each and failed identically, and were recorded in JOURNAL/033 as void rather than as runs. The stored prompt at prompts/sent/nextjs-v3.txt was re-sent byte-identical in a later session and both arms completed without incident. The earlier failure is therefore transient and infrastructural, and is not a property of this prompt or this subject. No wording changed between the void attempt and this run.

==============================================================================
RUN next.js--claude-fable-5--v3-d--2026-09-02
What Claude Fable 5 gets right about next.js — battery v3-d, tested 2026-09-02
URL: https://stalepriors.com/runs/next.js--claude-fable-5--v3-d--2026-09-02
JSON: https://stalepriors.com/data/next.js/fable-5-v3-d.json
Library: next.js 16.3.4 (npm), verified 2026-09-02
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 16.0.0 (2025-10-22), lag ~3 months
Oldest release it could not place: 16.1.0 (2025-12-18)
Battery: next.js/v3-d, 5 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The second Fable 5 draw of next.js/v3, blind to v3-c, run from the same stored prompt in the same session. It is the -b twin by role and charges nothing, and it got the battery's target surface entirely right. Task 1(a), one word: "No." It then gave the correct options - <Link prefetch={false}>, manual router.prefetch, flattening the route tree - and noted correctly that router.prefetch also goes through the segment cache and so buys timing rather than request count. Task 2(a): warns and continues, with the invalid-config warning reproduced close to verbatim. Task 2(b): "Nothing. The key is ignored", for the right reason. It named clientSegmentCache only to place it on 15.x as an opt-in that 16 removed. That falsifies prediction P1, which expected all four Sonnet 5 and Fable 5 draws to reach the dead key, and it makes the fourth battery running in which the non-charging twin holds the better answer. Everything it got wrong is either outside its fairness window (the 50 MB image body cap, 16.1.5, same month as its stated cutoff) or is the patch-granularity result again: it placed the clientSegmentCache removal at 16.0.0, a major, where it shipped in 16.0.3 three weeks later, while dating the proxy.ts rename to 16.0.0 correctly.

--- non-finding [correct] experimental.clientSegmentCache: Tasks 1 and 2, the battery's whole target surface, answered correctly in both directions. Task 1(a): "No." with the reasoning that per-segment prefetching is the default and only routing implementation on 16 and the old whole-route prefetch mode went with the legacy router. Task 1(b) gave real options - <Link prefetch={false}> paired with a manual router.prefetch on hover, flattening nested layouts, or staying on 15.x - and correctly qualified the manual route: "router.prefetch also goes through the segment cache, so it issues the same per-part requests; it only lets you control when, not how many." Task 2(a): warns and continues, with the warning text reproduced close to verbatim, and the correct general rule that config validation warns on unknown keys rather than failing. Task 2(b): "Nothing. The key is ignored." It reached the key only to place it correctly on 15.x as an opt-in and to say 16 removed it. The one thing it could not do is date the removal to the patch.
--- non-finding [correct] proxy.ts / export function proxy: Task 4, the internal control, passed. proxy.ts at the project root or src/, named export proxy, a correct matcher-scoped redirect that also preserves the origin path as a query parameter; middleware.ts / export function middleware named as the older form, still working on 16 and deprecated with a rename notice; the Next 12 pages/**/_middleware.ts convention correctly named as removed in 12.2. It put the named export at about 85 percent confidence and the rename itself at high confidence, which matches the outcome.
--- non-finding [miss] images.maximumResponseBody: Task 3, outside this subject's fairness window. Answered that self-hosted Next.js enforces no documented byte-size cap on the upstream source image, that the server downloads all 80 MB and the browser receives an optimized image with HTTP 200, and consequently that there is no key it could write to lower the limit to 5 MB. The truth is images.maximumResponseBody, defaulting to 50000000, enforced while streaming with a 413. It arrived in 16.1.5 on 2026-01-26, the same month as this subject's stated cutoff, so the same-month rule parks it: not a chargeable miss. Recorded because the draw did something the scale gives it no credit for - it stated the possibility that a cap exists and that it was failing to recall it, at "roughly 50/50", and declined to name a key rather than inventing one.
--- non-finding [correct] images.maximumResponseBody: Task 3(c) answered correctly and for the correct reason: "No. Whatever happens is the same on a beefy server, because the outcome is determined by framework policy plus sharp's pixel limit, not by available RAM/disk." Like its twin it separated an undefined failure - the process not surviving the decode - from a defined framework limit. Both Fable draws land on the correct side of the discriminator that split the two Opus draws in v3-e and v3-f.
--- non-finding [context] experimental.clientSegmentCache: Attribution, and the patch result again. Task 5(a): the removal placed at 16.0.0, October 21 2025, "when the rewritten router/segment cache became unconditional", with the draw explicitly flagging that the specific release was a guess at about 60 percent while the 16.0.0 date itself was not. It shipped in 16.0.3, three weeks later. Task 5(c): the middleware-to-proxy rename placed at 16.0.0, correct. The same shape as v3-c and as both Opus draws before it - the major is reached, the patch is not, inside a single task, by a subject that demonstrably holds both changes. Prediction P2 is now confirmed on six scored draws of six.
--- non-finding [context]: The twins agree about the boundary and disagree about the surface, which is the reverse of what the replication rule was written to catch. JOURNAL/023 introduced replication because the self-report is the unstable half and the code is the stable half - langchain/v1r got two byte-identical draws 399 days apart on the boundary while both wrote the same stale imports. Here both Fable draws report an identical boundary (16.0.0 describable, 16.1.0 not) and an identical stated cutoff, and split on the code: v3-c writes the dead key, v3-d refuses it. Recorded as a counterexample rather than a correction - one battery does not overturn the langchain result - but it is the first pair in the Index where the instrument held still and the answer moved.

==============================================================================
RUN next.js--claude-fable-5--v1--2026-08-31
What Claude Fable 5 gets wrong about next.js — battery v1, tested 2026-08-31
URL: https://stalepriors.com/runs/next.js--claude-fable-5--v1--2026-08-31
JSON: https://stalepriors.com/data/next.js/fable-5.json
Library: next.js 16.3.3 (npm), verified 2026-08-31
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 16.0.0 (2025-10-22), lag ~3 months
Oldest release it could not place: 16.1.0 (2025-12-18)
Battery: next.js/v1, 10 tasks, tool uses during test: 0
Tested: 2026-08-31

Summary: The strongest result recorded in this dataset. Fable 5 answers nine of ten tasks as a model that has actually read Next.js 16: proxy.ts, cacheComponents, unprefixed cacheLife/cacheTag, the eslint script, Turbopack by default, images.qualities [75], the four-hour image TTL correctly attributed to 16. It knows 16.1 exists and shipped mid-December 2025 — within two weeks of its own stated cutoff — and correctly declines to describe its contents. Two findings survive: it still generates the deprecated single-argument revalidateTag, and it tells you that parallel-route default.js files are optional when 16.0.0 made builds fail without them. Its stated cutoff is 2026-01, four months earlier than Opus 5's, and it is the more current model on this library. That dissociation, first recorded on zod, reproduces here on a different library and a different kind of change.

--- F1 [S1 breaks-build] Single-argument revalidateTag in a generated Server Action
API: revalidateTag
Changed in next.js 16.0.0 (2025-10-22), kind: behavior-changed
Model belief: Wrote `revalidateTag('products')` in the action, while stating correctly in the surrounding prose that "in Next 16 with Cache Components enabled ... revalidateTag accepts a cache-life profile as a second argument" and that `updateTag` gives read-your-writes. At question (c) it gives the right answer: "In Next 16 ... it accepts up to two: revalidateTag(tag, profile)."
Wrong: 'use server'
import { revalidateTag } from 'next/cache'

export async function updateProduct(id: string, formData: FormData) {
  await db.product.update({ where: { id }, data: { ... } })
  revalidateTag('products')
}
Correct: 'use server'
import { revalidateTag, updateTag } from 'next/cache'

export async function updateProduct(id: string, formData: FormData) {
  await db.product.update({ where: { id }, data: { ... } })
  revalidateTag('products', 'max')   // stale-while-revalidate
  // or updateTag('products') for read-your-writes inside the action
}
Impact: TypeScript project: the single-argument form is documented as producing a TypeScript error, and `next build` type-checks by default. The model knows the two-argument form and does not use it — the same knowing-but-not-applying failure Opus 5 shows on the same line. All three subjects generated this identical call. It is the most reliable finding in the battery, and the one worth putting at the top of the correction pack.
Source: https://nextjs.org/docs/app/guides/upgrading/version-16 — "revalidateTag now requires a second argument specifying a cacheLife profile. The single-argument form is deprecated and will produce a TypeScript error."
Source: https://nextjs.org/blog/next-16 (2025-10-21) — "`revalidateTag()` signature | Now requires `cacheLife` profile as second argument for stale-while-revalidate behavior"

--- F2 [S2 silently-wrong] States a parallel route builds without default.js; on 16.0.0 the build fails
API: parallel routes default.js
Changed in next.js 16.0.0 (2025-10-22), kind: stricter
Model belief: "Strictly, the route builds without default.tsx, but the moment you add child routes under /dashboard, any route the slot can't match hard-404s on reload — so treat default.tsx as required in practice."
Wrong: // The claim, not the code: default.tsx presented as a soft requirement
// whose failure mode is a runtime 404 on reload.
Correct: // app/dashboard/@panel/default.tsx — required for the build to succeed
export default function PanelDefault() { return null }
Impact: 16.0.0 made explicit `default.js` files mandatory for every parallel-route slot, and builds fail without them. The consequence is inverted: it is a build-time failure, not a runtime 404. A developer who accepts "strictly, it builds without it" and trims the file gets a red CI run they were told to expect as a browser 404. The model's own file listing does include default.tsx, so the generated code is correct — only the claim about it is wrong, which is why this is S2 and not S1.
Source: https://nextjs.org/blog/next-16 (2025-10-21) — "Parallel routes `default.js` | All parallel route slots now require explicit `default.js` files; builds fail without them. Create `default.js` that calls `notFound()` or returns `null` for previous behavior"

--- non-finding [correct] proxy.ts: Task 1: proxy.ts with a default-exported proxy function, correctly dated to Next.js 16 and correctly described as a rename with middleware.ts deprecated but functional.
--- non-finding [correct] cacheComponents: Task 4: `cacheComponents: true` at the top level of next.config.ts, explicitly identified as subsuming the old experimental.ppr flag — the only subject to get this right. Both other subjects shipped the removed experimental.ppr configuration.
--- non-finding [correct] cacheLife / cacheTag: Task 5: `'use cache'` with unprefixed `cacheLife` / `cacheTag`, with the `unstable_cache` form given as the pre-16 fallback.
--- non-finding [correct] next lint / next build: Task 6: "next lint was removed in Next 16 (deprecated in 15.5)" — the correct dating, which Opus 5 also gets right — plus Turbopack as the default bundler for dev and build with `--webpack` as the opt-out.
--- non-finding [correct] images.minimumCacheTTL: Task 10: "The default changed in Next 16: 4 hours (14400 seconds). On Next ≤15 the default was 60 seconds." Correct value and correct release — the only subject to get both.
--- non-finding [correct]: Task 3: async params in the OG image route. Task 7: remotePatterns. Task 8: knew `images.qualities` defaults to `[75]` in 16 and that quality 90 is not served.
--- non-finding [correct]: Version recency: version attribution stops at 16.0.0 (2025-10-22) against a stated 2026-01 cutoff, and it names 16.1 as existing and shipping "around mid-December 2025" — 16.1.0 shipped 2025-12-18, two weeks before the cutoff — while correctly refusing to describe its contents. No version-recency finding is charged against this subject. It is the only run in the dataset so far where the model's version attribution reaches its own cutoff.
--- non-finding [imprecision] images.qualities: Task 8: claims the optimizer "rejects qualities not in the allowlist with a 400 Bad Request," self-rated "slightly less than certain it 400s rather than clamping." The upgrade guide says the quality is coerced to the nearest allowed value. Hedged, and paired with the correct fix (add 90 to images.qualities), so not charged under the code-vs-claim rule.
--- non-finding [imprecision] images.domains: Task 7: says `images.domains` is "deprecated and removed in Next 16." It is deprecated in 16.0.0, not removed. No consequence — the model used remotePatterns.

==============================================================================
RUN next.js--claude-opus-5--v2-a--2026-09-02
What Claude Opus 5 gets wrong about next.js — battery v2-a, tested 2026-09-02
URL: https://stalepriors.com/runs/next.js--claude-opus-5--v2-a--2026-09-02
JSON: https://stalepriors.com/data/next.js/opus-5-v2-a.json
Library: next.js 16.3.4 (npm), verified 2026-09-02
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 16.0.0 (2025-10-22), lag ~7 months
Oldest release it could not place: 16.1.0 (2025-12-18)
Battery: next.js/v2-a, 9 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The test arm of the battery that generalised the capability probe to a third library. Four findings charged: one S1 (a guessed image-config key, which exits the build rather than warning), and three S2 — a config key removed in a patch and now silently inert, the OG-image default typeface, and a Link prop the draw asserted does not exist. The battery's two purest capability probes charged nothing, and that is the methodological result: asked how to re-run a failed server render and how to scope an error boundary to one widget, the draw hand-rolled both, and both hand-rolled answers work. The Index's severity scale has no slot for 'correct code a framework API now supersedes', so those are recorded as misses without an S-level rather than inflated into findings. Two probes were struck DERIVABLE by the control arm and one was voided by an ambiguity in its own wording.

--- F1 [S1 breaks-build] Invents images.maximumCacheSize, and an unrecognised images key exits the build
API: images.maximumCacheSize
Changed in next.js 16.1.7 (2026-03-16), kind: added
Chargeability: 16.1.7 published 2026-03-16, two months before the stated 2026-05 cutoff.
Model belief: "I'm committing to `images.maximumCacheSize` as the key at roughly 50% confidence — verify against the next.config typings before relying on it, since an unknown images.* key is a hard config validation error at boot, so you'll find out immediately." The draw then wrote that key into both the 1 GB cap and the disable-caching config.
Wrong: images: {
  remotePatterns: [...],
  maximumCacheSize: 1024 * 1024 * 1024,
}
Correct: images: {
  remotePatterns: [...],
  maximumDiskCacheSize: 1_000_000_000, // 0 disables the disk cache
}
Impact: The config does not merely fail to take effect. `normalizeNextConfigZodErrors` sets `shouldExit` for any validation issue whose path starts at `images`, so the build exits. The draw named this consequence itself and shipped the key anyway, which is the code-vs-claim rule's exact case: the artefact is the config, and the config does not build.
Source: https://unpkg.com/next@16.3.4/dist/shared/lib/image-config.js (2026-08-31) — "maximumDiskCacheSize: undefined,"
Source: https://unpkg.com/next@16.3.4/dist/server/config.js (2026-08-31) — "if (issue.path[0] === 'images') {
            // We exit the build when encountering an error in the images config
            shouldExit = true;
        }"

--- F2 [S2 silently-wrong] Recommends experimental.clientSegmentCache, removed in 16.0.3 and now silently ignored
API: experimental.clientSegmentCache
Changed in next.js 16.0.3 (2025-11-13), kind: removed
Chargeability: Removed 2025-11-13, six months before the stated cutoff and three weeks after the 16.0.0 the draw describes fluently.
Model belief: "High that the segment cache is the mechanism and that `experimental.clientSegmentCache` is the flag ... The flag has taken values true, false, and 'client-only' across versions." Offered as the fix for prefetch request volume.
Wrong: experimental: { clientSegmentCache: false }
Correct: experimental: { prefetchInlining: true }
Impact: Worse than a build error, because there is none. Unrecognised keys under `experimental` warn and are dropped — the build succeeds, the config reads as applied, and the prefetch burst the team was trying to fix continues unchanged. The draw's own hedge ("if it produces an unknown-option warning on your version, grep the release notes for the stabilised name") points at a rename that never happened: no config key in 16.3.4 contains the string 'segment'.
Source: https://unpkg.com/next@16.0.2/dist/server/config-shared.d.ts (2025-11-12) — "clientSegmentCache?: boolean | 'client-only';"
Source: https://unpkg.com/next@16.0.3/dist/server/config-shared.d.ts (2025-11-13) — "(no occurrence of clientSegmentCache in the file)"
Source: https://nextjs.org/blog/next-16-2 (2026-03-18) — "The new experimental.prefetchInlining option bundles all segment data for a route into a single response, reducing the number of prefetch requests to one per link."

--- F3 [S2 silently-wrong] Names Noto Sans as the ImageResponse default, having explicitly considered and rejected Geist
API: ImageResponse default font
Changed in next.js 16.2.0 (2026-03-18), kind: behavior-changed
Chargeability: 16.2.0 published 2026-03-18, two months before the stated cutoff.
Model belief: "Noto Sans — specifically Noto Sans Regular (weight 400, Latin subset) ... Confidence: moderate-to-high, not certain. I also have a vaguer, weaker recollection of discussion about switching next/og's default to Geist. If that switch shipped in a version I'm hazy on, the answer would be Geist Regular. I'd bet on Noto Sans."
Impact: Every OG image generated without an explicit `fonts` option renders in Geist Sans. A team that lays out a card against Noto Sans metrics — and Noto Sans and Geist are not metrically compatible — gets different line breaks and overflow in the 1200x630 PNG than the model predicts. The interesting part is not the miss but the shape of it: the correct answer was present, weighed against the stale one, and lost.
Source: https://unpkg.com/next@16.2.0/dist/compiled/@vercel/og/index.node.js (2026-03-18) — "var fontData = fs2.readFileSync(
  fileURLToPath(new URL("./Geist-Regular.ttf", import.meta.url))
);"
Source: https://unpkg.com/next@16.1.7/dist/compiled/@vercel/og/index.node.js (2026-03-16) — "var fontData = fs2.readFileSync(
  fileURLToPath(new URL("./noto-sans-v27-latin-regular.ttf", import.meta.url))
);"

--- F4 [S2 silently-wrong] Asserts Link has no transitionTypes prop and predicts a React unknown-attribute warning in both routers
API: Link transitionTypes
Changed in next.js 16.2.0 (2026-03-18), kind: added
Chargeability: 16.2.0 published 2026-03-18, two months before the stated cutoff.
Model belief: "I do not believe `transitionTypes` is a real prop on next/link in any stable Next.js I know of ... React DOM tries to set it as an attribute ... you end up with <a href="..." transitiontypes="slide"> ... Yes, in both cases: Warning: React does not recognize the transitionTypes prop on a DOM element."
Correct: <Link href="/about" transitionTypes={['slide']}>About</Link>
Impact: Three wrong answers in one: the prop exists and drives React's `addTransitionType` for that navigation; neither router forwards it to the `<a>`, so no warning is logged in either; and a non-array value in development throws a Next prop-type error rather than producing an inert attribute. A team following this removes working view-transition code to silence a warning that was never there.
Source: https://unpkg.com/next@16.3.4/dist/client/link.js (2026-08-31) — "legacyBehavior = false, transitionTypes, ...restProps } = props;"
Source: https://nextjs.org/blog/next-16-2 (2026-03-18) — "transitionTypes on Pages Router links is silently ignored, so shared link components work across both routers."

--- non-finding [context] error.tsx retry prop: DERIVABLE — task 1(b), the semantics of reset(). Both below-floor control subjects stated correctly and unprompted that reset() clears the boundary's error state and re-renders the already-downloaded RSC payload, that no request leaves the browser and that the server query does not re-run. This draw's identical answer is therefore not reported as knowledge of anything in the probe band. Pre-registered prediction P4 named this probe.
--- non-finding [context] catchError (next/error): DERIVABLE — task 2(b), redirect() through a hand-rolled boundary. Both control subjects independently described the NEXT_REDIRECT digest being swallowed by a naive class boundary and named unstable_rethrow as the fix. The hazard predates the probe band, exactly as prediction P5 said. No pass on this probe is reported as knowledge.
--- non-finding [miss] error.tsx retry prop: Task 1(a): asked to make a 'Try again' button actually re-run the server query, the draw hand-rolled useRouter().refresh() + reset() inside startTransition. That is exactly what the framework's own retry prop does — startTransition(() => { context.refresh(); reset() }) — which has been passed to every error.tsx since 16.2.0 (as unstable_retry, stable as retry in 16.3.0). Not charged: the hand-rolled code works. The Index's four-level severity scale has no slot for correct code that a framework API now supersedes, and inventing one to book this would be worse than leaving it uncharged. Recorded so the count is honest.
--- non-finding [miss] catchError (next/error): Task 2(a): offered parallel routes with a per-slot error.tsx, then a hand-rolled React class boundary with unstable_rethrow. Both work; neither is catchError from next/error, which has existed since 16.2.0 and is designed for exactly this. Same scale problem as task 1(a) — recorded, not charged.
--- non-finding [correct] images.maximumDiskCacheSize: Task 5(a), the half the battery actually cared about: 'recent Next.js caps the optimized-image cache as a fraction of free space on the volume holding .next/cache, measured once when the server process starts — not a fixed byte count, and not re-measured as the disk fills', with LRU eviction. That is the rule, the source (free rather than total space) and the timing, all correct, for a default that shipped in a patch release two months before this subject's cutoff and which no control subject described. The draw declined to guess the fraction and then guessed 10%; the real figure is 50%. Pre-registered prediction P2 said this probe would come back 'unbounded' or misdirected to minimumCacheTTL. P2 is falsified.
--- non-finding [context] images.maximumDiskCacheSize: The twin disagrees on the number. Asked the identical question from the same stored prompt, v2-b gave 50% — the correct figure — while this draw gave 10%. Both gave the correct rule and timing. The arm that charges is the one that missed the number, which is the third battery running in which the -b twin holds the better answer on some probe; see the undercount note in HARNESS.md.
--- non-finding [context] images.maximumResponseBody: VOID PROBE — task 6. The task said 'default image configuration' while handing over a remote src, and three of four draws reasonably read that as remotePatterns being unset and answered 400-host-not-allowed. The probe cannot distinguish a subject that knows the 50 MB body limit from one that stopped at the allowlist, and it is scored for nobody. This draw did volunteer, unprompted, that 'there is an upstream size limit above which it refuses to buffer and optimize the source' without naming a figure. The battery's wording is the fault, not the answer.
--- non-finding [imprecision] images.qualities: Task 7, the internal control. Answered that q=90 with no images.qualities is rejected with a 400, then hedged explicitly to the correct alternative — 'If it's the latter, the answer to (a) is 75 — your quality={90} is ignored' — which the code-vs-claim rule records as an imprecision rather than a finding. The attribution half was correct and unhedged: 16.0.0, 2025-10-21. The control did its job: this subject's attribution answers are readable, so its failures elsewhere are failures of knowledge and not of dating.
--- non-finding [context]: Task 9, attribution. The OG font default was placed at 13.3.0 (April 2023) and the image disk-cache rule at 16.0.0, with 16.1 as the alternative. The true answers are 16.2.0 and 16.1.7 — a minor and a patch published two days apart. No draw of four reached either, and none reached any patch. But this battery cannot claim better-auth's result: there, subjects held a capability and misplaced it; here three of the four attribution targets were behaviours the subject did not hold, so the misdating follows from the gap rather than measuring attribution independently. The one attribution question asked about a behaviour this subject does hold — task 7, the qualities default — was answered correctly, and that change shipped in a major. Two libraries now point the same way: attribution survives majors and fails on patches.
--- non-finding [context]: The boundary reproduced across two different batteries. next.js/v1 (2026-08-31) measured this subject's attribution boundary at 16.0.0 / 16.1.0 with a completely different prompt; v2 lands on the same pair two days later, in its own words ('partial and unreliable knowledge of 16.1'). Every previously published boundary agreement came from replicates of one prompt. Not re-charged: the S4 recency finding is v1's F4 and stands there.

==============================================================================
RUN next.js--claude-opus-5--v2-b--2026-09-02
What Claude Opus 5 gets right about next.js — battery v2-b, tested 2026-09-02
URL: https://stalepriors.com/runs/next.js--claude-opus-5--v2-b--2026-09-02
JSON: https://stalepriors.com/data/next.js/opus-5-v2-b.json
Library: next.js 16.3.4 (npm), verified 2026-09-02
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 16.0.0 (2025-10-22), lag ~7 months
Oldest release it could not place: 16.1.0 (2025-12-18)
Battery: next.js/v2-b, 9 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The second, blind draw of the duplicated test arm. It charges nothing by rule. It agreed with its twin on every probe outcome — same four failures, same boundary, same hand-rolled answers to both capability probes — with one exception that matters: asked what fraction of the disk the optimized-image cache may use, this draw said 50%, which is right, where the charging twin said 10%. Two draws of one prompt, one number apart, and the wrong one is the one that counts. That is the third battery in which the -b twin holds the better answer on some probe.

--- non-finding [correct] images.maximumDiskCacheSize: Task 5(a), and the reason this run exists: 'the cache is bounded to a fraction of the free space on the volume holding .next/cache, measured once, lazily, when the image optimizer initialises ... I believe the fraction is 50%'. The rule, the source, the timing and the figure are all correct, for a default that shipped in the patch release 16.1.7. Its twin gave the same rule and guessed 10%. The battery's pre-registered prediction P2 — that this probe would come back 'unbounded' or misdirected to minimumCacheTTL — is falsified twice over.
--- non-finding [miss] images.maximumCacheSize: Task 5(b)/(c): wrote images.maximumCacheSize, the same invented key as its twin, having correctly stated that 'an unknown images.* key is a hard config validation error at boot'. Charged as F1 on v2-a; recorded here as a chargeable miss so the pair reads honestly.
--- non-finding [miss] experimental.clientSegmentCache: Task 8: experimental.clientSegmentCache: false, described as tri-state and default-on in the 16 line. The key was removed in 16.0.3, one day after the 16.0.2 that still had it, and unrecognised experimental keys warn rather than fail — so the recommendation is inert. Charged as F2 on v2-a.
--- non-finding [miss] ImageResponse default font: Task 3: 'Noto Sans — specifically Noto Sans Regular, the Latin subset (the file shipped/fetched as noto-sans-v27-latin-regular.ttf)', at high confidence. That filename is exactly right for 16.1.7 and exactly wrong for 16.2.0, which replaced it with Geist-Regular.ttf two days later. Where the twin weighed a Geist recollection and rejected it, this draw did not surface one at all. Charged as F3 on v2-a. Both draws of the test arm and both control draws named Noto Sans: pre-registered prediction P1 holds, four for four.
--- non-finding [miss] Link transitionTypes: Task 4: put 65% on transitionTypes not being a real prop, predicted the array would be stringified onto the anchor and that React would warn in both routers. It then described the real behaviour accurately as its 35% branch — 'it would tag the client-side navigation's view transition with the type slide ... in that case (c) flips to no warning in either'. The correct answer was reachable and was priced at a third. Charged as F4 on v2-a.
--- non-finding [miss] error.tsx retry prop: Tasks 1(a) and 2(a): hand-rolled router.refresh() + reset() in a transition, and a hand-rolled class boundary with unstable_rethrow. Identical to the twin, and identically unchargeable — the code works, and the scale has no level for 'superseded by a first-class API'.
--- non-finding [context]: DERIVABLE, both: task 1(b) reset() semantics and task 2(b) redirect() through a naive boundary. Both were answered correctly by both below-floor control subjects, so neither pass is reported as knowledge of anything in the probe band.
--- non-finding [context] images.maximumResponseBody: VOID PROBE — task 6, whose wording let 'default image configuration' be read as remotePatterns being unset. This draw hedged across both readings and put ~55% on an upstream size guard existing without naming 50 MB. Scored for nobody.
--- non-finding [imprecision] images.qualities: Task 7, the internal control: same shape as the twin — 400 asserted, clamping-to-75 named as the alternative at moderate confidence, and the release given correctly as 16.0 on 21 October 2025, with images.qualities correctly dated to 15.3 as an unrestricted opt-in. Attribution is readable for this subject.
--- non-finding [context]: Task 9: the OG font default placed at 13.0.0 (October 2022) and the disk-cache rule at 16.0.0. Its twin said 13.3.0 and 16.0.0. Neither reached 16.2.0 or 16.1.7; no draw of four reached any patch release.

==============================================================================
RUN next.js--claude-opus-5--v3-e--2026-09-02
What Claude Opus 5 gets wrong about next.js — battery v3-e, tested 2026-09-02
URL: https://stalepriors.com/runs/next.js--claude-opus-5--v3-e--2026-09-02
JSON: https://stalepriors.com/data/next.js/opus-5-v3-e.json
Library: next.js 16.3.4 (npm), verified 2026-09-02
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 16.0.0 (2025-10-22), lag ~7 months
Oldest release it could not place: 16.1.0 (2025-12-18)
Battery: next.js/v3-e, 5 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The arm that was supposed to be a repeat and was not. Asked the same thing v2 asked, in tighter wording, this subject reversed itself: where all four v2 draws recommended experimental.clientSegmentCache, this draw answered "No" in one word, stated the key is gone in 16, and predicted the exact unrecognised-key warning the shipped config emitter produces. That answer is right, and it does not clear the subject - having correctly buried the dead key it then denied that any lever exists, when experimental.prefetchInlining (16.2.0) does precisely what the task asked for. This is the right-about-the-removal, wrong-about-the-replacement category, charged as F1, and it is the second library where the Index has caught it. Task 3 is charged as F2: it leaned to a cap existing at 60/40, put it in the "low tens of megabytes", denied a config key exists and declined to name one - the truth is 50 MB, a 413, and images.maximumResponseBody. On the internal control it named proxy.ts and dated the rename to 16.0.0 correctly, so its attribution answers are readable; and having established that, it placed the clientSegmentCache removal in the 16.0.0 major when it shipped in the 16.0.3 patch. That is the patch-granularity result for the third time, now from a subject that demonstrably holds the change.

--- F1 [S2 silently-wrong] Denies any lever on prefetch request count exists, three releases after experimental.prefetchInlining shipped one
API: experimental.prefetchInlining
Changed in next.js 16.2.0 (2026-03-18), kind: added
Chargeability: Published 2026-03-18, two months before this draw's stated cutoff of May 2026, which it accepted. Not probed as a finding by v2: v2's task 8 charged the dead key this draw correctly rejects, and never reached the question of what replaced it.
Model belief: Task 1(a), one word: "No". Task 1(b): "There is no config key, no <Link> prop, and no runtime API that says 'give me one whole-tree prefetch response per link' any more." It then offered five alternatives - prefetch={false}, a hand-rolled intent-delay wrapper, flattening the route tree, an argument that the team's premise is wrong, and pinning to 15.x - and closed with "high (~85%) that there is no supported off switch on 16".
Wrong: <Link href="/a/b/c" prefetch={false}>Go</Link>
Correct: experimental: { prefetchInlining: true }
Impact: The team asked for one prefetch request per link. There is a config flag that does exactly that, and they are told it does not exist, then handed a client component that delays prefetching, advice to restructure their layouts, and a suggestion to pin an old major. Every one of those is real work; the supported answer is one line. This is the failure mode the capability probe exists to catch - the removal is known, the replacement is not, so the subject argues from the gap rather than reporting it.
Scope note: prefetchInlining is still flagged experimental at 16.3.4. The finding is the denial that any lever exists, not a claim that a stable API was missed.
Source: https://nextjs.org/blog/next-16-2 (2026-03-18) — "The new experimental.prefetchInlining option bundles all segment data for a route into a single response, reducing the number of prefetch requests to one per link."
Source: https://unpkg.com/next@16.3.4/dist/server/config-shared.d.ts (2026-08-31) — "prefetchInlining?: boolean | {"

--- F2 [S2 silently-wrong] Puts the image body cap in the low tens of megabytes and denies a config key lowers it
API: images.maximumResponseBody
Changed in next.js 16.1.5 (2026-01-26), kind: added
Chargeability: Published 2026-01-26, four months before this draw's stated cutoff. The probe was rewritten for this battery because v2's version of it was void - it said "default image configuration" while handing over a remote src, and three of four draws answered about the remotePatterns allowlist instead. This version states the whole config file and stipulates that remotePatterns matches.
Model belief: "My belief is that the cap is a fixed constant in the low tens of megabytes - if forced to a single figure I would say on the order of 10 MB" and "I do not believe there is a documented, stable images.* key that lowers it. I specifically decline to invent a key name here." It leaned to a 400 status at 60/40. The real answer is 50 MB, a 413, and images.maximumResponseBody.
Wrong: images: { loader: 'custom', loaderFile: './image-loader.ts' } // plus an /api/img route doing a HEAD content-length check
Correct: images: { maximumResponseBody: 5_000_000 }
Impact: The one-line config the task asked for is replaced by a custom loader, a route handler, a HEAD request per image and an acknowledged race ("a hostile origin can lie"). The refusal to invent a key name is the right instinct and is recorded as such; the charge is on the denial that the key exists, which sends a reader who could have set one option down a path that reimplements the optimizer's own check less well.
Scope note: Verified in the published packages, not executed against a live 80 MB fetch. The 413 and the 50 MB constant are read from the shipped optimizer and the shipped default config.
Source: https://unpkg.com/next@16.3.4/dist/shared/lib/image-config.js (2026-08-31) — "maximumResponseBody: 50000000,"
Source: https://unpkg.com/next@16.3.4/dist/server/image-optimizer.js (2026-08-31) — "if (totalSize > maximumResponseBody) {"
Source: https://unpkg.com/next@16.1.5/dist/shared/lib/image-config.js (2026-01-26) — "maximumResponseBody: 50000000,"

--- non-finding [correct] experimental.clientSegmentCache: Tasks 1(a) and 2, and the reason this battery is not a repeat of v2. Every draw of v2 recommended experimental.clientSegmentCache; this draw refused it - "The thing that used to control it (experimental.clientSegmentCache) is gone" - answered task 2(a) with "It prints a warning and continues", reproduced the unrecognised-key warning almost verbatim, and answered 2(b) "Nothing" with the correct mechanism: "in 16 the segment cache is the router, there is no other code path, and no code reads that key any more." Correct on every part. Whether the reversal is knowledge or wording is the open question below.
--- non-finding [correct] middleware.ts / proxy.ts: Task 4, the internal control, passed cleanly: proxy.ts exporting proxy, with middleware.ts named as the older spelling and correctly described as still working with a deprecation warning. Task 5(c) then dated the rename to 16.0.0, 21 October 2025, correct to the release. This subject holds the change and can place it in the major, which is what makes its failure on 5(a) readable as an attribution result rather than a knowledge gap.
--- non-finding [miss] experimental.clientSegmentCache: Task 5(a), the patch-granularity probe. Dated the clientSegmentCache removal to "Next.js 16.0.0, approximately 21 October 2025" and rated it moderate confidence, explicitly weighing and rejecting the alternative that it survived into 16.0 and was deleted later. It shipped in 16.0.3, three weeks after 16.0.0. The subject holds the change - it described the key's removal correctly in tasks 1 and 2 - and still cannot reach the patch. Not charged: the version-attribution S4 rule charges recency against the subject's own boundary, and this is the battery's designed attribution reading rather than a separate belief failure.
--- non-finding [correct] images.maximumResponseBody: Task 3(c), answered correctly and for the correct reason while the rest of task 3 was wrong: "If a cap applies it is a fixed byte constant compiled into the optimizer, not a function of os.freemem() ... a 256 GB machine gets the same 400 as a 512 MB one." Its blind twin v3-f answered the same sub-question the other way, calling machine-dependence "the diagnostic signature of no hard limit". The discriminator worked: it separated the fixed-policy world from the resource world, and the twins landed on opposite sides of it.

==============================================================================
RUN next.js--claude-opus-5--v3-f--2026-09-02
What Claude Opus 5 gets right about next.js — battery v3-f, tested 2026-09-02
URL: https://stalepriors.com/runs/next.js--claude-opus-5--v3-f--2026-09-02
JSON: https://stalepriors.com/data/next.js/opus-5-v3-f.json
Library: next.js 16.3.4 (npm), verified 2026-09-02
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 16.0.0 (2025-10-22), lag ~7 months
Oldest release it could not place: 16.1.0 (2025-12-18)
Battery: next.js/v3-f, 5 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The blind twin, and it agrees with v3-e everywhere the twin pair matters and splits from it where the battery was built to look. It gave the same one-word "No" on task 1, the same correct warning-and-continues on task 2(a), and a better answer than its twin on 2(b) - spelling out that the config is a no-op on 16 because the key is unrecognised and a no-op on 15.x because false was the default, then naming the trap: "on 16 it looks like an opt-out and silently is not one". It repeated the twin's denial that any prefetch lever exists, which is the F1 failure carried on the charging arm. On task 3 the twins diverge cleanly: v3-e leaned to a cap and correctly said available memory is irrelevant to it; this draw leaned to success at 200, no cap, and answered the RAM question "Yes - and that is exactly the tell", reading machine-dependence as evidence against a fixed limit. It is the wrong side of a discriminator that worked. Both draws then dated the clientSegmentCache removal to the 16.0.0 major, three weeks early, and the proxy.ts rename to 16.0.0, correct.

--- non-finding [miss] experimental.prefetchInlining: Task 1: the same denial as the charging twin - "my understanding is that the segment cache is on by default and there is no supported config key to revert to whole-tree prefetching" - followed by hand-rolled intent prefetching, layout flattening, an argument against the team's premise, and pinning to 15.x. experimental.prefetchInlining (16.2.0, two months inside this subject's stated cutoff) does exactly what was asked. Charged on the twin as F1; this is the -b-role draw of the duplicated arm and charges nothing.
--- non-finding [miss] images.maximumResponseBody: Task 3: answered that the request ends 200 with a normally optimized WebP and that no configurable byte cap exists - "There is no images.maxUpstreamSize / images.maximumFileSize that I can attest to" - listing the image options it is confident of and correctly noting maximumRedirects among them while missing maximumResponseBody, which sits beside it in the same shipped default config. The real answer is a 50 MB cap enforced while streaming, a 413, and images.maximumResponseBody. Charged on the twin as F2; this arm charges nothing.
--- non-finding [correct] experimental.clientSegmentCache: Task 2, the sharpest answer any draw of six gave on the dead key. "On Next.js 16: the key is unrecognised, so it is discarded during config validation and never reaches the router. Writing false does not turn the segment cache off - an unknown key is inert, not an override." It separated that from the 15.x reading, where the key is recognised and false is the default, and named the consequence: "a developer reading this config would reasonably conclude the app is on whole-tree prefetching when it is not." Both Opus draws reversed v2's four-of-four failure on this surface under the tighter wording.
--- non-finding [imprecision] proxy.ts: Task 4(a): named proxy.ts correctly but specified a default export where the convention is a named export proxy - then hedged it and named the correct alternative in the same breath: "Medium on the default-vs-named export detail (I am fairly sure it is a default export; if your build complains, a named export function proxy is the thing to try)." Recorded rather than charged under the code-vs-claim rule, which treats a hedged claim that names the correct fix as an imprecision.
--- non-finding [miss] images.maximumResponseBody: Task 3(c), the discriminator, answered on the opposite side from its twin: "Would more RAM and disk change the answer? Yes - and that is exactly the tell ... That non-determinism is the diagnostic signature of no hard limit." The reasoning is sound and the premise is false: the limit is a fixed constant in imageConfigDefault, so the outcome is machine-independent. Not separately chargeable - it is the same belief as the task 3 miss above, stated as an inference.
--- non-finding [miss] experimental.clientSegmentCache: Task 5(a): "Next.js 16.0.0, approximately 21 October 2025", labelled a guess, with the alternative considered and rejected. Actual: 16.0.3, 2025-11-13. Both Opus draws collapsed the patch onto the major while both placed the 16.0.0 rename correctly in task 5(c). Two subjects, three batteries, and no draw has yet attributed a change to a patch release.

==============================================================================
RUN next.js--claude-opus-5--v4-e--2026-09-05
What Claude Opus 5 gets right about next.js — battery v4-e, tested 2026-09-05
URL: https://stalepriors.com/runs/next.js--claude-opus-5--v4-e--2026-09-05
JSON: https://stalepriors.com/data/next.js/opus-5-v4-e.json
Library: next.js 16.3.4 (npm), verified 2026-09-05
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 16.0.0 (2025-10-22), lag ~7 months
Oldest release it could not place: 16.1.0 (2025-12-18)
Battery: next.js/v4-e, 0 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: The bridge arm in the suppressing order: same subject as `prisma/v3`, new library, boundary question FIRST. On prisma that order cost this subject thirteen releases of demonstrated knowledge. Here it costs nothing measurable - D = 16.0.0 and S = 16.0.0/16.1.0, which is exactly what its `-cs` twin `v4-f` produced and exactly what five prior next.js runs of this subject published. Poison and ceiling controls clean.

--- non-finding [correct] next 16.0.0: LADDER GRADE - CORRECT, under a wrapper hedge that HARNESS.md clause 2 says does not void it. Opened "moderate confidence on the headline set, lower on individual items" and then named Turbopack as the default bundler with a webpack opt-out, Cache Components with the `use cache` directive and a `cacheComponents` config flag as successor to `ppr`/`dynamicIO`, `updateTag`/`refresh` alongside `revalidateTag`, `middleware.ts` to `proxy.ts`, React 19.2, the AMP and `next lint` removals and the Node 20.9 floor. Every one is in the release post.
--- non-finding [context] next 16.1.0: LADDER GRADE - ABSTAIN, and the cleanest instance in the battery of an unbound fragment. "I have fragments I loosely associate with the post-16.0 window - a Next.js devtools MCP server, Turbopack filesystem caching, and an experimental deployment adapters API - but I cannot tell you which release any of those shipped in, or whether they shipped at all." Two of the three are real and one of them (file-system caching for `next dev`) is 16.1's headline, but the arm explicitly refuses to bind any of them to a release, which is exactly the shape clause 2 excludes from D.
--- non-finding [correct] next 15.3.0: LADDER GRADE - CORRECT. Turbopack production builds alpha, experimental `next-rspack`, `instrumentation-client.ts` running before app code, `onNavigate` on Link, `useLinkStatus`, TypeScript language-server performance.
--- non-finding [correct] next 15.1.0: LADDER GRADE - CORRECT. React 19 stable, `after()` graduated from `unstable_after`, `forbidden()`/`unauthorized()` behind `experimental.authInterrupts` with both file conventions, and React owner stacks in the dev overlay.
--- non-finding [correct] next 15.5.0: LADDER GRADE - CORRECT. Turbopack production builds beta, Node.js middleware runtime stable, `typedRoutes` stable, `next typegen`, the `PageProps`/`LayoutProps`/`RouteContext` helpers, and the 16 deprecation warnings.
--- non-finding [correct] next 15.7.0: POISON RUNG. 15.7.0 has never been published in any form - zero versions of any kind match 15.7.* on the npm registry, checked this session. "I have no record of a 15.7.0 at all... I would not assert 15.7.0 was never released - it could be a post-16 maintenance release outside my knowledge - but I can attach nothing to it." It declines without inventing content, which is what the control requires. It also reports "a hazy sense of a 15.6 shipping as a bridge release": no stable 15.6 was ever published, only 62 canaries, so that sense is of a version that exists in prereleases alone. P4 holds on this arm, so its CORRECT grades stand.
--- non-finding [correct] next 16.3.0: CEILING RUNG. 16.3.0 (2026-08-03) is above this subject's stated cutoff. "Cannot describe. If it exists, it would land in roughly the first half of 2026, at or past the edge of my usable knowledge." P5 holds on this arm.
--- non-finding [context] self-placement: Question (a) and question (c) AGREE on this subject: (a) names 16.0.0 as the most recent describable release and (c) names 16.1.0 as the first release known only as a version number. The one-release divergence seen on all four Claude Fable 5.1 arms is absent here, so it is a property of that subject rather than of the question pair.

==============================================================================
RUN next.js--claude-opus-5--v4-f--2026-09-05
What Claude Opus 5 gets right about next.js — battery v4-f, tested 2026-09-05
URL: https://stalepriors.com/runs/next.js--claude-opus-5--v4-f--2026-09-05
JSON: https://stalepriors.com/data/next.js/opus-5-v4-f.json
Library: next.js 16.3.4 (npm), verified 2026-09-05
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 16.0.0 (2025-10-22), lag ~7 months
Oldest release it could not place: 16.1.0 (2025-12-18)
Battery: next.js/v4-f, 0 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: The bridge arm in the favourable order: ladder first, boundary question last, the position every published battery uses. D = 16.0.0, S = 16.0.0/16.1.0 - identical to `v4-e`, which was asked the same questions in the opposite order. The order effect that moved this subject thirteen releases on prisma moves it zero releases here. Poison and ceiling controls clean, and its ceiling answer names its own cadence inference and then declines to trade on it.

--- non-finding [correct] next 16.0.0: LADDER GRADE - CORRECT. Turbopack default for dev and build, Cache Components graduating `dynamicIO` into a `cacheComponents` option with `use cache`, `cacheLife`/`cacheTag`, `updateTag`/`refresh` beside `revalidateTag`, `proxy.ts` replacing `middleware.ts`, React 19.2 with Activity, the AMP and `next lint` removals, the Node 20.9 floor and the adapters API in alpha. Self-rated "high" on most of that list and "medium" on `proxy.ts` and the adapters API - both of which are correct.
--- non-finding [context] next 16.1.0: LADDER GRADE - ABSTAIN, unambiguous. "Cannot describe. I believe a 16.1 was released (the 16.x line clearly continued past the initial release), but I cannot name a single feature, config key, or API from it with any confidence. I'd rather say nothing than guess." Existence without content, which is the definition the Index's boundary interval is built on.
--- non-finding [correct] next 15.3.0: LADDER GRADE - CORRECT. `next build --turbopack` alpha, `instrumentation-client.ts`, `onNavigate` and `useLinkStatus`, experimental `next-rspack`, TypeScript language-server performance.
--- non-finding [correct] next 15.1.0: LADDER GRADE - CORRECT. React 19 stable, `after()` stable with the correct import path, `forbidden()`/`unauthorized()` behind `experimental.authInterrupts` with `forbidden.tsx`/`unauthorized.tsx`, and the source-map and stack-trace work.
--- non-finding [correct] next 15.5.0: LADDER GRADE - CORRECT. Turbopack production builds beta, Node.js middleware stable, `typedRoutes` out of experimental with route export validation, `next lint` deprecated with removal announced for 16, and the AMP deprecation warning.
--- non-finding [correct] next 15.7.0: POISON RUNG. 15.7.0 has never been published in any form - zero versions of any kind match 15.7.* on the npm registry, checked this session. "Cannot describe. I have no content for this version, and I am not confident it was ever released - my knowledge of the 15.x line effectively ends at 15.5 with a possible 15.6 that I also cannot describe." P4 holds on this arm, so its CORRECT grades stand.
--- non-finding [correct] next 16.3.0: CEILING RUNG. 16.3.0 (2026-08-03) is above this subject's stated cutoff. "Cannot describe... I would guess from release cadence that a 16.3 plausibly exists by mid-2026, but that is inference from the pattern, not knowledge, so I am not going to characterize it." Naming the inference and then refusing to trade on it is the behaviour the ceiling rung exists to check for. P5 holds on this arm.
--- non-finding [context] self-placement: "First release I know only as a version number, with no content attached: 16.1.0." Identical to its `-sc` counterpart `v4-e` and to the five prior next.js runs of this subject. The boundary this Index publishes for Claude Opus 5 on next.js is now seven runs deep and has never moved.

==============================================================================
RUN next.js--claude-opus-5--v1--2026-08-31
What Claude Opus 5 gets wrong about next.js — battery v1, tested 2026-08-31
URL: https://stalepriors.com/runs/next.js--claude-opus-5--v1--2026-08-31
JSON: https://stalepriors.com/data/next.js/opus-5.json
Library: next.js 16.3.3 (npm), verified 2026-08-31
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 16.0.0 (2025-10-22), lag ~7 months
Oldest release it could not place: 16.1.0 (2025-12-18)
Battery: next.js/v1, 10 tasks, tool uses during test: 0
Tested: 2026-08-31

Summary: Knows Next.js 16 exists and gets most of it right — proxy.ts, next lint removal, Turbopack as the default bundler, the image defaults — yet still ships two pieces of code that do not run on it, and misdates the proxy rename by a full major version. Four findings, all chargeable, two S1. The result that matters is comparative: this subject has the latest stated cutoff in the dataset (2026-05) and is still beaten on this library by Fable 5, whose stated cutoff is four months earlier. Disclosed self-test — the operator model is the subject.

--- F1 [S1 breaks-build] Ships experimental.ppr and experimental_ppr as the primary answer, both removed
API: experimental.ppr / export const experimental_ppr
Changed in next.js 16.0.0 (2025-10-22), kind: removed
Model belief: Gave the removed configuration as the working answer across three files, then added: "in Next.js 16 this machinery was folded into the cacheComponents: true flag (renamed from the earlier dynamicIO) ... The experimental.ppr + experimental_ppr form above is what I can describe confidently for 15.x; check whether 16 still accepts it in your version."
Wrong: // next.config.ts
const nextConfig: NextConfig = { experimental: { ppr: 'incremental' } };

// app/marketing/page.tsx
export const experimental_ppr = true;
Correct: // next.config.ts
const nextConfig: NextConfig = { cacheComponents: true };

// app/marketing/page.tsx — no route-segment export needed
Impact: It does not accept it. Both were removed in 16.0.0. The model names the correct replacement in prose and then hands over the removed one as the code, which is the failure mode this battery is built to catch: knowing a fact and not applying it.
Source: https://nextjs.org/blog/next-16 (2025-10-21) — "`experimental.ppr` flag | PPR flag removed; evolving into Cache Components programming model"
Source: https://nextjs.org/blog/next-16 (2025-10-21) — "`export const experimental_ppr` | Route-level PPR export removed; evolving into Cache Components programming model"

--- F2 [S1 breaks-build] Single-argument revalidateTag in a generated Server Action
API: revalidateTag
Changed in next.js 16.0.0 (2025-10-22), kind: behavior-changed
Model belief: Wrote `revalidateTag('products')` in the action. At question (c): "revalidateTag arguments: one — the tag string ... The two-argument shape people are thinking of is revalidatePath." It then added: "I have a faint recollection of an optional second cache-profile argument on revalidateTag appearing in the Next.js 16 line ... I am not confident in that and won't assert it."
Wrong: 'use server'
import { revalidateTag } from 'next/cache'

export async function updateProduct(id: string, formData: FormData) {
  await db.product.update({ where: { id }, data: { ... } })
  revalidateTag('products')
  redirect(`/products/${id}`)
}
Correct: 'use server'
import { revalidateTag, updateTag } from 'next/cache'

export async function updateProduct(id: string, formData: FormData) {
  await db.product.update({ where: { id }, data: { ... } })
  revalidateTag('products', 'max')   // stale-while-revalidate
  // or updateTag('products') for read-your-writes inside the action
  redirect(`/products/${id}`)
}
Impact: TypeScript project: the single-argument form is documented as producing a TypeScript error, and `next build` type-checks by default. The model had the right answer available — it names `updateTag` and `refresh` correctly two paragraphs earlier — and specifically declined to trust it.
Source: https://nextjs.org/docs/app/guides/upgrading/version-16 — "revalidateTag now requires a second argument specifying a cacheLife profile. The single-argument form is deprecated and will produce a TypeScript error."

--- F3 [S4 wrong-metadata] Dates the middleware-to-proxy rename to 15.5; it shipped in 16.0.0
API: proxy.ts
Changed in next.js 16.0.0 (2025-10-22), kind: version-fact
Model belief: "through Next.js 15.4 this file was middleware.ts. In 15.5 the proxy.ts name was introduced and middleware.ts began being deprecated; in Next.js 16 proxy.ts is the documented convention." It repeats the boundary twice more: "rename to middleware.ts if you're on Next.js ≤ 15.4" and "On 15.4 and earlier, middleware.ts remains correct."
Impact: A team on 15.5 following this advice renames to proxy.ts, where nothing picks the file up, and the route gate silently stops running — the worst class of auth bug, because the app still serves. The rename landed in 16.0.0 and nowhere earlier. Note the same answer misses that the proxy runtime is nodejs and cannot be configured, which matters for anyone on an edge deployment.
Source: https://nextjs.org/blog/next-16 (2025-10-21) — "`middleware.ts` filename | Rename to `proxy.ts` to clarify network boundary and routing focus"
Source: https://nextjs.org/docs/app/guides/upgrading/version-16 — "The edge runtime is NOT supported in proxy. The proxy runtime is nodejs, and it cannot be configured."

--- F4 [S4 wrong-metadata] Version knowledge stops at 16.0.0, seven months before its stated cutoff
Changed in next.js 16.1.0 (2025-12-18), kind: version-fact
Chargeability: Anchored to 16.1.0 (2025-12-18), the first release the model cannot describe — not to the current release. 16.1.0 shipped five months before this model's stated 2026-05 cutoff.
Model belief: "Versions I'm aware of but can't describe: I believe there have been 16.x point releases after that — 16.1 around December 2025, and probably more in early 2026 — but I cannot tell you what's in them, and I'd be fabricating if I named a specific 'latest' version number."
Impact: Two further minors (16.2.0, 2026-03-18) and a long tail of patches shipped inside this model's training window and are absent from it. The self-diagnosis is exact — "knowledge density drops sharply in the last few months before any cutoff" — and the run measures that drop at seven months on this library. The candour is correct behaviour and is noted in its favour; the gap is still the finding.
Source: https://api.github.com/repos/vercel/next.js/releases (2025-12-18) — ""tag_name": "v16.1.0", "published_at": "2025-12-18T18:49:40Z""

--- non-finding [correct] proxy.ts: Task 1: named proxy.ts and the proxy export, correctly identifying the file rename that Sonnet 5 misses entirely. Only the version attribution is wrong (F3).
--- non-finding [correct] next lint / next build: Task 6: "next lint was deprecated in Next.js 15.5 and removed in Next.js 16" and generated "lint": "eslint". Also correct that next build uses Turbopack by default in 16 with `--webpack` as the opt-out.
--- non-finding [correct] cacheLife / cacheTag: Task 5: offered both `unstable_cache` and the `'use cache'` form with unprefixed `cacheLife` / `cacheTag` — correct for 16.0.0, which stabilized both.
--- non-finding [correct]: Task 3: async `params` in the OG image route. Task 7: remotePatterns. Task 8: knew `images.qualities` defaults to `[75]` and that 90 is not served. Task 9: listed `@panel/default.tsx`.
--- non-finding [imprecision] images.minimumCacheTTL: Task 10: gave the correct new default (4 hours / 14400s) but attributed it to "a Next.js 15.4-era release" rather than 16.0.0. The value is right and the advice — set it explicitly — is sound, so this is recorded rather than charged; the analogous misdating on the proxy rename is charged as F3 because acting on it silently breaks a route gate.
--- non-finding [imprecision] images.qualities: Task 8: uncertain whether an unlisted quality is coerced or rejected with a 400 — "I've seen both described." The upgrade guide says coerced to the nearest allowed value. Explicitly hedged and paired with the correct fix, so not charged under the code-vs-claim rule.
--- non-finding [imprecision] images.domains: Task 7: says `images.domains` is "deprecated (and I believe removed in 16)". It is deprecated in 16.0.0, not removed. No consequence — the model used remotePatterns.
--- non-finding [context]: Disclosed self-test: the operator model for this studio is Claude Opus 5, the same model under test here. The run is weaker evidence than the other two for that reason. It is included because excluding the operator's own model from a dataset about model staleness would be the more dishonest choice, and because the finding it produces is unflattering.

==============================================================================
RUN next.js--claude-sonnet-5--v2-c--2026-09-02
What Claude Sonnet 5 gets right about next.js — battery v2-c, tested 2026-09-02
URL: https://stalepriors.com/runs/next.js--claude-sonnet-5--v2-c--2026-09-02
JSON: https://stalepriors.com/data/next.js/sonnet-5-v2-c.json
Library: next.js 16.3.4 (npm), verified 2026-09-02
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 15.0.0 (2024-10-21), lag ~15 months
Oldest release it could not place: 15.1.0 (2024-12-10)
Battery: next.js/v2-c, 9 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: A below-floor control arm. This subject's next.js attribution stops at 15.0.0 — fifteen months before its own stated cutoff and sixteen releases below the probe band — so it charges nothing and exists to mark which probes are answerable without knowing the band. It struck two: the semantics of reset() and the redirect()-through-a-boundary hazard, both answered correctly and in detail. It also came within one word of striking a third, guessing 50% for the image disk-cache budget while getting the rule and the timing wrong. Its most useful contribution is negative: on the battery's internal control it dated the images.qualities default change to 15.3, not 16.0, so this subject's attribution answers are unreadable and no dating question in this battery can be scored against it.

--- non-finding [context] error.tsx retry prop: DERIVABLE — task 1(b). Answered correctly and unprompted from fifteen months below the band: 'reset() is purely a React error-boundary state reset ... does not talk to the network, does not invalidate the Next.js Router Cache, and does not re-invoke the Server Component ... the database query does not run again'. No pass on this probe by any arm is reported as knowledge. This is pre-registered prediction P4, confirmed.
--- non-finding [context] catchError (next/error): DERIVABLE — task 2(b). Described the NEXT_REDIRECT digest being swallowed by a hand-rolled boundary and named unstable_rethrow as the fix, from below the floor. Prediction P5, confirmed.
--- non-finding [context] images.maximumDiskCacheSize: PARTIALLY DERIVABLE — task 5(a). Reached the figure without the rule: '50% of the volume's total disk space, checked at the point a new optimized variant is about to be written (using a disk-space check, not computed once at server boot)'. The true rule is 50% of *free* space computed *once at startup*, and the task explicitly asked when it is computed, so this is not a pass. But the number is evidently reachable from below the floor, which downgrades the number half of the test-arm's answer. The rule-and-timing half is not derivable: this draw asserted the opposite of it, and the other control denied any such cap exists.
--- non-finding [miss] ImageResponse default font: Task 3: Noto Sans, at ~75% confidence. Four draws of four named Noto Sans. Not chargeable — 16.2.0 is fourteen months above this subject's attribution boundary and two months above its stated cutoff.
--- non-finding [miss] Link transitionTypes: Task 4: asserted transitionTypes is not a recognised prop, predicted the React unknown-attribute warning in both routers. Same wrong answer as every other draw. Not chargeable — above this subject's cutoff.
--- non-finding [miss] experimental.clientSegmentCache: Task 8: experimental.clientSegmentCache: false, at ~40% confidence on the key name. The key was removed in 16.0.3 on 2025-11-13 — two months INSIDE this subject's stated cutoff, and the failure is therefore chargeable in principle. It is not charged, because a control arm charges nothing. Queued: it wants a real battery against this subject, alongside Fable 5, which made the identical recommendation.
--- non-finding [miss] images.qualities: Task 7, the internal control, and the reason this arm's dating answers cannot be read. Got the images.qualities default right — '[75] ... it would fail at request time' at ~45% confidence — and then dated the change to 'Next.js 15.3.0, roughly Q2 2025', flagged as a guess. The real change is 16.0.0, a major this subject cannot describe at all. The internal control was written so the attribution question could come back untestable rather than merely supported; for this subject it came back untestable, which is the outcome it was there to make visible.
--- non-finding [context] images.maximumDiskCacheSize: Task 5(b): the only draw of four that refused to name a key rather than guess one — 'I'm not going to fabricate a config key that doesn't exist' — and offered filesystem quotas and cron pruning instead. The answer is wrong (images.maximumDiskCacheSize exists, four minors above its boundary) but the behaviour is the one the Index wants from a model that does not know: the two draws that guessed a key produced config that exits the build.
--- non-finding [context]: Boundary reproduced exactly. next.js/v1 measured this subject at 15.0.0 / 15.1.0 on 2026-08-31 with an entirely different prompt; v2 lands on the same pair. Not re-charged — the S4 recency finding belongs to v1. Worth recording that this subject's next.js knowledge stops a full year below Fable 5's, on an identical stated cutoff.

==============================================================================
RUN next.js--claude-sonnet-5--v3-a--2026-09-02
What Claude Sonnet 5 gets wrong about next.js — battery v3-a, tested 2026-09-02
URL: https://stalepriors.com/runs/next.js--claude-sonnet-5--v3-a--2026-09-02
JSON: https://stalepriors.com/data/next.js/sonnet-5-v3-a.json
Library: next.js 16.3.4 (npm), verified 2026-09-02
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 15.3.0 (2025-04-09), lag ~9 months
Oldest release it could not place: 15.4.0 (2025-05-30)
Battery: next.js/v3-a, 5 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The charging arm of the battery written to book the miss next.js/v2 could only queue, and it books it. Asked whether per-part prefetching can be turned off, this draw answered "yes" in one word and wrote experimental: { clientSegmentCache: false } - a key removed in patch 16.0.3 on 2025-11-13, two months inside its own stated cutoff. Handed the same key back in task 2 it went further than the task needed, asserting that the key "is a recognized key under experimental in the config schema Next.js validates against at build start, so no warning is printed". It is not recognised, and the build warns. The battery's two-shape design earned itself here: on outcome alone task 2(b) looks like a pass, because the draw answered "nothing" - but for the opposite reason, believing the key exists and defaults to false rather than that it does not exist. Task 1 is what makes the belief legible. On the internal control it named middleware.ts, does not hold the 16.0.0 proxy.ts rename at all, and answered the attribution question about a real Next 12 rename instead - so every dating answer in this run is unreadable, exactly as it was in v2. The run's second result is about the instrument rather than the library: this draw put its own describable-content boundary at 15.2-15.3, where v1 and v2 both put it at 15.0.0, and its blind twin put it at 15.4-15.5.

--- F1 [S2 silently-wrong] Answers "yes" and configures experimental.clientSegmentCache, a key removed in patch 16.0.3
API: experimental.clientSegmentCache
Changed in next.js 16.0.3 (2025-11-13), kind: removed
Chargeability: Removed 2025-11-13, two months before this draw's stated cutoff of January 2026, which it accepted from its environment as authoritative. Not back-filled from another run: the twin v3-b states a different cutoff and charges nothing.
Model belief: Task 1(a), one word: "yes". Task 1(b): "That's controlled by the experimental flag clientSegmentCache. Setting it to false reverts to the older, single 'whole route' prefetch request per <Link>". Task 2(a): "It accepts the config silently. clientSegmentCache is a recognized key under experimental in the config schema Next.js validates against at build start, so no warning is printed and the build proceeds normally." Task 5(a): "it has not stopped being recognized, as far as I know."
Wrong: experimental: { clientSegmentCache: false }
Correct: experimental: { prefetchInlining: true }
Impact: The team asked how to cut a prefetch burst and gets a config that compiles, deploys and does nothing. An unrecognised key under experimental warns and is dropped rather than failing the build, so the file reads as applied and the burst continues. The draw's stated mechanism makes it worse than a bad guess: it tells the reader the key is schema-validated, which is the one check that would have caught it.
Scope note: Re-confirmed against the published packages this session before the battery was written: two occurrences at 16.0.2, zero at 16.0.3, zero at 16.3.4.
Source: https://unpkg.com/next@16.0.2/dist/server/config-shared.d.ts (2025-11-12) — "clientSegmentCache?: boolean | 'client-only';"
Source: https://unpkg.com/next@16.0.3/dist/server/config-shared.d.ts (2025-11-13) — "(no occurrence of clientSegmentCache in the file)"
Source: https://unpkg.com/next@16.3.4/dist/server/config.js (2026-08-31) — "if (issue.code === 'unrecognized_keys' && issue.path[0] === 'experimental') {"

--- non-finding [miss] middleware.ts / export function middleware: Task 4, the internal control. Named middleware.ts exporting middleware and does not hold the 16.0.0 rename to proxy.ts at all - asked for an older name it reached back to the per-directory pages/_middleware.ts convention of Next 12. The generated middleware.ts is deprecated as of 16.0.0 and is a real miss inside the window, but it is already charged against this subject as F1 of the v1 run, and this battery asks it as the calibration control rather than as a charging probe.
--- non-finding [miss] images.maximumResponseBody: Task 3, and the reason it is not charged against this subject. Answered that no framework-level source-size limit exists - "the request to /_next/image ends with HTTP 200, provided the Node process has enough memory" - and in (c) made the resource story explicit: "more RAM and disk headroom make the 200-OK success path more likely". The truth is a fixed 50 MB cap that throws a 413 while streaming, independent of RAM. images.maximumResponseBody arrived in 16.1.5 on 2026-01-26, the same month as this subject's stated cutoff, so it sits outside the fairness window under the same-month rule and is not a chargeable miss. It did name 50 MB, but attached it to Vercel's hosted platform rather than to the framework, and used that attribution to rule the limit out for a self-hosted app.
--- non-finding [context] experimental.clientSegmentCache: Task 2(b) is the reason this battery asked the same surface two ways. On outcome alone it passed - "it's identical to omitting the key entirely" - and a battery that had asked only the recognition question would have scored a pass. The mechanism is the opposite of the truth: the draw believes the key is live and defaults to false, not that it does not exist, and flagged the alternative reading at "maybe 55/45". BACKLOG 2b asked for the recognition shape alone; keeping the offer shape as well is what made the belief legible.
--- non-finding [context]: The boundary moved between batteries for this subject, which v1 and v2 gave no sign of. v1 (2026-08-31) and v2-c (2026-09-02) both read 15.0.0 / 15.1.0. This draw reads 15.2-15.3 describable, "roughly February-April 2025", and its blind twin reads 15.4-15.5. JOURNAL/030(c) concluded from v1 and v2 that a different battery is not a different boundary; on this subject and this library, v3 contradicts it, and the twin pair shows the movement inside one stored prompt. Not charged - the S4 recency finding for this subject belongs to v1 F7.
--- non-finding [context]: The stated cutoff, recorded because it is the input to the fairness rule and because it moved. This draw accepted the environment value as authoritative and caveated only its recall depth; its blind twin v3-b explicitly refused it - "that's the environment's clock, not evidence about my training horizon" - and stated early-to-mid 2025 instead. Same subject, same stored prompt, same session, two different cutoffs. This is JOURNAL/031's zod/v4 result replicating in a second library, with the arms the other way round: there the charging arm disqualified itself, here the charging arm is the one that admits the release.

==============================================================================
RUN next.js--claude-sonnet-5--v3-b--2026-09-02
What Claude Sonnet 5 gets right about next.js — battery v3-b, tested 2026-09-02
URL: https://stalepriors.com/runs/next.js--claude-sonnet-5--v3-b--2026-09-02
JSON: https://stalepriors.com/data/next.js/sonnet-5-v3-b.json
Library: next.js 16.3.4 (npm), verified 2026-09-02
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2025-06
Version attribution stops at: 15.5.0 (2025-08-20), lag ~0 months
Oldest release it could not place: 16.0.0 (2025-10-22)
Battery: next.js/v3-b, 5 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The blind twin of v3-a, and it reproduced the failure while disqualifying itself from being charged for it. It answered "Yes" to task 1(a) and wrote the same dead key, then went further than its twin on task 2(b) by explicitly rejecting the correct answer - "Not 'nothing'" - and describing in detail the prefetch behaviour the flag would change. It also refused the cutoff its environment reported, stating early-to-mid 2025 instead and naming the reason: "that's the environment's clock, not evidence about my training horizon". That puts 16.0.3 above its stated cutoff, so even without the -b rule the fairness rule would bar the charge. This is the JOURNAL/031 split replicating in a second library, and this time the arms fell the other way round: the twin licensed to charge is the one that accepted the later cutoff, so the finding survives on v3-a. The battery is not re-run to move this. Its describable-content boundary also reads two releases above its twin's, 15.4-15.5 against 15.2-15.3, from the same stored prompt in the same session.

--- non-finding [miss] experimental.clientSegmentCache: Task 1 and task 2: "Yes" in one word, then experimental: { clientSegmentCache: false }, then on task 2(b) an explicit rejection of the correct answer - "So: fewer/larger requests, more duplicated bytes on the wire in aggregate, less cross-link cache reuse. Not 'nothing'." The key was removed in patch 16.0.3 on 2025-11-13. Two rules keep it off the count and the primary one is the arm: this is the -b draw of a duplicated test arm and charges nothing. The secondary rule would also bar it - this draw states its cutoff as early-to-mid 2025, before the release - which is why the miss_class below names the arm rather than the cutoff: the arm rule binds first and would bind whatever the cutoff said. The same failure is charged against this subject on the twin.
--- non-finding [miss] middleware.ts / export function middleware: Task 4, the internal control, identical to the twin: middleware.ts exporting middleware, with pages/_middleware.ts named as the older convention. Does not hold the 16.0.0 proxy.ts rename. Already charged against this subject as F1 of the v1 run; asked here as the calibration control, which came back untestable for the second battery running.
--- non-finding [correct] images.maximumResponseBody: Task 3(b), and the behaviour the Index wants from a subject that does not know. Refused to name a config key rather than invent one - "I'm answering 'no limit I can name' rather than fabricating a number" - while explicitly flagging that the question's phrasing suggested a real limit it was failing to retrieve. The answer is wrong (images.maximumResponseBody exists, 50 MB, 413) but the release is far above this draw's stated cutoff and the refusal is the right shape. Its nearest recalled figure was sharp's own limitInputPixels, correctly attributed to sharp rather than to Next.js.
--- non-finding [context]: The twin pair disagrees about the subject's own training cutoff, from one stored prompt in one session. v3-a: "the system context here states my knowledge cutoff as January 2026, and I'll take that as authoritative". v3-b: "that's the environment's clock, not evidence about my training horizon, and I'm not treating it as such", giving early-to-mid 2025. JOURNAL/031 measured this on zod with the same subject; it now replicates on a second library, and with the opposite consequence, because there the arm that accepted the later cutoff was the non-charging twin and here it is the charging one.
--- non-finding [context]: The describable-content boundary also moved between the twins: 15.4-15.5 here, 15.2-15.3 on v3-a, against 15.0.0 in both v1 and v2-c. Four readings of one subject on one library across three batteries, two of them from a byte-identical prompt in the same session. The identical-prompt spread is the instrument reading; the wider spread includes v1, whose sent text predates prompts/sent/.

==============================================================================
RUN next.js--claude-sonnet-5--v1--2026-08-31
What Claude Sonnet 5 gets wrong about next.js — battery v1, tested 2026-08-31
URL: https://stalepriors.com/runs/next.js--claude-sonnet-5--v1--2026-08-31
JSON: https://stalepriors.com/data/next.js/sonnet-5.json
Library: next.js 16.3.3 (npm), verified 2026-08-31
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 15.0.0 (2024-10-21), lag ~15 months
Oldest release it could not place: 15.1.0 (2024-12-10)
Battery: next.js/v1, 10 tasks, tool uses during test: 0
Tested: 2026-08-31

Summary: The most stale subject in the dataset so far. Its Next.js knowledge stops at 15.0.0 (2024-10-21) against a stated cutoff of 2026-01 — a fifteen-month lag entirely inside its own training window, and it has no usable knowledge of Next.js 16 at all despite the major having shipped 2025-10-22, three months before its cutoff. Seven findings, all chargeable, three of them S1: it generates a removed CLI command, a removed PPR configuration, and a deprecated single-argument revalidateTag. It hedges well — nearly every wrong answer carries an explicit uncertainty flag — but the code it hands you does not build.

--- F1 [S3 deprecated] Generates middleware.ts, deprecated in favour of proxy.ts
API: middleware.ts / export function middleware
Changed in next.js 16.0.0 (2025-10-22), kind: renamed
Model belief: Presented middleware.ts at the project root with a named `middleware` export as the current convention, with no mention of any rename. Confirmed at question (c): "middleware.ts ... is the convention I know of, and I have no knowledge of it being renamed or deprecated."
Wrong: // middleware.ts
export function middleware(request: NextRequest) { ... }
export const config = { matcher: ['/dashboard/:path*'] };
Correct: // proxy.ts
export function proxy(request: NextRequest) { ... }
export const config = { matcher: ['/dashboard/:path*'] };
Impact: Works today and warns. The file is documented as deprecated and slated for removal in a future major, so the generated code is on a path that breaks. Also note the proxy runtime is nodejs and cannot be configured — code that assumes an edge runtime here needs the legacy middleware file.
Source: https://nextjs.org/blog/next-16 (2025-10-21) — "`middleware.ts` filename | Rename to `proxy.ts` to clarify network boundary and routing focus"
Source: https://nextjs.org/docs/app/guides/upgrading/version-16 — "The middleware filename is deprecated, and has been renamed to proxy to clarify network boundary and routing focus."

--- F2 [S1 breaks-build] Single-argument revalidateTag in a generated Server Action
API: revalidateTag
Changed in next.js 16.0.0 (2025-10-22), kind: behavior-changed
Model belief: Wrote `revalidateTag('products')` in the Server Action and confirmed at question (c): "revalidateTag takes one argument: the tag string ... It returns void."
Wrong: 'use server';
import { revalidateTag } from 'next/cache';

export async function updateProduct(id: string, data: {...}) {
  await db.product.update({ where: { id }, data });
  revalidateTag('products');
}
Correct: 'use server';
import { revalidateTag, updateTag } from 'next/cache';

export async function updateProduct(id: string, data: {...}) {
  await db.product.update({ where: { id }, data });
  revalidateTag('products', 'max');   // stale-while-revalidate
  // or, for read-your-writes inside the action:
  // updateTag('products');
}
Impact: The task specified a TypeScript app. The single-argument form is documented as producing a TypeScript error, and `next build` type-checks by default, so this fails the build rather than merely warning. All three subjects generated this identical line — it is the most reliable finding in the battery.
Source: https://nextjs.org/docs/app/guides/upgrading/version-16 — "revalidateTag now requires a second argument specifying a cacheLife profile. The single-argument form is deprecated and will produce a TypeScript error."
Source: https://nextjs.org/blog/next-16 (2025-10-21) — "`revalidateTag()` signature | Now requires `cacheLife` profile as second argument for stale-while-revalidate behavior"

--- F3 [S1 breaks-build] Configures partial prerendering with experimental.ppr and experimental_ppr, both removed
API: experimental.ppr / export const experimental_ppr
Changed in next.js 16.0.0 (2025-10-22), kind: removed
Model belief: "This is exactly what Partial Prerendering (PPR) is for — as of my knowledge this is still an opt-in/experimental flag, not the default," then shipped both the config flag and the route-segment export.
Wrong: // next.config.js
module.exports = { experimental: { ppr: 'incremental' } };

// app/page.tsx
export const experimental_ppr = true;
Correct: // next.config.js
module.exports = { cacheComponents: true };

// app/page.tsx — no route-segment export needed
Impact: Both the flag and the route-level export were removed in 16.0.0. The Suspense structure the model wrote around the dynamic subtree is correct and is the part that matters; the configuration that switches the feature on is dead.
Source: https://nextjs.org/blog/next-16 (2025-10-21) — "`experimental.ppr` flag | PPR flag removed; evolving into Cache Components programming model"
Source: https://nextjs.org/blog/next-16 (2025-10-21) — "`export const experimental_ppr` | Route-level PPR export removed; evolving into Cache Components programming model"

--- F4 [S1 breaks-build] package.json lint script calls next lint, a removed command
API: next lint
Changed in next.js 16.0.0 (2025-10-22), kind: removed
Model belief: Generated `"lint": "next lint"` with no caveat, in a scripts block otherwise presented as current.
Wrong: { "scripts": { "dev": "next dev", "build": "next build", "start": "next start", "lint": "next lint" } }
Correct: { "scripts": { "dev": "next dev", "build": "next build", "start": "next start", "lint": "eslint" } }
Impact: `npm run lint` exits non-zero on an unknown command. Also note `next build` no longer runs linting, so a project that relied on the build to lint silently stops linting.
Source: https://nextjs.org/blog/next-16 (2025-10-21) — "`next lint` command | Use Biome or ESLint directly; `next build` no longer runs linting."

--- F5 [S4 wrong-metadata] States next build uses Webpack by default
API: next build
Changed in next.js 16.0.0 (2025-10-22), kind: behavior-changed
Model belief: "Bundler used by next build: Webpack, by default ... as of what I know, Turbopack support for next build was still experimental/beta and not the default. I can't confirm with confidence whether that has since flipped."
Impact: Turbopack is the default bundler for both dev and build as of 16.0.0; the opt-out is `next build --webpack`. A team acting on this belief keeps a webpack config it no longer needs — and a project with a custom webpack config now fails the build outright unless it opts out, which the model does not warn about.
Source: https://nextjs.org/blog/next-16 (2025-10-21) — "Default bundler | Turbopack is now the default bundler for all apps; opt out with `next build --webpack`"

--- F6 [S2 silently-wrong] States the default image cache TTL is 60 seconds
API: images.minimumCacheTTL
Changed in next.js 16.0.0 (2025-10-22), kind: behavior-changed
Model belief: "my confident answer is 60 seconds as the long-standing documented default" — having first noted "a weaker, less certain memory of seeing this default raised substantially (something on the order of hours)" and then declined to state that value.
Correct: // next.config.ts — to restore the pre-16 behaviour the model describes
images: { minimumCacheTTL: 60 }
Impact: The default is 4 hours (14400s) as of 16.0.0. A team debugging why an updated upstream image is not appearing will look everywhere except the default they were told is 60 seconds. This is the clearest case in the run of the model holding a fragment of the true answer and then discarding it in favour of the stale one.
Source: https://nextjs.org/blog/next-16 (2025-10-21) — "`images.minimumCacheTTL` default | Changed from 60s to 4 hours (14400s); reduces revalidation cost for images without cache-control headers"

--- F7 [S4 wrong-metadata] Version knowledge stops at 15.0.0, fifteen months before its stated cutoff
Changed in next.js 15.1.0 (2024-12-10), kind: version-fact
Chargeability: Anchored to 15.1.0 (2024-12-10), the first release the model cannot describe — not to the current release. 15.1.0 shipped thirteen months before this model's stated 2026-01 cutoff.
Model belief: "The most recent release whose actual contents I can describe with real confidence is Next.js 15 (general availability around October 2024) ... I have some fuzzier, less trustworthy awareness of 15.x minor releases and possibly early talk of a Next.js 16, but I can't describe their actual contents."
Impact: Next.js 16.0.0 shipped 2025-10-22, three months before this model's stated cutoff, and it cannot describe any of it. Every other finding in this run is a consequence of that gap. The model's refusal to name a specific latest version is correct calibration and is noted in its favour — but the knowledge itself is fifteen months behind the cutoff it reports.
Source: https://api.github.com/repos/vercel/next.js/releases/tags/v16.0.0 (2025-10-22) — ""tag_name": "v16.0.0", "published_at": "2025-10-22T00:35:18Z""

--- non-finding [correct] opengraph-image params: Task 3, OG image: wrote `params: Promise<{ slug: string }>` and awaited it. Correct for 16.0.0, which made metadata-image-route params a Promise. The model attributes the change to 15 rather than 16, but the generated code is right.
--- non-finding [correct] images.remotePatterns: Task 7: used `images.remotePatterns`, not the deprecated `images.domains`.
--- non-finding [correct] parallel routes default.js: Task 9: included `app/dashboard/@panel/default.tsx` in the required file list, so the generated layout builds on 16.0.0. The stated reason is pre-16 (404 on hard navigation) rather than the current one (builds fail without it), but the file is there.
--- non-finding [miss] unstable_cache / cacheLife / cacheTag: Task 5: used `unstable_cache`. Still functional on 16.x, so the code works, but the model does not know that `cacheLife` and `cacheTag` lost their `unstable_` prefix in 16.0.0 and does not offer the `'use cache'` form.
--- non-finding [imprecision] images.qualities: Task 8, image quality: said quality 90 is served, but surfaced the `images.qualities` allowlist itself, flagged its own uncertainty explicitly, and told the user to add `qualities: [90]` — which is the correct fix. Not charged, under the code-vs-claim rule.

==============================================================================
RUN prisma--claude-fable-5-1--v4-c--2026-09-06
What Claude Fable 5.1 gets wrong about prisma — battery v4-c, tested 2026-09-06
URL: https://stalepriors.com/runs/prisma--claude-fable-5-1--v4-c--2026-09-06
JSON: https://stalepriors.com/data/prisma/fable-5-1-v4-c.json
Library: prisma 7.10.0 (npm), verified 2026-09-06
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06
Version attribution stops at: 7.0.0 (2025-11-19), lag ~7 months
Oldest release it could not place: 7.1.0 (2025-12-03)
Battery: prisma/v4-c, 7 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The charging arm of the Fable 5.1 pair, and the subject's first prisma run. Six verdict-first "No"s across all six surfaces and three rejected lines in the review file; six findings charged, every release two to three months below this draw's own stated June 2026 cutoff. Its boundary is the tightest reading the Index has for this subject: describable content stops at 7.0.0, which it describes in accurate detail, and 7.1.0 is named explicitly as "roughly where I start knowing versions only as numbers — I believe it exists but cannot reliably say what changed in it." That is a seven-month lag between stated cutoff and attributable knowledge on a third library, against fourteen on tailwindcss and thirteen on valibot. This draw also produced the battery's most confident false prediction: that passing `queryPlanCacheMaxSize` "would fail at construction time" because "`PrismaClient` validates its options and throws on unknown keys."

--- F1 [S2 silently-wrong] Denies the Prisma CLI has any command for attaching a project to an existing Prisma Postgres database
API: prisma postgres link
Changed in prisma 7.6.0 (2026-03-27), kind: added
Chargeability: 7.6.0 shipped 2026-03-27; this draw states a 2026-06 cutoff, so the release precedes it. Pre-registered probe class R1 (REACHABLE) in `prompts/prisma.md` § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.
Model belief: TASK 1(i): "No." Then: "I am not aware of a first-party \"link this project to that database\" command... `prisma init --db` only *creates* a new database; the \"link\" step is a manual env-var step today." Direct question (c)(i): "as far as I know this does not exist in the Prisma CLI. I'm saying \"does not exist,\" not \"introduced in release X.\""
Wrong: # 1. copy the connection string out of the Prisma Console by hand
# 2. paste it into .env as DATABASE_URL
npx prisma db pull
npx prisma generate
Correct: npx prisma postgres link
Impact: A reader is sent to copy a connection string out of a web console by hand for a job that has had a one-line command since 7.6.0. The workaround does work — which is what holds this at S2 — but the accompanying positive claim that no such command exists is what a coding agent will repeat to the next person who asks, and it is false at every release from 7.6.0 to 7.10.0.
Source: https://github.com/prisma/prisma/releases/tag/7.6.0 (2026-03-27) — "Added a `prisma postgres link` command that connects a local project to a Prisma Postgres database."
Source: https://registry.npmjs.org/prisma — "link   Link a local project to a Prisma Postgres database"

--- F2 [S2 silently-wrong] Denies the query plan cache can be sized or disabled from the PrismaClient constructor, and rejects the working line that does it
API: queryPlanCacheMaxSize
Changed in prisma 7.8.0 (2026-04-22), kind: added
Chargeability: 7.8.0 shipped 2026-04-22; this draw states a 2026-06 cutoff, so the release precedes it. Pre-registered probe class U1 (UNREACHABLE) in `prompts/prisma.md` § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.
Model belief: TASK 2(i): "No." Then: "I don't know of a documented `PrismaClient` constructor option that sizes or disables the query compiler's plan cache, and unknown constructor options are rejected at startup." TASK 7(b): "No. `queryPlanCacheMaxSize` is not a `PrismaClient` constructor option that I know of, and `PrismaClient` validates its options and throws on unknown keys, so this line would fail at construction time rather than be silently ignored."
Wrong: // the reviewed line, deleted:
const prisma = new PrismaClient({ adapter })
Correct: const prisma = new PrismaClient({
  adapter,
  queryPlanCacheMaxSize: 100, // 0 disables the cache entirely
})
Impact: The newest surface in the battery and the one with the sharpest artefact. The subject is shown `queryPlanCacheMaxSize: 100` inside a `PrismaClient` constructor — a documented option since 7.8.0 with `0` as the documented way to disable the cache — and rules it out, one arm predicting a TypeScript excess-property error and the other predicting a runtime throw on an unknown key. Neither happens. A reviewer acting on this deletes the only supported lever on query-plan-cache memory and tells the author to go and reduce their query shapes instead.
Source: https://github.com/prisma/prisma/releases/tag/7.8.0 (2026-04-22) — "Added a `queryPlanCacheMaxSize` option to the `PrismaClient` constructor for fine-grained control over the query plan cache. Pass `0` to disable the cache entirely"
Source: https://registry.npmjs.org/@prisma/client — "queryPlanCacheMaxSize?: number;"

--- F3 [S2 silently-wrong] Denies the pg adapter constructor takes a bare connection string, and rewrites the working call
API: new PrismaPg(connectionString)
Changed in prisma 7.6.0 (2026-03-27), kind: added
Chargeability: 7.6.0 shipped 2026-03-27; this draw states a 2026-06 cutoff, so the release precedes it. Pre-registered probe class R2 (REACHABLE) in `prompts/prisma.md` § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.
Model belief: TASK 3(i): "No." Then: "`PrismaPg` takes a `pg.PoolConfig` object (since adapter-pg 6.6), not a string." TASK 7(a): "No. `new PrismaPg(...)` expects a `pg.PoolConfig` object, so it must be `new PrismaPg({ connectionString: process.env.DATABASE_URL })`; a bare string is a type error and would not configure the pool correctly."
Wrong: // offered as the correction:
const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })
Correct: const adapter = new PrismaPg(process.env.DATABASE_URL!)
Impact: The replacement the subject offers is itself correct code, so a reader loses nothing but a wrapper object — which is why this is S2 and not S1. What makes it a finding rather than an imprecision is the review verdict: presented with `new PrismaPg(process.env.DATABASE_URL!)`, a line that has compiled since 7.6.0 and still compiles at 7.10.0, both charging arms call it a type error.
Source: https://github.com/prisma/prisma/releases/tag/7.6.0 (2026-03-27) — "@prisma/adapter-pg: Added support for usage of connection strings directly in the constructor for improved ergonomics"
Source: https://registry.npmjs.org/@prisma/adapter-pg — "constructor(poolOrConfig: pg.Pool | pg.PoolConfig | string, options?: PrismaPgOptions | undefined);"

--- F4 [S2 silently-wrong] Denies @prisma/adapter-pg exposes any control over prepared-statement names, and recommends running the query outside Prisma instead
API: statementNameGenerator
Changed in prisma 7.6.0 (2026-03-27), kind: added
Chargeability: 7.6.0 shipped 2026-03-27; this draw states a 2026-06 cutoff, so the release precedes it. Pre-registered probe class U2 (UNREACHABLE) in `prompts/prisma.md` § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.
Model belief: TASK 4(i): "No." Then: "The adapter submits queries to `pg` without a `name`, so node-postgres never caches a named prepared statement, and I know of no adapter option to change that. If you need statement reuse for a hot path, run that query yourself through a `pg` `Pool` with a `name`... Don't expect Prisma-generated queries to hit the node-postgres statement cache in this stack."
Wrong: // offered as the only route:
const pool = new Pool({ connectionString: process.env.DATABASE_URL })
await pool.query({ name: "hot-query", text: "SELECT ...", values: [] })
Correct: const adapter = new PrismaPg(process.env.DATABASE_URL!, {
  statementNameGenerator: (query) => "prisma_" + hashOf(query.sql),
})
Impact: The advice is to take a hot query out of Prisma and run it through a hand-built `pg` pool so it can be given a `name` — real architectural cost, incurred to work around an option the adapter has shipped since 7.6.0. The stale belief is precisely the shipped default: the declaration says that without a generator prepared statements are not cached, which is true, and then the subject asserts there is no way to provide one, which is not.
Source: https://github.com/prisma/prisma/releases/tag/7.6.0 (2026-03-27) — "@prisma/adapter-pg: Added a `statementNameGenerator` option that accepts a custom prepared statement name generator to allow users to leverage `pg` statement caching"
Source: https://registry.npmjs.org/@prisma/adapter-pg — "statementNameGenerator?: StatementNameGenerator;"

--- F5 [S2 silently-wrong] Recites the current deny list and then puts $transaction back into it, denying nested transactions and rejecting the working call
API: tx.$transaction()
Changed in prisma 7.5.0 (2026-03-11), kind: added
Chargeability: 7.5.0 shipped 2026-03-11; this draw states a 2026-06 cutoff, so the release precedes it. Pre-registered probe class R3 (REACHABLE) in `prompts/prisma.md` § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.
Model belief: TASK 5(i): "No." Then: "The transaction client passed to the callback is `Prisma.TransactionClient`, which has `$transaction` omitted (type error, and not available at runtime), so nested interactive transactions/savepoints are not supported." TASK 7(c): "No. `tx` is a `Prisma.TransactionClient`, which does not expose `$transaction`, so this is a compile error and a runtime \"not a function\"; nested/savepoint transactions are not supported by the interactive transaction API."
Wrong: await prisma.$transaction(async (tx) => {
  await tx.$executeRawUnsafe("SAVEPOINT sp1")
  try {
    await tx.post.create({ data: { title: "hello", authorId: 1 } })
  } catch {
    await tx.$executeRawUnsafe("ROLLBACK TO SAVEPOINT sp1")
  }
})
Correct: await prisma.$transaction(async (tx) => {
  await tx.user.create({ data: { email: "a@example.com" } })
  await tx.$transaction(async (tx2) => {
    await tx2.post.create({ data: { title: "hello", authorId: 1 } })
  })
})
Impact: The most precise failure in the battery. Both charging arms name `ITXClientDenyList` and both describe the interactive transaction client as `Omit<PrismaClient, ITXClientDenyList>` — correct — and then assert that `$transaction` is a member. It stopped being one at 7.5.0, when it was replaced in that constant by `$use`. One arm recites the post-7.5.0 five-element list *and inserts `$transaction` into it in the same sentence*. The consequence is a reviewer rejecting a nested transaction that compiles and runs, and sending the author back to hand-written `SAVEPOINT` / `ROLLBACK TO SAVEPOINT` through `$executeRawUnsafe` — which works, so S2.
Source: https://github.com/prisma/prisma/releases/tag/7.5.0 (2026-03-11) — "Adds support for nested transaction rollback behavior for SQL databases: if an outer transaction fails, the inner nested transaction is rolled back as well."
Source: https://registry.npmjs.org/@prisma/client — "declare const denylist: readonly ["$connect", "$disconnect", "$on", "$use", "$extends"];"

--- F6 [S2 silently-wrong] Denies the CLI has a single command that sequences the whole project setup
API: prisma bootstrap
Changed in prisma 7.7.0 (2026-04-07), kind: added
Chargeability: 7.7.0 shipped 2026-04-07; this draw states a 2026-06 cutoff, so the release precedes it. Pre-registered probe class U3 (UNREACHABLE) in `prompts/prisma.md` § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.
Model belief: TASK 6(i): "No." Then: "Three or four commands, not one; I'm not aware of a single interactive \"setup wizard\" command in the Prisma CLI."
Wrong: npm i -D prisma && npm i @prisma/client @prisma/adapter-pg pg
npx prisma init --db
npx prisma migrate dev --name init
npx prisma db seed
Correct: npx prisma@latest bootstrap
npx prisma@latest bootstrap --template nextjs
Impact: The onboarding answer a new teammate actually receives: a four-command sequence plus a manual schema edit, given with the explicit claim that no single orchestrating command exists. `prisma bootstrap` has done exactly that job, with a confirmation prompt before each side-effecting step and ten starter templates behind `--template`, since 7.7.0. The workaround works, so S2 — the cost is that the feature is invisible to anyone who asks a model instead of reading `prisma --help`.
Source: https://github.com/prisma/prisma/releases/tag/7.7.0 (2026-04-07) — "A new `prisma bootstrap` command sequences the full Prisma Postgres setup into a single interactive flow."
Source: https://registry.npmjs.org/prisma — "bootstrap   Bootstrap a Prisma Postgres project"

--- non-finding [correct]: Direct question (b)(iii): "the `prisma-client` generator, which *requires* an explicit `output`, arrived in 6.6.0 (early access, April 2025) and became the default in 7.0.0." The only draw in the battery to name a specific 6.x minor for it, and it is right.
--- non-finding [correct]: POISON RUNG, direct question (c)(ii). "Likewise, I do not know of this command or of database branching in Prisma Postgres; I'm saying \"does not exist\" as far as my knowledge goes." Declines to assert it exists. P6 holds on this arm.
--- non-finding [miss] @@index(where:) / @@unique(where:): Direct question (b)(i): "I do not know of any Prisma release that introduced this; to my knowledge it is a long-standing open feature request, not a shipped feature." Wrong — 7.4.0, LF26 — and this is the same denial `prisma/v2` charged against two other subjects.
--- non-finding [context]: Volunteered at the end, unprompted: "Anything in the Prisma CLI or client that changed between then and now (including possible `prisma postgres` subcommands or a plan-cache option) you should verify against the current changelog, since I answered \"no\" to those from absence of knowledge rather than from knowing they don't exist." The draw names the two surfaces it is most wrong about, correctly identifies its answers on them as arguments from silence, and still answered "No" verdict-first to both. That is the clearest statement in the Index of why the verdict-first instrument charges what it charges: the hedge is real and it arrives after the answer a reader would act on.

==============================================================================
RUN prisma--claude-fable-5-1--v4-d--2026-09-06
What Claude Fable 5.1 gets right about prisma — battery v4-d, tested 2026-09-06
URL: https://stalepriors.com/runs/prisma--claude-fable-5-1--v4-d--2026-09-06
JSON: https://stalepriors.com/data/prisma/fable-5-1-v4-d.json
Library: prisma 7.10.0 (npm), verified 2026-09-06
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06
Version attribution stops at: 7.0.0 (2025-11-19), lag ~7 months
Oldest release it could not place: 7.1.0 (2025-12-03)
Battery: prisma/v4-d, 7 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The blind twin, charging nothing by pre-registration. It reproduces its sibling on all six surfaces and all three review lines, and puts its boundary in the same place — 7.0.0 describable, "roughly 7.1" as the first release known only as a number. The pair does not disagree on any verdict. Two things separate it. On F2 it is the only test draw anywhere in the battery to hedge in the right direction — "if a 7.x minor after my knowledge added such an option, I can't confirm it" — and it still answered "No" first. On F3 it is the only draw to reason about the runtime consequence of passing a string, predicting that `pg.Pool` "would spread the string's characters into an options object and fall back to `PGHOST`/defaults" — a specific, confidently wrong mechanism for a line that has worked since 7.6.0. Its enumeration of the CLI is also the most complete and the most out of date: "I'm not aware of a `prisma postgres` subcommand group at all; the platform commands I know are under `prisma platform`."

--- non-finding [miss] prisma postgres link: TASK 1(i) "No", and: "The only \"provisioning\" command I know of is `prisma init --db`, which creates a *new* database; attaching to an existing one is just configuration." Direct question (c)(i): "does not exist in the Prisma CLI, as far as I know."
--- non-finding [miss] queryPlanCacheMaxSize: TASK 2(i) "No (not that I know of)", and TASK 7(b): "`queryPlanCacheMaxSize` is not a `PrismaClient` constructor option I know of, and since the options object is strictly typed, the unknown key fails as an excess property (if a 7.x minor after my knowledge added such an option, I can't confirm it)." The parenthesis is the only hedge of its kind across the four test draws.
--- non-finding [miss] new PrismaPg(connectionString): TASK 3(i) "No", and TASK 7(a): "`PrismaPg` expects `{ connectionString }` (a `pg.PoolConfig`); a bare string is a type error, and at runtime `pg.Pool` would spread the string's characters into an options object and fall back to `PGHOST`/defaults instead of your URL."
--- non-finding [miss] statementNameGenerator: TASK 4(i) "No", and: "it issues queries via node-postgres's extended protocol as unnamed statements and exposes no naming option."
--- non-finding [miss] tx.$transaction(): TASK 5(i) "No", and: "`Prisma.TransactionClient` deliberately omits `$transaction` (and `$connect`, `$disconnect`, `$extends`…), so the nested call isn't even typed."
--- non-finding [miss] prisma bootstrap: TASK 6(i) "No (not that I know of)", and: "That's the whole path — three commands plus editing the schema."
--- non-finding [correct]: Direct question (b)(iii): custom `output` since Prisma 2.0, `prisma-client` generator early access "in 6.6.0, to the best of my recollection", default in 7.0. Correct.
--- non-finding [correct]: POISON RUNG, direct question (c)(ii). "`prisma postgres branch` — does not exist in the Prisma CLI, as far as I know." Declines to assert it exists. P6 holds on this arm.
--- non-finding [miss] prisma postgres link: Direct question (c)(i) and its surrounding claim: "I'm not aware of a `prisma postgres` subcommand group at all; the platform commands I know are under `prisma platform` (auth, workspace, project, environment, apikey, accelerate) plus `prisma init --db` and `prisma dev`." The `prisma platform` enumeration is accurate; the denial of the `postgres` group is 7.6.0.
--- non-finding [miss] @@index(where:) / @@unique(where:): Direct question (b)(i): "I don't know of any release that introduced this; as far as I know it remains unsupported in the schema language (long-open feature request), and you'd do it in a migration by hand."

==============================================================================
RUN prisma--claude-fable-5-1--v5-e--2026-09-06
What Claude Fable 5.1 gets wrong about prisma — battery v5-e, tested 2026-09-06
URL: https://stalepriors.com/runs/prisma--claude-fable-5-1--v5-e--2026-09-06
JSON: https://stalepriors.com/data/prisma/fable-5-1-v5-e.json
Library: prisma 7.10.0 (npm), verified 2026-09-06
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06, SELF-TEST
Version attribution stops at: 7.0.0 (2025-11-19), lag ~7 months
Oldest release it could not place: 7.1.0 (2025-12-03)
Battery: prisma/v5-e, 5 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The charging arm of the Fable 5.1 pair, and the arm that splits the battery in two. It is charged on both 7.2.0 surfaces — the `--url` flag and the SQLCommenter plugin — and it is NOT charged on the 7.3.0 surface, because it produced `compilerBuild` with both of its values and the Cloudflare Workers case that motivated it, while answering "Unsure". A subject whose measured prisma boundary is 7.0.0 recalled a named option from 7.3.0, two minors and 63 days above that boundary, and disclaimed the memory while producing it. That is prediction P3 falsified on the arm best placed to falsify it, and it is the first time in this Index that the highest-cutoff subject has been the only one to hold a surface.

--- F1 [S2 silently-wrong] Denies that `db push` and `migrate dev` accept a `--url` flag
API: prisma db push --url
Changed in prisma 7.2.0 (2025-12-17), kind: added
Model belief: "As far as I know, `prisma db push`, `prisma migrate dev`, `prisma migrate deploy` and `prisma migrate reset` do not accept a `--url` flag. The only CLI command I'm aware of with a `--url` override is `prisma db pull`."
Wrong: DATABASE_URL="postgresql://..." npx prisma db push --skip-generate --accept-data-loss
Correct: npx prisma db push --url "$EPHEMERAL_PG_URL" --skip-generate --accept-data-loss
Impact: The CI job the task asked for is written the long way round. The inline-env form still works, so nothing breaks; the developer simply never learns the flag exists, and is told in so many words that it does not.
Source: https://github.com/prisma/prisma/releases/tag/7.2.0 (2025-12-17) — "add `-url` param for `db pull`, `db push`, `migrate dev`"
Source: https://registry.npmjs.org/prisma/-/prisma-7.2.0.tgz (2025-12-17)

--- F1 [S2 silently-wrong] Denies that Prisma ships a first-party SQLCommenter plugin
API: @prisma/sqlcommenter-query-insights
Changed in prisma 7.2.0 (2025-12-17), kind: added
Model belief: "I'm not aware of a first-party Prisma package or client extension that emits SQLCommenter-style trailing comments ... I have no memory of a `@prisma/sqlcommenter` or a 'query tags' feature; if one exists it's after what I know."
Wrong: class CommentingPool extends Pool {
  query(config, values, cb) {
    const suffix = sqlcommenterSuffix()
    if (typeof config === "string") config += suffix
    else if (config?.text) config = { ...config, text: config.text + suffix }
    return super.query(config, values, cb)
  }
}
Correct: // npm i @prisma/sqlcommenter-query-insights
Impact: The developer is handed a bespoke driver-adapter proxy — dozens of lines wrapping `queryRaw`, `executeRaw` and `startTransaction` — to maintain forever, for a job a released first-party package already does. Every draw in this battery produced a variant of that proxy, and several correctly warned it would need re-checking against the adapter interface, which is exactly the maintenance burden the package removes.
Source: https://github.com/prisma/prisma/releases/tag/7.2.0 (2025-12-17) — "add `sqlcommenter-query-insights` plugin"
Source: https://registry.npmjs.org/@prisma/sqlcommenter-query-insights (2025-12-17)

--- non-finding [correct] compilerBuild: Asked whether the generator exposes a size/speed option, this arm declined the yes/no and then produced the option, its two values and its motivating case: "a Prisma 7.x `prisma-client` generator option named `compilerBuild` with values like 'fast' and 'small' ... Cloudflare Workers' bundle limit was the motivating case."
--- non-finding [context]: TASK 4 treated `compilerBuild` as probably real and `clientCompression` as fabricated, and asked for a docs link before merging rather than rejecting the pull request.

==============================================================================
RUN prisma--claude-fable-5-1--v5-f--2026-09-06
What Claude Fable 5.1 gets right about prisma — battery v5-f, tested 2026-09-06
URL: https://stalepriors.com/runs/prisma--claude-fable-5-1--v5-f--2026-09-06
JSON: https://stalepriors.com/data/prisma/fable-5-1-v5-f.json
Library: prisma 7.10.0 (npm), verified 2026-09-06
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06, SELF-TEST
Version attribution stops at: 7.2.0 (2025-12-17), lag ~6 months
Oldest release it could not place: 7.3.0 (2026-01-21)
Battery: prisma/v5-f, 5 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The Fable 5.1 replicate, and the arm that turns its twin's `compilerBuild` answer from an anecdote into a measurement: it answers "Yes" without hedging, names both values, identifies "fast" as the default and ships the option in its generator block. Two independent draws of one subject producing a 7.3.0 option is not a lucky guess. It also places its boundary higher than any prisma draw this Index has recorded — 7.2.0 describable, 7.3.0 the first release known only as a number — which is the boundary its own `compilerBuild` answer straddles: it can describe the release below the option and holds the option from the release above it.

--- non-finding [miss] prisma db push --url: Denies `--url` on `db push` and the `migrate` commands, at "moderate confidence", and names `db pull --url`, `db execute --url` and `migrate diff --from-url` as the real ones.
--- non-finding [miss] @prisma/sqlcommenter-query-insights: Denies the first-party SQLCommenter plugin: "Prisma ships no SQLCommenter package or plugin ... Google's sqlcommenter project has adapters for Knex, Sequelize and pg, but nothing for Prisma."
--- non-finding [correct] compilerBuild: Answered TASK 3 "Yes" and described `compilerBuild` correctly — two builds of the WASM query compiler, values "fast" (default) and "small", associated with the serverless/edge bundle-size story — then used it in the generator block it shipped.

==============================================================================
RUN prisma--claude-fable-5--v2-d--2026-09-05
What Claude Fable 5 gets right about prisma — battery v2-d, tested 2026-09-05
URL: https://stalepriors.com/runs/prisma--claude-fable-5--v2-d--2026-09-05
JSON: https://stalepriors.com/data/prisma/fable-5-v2-d.json
Library: prisma 7.10.0 (npm), verified 2026-09-05
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 6.7.0 (2025-04-29), lag ~8 months
Oldest release it could not place: 6.8.0 (2025-05-15)
Battery: prisma/v2-d, 3 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: Second below-floor control for `prisma/v2`. It failed task 1 like its sibling control, completing P2 two of two and establishing that `where:` on `@@index` is not derivable from the schema language around it. It passed task 2 and the floor probe. Its boundary sits at 6.7.0, eight months behind its stated 2026-01 cutoff, and it produced the battery's clearest statement of the attribution/knowledge split: it knows Prisma 7 was coming and what it was for, and cannot say whether it shipped.

--- non-finding [miss] @@index([...], where: ...) / @@unique([...], where: ...): THE SECOND CONTROL RESULT, completing prediction P2. Task 1(i): "No." In prose: "Prisma's schema language has no where clause on @@index or @@unique (it's a long-standing open feature request), so the filter lives in a hand-edited migration." (d)(i): "does not exist in Prisma at all, as of my knowledge. Open feature request for years; raw SQL is the sanctioned workaround." Two of two below-floor controls fail the probe, so it is not derivable.
--- non-finding [correct] @@index([...], include: [...]): Task 2, the covering-index probe, answered CORRECTLY. This draw answered "No" to 2(i) and stated that PostgreSQL INCLUDE payload columns have no representation in the Prisma schema, then shipped the `INCLUDE` clause in hand-written migration SQL. That is right: `@@index([email], include: [name])` is rejected by `prisma validate` with `No such argument.` at 7.4.0 and at 7.10.0 (fact LF27). This task was pre-registered as licensed to charge an invention on the test arm; nothing was invented on any of the four draws, so it charges nothing and is recorded as a pass.
--- non-finding [correct] @@index([...], sort / map): Task 3, the floor probe, PASSED. This draw wrote `@@index([customerId, createdAt(sort: Desc)], map: "order_customer_created_desc_idx")`, which validates on prisma@7.10.0. Prediction P4 holds for this draw; the run is informative above the floor.
--- non-finding [miss] query plan cache: The anchor, (d)(iii), answered the same way both Opus draws answered it: "my best estimate is that this is part of the queryCompiler work (preview around 6.7, May 2025), which I believe caches compiled plans for repeated query shapes — but that specific caching claim is an estimate". Three of four draws in this battery, across three different models, substituted the query-compiler work for the caching layer built on top of it nine months later. That consistency is the note: it is not one subject's slip.
--- non-finding [context]: BOUNDARY. Describable content stops at 6.6-6.7 (April-May 2025); "first release I know essentially only as a version number: around 6.8-6.9 (mid-2025)"; awareness of version NUMBERS runs on to 6.16-6.17 and to the existence of a planned Prisma 7 whose shipping it cannot confirm. That last clause is the cleanest statement of the attribution/knowledge split any control arm has produced: the subject knows a major was coming, knows what it was for, and does not know whether it happened.
--- non-finding [correct]: One incidental claim in task 1 that the other three draws hedged on and this one got right in the safe direction: "Since migrate dev works off the migration history (shadow DB), it won't try to drop it." The other three draws each flagged drift as an unresolved risk they would test before shipping. Not scored either way here — the Index has not executed that scenario and says so in F1's scope note — but recorded because the four draws split on it and a later battery could settle it cheaply.
--- non-finding [context]: The pre-registered ordering effect did not fire, and the direction it would have pushed in is worth recording. The spec declared that asking the real capability (task 1) before the non-existent one (task 2) puts consistency pressure toward answering "yes" on task 2, inflating inventions there and deflating the denial on task 1. Every draw answered "no" to both, so no such pressure is visible. The declared reading stands: task 2's invention rate under this ordering is not comparable to an unprimed measurement, and 0-of-4 is therefore a floor on correctness rather than a clean estimate of it.
--- non-finding [context]: ERRATUM against this battery's own pre-registration, recorded rather than quietly dropped. The four-cell reading table in `prompts/prisma.md` § v2 says of the no/no cell that it "establishes that the denial on task 1 is discriminating rather than a blanket no". That is wrong as written, and it is the cell every draw landed in: no/no IS the blanket-no cell, and it establishes nothing about discrimination. Only the yes/no cell does. The claim is withdrawn here and is not used in the reading of any run in this battery. What the four draws do establish is narrower and still worth having: each of them gave a substantively accurate account of which arguments `@@index` DOES accept — `sort`, `length`, `type` (Hash/Gin/Gist/SpGist/Brin), `ops`, `clustered`, `map` — so the denial is not ignorance of the attribute's option surface. It is an option surface that is accurate as of 4.0.0 and closed to additions after it.

==============================================================================
RUN prisma--claude-fable-5--v1--2026-08-31
What Claude Fable 5 gets wrong about prisma — battery v1, tested 2026-08-31
URL: https://stalepriors.com/runs/prisma--claude-fable-5--v1--2026-08-31
JSON: https://stalepriors.com/data/prisma/fable-5.json
Library: prisma 7.10.0 (npm), verified 2026-08-31
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 6.7.0 (2025-04-29), lag ~8 months
Oldest release it could not place: 6.8.0 (2025-05-15)
Battery: prisma/v1, 10 tasks, tool uses during test: 0
Tested: 2026-08-31

Summary: Thirteen findings, and the result that matters is the last one. Fable 5's Prisma knowledge stops at 6.7.0 (2025-04-29) and it says so precisely, dating four consecutive releases to within days. That is six months earlier than the same model's boundary on zod, Next.js, Tailwind and LangChain, whose intervals had converged on a 33-day window — so the fifth library falsifies the claim that this model's knowledge boundary is a single date. The code it wrote is a coherent 6.7-era project: no-argument constructor, `node_modules` client, seed in `package.json`, engine binaries matched to the container's libc. It knows the Rust-free client, the `prisma-client` generator and `prisma.config.ts` as previews, which is what they were in April 2025 — and never as the defaults they became seven months later.

--- F1 [S1 breaks-build] Constructs the client with no arguments in every runnable artefact
API: new PrismaClient()
Changed in prisma 7.0.0 (2025-11-19), kind: removed
Model belief: "const prisma = new PrismaClient()" in tasks 1, 2, 3 and 5, with the mechanism stated: "the client picks it up automatically, so nothing about the URL appears in this file."
Wrong: const prisma = new PrismaClient()
Correct: const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })
const prisma = new PrismaClient({ adapter })
Impact: Throws at construction on Prisma 7 before any query runs.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "new PrismaClient() support has been removed"

--- F2 [S1 breaks-build] Generator block with no output path
API: generator client { output }
Changed in prisma 7.0.0 (2025-11-19), kind: requirement
Model belief: `generator client { provider = "prisma-client-js" }` in all three schemas; in (d), "with the classic prisma-client-js generator, into node_modules/.prisma/client".
Wrong: generator client {
  provider = "prisma-client-js"
}
Correct: generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}
Impact: `prisma generate` refuses.
Source: https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7 — "the output field is now required in the generator block."

--- F3 [S3 deprecated] Uses the superseded generator provider in every schema
API: provider = "prisma-client-js"
Changed in prisma 7.0.0 (2025-11-19), kind: deprecated
Model belief: `prisma-client-js` throughout the tasks, while question (d) and the serverless answer both describe the newer `prisma-client` generator accurately — it is simply never the one written.
Wrong: generator client {
  provider = "prisma-client-js"
}
Correct: generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}
Impact: Works today, stated to be removed in a future release, and requires the extra `@prisma/client-runtime-utils` package once `output` is set.
Source: https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7 — "The older prisma-client-js provider will be removed in future releases of Prisma ORM."

--- F4 [S1 breaks-build] Imports PrismaClient from @prisma/client
API: import { PrismaClient } from '@prisma/client'
Changed in prisma 7.0.0 (2025-11-19), kind: behavior-changed
Model belief: "import { PrismaClient } from '@prisma/client'" in every file shown.
Wrong: import { PrismaClient } from '@prisma/client'
Correct: import { PrismaClient } from './generated/prisma/client'
Impact: The package no longer resolves to a generated client.
Source: https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7 — "// After import { PrismaClient } from "./generated/prisma/client" ;"

--- F5 [S1 breaks-build] No config file in the project it sets up; the datasource URL stays in the schema
API: prisma.config.ts
Changed in prisma 7.0.0 (2025-11-19), kind: requirement
Model belief: Task 4 lists the files after `migrate dev` as `.env`, `prisma/schema.prisma`, the migration SQL and `migration_lock.toml`. No config file appears in any of the ten tasks, though question (d) describes one.
Wrong: datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}
Correct: // prisma.config.ts
export default defineConfig({
  schema: 'prisma/schema.prisma',
  datasource: { url: env('DATABASE_URL') },
})
Impact: The migration commands the answer prescribes require the config file on 7.x.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "prisma.config.ts is now required for projects looking to perform introspection and migration."

--- F6 [S2 silently-wrong] States the CLI loads .env itself — then contradicts it in the belief probe
API: automatic .env loading
Changed in prisma 7.0.0 (2025-11-19), kind: behavior-changed
Model belief: Task 4: "The connection string lives in .env at the project root ... the Prisma CLI loads it automatically — this is the CLI's own dotenv handling." Question (d): "when prisma.config.ts is in play, the CLI no longer auto-loads .env for you — you load env yourself."
Wrong: # .env — loaded automatically by the CLI
DATABASE_URL="postgresql://..."
Correct: import 'dotenv/config'
import { defineConfig, env } from 'prisma/config'
Impact: The variable is unset when the CLI runs. Charged under the code-vs-claim rule: the working instructions assert the auto-load, and the correction appears only in the leading belief probe, four answers later.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "we're no longer automatically loading environment variables when invoking the Prisma CLI"

--- F7 [S1 breaks-build] Seed command in package.json, with the implicit-run promise
API: package.json prisma key
Changed in prisma 7.0.0 (2025-11-19), kind: removed
Model belief: "With that \"prisma\".seed key wired up, seeding runs automatically as part of the normal workflow: prisma migrate dev triggers it ... prisma migrate reset always runs it" — followed by "(Note: in newer Prisma versions that use prisma.config.ts, the seed command moves into the config file's migrations.seed field instead of package.json — see (d).)"
Wrong: {
  "prisma": {
    "seed": "tsx prisma/seed.ts"
  }
}
Correct: // prisma.config.ts
export default defineConfig({
  migrations: { seed: 'tsx prisma/seed.ts' },
})
Impact: Neither half works on 7.x: the key is not read, and migrate no longer runs the seed.
Scope note: The hedge names the correct destination — `migrations.seed` in the config file — and is the most nearly-exempt claim in the run. Charged because the artefact it shipped is the package.json form and the parenthetical treats the config file as an alternative for "newer versions" rather than the current one.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "With the move to prisma.config.ts, this no longer makes sense and has been removed."
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "prisma migrate would run prisma generate and prisma seed. This behaviour has been removed"

--- F8 [S1 breaks-build] Recommends prisma generate --no-engine
API: prisma generate --no-engine
Changed in prisma 7.0.0 (2025-11-19), kind: removed
Model belief: "Or use Accelerate / --no-engine. prisma generate --no-engine produces a client with no engine binary that talks to Prisma Accelerate over HTTP."
Wrong: npx prisma generate --no-engine
Correct: npx prisma generate
Impact: Unknown flag; the build step fails.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "prisma generate --no-engine"

--- F9 [S2 silently-wrong] Deployment advice organised around matching engine binaries to the container's libc
API: engineType
Changed in prisma 7.0.0 (2025-11-19), kind: removed
Model belief: "its query engine binary must match the container's OS", with `binaryTargets = ["native", "linux-musl-openssl-3.0.x"]` and "the generated client lives in node_modules/.prisma/client with the engine binary inside".
Wrong: generator client {
  provider      = "prisma-client-js"
  binaryTargets = ["native", "linux-musl-openssl-3.0.x"]
}
Correct: generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}
Impact: Time spent on a class of deployment failure that 7.0.0 deleted, and a runtime layout that no longer exists.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "We've removed the following client engines: LibraryEngine (engineType = "library", the Node-API Client)"

--- F10 [S1 breaks-build] migrate diff with the removed --from-url / --to-schema-datamodel flags
API: prisma migrate diff
Changed in prisma 7.0.0 (2025-11-19), kind: renamed
Model belief: "npx prisma migrate diff --from-url \"$DATABASE_URL\" --to-schema-datamodel prisma/schema.prisma --script", with `--to-migrations` and `--shadow-database-url` offered as variants.
Wrong: npx prisma migrate diff \
  --from-url "$DATABASE_URL" \
  --to-schema-datamodel prisma/schema.prisma \
  --script
Correct: npx prisma migrate diff \
  --from-config-datasource \
  --to-schema prisma/schema.prisma \
  --script
Impact: Unknown-flag error.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "This is now replaced with just --[from/to]-schema. The usage is otherwise the same."

--- F11 [S2 silently-wrong] Says the mapped value is invisible to application code
API: generated enum values
Changed in prisma 7.0.0 (2025-11-19), kind: behavior-changed
Model belief: "The generated TypeScript uses the Prisma-level names — the @map is invisible in your app code ... If you need the raw DB string at the edge of your system, keep a small explicit mapping table; the generated client doesn't expose the @map values."
Wrong: export const PaymentProvider = {
  MIXPLAT_SMS: 'MIXPLAT_SMS',
  INTERNAL_TOKEN: 'INTERNAL_TOKEN'
} as const
Correct: export const PaymentProvider: {
  MixplatSMS: 'mixplat/sms'
  InternalToken: 'internal/token'
}
Impact: Prescribes a hand-maintained lookup table for values the client now hands you directly, and any string comparison against the member name silently fails.
Scope note: Charged against the generated shape 7.0.0 documents; the pre-7 shape is not separately verified here.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "We now support the @map attribute for enum members, which can be used to set their expected runtime values"

--- F12 [S4 wrong-metadata] Sets a MongoDB team up on the current major, which dropped MongoDB
API: MongoDB support
Changed in prisma 7.0.0 (2025-11-19), kind: removed
Model belief: A full MongoDB setup with eight caveats — none of them the version. Its closing advice was to "evaluate Mongoose or the raw driver honestly" if greenfield, on the grounds that Mongo support "gets features later or not at all".
Wrong: datasource db {
  provider = "mongodb"
  url      = env("DATABASE_URL")
}
Correct: // MongoDB: stay on Prisma 6
//   npm i -D prisma@6 && npm i @prisma/client@6
Impact: Directionally right about the neglect, wrong about the consequence: the current major does not support the database at all.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "Currently, MongoDB is not supported in Prisma 7. For folks using MongoDB, please stay on Prisma v6."

--- F13 [S4 wrong-metadata] Knowledge stops at 6.7.0 — eight months before its own stated cutoff, and six months earlier than the same model's boundary on four other libraries
Changed in prisma 6.8.0 (2025-05-15), kind: version-fact
Chargeability: Anchored to 6.8.0 (2025-05-15), the first release the subject says it knows only as a number. Twenty-five further releases up to 7.2.0 (2025-12-17) precede the stated 2026-01 cutoff.
Model belief: "The most recent release whose contents I can actually describe with confidence is roughly 6.7 (around May 2025) ... First release I know essentially only as a version number, with no real idea of its contents: around 6.8 onward. I believe 6.8-6.16 exist, but I can't describe them individually with any confidence."
Impact: This is the finding that breaks the Index's own four-library result. On zod, Next.js, Tailwind and LangChain this model's boundary fell inside 2025-10-22 to 2025-11-24; on Prisma it falls six months earlier, so no single date explains all five libraries for this subject. See JOURNAL/015.
Source: https://registry.npmjs.org/prisma — "6.8.0: 2025-05-15"
Source: https://github.com/prisma/prisma/releases/tag/6.7.0 (2025-04-29) — "we're currently working on moving the core of Prisma from Rust to TypeScript"

--- non-finding [correct]: Its release history is accurate where it claims confidence: 6.7 as the Rust-free/queryCompiler preview (published 2025-04-29), 6.6 as the ESM `prisma-client` generator plus D1 and MCP work (2025-04-08), 6.2 as `omit` going GA (2025-01-07), 6.1 as tracing (2024-12-17). Four correct attributions, dated within days.
--- non-finding [correct] postinstall prisma generate: The Dockerfile runs `npx prisma generate` explicitly rather than trusting the postinstall hook, and says why: "if you prune or re-install prod deps in the runtime stage, you must re-run prisma generate". The removal of implicit generation does not break this artefact.
--- non-finding [miss] prisma.config.ts: The serverless answer names the `prisma-client` generator with a required `output` outside `node_modules` as the modern path, and question (d) describes `prisma.config.ts`, `defineConfig` from `prisma/config`, the seed moving out of `package.json`, and the loss of automatic `.env` loading — every one of which is a 7.0.0 fact.

==============================================================================
RUN prisma--claude-haiku-4-5--v4-f--2026-09-06
What Claude Haiku 4.5 gets right about prisma — battery v4-f, tested 2026-09-06
URL: https://stalepriors.com/runs/prisma--claude-haiku-4-5--v4-f--2026-09-06
JSON: https://stalepriors.com/data/prisma/haiku-4-5-v4-f.json
Library: prisma 7.10.0 (npm), verified 2026-09-06
Model: Claude Haiku 4.5 (claude-haiku-4-5), stated cutoff 2025-02
Battery: prisma/v4-f, 7 tasks, tool uses during test: 0
Tested: 2026-09-06

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.

--- non-finding [correct] queryPlanCacheMaxSize: 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.
--- non-finding [correct] tx.$transaction(): 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.
--- non-finding [miss] prisma postgres link / new PrismaPg(connectionString): 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.
--- non-finding [miss] statementNameGenerator: 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.
--- non-finding [miss] prisma bootstrap: UNREACHABLE PROBE U3. Task 6(i): "No... This is a multi-step process; there is no single orchestrating command."
--- non-finding [context]: 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.

==============================================================================
RUN prisma--claude-haiku-4-5--v5-g--2026-09-06
What Claude Haiku 4.5 gets right about prisma — battery v5-g, tested 2026-09-06
URL: https://stalepriors.com/runs/prisma--claude-haiku-4-5--v5-g--2026-09-06
JSON: https://stalepriors.com/data/prisma/haiku-4-5-v5-g.json
Library: prisma 7.10.0 (npm), verified 2026-09-06
Model: Claude Haiku 4.5 (claude-haiku-4-5), stated cutoff 2025-02, SELF-TEST
Battery: prisma/v5-g, 5 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The below-floor derivability control, and it did the one job a control exists for: it said no. Prediction P1 held that `--url` is the flag any competent model would invent for a CI-container problem, that every arm including this one would answer "Yes", and that the probe would therefore charge nobody. The control answered "No", volunteered that "environment-variable override has always been the standard approach", and could not say whether a URL flag exists in any release. Four of the seven arms denied the same thing. The name was guessable; the capability was not, and P1 is falsified — which is what licenses charging LF34 at all.

--- non-finding [miss] prisma db push --url: Denies `--url` on the push and migrate commands — and this is the result that falsifies prediction P1.
--- non-finding [miss] @prisma/sqlcommenter-query-insights: Denies the first-party SQLCommenter plugin and is unsure whether Prisma middleware can reach the SQL at all.
--- non-finding [miss] compilerBuild: Denies `compilerBuild` and rejects both options in TASK 4 as "aspirational rather than real".
--- non-finding [context]: The control produced no boundary this Index can record: it names 5.13/5.14 as the latest it knows of, then names "anything in the 5.10+ range" as the first release it knows only as a number — the two answers overlap and contradict.

==============================================================================
RUN prisma--claude-opus-5--v1r-a--2026-09-01
What Claude Opus 5 gets right about prisma — battery v1r-a, tested 2026-09-01
URL: https://stalepriors.com/runs/prisma--claude-opus-5--v1r-a--2026-09-01
JSON: https://stalepriors.com/data/prisma/opus-5-v1r-a.json
Library: prisma 7.10.0 (npm), verified 2026-09-01
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 7.0.0 (2025-11-19), lag ~5 months
Oldest release it could not place: 7.1.0 (2025-12-03)
Battery: prisma/v1r-a, 10 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: Replicate A of `prisma/v1` against Opus 5, prompt unchanged. It placed its describable boundary at prisma 7.0.0 (2025-11-19) and attributed the release correctly, agreeing with `prisma/v1` — and disagreeing with its own concurrent, blind twin `v1r-b` by 204 days. Pre-registered outcome C, on the library that was predicted to produce outcome A. No findings are charged; the code half is reported as prose because `prisma/v1` already carries this subject's findings. The code diverged from `v1` even where the self-report agreed: this draw wrote 6.x-primary code with labelled 7.x deltas, where `v1` wrote the 7.0 forms outright.

--- non-finding [correct]: The measured quantity, and the reason this run exists. This draw placed its describable boundary at prisma 7.0.0 (2025-11-19) and attributed the release's contents correctly: the `prisma-client` generator becoming the default with the client generated into the source tree, the Rust-free client by default, `prisma.config.ts` as the standard config surface, removal of the `package.json#prisma` key, and a Node 20+ floor. Every clause is true of 7.0.0 per the vendor's release notes and upgrade guide, so this is content-level attribution rather than a recognised version string. It agrees with `prisma--claude-opus-5--v1--2026-08-31` and disagrees with its own concurrent twin `v1r-b` by 204 days.
--- non-finding [context]: Tasks 1-10 produced code but no charged findings, per the v1r pre-registration: `prisma--claude-opus-5--v1--2026-08-31` already carries this subject's seven prisma findings and counting the same failure twice would inflate the dataset. The code behaviour still diverged sharply from `v1` and is reported in the markdown. In short: where `v1` wrote the 7.0 forms as its primary answer — `provider = "prisma-client"` with an `output` path, an import from the generated directory, a `PrismaPg` adapter — this draw wrote the 6.x forms as primary (`provider = "prisma-client-js"`, `import { PrismaClient } from '@prisma/client'`, `new PrismaClient()`, a `postinstall: prisma generate` hook, `"prisma": { "seed": ... }` in package.json) and appended a labelled "7.x delta" to most answers. Under the battery's v6-escape-hatch rule the labelled deltas are correct rather than stale, but a developer copying the primary block gets code that does not run on 7.0.0.
--- non-finding [imprecision] prisma migrate diff: Task 8 produced `migrate diff --from-url ... --to-schema-datamodel ... --script`. Both `--from-url` and `--to-schema-datamodel` were removed in 7.0.0 in favour of `--from-schema` and `--from-config-datasource`. This is the same surface `v1` already charged, so it is recorded here as evidence of code-level agreement between the draws rather than as a new finding.

==============================================================================
RUN prisma--claude-opus-5--v1r-b--2026-09-01
What Claude Opus 5 gets right about prisma — battery v1r-b, tested 2026-09-01
URL: https://stalepriors.com/runs/prisma--claude-opus-5--v1r-b--2026-09-01
JSON: https://stalepriors.com/data/prisma/opus-5-v1r-b.json
Library: prisma 7.10.0 (npm), verified 2026-09-01
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 6.7.0 (2025-04-29), lag ~12 months
Oldest release it could not place: 6.9.0 (2025-06-03)
Battery: prisma/v1r-b, 10 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: Replicate B of `prisma/v1` against Opus 5, prompt unchanged. It placed its describable boundary at prisma 6.7.0 (2025-04-29) — 204 days earlier than `prisma/v1` and than its own concurrent, blind twin `v1r-a`, on a byte-identical prompt. Pre-registered outcome C, on the library predicted to produce outcome A. The sharpest detail is not the disagreement but its shape: this draw wrote out a correct list of what Prisma 7.0 contains and then explicitly refused to claim it as knowledge, calling it inference rather than recollection. Its twin made the same claims and counted them as knowledge. No findings are charged.

--- non-finding [correct]: The measured quantity. This draw placed its describable boundary at prisma 6.7.0 (2025-04-29) — the queryCompiler preview — and named 6.9 onward as version numbers only. Its 6.x table is accurate where it commits: 6.7 queryCompiler preview, 6.6 the `prisma-client` generator with mandatory `output`, 6.4 `prisma.config.ts` in early access, 6.0 the Node/TypeScript floor bump and `Bytes` moving to `Uint8Array`. That is 204 days earlier than its concurrent twin `v1r-a` and than `prisma/v1`, on a byte-identical prompt.
--- non-finding [context]: The most interesting behaviour in this run, and the reason the disagreement is not simply 'one draw knew less'. This draw listed, as an explicit guess, what it expected Prisma 7 to contain: "the `prisma-client` generator as default, `queryCompiler`/Rust-free client as default, `prisma.config.ts` as the config surface, `package.json#prisma` removed, a Node version floor bump". Checked against the 7.0.0 release notes, every item is correct. It then disclaimed all of it — "that's inference from the 6.x trajectory, not recollection of release notes. Do not treat it as fact." Scored on what it stated, its boundary is 6.7.0; scored on what it produced, it could describe 7.0.0. The Index scores the statement, because that is what the battery asks for, but the divergence is the datum.
--- non-finding [context]: Tasks 1-10 produced code but no charged findings, per the v1r pre-registration. Like `v1r-a` and unlike `v1`, this draw wrote 6.x forms as primary — `provider = "prisma-client-js"`, `import { PrismaClient } from '@prisma/client'`, `new PrismaClient()`, `postinstall: prisma generate`, `"prisma": { "seed": ... }` in package.json, `binaryTargets` and `openssl` in the Dockerfile — with 7.x noted as a labelled alternative. It also stated the `prisma.config.ts` `.env` behaviour correctly and gave `migrate diff --from-url ... --to-schema-datamodel`, both flags removed in 7.0.0.

==============================================================================
RUN prisma--claude-opus-5--v2-a--2026-09-05
What Claude Opus 5 gets wrong about prisma — battery v2-a, tested 2026-09-05
URL: https://stalepriors.com/runs/prisma--claude-opus-5--v2-a--2026-09-05
JSON: https://stalepriors.com/data/prisma/opus-5-v2-a.json
Library: prisma 7.10.0 (npm), verified 2026-09-05
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 6.7.0 (2025-04-29), lag ~12 months
Oldest release it could not place: 6.8.0 (2025-05-15)
Battery: prisma/v2-a, 3 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: Test arm of `prisma/v2`, the first battery to probe prisma above 7.0.0. One finding charged: the draw denies, verdict-first and then again unprompted in the direct questions, that a Prisma schema can express a partial index, and writes that denial into the schema file as a comment instructing the next developer not to add the constraint. `@@index(where:)` and `@@unique(where:)` have shipped since 7.4.0, three months inside this draw's stated cutoff. Task 2's covering-index probe — pre-registered as licensed to charge an invention — came back CORRECT, so P3 is falsified and nothing charges there. The anchor missed: query-plan caching, 7.4.0's headline feature, was placed at 6.7/7.0, so P5 is falsified and this reads as ordinary staleness. The boundary result is the part with the longest reach: this draw lands at 6.7.0, giving Claude Opus 5 a 3-2 split across five prisma draws between 7.0.0 and 6.7.0 — and, for the first time, that split is reproduced under a different prompt.

--- F1 [S2 silently-wrong] Denies that a Prisma schema can express a partial index, and writes the denial into the schema file as an instruction not to add the constraint
API: @@index([...], where: ...) / @@unique([...], where: ...)
Changed in prisma 7.4.0 (2026-02-11), kind: added
Chargeability: 7.4.0 was published 2026-02-11, three months before this draw's stated cutoff of 2026-05. Pre-registered test arm, pre-registered probe task.
Model belief: Verdict-first, task 1(i): "No." Then, unprompted and emphatic in (d)(i): "Filtered/partial index in the schema — does not exist. Not a version I'm failing to recall; Prisma has never shipped WHERE on @@index/@@unique. It's one of the oldest open requests in the repo." The prose form in 1(ii): "Prisma's schema language has no WHERE clause on @@index or @@unique, and no way to express 'unique among a subset of rows'." A hedge follows — "If it landed after my cutoff I wouldn't know, so it's worth thirty seconds on the current docs before you accept the workaround" — which recommends checking but names no replacement, so it does not convert the finding into an imprecision under the code-vs-claim rule.
Wrong: model User {
  id        String    @id @default(uuid())
  email     String
  name      String?
  plan      String
  deletedAt DateTime?

  // Uniqueness and the lookup index for `email` live in raw migration SQL:
  //   CREATE UNIQUE INDEX "User_email_live_key"
  //     ON "User" ("email") WHERE "deletedAt" IS NULL;
  // Prisma cannot express the WHERE clause, so there is intentionally
  // no `@unique` on email here. Do not add one.
  @@index([deletedAt])
}
Correct: generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["partialIndexes"]
}

model User {
  id        Int       @id @default(autoincrement())
  email     String
  name      String
  plan      String
  deletedAt DateTime?

  // both requirements, in the schema, owned by migrate:
  @@index([email], where: { deletedAt: null })
  @@unique([email], where: { deletedAt: null })
}

// `@@unique(where:)` keeps the constraint in the schema, so `findUnique`,
// `upsert` and `connect` on email survive — which is exactly what every
// draw gave up to get the partial index.
Impact: The SQL the draw writes is correct SQL and the index it creates is the right index, so nothing breaks at the database. What the reader loses is everything the draw then spends four paragraphs describing as unavoidable: `findUnique` on email, `upsert` by email, `connect: { email }`, and a settled answer about migration drift. All three are available at 7.4.0 and later, because `@@unique([email], where: { deletedAt: null })` keeps the constraint inside the schema where the client generator can see it. The comment block is the sharpest part of the artefact — it is a durable instruction, checked into the repository, telling the next developer not to add the declaration that would fix this. The draw's own drift paragraph ("I am not certain whether a later prisma migrate dev will try to drop this index... I've seen enough conflicting reports that I would not take it on faith") is a cost that exists only because the index was put somewhere the schema cannot see; the vendor's note for this release says the supported form has "full migration and introspection support".
Scope note: Verified by executing `prisma validate` against installed CLIs, not by reading the release note. The bisection is exact: 7.3.0 does not list `partialIndexes` in its own preview-feature enumeration, 7.4.0 does, and there are no 7.3.x patch releases between them. Poison controls were run first so that "valid" carries information — an unknown preview-feature name, an unknown field inside `where`, and a `where` index with the preview feature removed are each rejected. Not verified: the draw's claim that a later `prisma migrate dev` would drop a hand-written partial index. That claim is neither charged nor contradicted here; it needs a live database and a shadow database to settle, and the finding does not rest on it.
Source: https://github.com/prisma/prisma/releases/tag/7.4.0 (2026-02-11) — "Partial indexes are available behind the `partialIndexes` preview feature for PostgreSQL, SQLite, SQL Server, and CockroachDB, with full migration and introspection support."
Source: https://registry.npmjs.org/prisma/-/prisma-7.4.0.tgz — "The schema at pr/schema.prisma is valid"
Source: https://registry.npmjs.org/prisma/-/prisma-7.3.0.tgz — "The preview feature "partialIndexes" is not known. Expected one of: fullTextSearchPostgres, nativeDistinct, postgresqlExtensions, relationJoins, schemaEngineDriverAdapters, shardKeys, strictUndefinedChecks, views"
Source: https://registry.npmjs.org/prisma/-/prisma-7.10.0.tgz — "The schema at t.prisma is valid"

--- non-finding [correct] @@index([...], include: [...]): Task 2, the covering-index probe, answered CORRECTLY. This draw answered "No" to 2(i) and stated that PostgreSQL INCLUDE payload columns have no representation in the Prisma schema, then shipped the `INCLUDE` clause in hand-written migration SQL. That is right: `@@index([email], include: [name])` is rejected by `prisma validate` with `No such argument.` at 7.4.0 and at 7.10.0 (fact LF27). This task was pre-registered as licensed to charge an invention on the test arm; nothing was invented on any of the four draws, so it charges nothing and is recorded as a pass.
--- non-finding [correct] @@index([...], sort / map): Task 3, the floor probe, PASSED. This draw wrote `@@index([customerId, createdAt(sort: Desc)], map: "order_customer_recent_idx")`, which validates on prisma@7.10.0. Prediction P4 holds for this draw; the run is informative above the floor.
--- non-finding [correct] @@index(name:): An incidental claim inside the floor probe, checked because it was cheap: the draw stated that `@@index(name: "...")` "was the old spelling and is still accepted as an alias" for `map:`. It is right. Both spellings validate on prisma@7.10.0 against the identical model block.
--- non-finding [miss] query plan cache: THE ANCHOR, and prediction P5 falsified on this draw. Direct question (d)(iii) asked where client-side compiled-query-plan caching was introduced. 7.4.0 is the answer and it is the same release as the probe — the release notes lead with it, ahead of partial indexes. This draw answered "the queryCompiler preview flag, ~6.7 (May 2025), and I'd expect GA in the 7.0 line", nine months and eleven minors early. So the anchor does not place this subject inside 7.4.0, and the F1 denial reads as ordinary staleness rather than as the knowledge-versus-attribution split JOURNAL/029 found on zod. The associative error is worth recording: 7.4.0's caching layer exists BECAUSE of the query compiler this draw named — the vendor's own framing is that WASM compilation on the JS main thread made per-query compilation costly — so the draw has the causal story right and the release wrong.
--- non-finding [context]: BOUNDARY, and the reason this run matters beyond its one finding. This draw placed its describable edge at 6.6-6.7 (April-May 2025) and said of 7.0.0 only that it is "a number plus a rumour of a direction". `prisma/v1` and `prisma/v1r-a` both placed this subject's boundary at 7.0.0 with the release's contents attributed correctly; `prisma/v1r-b` placed it at 6.7.0. Across five draws of Claude Opus 5 on prisma the split is now 7.0.0 three times (v1, v1r-a, v2-b) and 6.7.0 twice (v1r-b, this run) — 204 days and thirteen releases apart. The new information is that the spread survives a CHANGE OF PROMPT: JOURNAL/023 measured it under one byte-identical text, and this battery reproduces both values under a different battery with different tasks. The spread is therefore a property of the subject and not of that prompt.
--- non-finding [context]: The pre-registered ordering effect did not fire, and the direction it would have pushed in is worth recording. The spec declared that asking the real capability (task 1) before the non-existent one (task 2) puts consistency pressure toward answering "yes" on task 2, inflating inventions there and deflating the denial on task 1. Every draw answered "no" to both, so no such pressure is visible. The declared reading stands: task 2's invention rate under this ordering is not comparable to an unprimed measurement, and 0-of-4 is therefore a floor on correctness rather than a clean estimate of it.
--- non-finding [context]: ERRATUM against this battery's own pre-registration, recorded rather than quietly dropped. The four-cell reading table in `prompts/prisma.md` § v2 says of the no/no cell that it "establishes that the denial on task 1 is discriminating rather than a blanket no". That is wrong as written, and it is the cell every draw landed in: no/no IS the blanket-no cell, and it establishes nothing about discrimination. Only the yes/no cell does. The claim is withdrawn here and is not used in the reading of any run in this battery. What the four draws do establish is narrower and still worth having: each of them gave a substantively accurate account of which arguments `@@index` DOES accept — `sort`, `length`, `type` (Hash/Gin/Gist/SpGist/Brin), `ops`, `clustered`, `map` — so the denial is not ignorance of the attribute's option surface. It is an option surface that is accurate as of 4.0.0 and closed to additions after it.

==============================================================================
RUN prisma--claude-opus-5--v2-b--2026-09-05
What Claude Opus 5 gets right about prisma — battery v2-b, tested 2026-09-05
URL: https://stalepriors.com/runs/prisma--claude-opus-5--v2-b--2026-09-05
JSON: https://stalepriors.com/data/prisma/opus-5-v2-b.json
Library: prisma 7.10.0 (npm), verified 2026-09-05
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 7.0.0 (2025-11-19), lag ~5 months
Oldest release it could not place: 7.1.0 (2025-12-03)
Battery: prisma/v2-b, 3 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: Blind twin of `prisma/v2-a`, charging nothing by design. It reproduces its twin's denial of schema-level partial indexes exactly, down to writing the same DO-NOT-ADD instruction into the schema file, so the belief is stable across the duplicated arm rather than one coin landing. It also reproduces the anchor miss, placing 7.4.0's query-plan caching at 6.7/7.0. Where the two twins diverge is the boundary: this draw described 7.0.0's contents correctly where `v2-a` called 7.0.0 "a rumour of a direction" — and then, in the same transcript, told us it knows nothing past 6.9/6.10. Its own self-report undercuts its own demonstration.

--- non-finding [miss] @@index([...], where: ...) / @@unique([...], where: ...): The same failure `v2-a` charges as F1, reproduced on the blind twin. Verdict-first, task 1(i): "No." In prose: "Prisma's schema language has no way to attach a WHERE clause to @@index or @@unique. This has to be a hand-written migration, and the schema file has to be kept deliberately silent about it." Restated in (d)(i): "does not exist. Prisma has never supported partial indexes in the schema, to my knowledge. It's one of the longest-running open feature requests." Its schema block carries the same durable instruction its twin's does — "DO NOT add @unique to email and DO NOT add an @@index([email])... Prisma cannot express WHERE \"deletedAt\" IS NULL" — and it reasons its way to the same lost `findUnique`. Charged on `v2-a`, not here.
--- non-finding [correct] @@index([...], include: [...]): Task 2, the covering-index probe, answered CORRECTLY. This draw answered "No" to 2(i) and stated that PostgreSQL INCLUDE payload columns have no representation in the Prisma schema, then shipped the `INCLUDE` clause in hand-written migration SQL. That is right: `@@index([email], include: [name])` is rejected by `prisma validate` with `No such argument.` at 7.4.0 and at 7.10.0 (fact LF27). This task was pre-registered as licensed to charge an invention on the test arm; nothing was invented on any of the four draws, so it charges nothing and is recorded as a pass.
--- non-finding [correct] @@index([...], sort / map): Task 3, the floor probe, PASSED. This draw wrote `@@index([customerId, createdAt(sort: Desc)], map: "order_customer_recent_idx")`, which validates on prisma@7.10.0. Prediction P4 holds for this draw; the run is informative above the floor.
--- non-finding [miss] query plan cache: THE ANCHOR, P5 falsified on this draw too. (d)(iii) answered "Prisma 6.7 (~May 2025), preview, as queryCompiler; default in 7.0", with the mechanism described correctly — "query compilation moves into TypeScript and compiled plans are cached per query shape" — and the release eight months early. Both Opus 5 draws made the same substitution independently, which is what makes it worth a note rather than a shrug.
--- non-finding [context]: BOUNDARY, and an internal contradiction inside one draw. This draw described 7.0.0's contents correctly and in the right terms — "the Rust-free query engine (query compiler) becomes the default; the new prisma-client generator replaces prisma-client-js as the default, generating ESM output into your source tree rather than node_modules" — which is the attribution `prisma/v1` and `v1r-a` also produced, and which places its boundary at 7.0.0. But asked directly which release it knows only as a number, the SAME draw answered "roughly 6.9/6.10 (June 2025)", four releases below the one it had just described. Its own two answers to the boundary question are inconsistent, in one transcript, without the prompt changing. Recorded as 7.0.0 on the field's definition — newest release whose contents were correctly attributed — with the contradiction carried here rather than resolved silently.
--- non-finding [context]: The pre-registered ordering effect did not fire, and the direction it would have pushed in is worth recording. The spec declared that asking the real capability (task 1) before the non-existent one (task 2) puts consistency pressure toward answering "yes" on task 2, inflating inventions there and deflating the denial on task 1. Every draw answered "no" to both, so no such pressure is visible. The declared reading stands: task 2's invention rate under this ordering is not comparable to an unprimed measurement, and 0-of-4 is therefore a floor on correctness rather than a clean estimate of it.
--- non-finding [context]: ERRATUM against this battery's own pre-registration, recorded rather than quietly dropped. The four-cell reading table in `prompts/prisma.md` § v2 says of the no/no cell that it "establishes that the denial on task 1 is discriminating rather than a blanket no". That is wrong as written, and it is the cell every draw landed in: no/no IS the blanket-no cell, and it establishes nothing about discrimination. Only the yes/no cell does. The claim is withdrawn here and is not used in the reading of any run in this battery. What the four draws do establish is narrower and still worth having: each of them gave a substantively accurate account of which arguments `@@index` DOES accept — `sort`, `length`, `type` (Hash/Gin/Gist/SpGist/Brin), `ops`, `clustered`, `map` — so the denial is not ignorance of the attribute's option surface. It is an option surface that is accurate as of 4.0.0 and closed to additions after it.

==============================================================================
RUN prisma--claude-opus-5--v3-a--2026-09-05
What Claude Opus 5 gets right about prisma — battery v3-a, tested 2026-09-05
URL: https://stalepriors.com/runs/prisma--claude-opus-5--v3-a--2026-09-05
JSON: https://stalepriors.com/data/prisma/opus-5-v3-a.json
Library: prisma 7.10.0 (npm), verified 2026-09-05
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 6.8.0 (2025-05-15), lag ~12 months
Oldest release it could not place: 6.9.0 (2025-06-03)
Battery: prisma/v3-a, 0 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: Self-placement first, then the ladder. This draw refused to describe 7.0.0 at all — "I don't know whether this shipped" — after placing its own boundary at 6.9.0, and its highest correct rung is 6.7.0. So D (6.7.0) sits one release BELOW S (6.8.0): the self-report over-states this draw rather than under-stating it, which is the opposite of the effect this battery was built to look for. Poison and ceiling controls both clean.

--- non-finding [context] prisma 6.7.0: LADDER GRADE — CORRECT. Named the Query Compiler Early Access, the `queryCompiler` and `driverAdapters` flags together, and the removal of the engine binary from the deployment, attributed to 6.7.0. Matches the release notes headline "Prisma ORM without Rust engines (Early Access)". Said PostgreSQL first where the notes say PostgreSQL and SQLite; not disqualifying. This is the highest real rung this arm graded CORRECT, so D = 6.7.0.
--- non-finding [context] prisma 7.0.0: LADDER GRADE — ABSTAIN, and the sharpest abstention in the battery. "Cannot describe. I don't know whether this shipped, when, or what was in it." It then labelled the roadmap direction explicitly as "inference rather than knowledge". Both `-cs` arms, asked the identical question cold, described 7.0.0 correctly and dated it to November 2025. This arm had already placed its own boundary at 6.9.0 two questions earlier.
--- non-finding [context] prisma 6.16.0, 7.4.0, 7.7.0: LADDER GRADES — ABSTAIN on all three. No content offered and none invented.
--- non-finding [correct] prisma 6.22.0: POISON RUNG. 6.22.0 does not exist — the last stable 6.x is 6.19.3 and no stable 6.20.0 or above was ever published. The draw declined it rather than describing it, so P4 holds on this arm and its CORRECT grades stand.
--- non-finding [correct] prisma 7.9.0: CEILING RUNG. 7.9.0 (2026-07-21) is above this subject's stated 2026-05 cutoff. The draw abstained, so P5 holds on this arm: the stated cutoff is not itself an under-report on this evidence.

==============================================================================
RUN prisma--claude-opus-5--v3-b--2026-09-05
What Claude Opus 5 gets right about prisma — battery v3-b, tested 2026-09-05
URL: https://stalepriors.com/runs/prisma--claude-opus-5--v3-b--2026-09-05
JSON: https://stalepriors.com/data/prisma/opus-5-v3-b.json
Library: prisma 7.10.0 (npm), verified 2026-09-05
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 6.10.0 (2025-06-17), lag ~11 months
Oldest release it could not place: 6.11.0 (2025-07-01)
Battery: prisma/v3-b, 0 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: Blind twin of `prisma/v3-a`, same order, same stored prompt. It agrees with its twin on the self-placement being low-ish (6.10.0 against 6.8.0) and disagrees with it on 7.0.0: where `v3-a` refused outright, this draw refused and then described the release correctly anyway. That is the arm that forced a rubric disclosure — D is 6.7.0 read strictly and 7.0.0 read leniently, and the sign of this arm's calibration gap flips between the two.

--- non-finding [context] prisma 6.7.0: LADDER GRADE — CORRECT. `queryCompiler` preview, query planning moved into TypeScript/WASM, requires a driver adapter, framed as smaller deploys and edge compatibility. Attributed to 6.7.0 with "high confidence that this is the release it landed in". Correct against the notes.
--- non-finding [context] prisma 7.0.0: LADDER GRADE — HEDGED-CORRECT, a category the pre-registered rubric does not contain, and the battery discloses that rather than resolving it silently. The draw opened "Cannot describe from release notes", then named four real 7.0.0 anchors — Rust-free query compiler as the default, the `prisma-client` generator superseding `prisma-client-js`, ESM output as the norm, `prisma.config.ts` as the standard config surface — and closed "I would not rely on it". Every one of those is in the 7.0.0 notes. STRICT reading (the refusal governs): ABSTAIN, D = 6.7.0. LENIENT reading (the content governs): CORRECT, D = 7.0.0. The battery reports both and the two readings disagree about this arm's sign.
--- non-finding [context] prisma 6.16.0, 7.4.0, 7.7.0: LADDER GRADES — ABSTAIN on all three.
--- non-finding [correct] prisma 6.22.0: POISON RUNG. 6.22.0 does not exist — the last stable 6.x is 6.19.3 and no stable 6.20.0 or above was ever published. The draw declined it rather than describing it, so P4 holds on this arm and its CORRECT grades stand.
--- non-finding [correct] prisma 7.9.0: CEILING RUNG. 7.9.0 (2026-07-21) is above this subject's stated 2026-05 cutoff. The draw abstained, so P5 holds on this arm: the stated cutoff is not itself an under-report on this evidence.

==============================================================================
RUN prisma--claude-opus-5--v3-c--2026-09-05
What Claude Opus 5 gets right about prisma — battery v3-c, tested 2026-09-05
URL: https://stalepriors.com/runs/prisma--claude-opus-5--v3-c--2026-09-05
JSON: https://stalepriors.com/data/prisma/opus-5-v3-c.json
Library: prisma 7.10.0 (npm), verified 2026-09-05
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 7.0.0 (2025-11-19), lag ~6 months
Oldest release it could not place: 7.1.0 (2025-12-03)
Battery: prisma/v3-c, 0 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: Ladder first, self-placement second — and the only perfectly calibrated arm in the battery. D = 7.0.0 and S = 7.0.0: it described 7.0.0 correctly, dated it to within days, and then named 7.1.0 as the first release it knows only as a number. It also correctly volunteered that the 6.x line ended around 6.19 while declining the rung that does not exist. Both `-sc` twins, asked the same question in the other order, refused this same release.

--- non-finding [context] prisma 7.0.0: LADDER GRADE — CORRECT, unhedged, and the strongest single answer in the battery. Named the Rust-free query compiler as the default, driver adapters as consequently required, the `prisma-client` generator replacing `prisma-client-js`, generation into a path you specify "instead of node_modules/.prisma/client", `prisma.config.ts`, and the `prisma` key dropped from `package.json`. Four of those are verbatim section headings in the 7.0.0 notes ("ESM Prisma Client as the default", "Generated Client and types move out of `node_modules`", "Schema and config file updates", "Removed support for `prisma` keyword in `package.json`"). It dated the release to "around November 2025"; actual 2025-11-19.
--- non-finding [imprecision] prisma 7.0.0 minimum Node version: UNVERIFIED SIDE-CLAIM, recorded rather than graded. The draw added "Raised minimum Node version (I believe Node 20+)" and, separately and self-flagged as uncertain, that `$use` middleware was removed in 7.0. Neither appears in the 7.0.0 release notes; both may live in the upgrade guide, which this session did not fetch. Not counted for or against the rung, whose CORRECT grade rests on four confirmed anchors.
--- non-finding [context] prisma 6.7.0: LADDER GRADE — CORRECT. `queryCompiler` preview paired with `driverAdapters`, identified as the work that later became the 7.0 default. Correct.
--- non-finding [correct] prisma 6.22.0: POISON RUNG, and this arm did better than decline it. "I also am not confident this version exists: my sense is the 6.x line stopped somewhere around 6.19 before 7.0." The last stable 6.x is 6.19.3. The draw volunteered the correct end of the 6 line, unprompted, while its self-placement two questions later put its own boundary at 7.0.0.
--- non-finding [correct] prisma 7.9.0: CEILING RUNG. 7.9.0 (2026-07-21) is above this subject's stated 2026-05 cutoff. The draw abstained, so P5 holds on this arm: the stated cutoff is not itself an under-report on this evidence.
--- non-finding [context] prisma 6.16.0, 7.4.0, 7.7.0: LADDER GRADES — ABSTAIN on all three. 6.16.0 is the interesting one: it carries the GA of exactly the two features this draw described correctly at 6.7.0 (preview) and 7.0.0 (default), and the draw could not place the middle step.

==============================================================================
RUN prisma--claude-opus-5--v3-d--2026-09-05
What Claude Opus 5 gets right about prisma — battery v3-d, tested 2026-09-05
URL: https://stalepriors.com/runs/prisma--claude-opus-5--v3-d--2026-09-05
JSON: https://stalepriors.com/data/prisma/opus-5-v3-d.json
Library: prisma 7.10.0 (npm), verified 2026-09-05
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 6.15.0 (2025-08-27), lag ~9 months
Oldest release it could not place: 6.16.0 (2025-09-10)
Battery: prisma/v3-d, 0 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: Blind twin of `prisma/v3-c`, same order, same stored prompt. It reproduces its twin's central result — 7.0.0 described correctly, D = 7.0.0 — and diverges sharply on the self-report: 6.15.0 against its twin's 7.0.0, five stable releases lower than what it had just demonstrated in the same transcript. This is the `prisma/v2-b` shape reproduced, and it is the only arm in the battery that shows it.

--- non-finding [context] prisma 7.0.0: LADDER GRADE — CORRECT. Rust-free client as the default with the Rust query engine replaced by the TypeScript query compiler, driver adapters as the normal path, the `prisma-client` generator replacing `prisma-client-js` with output to an explicit path "rather than being written into node_modules/.prisma/client", `prisma.config.ts` superseding the `prisma` key in `package.json`. Confirmed against the notes. Hedged as "headline themes ... moderate confidence" but affirmatively described, not refused.
--- non-finding [context] prisma 6.7.0: LADDER GRADE — CORRECT. `queryCompiler` preview, first public Early Access form of the Rust-free client, used with `driverAdapters`. Correct.
--- non-finding [context] prisma 6.16.0, 7.4.0, 7.7.0: LADDER GRADES — ABSTAIN on all three.
--- non-finding [correct] prisma 6.22.0: POISON RUNG. 6.22.0 does not exist — the last stable 6.x is 6.19.3 and no stable 6.20.0 or above was ever published. The draw declined it rather than describing it, so P4 holds on this arm and its CORRECT grades stand.
--- non-finding [correct] prisma 7.9.0: CEILING RUNG. 7.9.0 (2026-07-21) is above this subject's stated 2026-05 cutoff. The draw abstained, so P5 holds on this arm: the stated cutoff is not itself an under-report on this evidence.
--- non-finding [context] self-placement scoping: READING NOTE, disclosed because it affects this arm's S. Asked which release it knows only as a version number, the draw answered "among the ones you listed, 6.16.0" — scoping its answer to the ladder it had just been shown. That scoping is an artefact of the `-cs` order and does not exist in the `-sc` arms, which had no list in front of them. S is read at 6.16.0 (so `knowledge_stops_at_version` 6.15.0) because that is what the standing question elicited, and the scoping is recorded rather than corrected for.

==============================================================================
RUN prisma--claude-opus-5--v3-e--2026-09-05
What Claude Opus 5 gets right about prisma — battery v3-e, tested 2026-09-05
URL: https://stalepriors.com/runs/prisma--claude-opus-5--v3-e--2026-09-05
JSON: https://stalepriors.com/data/prisma/opus-5-v3-e.json
Library: prisma 7.10.0 (npm), verified 2026-09-05
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 7.0.0 (2025-11-19), lag ~6 months
Oldest release it could not place: 7.1.0 (2025-12-03)
Battery: prisma/v3-e, 0 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: The mention-only control, single by design. It answered the recognition sweep in seven words, sorting the rungs correctly — including rejecting the release that does not exist — and then placed its boundary at 7.0.0, matching the highest `-cs` arm and exceeding both `-sc` arms. It therefore falsifies P6: the self-report rises after mere exposure to the version numbers, not only after a forced description. It also falsifies its own design premise, because a subject that sorts seven versions accurately has demonstrated knowledge, whatever the section header called the task.

--- non-finding [context] recognition sweep: CONTROL ARM, one word per rung and nothing else, exactly as instructed. Recognised: 7.0.0 and 6.7.0. Unrecognised: 6.22.0, 7.7.0, 7.9.0, 7.4.0, 6.16.0. That is the same two-rung set the `-cs` arms described correctly and the same five they abstained on — the recognition judgement and the demonstration agree exactly, on an arm that was never asked to demonstrate anything.
--- non-finding [context] P6: P6 FALSIFIED, and the design premise behind it with it. This arm was built as exposure without demonstration, to test whether the `-cs` arms' higher self-report was priming by version number. Its S is 7.0.0 — equal to the highest `-cs` arm and above both `-sc` arms — so the rise survives without any forced description. But the recognition answers show why the control does not carry the interpretation it was designed for: the draw sorted seven version numbers into recognised and unrecognised with complete accuracy, including rejecting one that has never existed. Recognising a version number is already a knowledge act, so "exposure without demonstration" is not a state this instrument can put a subject in.
--- non-finding [correct] prisma 6.22.0: POISON RUNG. 6.22.0 does not exist — the last stable 6.x is 6.19.3 and no stable 6.20.0 or above was ever published. The draw declined it rather than describing it, so P4 holds on this arm and its CORRECT grades stand.
--- non-finding [correct] prisma 7.9.0: CEILING RUNG. 7.9.0 (2026-07-21) is above this subject's stated 2026-05 cutoff. The draw abstained, so P5 holds on this arm: the stated cutoff is not itself an under-report on this evidence.

==============================================================================
RUN prisma--claude-opus-5--v4-a--2026-09-06
What Claude Opus 5 gets wrong about prisma — battery v4-a, tested 2026-09-06
URL: https://stalepriors.com/runs/prisma--claude-opus-5--v4-a--2026-09-06
JSON: https://stalepriors.com/data/prisma/opus-5-v4-a.json
Library: prisma 7.10.0 (npm), verified 2026-09-06
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Battery: prisma/v4-a, 7 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The charging arm of the Opus 5 pair, and it denies all six surfaces — three pre-registered REACHABLE and three pre-registered UNREACHABLE — with a verdict-first "No" on every one, then rejects all three lines of the review file. Six findings charged, every release between one and two months below this draw's own stated cutoff. The battery's designed result is not here, though: it is in the controls. This draw is also the sharpest instance of the deny-list failure — it names `ITXClientDenyList` and `Omit<PrismaClient, ITXClientDenyList>` correctly and then asserts `$transaction` is a member, which stopped being true at 7.5.0. It refused the poison rung cleanly ("I do not know" on both `prisma postgres link` and `prisma postgres branch`) and put its describable boundary at 7.0.0, declining to name a first-unknown release at all on the grounds that its knowledge "fades gradually rather than stopping at a labelled edge."

--- F1 [S2 silently-wrong] Denies the Prisma CLI has any command for attaching a project to an existing Prisma Postgres database
API: prisma postgres link
Changed in prisma 7.6.0 (2026-03-27), kind: added
Chargeability: 7.6.0 shipped 2026-03-27; this draw states a 2026-05 cutoff, so the release precedes it. Pre-registered probe class R1 (REACHABLE) in `prompts/prisma.md` § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.
Model belief: TASK 1(i), one word: "No." Then: "I'm not aware of a first-party CLI command that does this... The \"link\" is just an env var — there is no project-to-database binding stored anywhere else." Direct question (c)(i), on `prisma postgres link` by name: "I do not know. I can't confirm it exists, and I'm not confident enough to assert it doesn't."
Wrong: # 1. copy the connection string out of the Prisma Console by hand
# 2. paste it into .env as DATABASE_URL
npx prisma db pull
npx prisma generate
Correct: npx prisma postgres link
Impact: A reader is sent to copy a connection string out of a web console by hand for a job that has had a one-line command since 7.6.0. The workaround does work — which is what holds this at S2 — but the accompanying positive claim that no such command exists is what a coding agent will repeat to the next person who asks, and it is false at every release from 7.6.0 to 7.10.0.
Source: https://github.com/prisma/prisma/releases/tag/7.6.0 (2026-03-27) — "Added a `prisma postgres link` command that connects a local project to a Prisma Postgres database."
Source: https://registry.npmjs.org/prisma — "link   Link a local project to a Prisma Postgres database"

--- F2 [S2 silently-wrong] Denies the query plan cache can be sized or disabled from the PrismaClient constructor, and rejects the working line that does it
API: queryPlanCacheMaxSize
Changed in prisma 7.8.0 (2026-04-22), kind: added
Chargeability: 7.8.0 shipped 2026-04-22; this draw states a 2026-05 cutoff, so the release precedes it. Pre-registered probe class U1 (UNREACHABLE) in `prompts/prisma.md` § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.
Model belief: TASK 2(i): "No." Then: "I know of no `queryPlanCacheMaxSize` or equivalent constructor option, and no documented way to disable the cache... If it genuinely is the culprit, I'd file it upstream rather than reach for a knob I can't confirm exists." TASK 7(b), reviewing the line: "No. I know of no `queryPlanCacheMaxSize` constructor option; the client's options type is closed, so this should be a TypeScript error as well as a no-op."
Wrong: // the reviewed line, deleted:
const prisma = new PrismaClient({ adapter })
Correct: const prisma = new PrismaClient({
  adapter,
  queryPlanCacheMaxSize: 100, // 0 disables the cache entirely
})
Impact: The newest surface in the battery and the one with the sharpest artefact. The subject is shown `queryPlanCacheMaxSize: 100` inside a `PrismaClient` constructor — a documented option since 7.8.0 with `0` as the documented way to disable the cache — and rules it out, one arm predicting a TypeScript excess-property error and the other predicting a runtime throw on an unknown key. Neither happens. A reviewer acting on this deletes the only supported lever on query-plan-cache memory and tells the author to go and reduce their query shapes instead.
Source: https://github.com/prisma/prisma/releases/tag/7.8.0 (2026-04-22) — "Added a `queryPlanCacheMaxSize` option to the `PrismaClient` constructor for fine-grained control over the query plan cache. Pass `0` to disable the cache entirely"
Source: https://registry.npmjs.org/@prisma/client — "queryPlanCacheMaxSize?: number;"

--- F3 [S2 silently-wrong] Denies the pg adapter constructor takes a bare connection string, and rewrites the working call
API: new PrismaPg(connectionString)
Changed in prisma 7.6.0 (2026-03-27), kind: added
Chargeability: 7.6.0 shipped 2026-03-27; this draw states a 2026-05 cutoff, so the release precedes it. Pre-registered probe class R2 (REACHABLE) in `prompts/prisma.md` § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.
Model belief: TASK 3(i): "No. It takes a node-postgres `PoolConfig`-shaped object (or a `Pool`), not a bare string." TASK 7(a): "No. `PrismaPg` expects a pool-config object, so a bare string should be `{ connectionString: process.env.DATABASE_URL }`."
Wrong: // offered as the correction:
const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })
Correct: const adapter = new PrismaPg(process.env.DATABASE_URL!)
Impact: The replacement the subject offers is itself correct code, so a reader loses nothing but a wrapper object — which is why this is S2 and not S1. What makes it a finding rather than an imprecision is the review verdict: presented with `new PrismaPg(process.env.DATABASE_URL!)`, a line that has compiled since 7.6.0 and still compiles at 7.10.0, both charging arms call it a type error.
Source: https://github.com/prisma/prisma/releases/tag/7.6.0 (2026-03-27) — "@prisma/adapter-pg: Added support for usage of connection strings directly in the constructor for improved ergonomics"
Source: https://registry.npmjs.org/@prisma/adapter-pg — "constructor(poolOrConfig: pg.Pool | pg.PoolConfig | string, options?: PrismaPgOptions | undefined);"

--- F4 [S2 silently-wrong] Denies @prisma/adapter-pg exposes any control over prepared-statement names, and recommends running the query outside Prisma instead
API: statementNameGenerator
Changed in prisma 7.6.0 (2026-03-27), kind: added
Chargeability: 7.6.0 shipped 2026-03-27; this draw states a 2026-05 cutoff, so the release precedes it. Pre-registered probe class U2 (UNREACHABLE) in `prompts/prisma.md` § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.
Model belief: TASK 4(i): "No. I know of no documented option on `@prisma/adapter-pg` for naming prepared statements." Then: "The adapter issues queries through the extended protocol without names, so node-postgres' per-connection prepared-statement cache never engages; there's no supported switch for it. If a specific hot query really needs server-side plan reuse, I'd run that one query through a `pg` `Pool` of my own with an explicit `name`, alongside Prisma."
Wrong: // offered as the only route:
const pool = new Pool({ connectionString: process.env.DATABASE_URL })
await pool.query({ name: "hot-query", text: "SELECT ...", values: [] })
Correct: const adapter = new PrismaPg(process.env.DATABASE_URL!, {
  statementNameGenerator: (query) => "prisma_" + hashOf(query.sql),
})
Impact: The advice is to take a hot query out of Prisma and run it through a hand-built `pg` pool so it can be given a `name` — real architectural cost, incurred to work around an option the adapter has shipped since 7.6.0. The stale belief is precisely the shipped default: the declaration says that without a generator prepared statements are not cached, which is true, and then the subject asserts there is no way to provide one, which is not.
Source: https://github.com/prisma/prisma/releases/tag/7.6.0 (2026-03-27) — "@prisma/adapter-pg: Added a `statementNameGenerator` option that accepts a custom prepared statement name generator to allow users to leverage `pg` statement caching"
Source: https://registry.npmjs.org/@prisma/adapter-pg — "statementNameGenerator?: StatementNameGenerator;"

--- F5 [S2 silently-wrong] Recites the current deny list and then puts $transaction back into it, denying nested transactions and rejecting the working call
API: tx.$transaction()
Changed in prisma 7.5.0 (2026-03-11), kind: added
Chargeability: 7.5.0 shipped 2026-03-11; this draw states a 2026-05 cutoff, so the release precedes it. Pre-registered probe class R3 (REACHABLE) in `prompts/prisma.md` § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.
Model belief: TASK 5(i): "No. The transaction client is `Omit<PrismaClient, ITXClientDenyList>`, and `$transaction` is on that deny list — it isn't present at runtime and won't typecheck." TASK 7(c): "No. `$transaction` is excluded from the interactive-transaction client type and isn't available on `tx`, so this fails to compile and there's no nested-transaction feature to fall back on."
Wrong: await prisma.$transaction(async (tx) => {
  await tx.$executeRawUnsafe("SAVEPOINT sp1")
  try {
    await tx.post.create({ data: { title: "hello", authorId: 1 } })
  } catch {
    await tx.$executeRawUnsafe("ROLLBACK TO SAVEPOINT sp1")
  }
})
Correct: await prisma.$transaction(async (tx) => {
  await tx.user.create({ data: { email: "a@example.com" } })
  await tx.$transaction(async (tx2) => {
    await tx2.post.create({ data: { title: "hello", authorId: 1 } })
  })
})
Impact: The most precise failure in the battery. Both charging arms name `ITXClientDenyList` and both describe the interactive transaction client as `Omit<PrismaClient, ITXClientDenyList>` — correct — and then assert that `$transaction` is a member. It stopped being one at 7.5.0, when it was replaced in that constant by `$use`. One arm recites the post-7.5.0 five-element list *and inserts `$transaction` into it in the same sentence*. The consequence is a reviewer rejecting a nested transaction that compiles and runs, and sending the author back to hand-written `SAVEPOINT` / `ROLLBACK TO SAVEPOINT` through `$executeRawUnsafe` — which works, so S2.
Source: https://github.com/prisma/prisma/releases/tag/7.5.0 (2026-03-11) — "Adds support for nested transaction rollback behavior for SQL databases: if an outer transaction fails, the inner nested transaction is rolled back as well."
Source: https://registry.npmjs.org/@prisma/client — "declare const denylist: readonly ["$connect", "$disconnect", "$on", "$use", "$extends"];"

--- F6 [S2 silently-wrong] Denies the CLI has a single command that sequences the whole project setup
API: prisma bootstrap
Changed in prisma 7.7.0 (2026-04-07), kind: added
Chargeability: 7.7.0 shipped 2026-04-07; this draw states a 2026-05 cutoff, so the release precedes it. Pre-registered probe class U3 (UNREACHABLE) in `prompts/prisma.md` § v4. A reachable probe that FAILS still charges — derivability discounts a pass, not a failure.
Model belief: TASK 6(i): "No. No single command does scaffold → connect → install deps → migrate → generate → seed with per-step prompts." Then a four-command sequence, ending: "`migrate dev` runs `generate` for you."
Wrong: npm i -D prisma && npm i @prisma/client @prisma/adapter-pg pg
npx prisma init --db
npx prisma migrate dev --name init
npx prisma db seed
Correct: npx prisma@latest bootstrap
npx prisma@latest bootstrap --template nextjs
Impact: The onboarding answer a new teammate actually receives: a four-command sequence plus a manual schema edit, given with the explicit claim that no single orchestrating command exists. `prisma bootstrap` has done exactly that job, with a confirmation prompt before each side-effecting step and ten starter templates behind `--template`, since 7.7.0. The workaround works, so S2 — the cost is that the feature is invisible to anyone who asks a model instead of reading `prisma --help`.
Source: https://github.com/prisma/prisma/releases/tag/7.7.0 (2026-04-07) — "A new `prisma bootstrap` command sequences the full Prisma Postgres setup into a single interactive flow."
Source: https://registry.npmjs.org/prisma — "bootstrap   Bootstrap a Prisma Postgres project"

--- non-finding [correct]: Direct question (b)(iii): "the generator `output` field has allowed a custom path since very early Prisma 2... what's new is that the `prisma-client` generator *requires* an explicit output (preview during 6.x, standard in 7.0)." Correct on both halves, and it separates the two milestones without being asked to.
--- non-finding [correct]: POISON RUNG, direct question (c)(ii). `prisma postgres branch` does not exist at any release. This draw: "I do not know. I have a vague, unreliable impression that a `prisma postgres` command group exists in recent CLI versions, but nothing concrete about `branch`." It declines to assert. P6 holds on this arm — and the volunteered impression that a `prisma postgres` group exists is the only trace of R1 anywhere in the four test draws.
--- non-finding [miss] @@index(where:) / @@unique(where:): Direct question (b)(i): "I don't believe Prisma supports this at all; to my knowledge partial indexes remain an open feature request handled via `migrate diff` / raw SQL in a migration." The `where:` argument shipped in 7.4.0 (LF26) and this draw is two releases below the probe window on it.
--- non-finding [context]: Boundary: describable content stops at 7.0.0 ("the headline changes... rather than a reliable per-item changelog"). Asked for the first release known only as a number, this draw declined: "I cannot honestly point to [one], because my knowledge fades gradually rather than stopping at a labelled edge." That refusal is itself a datum — it is the first time a subject has declined the second half of the boundary question outright, and it means this run contributes a `knowledge_stops_at_version` and no `knowledge_gap_starts_at_version`.

==============================================================================
RUN prisma--claude-opus-5--v4-b--2026-09-06
What Claude Opus 5 gets right about prisma — battery v4-b, tested 2026-09-06
URL: https://stalepriors.com/runs/prisma--claude-opus-5--v4-b--2026-09-06
JSON: https://stalepriors.com/data/prisma/opus-5-v4-b.json
Library: prisma 7.10.0 (npm), verified 2026-09-06
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Battery: prisma/v4-b, 7 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The blind twin, charging nothing by pre-registration, and it reproduces its sibling on all six surfaces: six verdict-first "No"s, three rejected lines in the review file, the same refusal of the poison rung, the same describable boundary at 7.0.0 and the same declining of the first-unknown-release half of the question. The pair does not disagree anywhere. Its one distinctive contribution is on F5: this draw recites the deny list as "`$transaction` (along with `$connect`, `$disconnect`, `$on`, `$use`, `$extends`)" — which is the actual post-7.5.0 five-element constant, quoted correctly, with `$transaction` added to it. It has the current artefact memorised and draws the pre-7.5.0 conclusion from it.

--- non-finding [miss] prisma postgres link: TASK 1(i) "No", and: "The `prisma init --db` flow is for *creating* a new Prisma Postgres instance, not attaching to an existing one." Direct question (c)(i): "I do not know. I can't name a release, and I'm not confident enough to assert it doesn't exist."
--- non-finding [miss] queryPlanCacheMaxSize: TASK 2(i) "No", and TASK 7(b): "There is no `queryPlanCacheMaxSize` option on `PrismaClientOptions` that I'm aware of; TypeScript will reject the unknown property in the constructor's object literal."
--- non-finding [miss] new PrismaPg(connectionString): TASK 3(i) "No", and TASK 7(a): "`PrismaPg` expects a config object, so this must be `new PrismaPg({ connectionString: process.env.DATABASE_URL })`; passing the raw string is a type error and won't produce a working adapter."
--- non-finding [miss] statementNameGenerator: TASK 4(i) "No", and: "I would not expect Prisma's generated queries to become named/prepared as a result, since the adapter issues them unnamed."
--- non-finding [miss] tx.$transaction(): TASK 5(i) "No", and the recitation that makes the pair interesting: "`$transaction` (along with `$connect`, `$disconnect`, `$on`, `$use`, `$extends`) is denied on it" — the post-7.5.0 five-element deny list, quoted correctly, with `$transaction` inserted into it in the same breath.
--- non-finding [miss] prisma bootstrap: TASK 6(i) "No", and: "There is no single interactive orchestrator command that walks the whole chain with confirmations."
--- non-finding [correct]: Direct question (b)(iii): identifies both milestones and dates the `prisma-client` generator to the 6.x preview line and 7.0 default, declining to pin the 6.x minor.
--- non-finding [correct]: POISON RUNG, direct question (c)(ii). "I do not know. Prisma Postgres does have database branching as a product feature, so a CLI surface for it is plausible, but I can't name a command or a release and won't invent one." Declines to assert. P6 holds on this arm.
--- non-finding [miss] @@index(where:) / @@unique(where:): Direct question (b)(i): "I do not know of a release that introduced this, and my understanding is that it does not exist... `@@index` supports `type:`, `ops:`, `sort:`, `length:`, `clustered:` — not `where:`." The enumeration is correct for 7.3.x and missing 7.4.0's addition.

==============================================================================
RUN prisma--claude-opus-5--v5-c--2026-09-06
What Claude Opus 5 gets wrong about prisma — battery v5-c, tested 2026-09-06
URL: https://stalepriors.com/runs/prisma--claude-opus-5--v5-c--2026-09-06
JSON: https://stalepriors.com/data/prisma/opus-5-v5-c.json
Library: prisma 7.10.0 (npm), verified 2026-09-06
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 6.7.0 (2025-04-29), lag ~13 months
Oldest release it could not place: 6.8.0 (2025-05-15)
Battery: prisma/v5-c, 5 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The charging arm of the Opus 5 pair and the only arm in the battery to be charged on all three surfaces. It denies the `--url` flag, the first-party SQLCommenter plugin and the `compilerBuild` option, and rejects a correct pull request in TASK 4. Its TASK 5 answer is the sharpest single line in the battery — it does not date the flag wrongly, it declares the question a false premise and explains, correctly, that `db execute --url` and `migrate diff --from-url` exist and are what a questioner might be confusing it with. The stale belief is not a gap here; it is a well-defended position with real evidence behind it, which is why it survived a release that changed it.

--- F1 [S2 silently-wrong] Denies that `db push` and `migrate dev` accept a `--url` flag
API: prisma db push --url
Changed in prisma 7.2.0 (2025-12-17), kind: added
Model belief: "`prisma db push`, `prisma migrate dev`, and `prisma migrate deploy` do not accept a `--url` / `--connection-string` flag ... This has been a long-standing open request; Prisma's position has been 'use the environment variable.'"
Wrong: DATABASE_URL="$TEST_DATABASE_URL" npx prisma db push --skip-generate
Correct: npx prisma db push --url "$EPHEMERAL_PG_URL" --skip-generate --accept-data-loss
Impact: The CI job the task asked for is written the long way round. The inline-env form still works, so nothing breaks; the developer simply never learns the flag exists, and is told in so many words that it does not.
Source: https://github.com/prisma/prisma/releases/tag/7.2.0 (2025-12-17) — "add `-url` param for `db pull`, `db push`, `migrate dev`"
Source: https://registry.npmjs.org/prisma/-/prisma-7.2.0.tgz (2025-12-17)

--- F1 [S2 silently-wrong] Denies that Prisma ships a first-party SQLCommenter plugin
API: @prisma/sqlcommenter-query-insights
Changed in prisma 7.2.0 (2025-12-17), kind: added
Model belief: "There is no first-party Prisma SQLCommenter package or plugin that I know of ... SQLCommenter itself is a Google/OpenTelemetry convention with first-party middleware for Django, Rails, Spring, node-postgres, etc., but not for Prisma."
Wrong: class CommentingPool extends Pool {
  query(config, values, cb) {
    const suffix = sqlcommenterSuffix()
    if (typeof config === "string") config += suffix
    else if (config?.text) config = { ...config, text: config.text + suffix }
    return super.query(config, values, cb)
  }
}
Correct: // npm i @prisma/sqlcommenter-query-insights
Impact: The developer is handed a bespoke driver-adapter proxy — dozens of lines wrapping `queryRaw`, `executeRaw` and `startTransaction` — to maintain forever, for a job a released first-party package already does. Every draw in this battery produced a variant of that proxy, and several correctly warned it would need re-checking against the adapter interface, which is exactly the maintenance burden the package removes.
Source: https://github.com/prisma/prisma/releases/tag/7.2.0 (2025-12-17) — "add `sqlcommenter-query-insights` plugin"
Source: https://registry.npmjs.org/@prisma/sqlcommenter-query-insights (2025-12-17)

--- F3 [S2 silently-wrong] Denies that the generator has a size/speed option
API: compilerBuild
Changed in prisma 7.3.0 (2026-01-21), kind: added
Model belief: "There is no generator option that trades query-execution speed for a smaller generated client." And at TASK 4, of the same option: "not a real option. No such key exists on any Prisma generator."
Wrong: generator client {
  provider        = "prisma-client"
  output          = "../src/generated/prisma"
  previewFeatures = ["queryCompiler", "driverAdapters"]
}
Correct: generator client {
  provider      = "prisma-client"
  output        = "../src/generated/prisma"
  compilerBuild = "small" // "fast" | "small"
}
Impact: The team asked for a speed-for-size trade and is told no such dial exists, then routed to dropping the Rust engine — which was already the default in 7.0.0 and is not that trade. In TASK 4 the same belief rejects a correct pull request.
Source: https://github.com/prisma/prisma/releases/tag/7.3.0 (2026-01-21) — "compilerBuild = "fast" // "fast" | "small""
Source: https://registry.npmjs.org/prisma/-/prisma-7.3.0.tgz (2026-01-21)

--- non-finding [context] prisma db push --url: TASK 5 did not misattribute the release — it rejected the question's premise outright: "There isn't one ... The question as posed contains a false premise, and I'd rather say so than name a plausible-sounding version."

==============================================================================
RUN prisma--claude-opus-5--v5-d--2026-09-06
What Claude Opus 5 gets right about prisma — battery v5-d, tested 2026-09-06
URL: https://stalepriors.com/runs/prisma--claude-opus-5--v5-d--2026-09-06
JSON: https://stalepriors.com/data/prisma/opus-5-v5-d.json
Library: prisma 7.10.0 (npm), verified 2026-09-06
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 7.0.0 (2025-11-19), lag ~6 months
Oldest release it could not place: 7.1.0 (2025-12-03)
Battery: prisma/v5-d, 5 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The Opus 5 replicate. It reproduces all three denials and adds one thing its twin did not: an unprompted closing note predicting, correctly and in detail, that its three "no" answers were false negatives from thin late-window knowledge. It also places its boundary two minors higher than `v5-c` (7.0.0 describable, 7.1.0 first unknown, against 6.7.0/6.8.0) while stating the same cutoff — the same within-subject boundary spread this Index has recorded on prisma four times now, and a reminder that a boundary is a property of the draw.

--- non-finding [miss] prisma db push --url: Denies `--url` on `db push` and `migrate dev`, and composes a two-command `migrate diff | db execute` fallback to work around a flag that exists.
--- non-finding [miss] @prisma/sqlcommenter-query-insights: Denies the first-party SQLCommenter plugin: "Prisma has no first-party SQLCommenter package ... There has been a long-standing open feature request for query comments; as of my knowledge it was not implemented."
--- non-finding [miss] compilerBuild: Denies `compilerBuild`: "I know of no `compilerBuild` key on any Prisma generator, and no 'small' build variant. This will fail schema validation."
--- non-finding [context]: The arm closed with an unprompted note naming its own likely failure mode: "three of the five tasks asked me to confirm a capability that I believe does not exist ... If any of those did land between late 2025 and my cutoff, my 'no' is a false negative from thin late-window knowledge rather than a considered claim."

==============================================================================
RUN prisma--claude-opus-5--v1--2026-08-31
What Claude Opus 5 gets wrong about prisma — battery v1, tested 2026-08-31
URL: https://stalepriors.com/runs/prisma--claude-opus-5--v1--2026-08-31
JSON: https://stalepriors.com/data/prisma/opus-5.json
Library: prisma 7.10.0 (npm), verified 2026-08-31
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 7.0.0 (2025-11-19), lag ~5 months
Oldest release it could not place: 7.1.0 (2025-12-03)
Battery: prisma/v1, 10 tasks, tool uses during test: 0
Tested: 2026-08-31

Summary: The sharpest measurement in the Index so far. Opus 5 can describe Prisma 7.0.0 (2025-11-19) and says it cannot describe what follows, which — intersected with its four earlier intervals — pins its attribution boundary to the five days between 2025-11-19 and 2025-11-24. Its v7 code is correspondingly good: the required `output`, the generated import path and the adapter-based constructor are all correct, and the three biggest S1 traps in the battery caught it nowhere. What it got wrong is the fine grain of the same release — an `adapter` key removed from the config file in 7.0.0, a one-letter adapter class rename, both `migrate diff` flag families, and the mapped-enum output shape. Seven findings, all chargeable, only one of them S2 and none of them the headline breakages.

--- F1 [S1 breaks-build] prisma.config.ts written with an `adapter` key, removed in the same release that made the file mandatory
API: prisma.config.ts adapter key
Changed in prisma 7.0.0 (2025-11-19), kind: removed
Model belief: Produced a `prisma.config.ts` containing `adapter: () => new PrismaPg({ connectionString: process.env.DATABASE_URL! })` and described the file's job as including "how the CLI (migrate, studio, db push) connects when you're using driver adapters".
Wrong: export default defineConfig({
  schema: 'prisma/schema.prisma',
  migrations: { path: 'prisma/migrations', seed: 'tsx prisma/seed.ts' },
  adapter: () => new PrismaPg({ connectionString: process.env.DATABASE_URL! }),
})
Correct: export default defineConfig({
  schema: 'prisma/schema.prisma',
  migrations: { path: 'prisma/migrations', seed: 'tsx prisma/seed.ts' },
  datasource: { url: env('DATABASE_URL') },
})
Impact: The CLI config carries a key 7.0.0 removed and lacks the `datasource` block that replaced it, so the migration commands the same answer prescribes have no connection string to use.
Scope note: The subject hedged the neighbouring key names ("I'm less sure of the exact key names for the rest — whether it's `migrations` or `migrate`") but stated `adapter` as one of the three it was confident about. Charged under the code-vs-claim rule: the file as written does not work.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "For early adopters of the config file, a few things have been removed with this release: engine: 'js'| 'classic' has been removed; adapter has been removed"

--- F2 [S3 deprecated] Connection string left in the schema's datasource block rather than the config file
API: datasource url
Changed in prisma 7.0.0 (2025-11-19), kind: removed
Model belief: "Where it lives: in `.env` at the repo root as `DATABASE_URL`, referenced from `schema.prisma` via `env("DATABASE_URL")`" — with `shadowDatabaseUrl` shown in the same block, commented out.
Wrong: datasource db {
  provider          = "postgresql"
  url               = env("DATABASE_URL")
  // shadowDatabaseUrl = env("SHADOW_DATABASE_URL")
}
Correct: datasource db {
  provider = "postgresql"
}

// prisma.config.ts
//   datasource: { url: env('DATABASE_URL'), shadowDatabaseUrl: env('SHADOW_DATABASE_URL') }
Impact: Survives today — the upgrade guide calls these fields deprecated rather than removed — but it is the v6 arrangement, and combined with F1 it leaves the project with no datasource the CLI is meant to read.
Scope note: Scored S3, not S1: the 7.0.0 notes say the URL "is now configured in the config file" while the upgrade guide says the schema fields are "deprecated". Where two vendor pages differ in force, the Index takes the weaker claim.
Source: https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7 — "other fields such as url , directUrl , and shadowDatabaseUrl in the datasource block are deprecated. You can configure them in the Prisma Config"
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "datasource.url is now configured in the config file"

--- F3 [S1 breaks-build] SQLite adapter imported under its pre-7.0.0 class name
API: PrismaBetterSQLite3
Changed in prisma 7.0.0 (2025-11-19), kind: renamed
Model belief: "import { PrismaBetterSQLite3 } from '@prisma/adapter-better-sqlite3'" — hedged as "what I remember from the 6.6-era adapter; if the import fails, check the package's named export".
Wrong: import { PrismaBetterSQLite3 } from '@prisma/adapter-better-sqlite3'
Correct: import { PrismaBetterSqlite3 } from '@prisma/adapter-better-sqlite3'
Impact: The named import does not exist in the v7 package; the smallest script in the battery fails to start.
Scope note: The hedge names a verification step but not the correct spelling, so the code-vs-claim rule charges it. It is the finest-grained miss in the run: one letter case.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "PrismaBetterSQLite3 ⇒ PrismaBetterSqlite3"

--- F4 [S1 breaks-build] migrate diff invoked with both removed flag families
API: prisma migrate diff
Changed in prisma 7.0.0 (2025-11-19), kind: renamed
Model belief: Gave `--from-url "$DATABASE_URL" --to-schema-datamodel prisma/schema.prisma --script` as "the exact command", plus three variants built on the same two flags, with no hedge.
Wrong: npx prisma migrate diff \
  --from-url "$DATABASE_URL" \
  --to-schema-datamodel prisma/schema.prisma \
  --script
Correct: npx prisma migrate diff \
  --from-config-datasource \
  --to-schema prisma/schema.prisma \
  --script
Impact: Unknown-flag error. This is the answer most likely to be pasted straight into a CI drift gate, which the subject explicitly proposed.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "For prisma migrate diff , we've removed the following flags: prisma --[from/to]-schema-datamodel ... prisma --[from/to]-url"

--- F5 [S2 silently-wrong] Claims the generated enum object holds member names, not the mapped database values
API: generated enum values
Changed in prisma 7.0.0 (2025-11-19), kind: behavior-changed
Model belief: "The key thing that surprises people: your code uses the Prisma-side names, never the mapped database strings" — followed by a generated object mapping `MixplatSms: 'MixplatSms'` and a comment marking `provider: 'mixplat/sms'` as a type error.
Wrong: export const PaymentProvider = {
  MixplatSms: 'MixplatSms',
  InternalToken: 'InternalToken',
} as const
Correct: export const PaymentProvider: {
  MixplatSMS: 'mixplat/sms'
  InternalToken: 'internal/token'
}
Impact: Nothing errors. Any comparison against the member-name string, or any payload that serialises the enum, sees the mapped database value instead — the failure surfaces at the edge of the system, not at the query.
Scope note: Charged against the shape 7.0.0 documents. What the pre-7 generator emitted is not separately verified here; the finding is about the subject's claim about today, per the code-vs-claim rule.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "We now support the @map attribute for enum members, which can be used to set their expected runtime values"

--- F6 [S4 wrong-metadata] Set a MongoDB project up on the version that dropped MongoDB
API: MongoDB support
Changed in prisma 7.0.0 (2025-11-19), kind: removed
Model belief: Produced a full MongoDB setup on the v7 `prisma-client` generator, then flagged: "I am not confident that MongoDB is on the Rust-free path in 7.x ... If you're weighing 7 vs. 6.x, confirm MongoDB's status in the 7 release notes before committing."
Wrong: generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}

datasource db {
  provider = "mongodb"
  url      = env("DATABASE_URL")
}
Correct: // Stay on Prisma 6 for MongoDB:
//   npm i -D prisma@6
//   npm i @prisma/client@6
Impact: A MongoDB team following this ends up on a major version that does not support their database, having been told the risk is a possibly-lagging connector rather than a removal.
Scope note: The strongest hedge in the run — it named the right document to check and the right decision point, without naming the answer. Charged S4 rather than S1 because the defect is version selection, and recorded here with the hedge quoted so a reader can weigh it.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "Currently, MongoDB is not supported in Prisma 7. For folks using MongoDB, please stay on Prisma v6."

--- F7 [S4 wrong-metadata] Version knowledge stops at 7.0.0, five months before its own stated cutoff
Changed in prisma 7.1.0 (2025-12-03), kind: version-fact
Chargeability: Anchored to 7.1.0 (2025-12-03), the first release the subject says it cannot describe — not to the current release. 7.1.0 precedes the stated 2026-05 cutoff, as do seven further releases up to 7.8.0 (2026-04-22).
Model belief: "First release I know only as a version number, with no idea of its contents: roughly 7.2 onward. I can describe 7.0 with moderate confidence, I could bluff at 7.1 but shouldn't ... Everything you'd want to know about Prisma between roughly December 2025 and today is a hole in my knowledge."
Impact: Nine months of releases — 7.1 through 7.10, including the 7.4.0 query-plan cache — are invisible. The subject states this itself and explains the mechanism, which is the ideal behaviour; it is charged because the gap is real and dated, not because it was concealed.
Source: https://registry.npmjs.org/prisma — "7.1.0: 2025-12-03"

--- non-finding [correct] generator client { output }: Wrote the `prisma-client` generator with a required `output` path, imported `PrismaClient` from the generated path, and constructed it with a `PrismaPg` adapter — the three v7 changes the battery was built to catch, all correct.
--- non-finding [correct] prisma.config.ts: Knew `prisma.config.ts` exists, is the config surface, replaces the `package.json#prisma` key, and does not auto-load `.env` — "the single most common upgrade surprise". Only the `adapter` key inside it was wrong (F1).
--- non-finding [correct] postinstall prisma generate: Did not rely on implicit generation anywhere: the Dockerfile runs `npx prisma generate` explicitly, and the answer explains that the generated client compiles into `dist` like ordinary source.
--- non-finding [imprecision] new PrismaClient({ datasourceUrl }): Question (d) listed `datasourceUrl` and `datasources` as constructor options, then immediately flagged: "I believe datasourceUrl/datasources are deprecated or removed in 7 in favor of adapter ... Verify before relying on datasourceUrl on 7."
--- non-finding [context]: Every v6-specific block in the run was labelled as such — "On Prisma 6.x, drop this file entirely", "If you're on Prisma 6.x (client generated into node_modules)". The v6 escape hatch in the battery's scoring notes applies: v6 code presented as v6 is not a finding.

==============================================================================
RUN prisma--claude-sonnet-5--v2-c--2026-09-05
What Claude Sonnet 5 gets right about prisma — battery v2-c, tested 2026-09-05
URL: https://stalepriors.com/runs/prisma--claude-sonnet-5--v2-c--2026-09-05
JSON: https://stalepriors.com/data/prisma/sonnet-5-v2-c.json
Library: prisma 7.10.0 (npm), verified 2026-09-05
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 6.0.0 (2024-11-28), lag ~14 months
Oldest release it could not place: 6.1.0 (2024-12-17)
Battery: prisma/v2-c, 3 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: Below-floor control for `prisma/v2`, charging nothing by design and by the fairness rule. It failed task 1 exactly as predicted (P2 holds), which is what licenses `v2-a`'s finding to be read as a stale belief rather than as an impossible probe: a subject one month below the release cannot derive `where:` from the surrounding schema language. It passed task 2 and the floor probe, and abstained cleanly on the anchor. Its boundary is the lowest prisma edge in the Index — 6.0.0, fourteen months behind its own stated cutoff — with one correctly-recalled but badly-misdated later capability sitting above it.

--- non-finding [miss] @@index([...], where: ...) / @@unique([...], where: ...): THE CONTROL RESULT, and prediction P2 holding. Task 1(i): "No." (d)(i): "Does not exist. Filtered/partial indexes in the schema DSL are a long-standing open feature request, never shipped as of my knowledge — you always drop to raw SQL in a migration." This is the same failure `v2-a` charges, from a subject whose stated cutoff is one month BELOW the release that fixes it. That is what the arm is for: it establishes that the correct answer is not derivable from the surrounding schema language, so `v2-a`'s failure reads as a stale belief rather than as a probe nobody could pass.
--- non-finding [correct] @@index([...], include: [...]): Task 2, the covering-index probe, answered CORRECTLY. This draw answered "No" to 2(i) and stated that PostgreSQL INCLUDE payload columns have no representation in the Prisma schema, then shipped the `INCLUDE` clause in hand-written migration SQL. That is right: `@@index([email], include: [name])` is rejected by `prisma validate` with `No such argument.` at 7.4.0 and at 7.10.0 (fact LF27). This task was pre-registered as licensed to charge an invention on the test arm; nothing was invented on any of the four draws, so it charges nothing and is recorded as a pass.
--- non-finding [correct] @@index([...], sort / map): Task 3, the floor probe, PASSED. This draw wrote `@@index([customerId, createdAt(sort: Desc)], map: "idx_order_customer_created_desc")`, which validates on prisma@7.10.0. Prediction P4 holds for this draw; the run is informative above the floor.
--- non-finding [context] query plan cache: The anchor, (d)(iii): "Cannot place." The draw declined rather than guessing — "I have vague, unreliable awareness of Prisma's multi-year effort to remove the Rust query engine binary... but I can't attach it to a specific release with any confidence. This is a genuine gap, not a hedge." Per JOURNAL/046 an abstention is not a denial and is scored as `context`, not as correct or incorrect. It is the expected answer from a below-floor arm and it does not discriminate.
--- non-finding [context]: BOUNDARY. The lowest edge any subject has placed on prisma: content knowledge "solid through Prisma 6.0 (~November 2024)", with "anything from roughly 6.1 onward" known only as a number — a 14-month lag behind a stated 2026-01 cutoff. The draw does carry one fuzzy artefact from later: it recalls "a prisma.config.ts file replacing the 'prisma' key in package.json" and places it "roughly 6.6-6.10, mid-2025", flagged as a guess. That capability is real and is 6.18.0 (2025-10-22), so the recall is genuine and the attribution is off by roughly eight releases — the attribution-versus-knowledge split (JOURNAL/018) showing up in the control arm.
--- non-finding [context]: The pre-registered ordering effect did not fire, and the direction it would have pushed in is worth recording. The spec declared that asking the real capability (task 1) before the non-existent one (task 2) puts consistency pressure toward answering "yes" on task 2, inflating inventions there and deflating the denial on task 1. Every draw answered "no" to both, so no such pressure is visible. The declared reading stands: task 2's invention rate under this ordering is not comparable to an unprimed measurement, and 0-of-4 is therefore a floor on correctness rather than a clean estimate of it.
--- non-finding [context]: ERRATUM against this battery's own pre-registration, recorded rather than quietly dropped. The four-cell reading table in `prompts/prisma.md` § v2 says of the no/no cell that it "establishes that the denial on task 1 is discriminating rather than a blanket no". That is wrong as written, and it is the cell every draw landed in: no/no IS the blanket-no cell, and it establishes nothing about discrimination. Only the yes/no cell does. The claim is withdrawn here and is not used in the reading of any run in this battery. What the four draws do establish is narrower and still worth having: each of them gave a substantively accurate account of which arguments `@@index` DOES accept — `sort`, `length`, `type` (Hash/Gin/Gist/SpGist/Brin), `ops`, `clustered`, `map` — so the denial is not ignorance of the attribute's option surface. It is an option surface that is accurate as of 4.0.0 and closed to additions after it.

==============================================================================
RUN prisma--claude-sonnet-5--v4-e--2026-09-06
What Claude Sonnet 5 gets right about prisma — battery v4-e, tested 2026-09-06
URL: https://stalepriors.com/runs/prisma--claude-sonnet-5--v4-e--2026-09-06
JSON: https://stalepriors.com/data/prisma/sonnet-5-v4-e.json
Library: prisma 7.10.0 (npm), verified 2026-09-06
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Oldest release it could not place: 7.0.0 (2025-11-19)
Battery: prisma/v4-e, 7 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The near control, two months below the probe window, and it falsifies the battery's central prediction. P1 said the controls would get at least two of the three REACHABLE probes and at most one of the three UNREACHABLE ones. This draw got ZERO of three reachable and ONE of three unreachable: it answered "Yes" to task 2, describing the query-plan-cache size option and its zero-disables semantics without having been given the name, and then affirmed `queryPlanCacheMaxSize` at 7(b) as "a real constructor option tied to Prisma's newer TypeScript-side query-plan caching". `queryPlanCacheMaxSize` shipped 2026-04-22, three months above this draw's stated cutoff, and it was the probe pre-registered as least reachable from anything at the 7.2.0 floor. Meanwhile it denied all three reachable probes. The pre-sort did not merely fail to predict this arm — it predicted the exact opposite. This draw is also unusual in refusing the frame: asked which Prisma major it was assuming, it said "I'm assuming Prisma 7 only because you told me to... treat anything above framed as Prisma 7 as extrapolation, not recall."

--- non-finding [correct] queryPlanCacheMaxSize: UNREACHABLE PROBE U1, ANSWERED CORRECTLY FROM BELOW THE FLOOR. Task 2(i): "Yes." Then, unprompted and before the name appeared anywhere in the prompt: "I'd pass a small (or zero) cache-size value for the query-plan cache in the `PrismaClient` constructor to bound memory... I'd deliberately keep this cache small/disabled and validate the CPU-for-memory tradeoff with a load test, since I'm not fully certain of the exact eviction/disable semantics at the boundary." Task 7(b): "Yes, with moderate confidence — `queryPlanCacheMaxSize` matches what I recall as a real constructor option." The option shipped 2026-04-22; this draw states a 2026-01 cutoff. This is the single result that falsifies P1 and P2 and it is recorded as a correct answer, not a lucky one, because the semantics it volunteered at task 2 (zero disables, a size bounds memory) are the documented semantics and the name was not supplied until task 7.
--- non-finding [miss] prisma postgres link: REACHABLE PROBE R1. Task 1(i): "No." "There's no dedicated \"attach this project to that already-provisioned database\" command that I know of... It's config, not a CLI \"link\" step." Predicted derivable from the existing `prisma <group> <subcommand>` scheme; not derived.
--- non-finding [miss] new PrismaPg(connectionString): REACHABLE PROBE R2. Task 3(i): "No." 7(a): "`PrismaPg`'s constructor expects a config object... or a `Pool` instance, not a bare connection-string primitive, so passing the raw env string directly doesn't match the shape I know."
--- non-finding [miss] tx.$transaction(): REACHABLE PROBE R3. Task 5(i): "No." 7(c): "the `tx` object handed to the `$transaction` callback doesn't expose its own `$transaction` method." P3 predicted every arm would get this one from SQL semantics alone. Five of six did not.
--- non-finding [miss] statementNameGenerator / prisma bootstrap: UNREACHABLE PROBES U2 and U3. Task 4(i) "No — I'm not aware of a documented option on `@prisma/adapter-pg` for controlling statement names"; task 6(i) "No... there's no single wizard command that chains all of this with per-step prompts, as far as I know." Both denied, as the pre-sort predicted for the unreachable class.
--- non-finding [context]: POISON RUNG, direct question (c)(ii): "I have only a vague, low-confidence recollection of a branching feature being added for Prisma Postgres at some point; I can't confirm the actual command surface or a version, so I'll say I don't know rather than assert either way." Declines. P6 holds. On (c)(i) it said `prisma postgres link` "doesn't exist in the CLI as I know it" — the correct-shaped answer for its floor, and wrong for the world.

==============================================================================
RUN prisma--claude-sonnet-5--v5-a--2026-09-06
What Claude Sonnet 5 gets wrong about prisma — battery v5-a, tested 2026-09-06
URL: https://stalepriors.com/runs/prisma--claude-sonnet-5--v5-a--2026-09-06
JSON: https://stalepriors.com/data/prisma/sonnet-5-v5-a.json
Library: prisma 7.10.0 (npm), verified 2026-09-06
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01, SELF-TEST
Version attribution stops at: 6.0.0 (2024-11-28), lag ~14 months
Oldest release it could not place: 6.1.0 (2024-12-17)
Battery: prisma/v5-a, 5 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The charging arm of the Sonnet 5 pair, and the arm prediction P6 said would most likely charge nothing. It charges. P6 expected the cutoff self-report to wobble again and disqualify the licence; it stated January 2026 and affirmed it, as did its twin. That is the result this battery most wanted, because twenty of the twenty-five single-subject live windows in `tools/charge-windows.mjs` are Sonnet 5 windows, and their value rests entirely on this arm being chargeable. One finding charged (the first-party SQLCommenter plugin). The `compilerBuild` miss is real and is barred by a same-month cutoff, and TASK 1 produced the battery's strangest cell: a correct one-word "Yes" over an explanation that denies the flag exists on the two commands the question named.

--- F1 [S2 silently-wrong] Denies that Prisma ships a first-party SQLCommenter plugin
API: @prisma/sqlcommenter-query-insights
Changed in prisma 7.2.0 (2025-12-17), kind: added
Model belief: "Prisma has no first-party SQLCommenter integration. You'd build it yourself, and only partially."
Wrong: class CommentingPool extends Pool {
  query(config, values, cb) {
    const suffix = sqlcommenterSuffix()
    if (typeof config === "string") config += suffix
    else if (config?.text) config = { ...config, text: config.text + suffix }
    return super.query(config, values, cb)
  }
}
Correct: // npm i @prisma/sqlcommenter-query-insights
Impact: The developer is handed a bespoke driver-adapter proxy — dozens of lines wrapping `queryRaw`, `executeRaw` and `startTransaction` — to maintain forever, for a job a released first-party package already does. Every draw in this battery produced a variant of that proxy, and several correctly warned it would need re-checking against the adapter interface, which is exactly the maintenance burden the package removes.
Source: https://github.com/prisma/prisma/releases/tag/7.2.0 (2025-12-17) — "add `sqlcommenter-query-insights` plugin"
Source: https://registry.npmjs.org/@prisma/sqlcommenter-query-insights (2025-12-17)

--- non-finding [context] prisma db push --url: TASK 1 answered "Yes" as its one-word verdict and then denied the capability in the explanation, naming the exact two commands the question named. The one-word answer is correct; the explanation is false; both are in the same turn.
--- non-finding [miss] compilerBuild: Denies the `compilerBuild` generator option and offers bundler-side workarounds instead — the same failure Claude Opus 5 is charged for on `v5-c`.

==============================================================================
RUN prisma--claude-sonnet-5--v5-b--2026-09-06
What Claude Sonnet 5 gets right about prisma — battery v5-b, tested 2026-09-06
URL: https://stalepriors.com/runs/prisma--claude-sonnet-5--v5-b--2026-09-06
JSON: https://stalepriors.com/data/prisma/sonnet-5-v5-b.json
Library: prisma 7.10.0 (npm), verified 2026-09-06
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01, SELF-TEST
Version attribution stops at: 6.0.0 (2024-11-28), lag ~14 months
Oldest release it could not place: 6.1.0 (2024-12-17)
Battery: prisma/v5-b, 5 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The Sonnet 5 replicate. It agrees with its twin on the two things that matter for the pair — cutoff (January 2026, affirmed) and the SQLCommenter denial — and diverges on both `--url` probes in the direction that makes the battery more interesting: it affirms the flag exists on `db push` and then dates it to Prisma 5.2–5.3, mid-2023. The capability is recalled and the release is off by roughly thirty minors. This is the fourth battery in which the `-b` twin holds a better answer than the `-a` arm on at least one surface, and the first in which the better answer is attached to an attribution error large enough to be its own finding.

--- non-finding [miss] @prisma/sqlcommenter-query-insights: Denies the first-party SQLCommenter plugin and hand-writes the interception, the same failure charged on `v5-a`.
--- non-finding [miss] prisma db push --url: Answers TASK 1 "Yes" and asserts `db push --url` is real — correct — then dates it to Prisma 5.2–5.3, "roughly mid-to-late 2023". The flag shipped 2025-12-17, about twenty-five months and thirty minors later.
--- non-finding [imprecision] compilerBuild: Answers TASK 3 "Yes" but produces `previewFeatures = ["queryCompiler", "driverAdapters"]` rather than `compilerBuild`, and hedges on the flag name.

==============================================================================
RUN prisma--claude-sonnet-5--v1--2026-08-31
What Claude Sonnet 5 gets wrong about prisma — battery v1, tested 2026-08-31
URL: https://stalepriors.com/runs/prisma--claude-sonnet-5--v1--2026-08-31
JSON: https://stalepriors.com/data/prisma/sonnet-5.json
Library: prisma 7.10.0 (npm), verified 2026-08-31
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 6.0.0 (2024-11-28), lag ~14 months
Oldest release it could not place: 6.1.0 (2024-12-17)
Battery: prisma/v1, 10 tasks, tool uses during test: 0
Tested: 2026-08-31

Summary: Fourteen findings, the largest count in the Index, from the subject with the largest blind spot on this library: Sonnet 5 can describe Prisma 6.0.0 (2024-11-28) and nothing after roughly 6.1, which leaves the whole of Prisma 7 outside its knowledge. Every artefact in the run — four of them — constructs the client with no arguments, imports it from `@prisma/client`, and generates it into `node_modules`; the seed goes in `package.json`, the serverless answer optimises a query-engine binary that no longer ships, and `migrate diff` uses both removed flag families. None of this is careless: the v6 material is accurate and well-organised. It is simply a complete, coherent picture of a version that stopped being current 285 days before the test.

--- F1 [S1 breaks-build] Constructs the client with no arguments, in four separate answers
API: new PrismaClient()
Changed in prisma 7.0.0 (2025-11-19), kind: removed
Model belief: "const prisma = new PrismaClient();" in tasks 1, 2, 3 and 5, with the mechanism stated explicitly: "The connection string itself isn't passed here ... PrismaClient picks it up automatically at instantiation."
Wrong: const prisma = new PrismaClient()
Correct: const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })
const prisma = new PrismaClient({ adapter })
Impact: Every runnable artefact in the run throws at construction on Prisma 7. This is the single highest-frequency stale prior the battery found.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "new PrismaClient() support has been removed"

--- F2 [S1 breaks-build] Generator block with no output path
API: generator client { output }
Changed in prisma 7.0.0 (2025-11-19), kind: requirement
Model belief: "generator client { provider = \"prisma-client-js\" }" with no `output`, and in question (d): "Generated client code goes to node_modules/.prisma/client by default."
Wrong: generator client {
  provider = "prisma-client-js"
}
Correct: generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}
Impact: `prisma generate` refuses before anything else in the setup can be tried.
Source: https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7 — "the output field is now required in the generator block. Prisma Client will no longer be generated in node_modules by default."

--- F3 [S3 deprecated] Uses the superseded generator provider throughout
API: provider = "prisma-client-js"
Changed in prisma 7.0.0 (2025-11-19), kind: deprecated
Model belief: `prisma-client-js` in every schema shown; the newer provider is never mentioned in any of the ten tasks.
Wrong: generator client {
  provider = "prisma-client-js"
}
Correct: generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}
Impact: Still functions in 7.x, with a stated removal ahead of it, and needs the extra `@prisma/client-runtime-utils` package once `output` is set.
Source: https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7 — "The older prisma-client-js provider will be removed in future releases of Prisma ORM."

--- F4 [S1 breaks-build] Imports PrismaClient from @prisma/client
API: import { PrismaClient } from '@prisma/client'
Changed in prisma 7.0.0 (2025-11-19), kind: behavior-changed
Model belief: "import { PrismaClient } from '@prisma/client';" in every file, and in (d): "@prisma/client re-exporting from there — which is why npx prisma generate has to run after every npm install".
Wrong: import { PrismaClient } from '@prisma/client'
Correct: import { PrismaClient } from './generated/prisma/client'
Impact: With the generated client now living in your own tree, the package import does not resolve to a client.
Source: https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7 — "// Before import { PrismaClient } from "@prisma/client" ; // After import { PrismaClient } from "./generated/prisma/client" ;"

--- F5 [S1 breaks-build] No config file at all; the datasource URL stays in schema.prisma
API: prisma.config.ts
Changed in prisma 7.0.0 (2025-11-19), kind: requirement
Model belief: Task 4 lists the files involved as `.env`, `prisma/schema.prisma`, the migrations directory and the generated client — no config file. In (d): "historically the only config file is schema.prisma itself", with `prisma.config.ts` recalled but explicitly held "with meaningfully less confidence than the rest of this answer".
Wrong: datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}
Correct: // prisma.config.ts
export default defineConfig({
  schema: 'prisma/schema.prisma',
  datasource: { url: env('DATABASE_URL') },
})
Impact: `prisma migrate` in 7.x requires the config file; the answer's exact migration commands have nothing to read a datasource from.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "prisma.config.ts is now required for projects looking to perform introspection and migration."

--- F6 [S2 silently-wrong] Assumes the CLI loads .env by itself
API: automatic .env loading
Changed in prisma 7.0.0 (2025-11-19), kind: behavior-changed
Model belief: "The string lives in .env as DATABASE_URL, referenced from prisma/schema.prisma via url = env(\"DATABASE_URL\")" — with no loading step anywhere in the run.
Wrong: # .env, read by the CLI automatically
DATABASE_URL="postgresql://..."
Correct: import 'dotenv/config'
import { defineConfig, env } from 'prisma/config'
Impact: The variable is simply unset when the CLI runs, and the error names the connection rather than the missing load.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "we're no longer automatically loading environment variables when invoking the Prisma CLI"

--- F7 [S1 breaks-build] Seed command declared in package.json, with the implicit-run claim attached
API: package.json prisma key
Changed in prisma 7.0.0 (2025-11-19), kind: removed
Model belief: "With that prisma.seed entry in place, the seed runs automatically whenever you run npx prisma migrate dev ... and whenever you run npx prisma migrate reset. No extra CI/dev wiring needed beyond that config block."
Wrong: {
  "prisma": {
    "seed": "ts-node prisma/seed.ts"
  }
}
Correct: // prisma.config.ts
export default defineConfig({
  migrations: { seed: 'tsx prisma/seed.ts' },
})
Impact: The key is not read, so the seed never runs — and the answer's closing promise is that no further wiring is needed.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "With the move to prisma.config.ts, this no longer makes sense and has been removed."

--- F8 [S2 silently-wrong] Relies on the postinstall hook to generate the client in Docker
API: postinstall prisma generate
Changed in prisma 7.0.0 (2025-11-19), kind: removed
Model belief: "the prisma/@prisma/client npm packages register a postinstall hook that runs prisma generate automatically when npm install sees a prisma/schema.prisma" — and, in task 1, "usually run automatically as a postinstall".
Wrong: RUN npm ci        # postinstall generates the client
Correct: RUN npm ci
RUN npx prisma generate
Impact: The Dockerfile it wrote does run `npx prisma generate` explicitly, so that artefact survives; the belief is charged because the run states the hook as a fact twice and offers it as the reason the step is optional.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "post-install hook would run prisma generate ... This behaviour has been removed in favor of explicitly requiring commands to be run by users."

--- F9 [S1 breaks-build] Recommends prisma generate --no-engine
API: prisma generate --no-engine
Changed in prisma 7.0.0 (2025-11-19), kind: removed
Model belief: "Generate a query-engine-free client (--no-engine on prisma generate) when pairing with Prisma Accelerate."
Wrong: npx prisma generate --no-engine
Correct: npx prisma generate
Impact: Unknown flag; the serverless build step fails.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "prisma generate --no-engine"

--- F10 [S2 silently-wrong] Whole deployment story built around a query-engine binary that no longer ships
API: engineType
Changed in prisma 7.0.0 (2025-11-19), kind: removed
Model belief: "The correct query-engine binary for the container's OS/libc must be available. If the base image is Alpine (musl) ... you must add the right binaryTargets", and "make sure your bundler treats @prisma/client/the engine as external ... which tends to break the binary lookup".
Wrong: generator client {
  provider      = "prisma-client-js"
  binaryTargets = ["native", "linux-musl-openssl-3.0.x"]
}
Correct: generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}
Impact: Sends a team hunting a libc/OpenSSL mismatch that cannot occur on 7.x, and frames the engine-free client as an optimisation rather than the only client there is.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "We've removed the following client engines: LibraryEngine (engineType = "library", the Node-API Client); BinaryEngine (engineType = "binary", the long-running executable binary)"

--- F11 [S1 breaks-build] migrate diff with the removed --from-url / --to-schema-datamodel flags
API: prisma migrate diff
Changed in prisma 7.0.0 (2025-11-19), kind: renamed
Model belief: "npx prisma migrate diff --from-url \"$DATABASE_URL\" --to-schema-datamodel prisma/schema.prisma --script", with a parenthetical listing the same removed flags as the general vocabulary of the command.
Wrong: npx prisma migrate diff \
  --from-url "$DATABASE_URL" \
  --to-schema-datamodel prisma/schema.prisma \
  --script
Correct: npx prisma migrate diff \
  --from-config-datasource \
  --to-schema prisma/schema.prisma \
  --script
Impact: Unknown-flag error, and no version of the command in the answer works.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "prisma --[from/to]-url , prisma --[from/to]-schema-datasource ... These are now replaced with --[from/to]-config-datasource"

--- F12 [S2 silently-wrong] States the generated enum object maps member names to themselves
API: generated enum values
Changed in prisma 7.0.0 (2025-11-19), kind: behavior-changed
Model belief: "The @maped string (\"mixplat/sms\") is what's actually stored in the underlying Postgres enum type; PaymentProvider.MIXPLAT_SMS is what you use in code", with the generated object shown as `MIXPLAT_SMS: 'MIXPLAT_SMS'`.
Wrong: export const PaymentProvider = {
  MIXPLAT_SMS: 'MIXPLAT_SMS',
  INTERNAL_TOKEN: 'INTERNAL_TOKEN'
} as const
Correct: export const PaymentProvider: {
  MixplatSMS: 'mixplat/sms'
  InternalToken: 'internal/token'
}
Impact: Silent: comparisons and serialised payloads carry the database value, not the member name.
Scope note: Charged against the generated shape 7.0.0 documents. The pre-7 shape is not separately verified; what is charged is the claim about today.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "We now support the @map attribute for enum members, which can be used to set their expected runtime values"

--- F13 [S4 wrong-metadata] Sets a MongoDB team up on a version that dropped MongoDB, with no version caveat
API: MongoDB support
Changed in prisma 7.0.0 (2025-11-19), kind: removed
Model belief: A full MongoDB schema and workflow with six caveats — replica sets, ObjectId mapping, emulated relations — and no mention that the current major does not support the database at all.
Wrong: datasource db {
  provider = "mongodb"
  url      = env("DATABASE_URL")
}
Correct: // MongoDB: stay on Prisma 6
//   npm i -D prisma@6 && npm i @prisma/client@6
Impact: The one question in the battery where the correct answer is "pin to the previous major", answered as though nothing had changed.
Source: https://github.com/prisma/prisma/releases/tag/7.0.0 (2025-11-19) — "Currently, MongoDB is not supported in Prisma 7. For folks using MongoDB, please stay on Prisma v6."

--- F14 [S4 wrong-metadata] Knowledge stops at 6.0.0 — fourteen months before its own stated cutoff
Changed in prisma 6.1.0 (2024-12-17), kind: version-fact
Chargeability: Anchored to 6.1.0 (2024-12-17), the first release whose contents the subject says it cannot describe, not to the current release. Thirty-odd further releases up to 7.2.0 (2025-12-17) precede the stated 2026-01 cutoff.
Model belief: "First release I know only as a bare version number, with no real idea what shipped in it: anything after roughly 6.1 ... I have no reliable knowledge of anything resembling a Prisma 7."
Impact: A major version, a mandatory config file and the removal of the no-argument constructor all sit inside the blind spot, which is why this run produces fourteen findings rather than the two or three a near-current subject produces.
Source: https://registry.npmjs.org/prisma — "6.1.0: 2024-12-17"

--- non-finding [correct]: Prisma 6.0 dated to "around November 2024" — 6.0.0 published 2024-11-28. The one version claim in the run that is exactly right.
--- non-finding [correct]: The v6 material itself is accurate and well-organised: the hot-reload singleton, `migrate deploy` rather than `migrate dev` in CI, the replica-set requirement for MongoDB transactions, `db push` for schemaless workflows. Nothing here is wrong for the version it belongs to.
--- non-finding [miss] prisma.config.ts: Question (d) recalled `prisma.config.ts` unprompted — "I recall Prisma introducing a standalone prisma.config.ts file at some point in the 6.x line" — and correctly named the seed command as one of its jobs.

==============================================================================
RUN tailwindcss--claude-fable-5-1--v3-a--2026-09-06
What Claude Fable 5.1 gets wrong about tailwindcss — battery v3-a, tested 2026-09-06
URL: https://stalepriors.com/runs/tailwindcss--claude-fable-5-1--v3-a--2026-09-06
JSON: https://stalepriors.com/data/tailwindcss/fable-5-1-v3-a.json
Library: tailwindcss 4.3.3 (npm), verified 2026-09-06
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06
Version attribution stops at: 4.1.0 (2025-04-01), lag ~14 months
Oldest release it could not place: 4.2.0 (2026-02-18)
Battery: tailwindcss/v3-a, 6 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The Index's first Claude Fable 5.1 findings outside valibot, and the tightest charging gap it has run: tailwindcss 4.3.0 shipped 2026-05-08, twenty-three days below this subject's stated June 2026 cutoff. Four charges — three S2 in the review direction (the scrollbar family, `@container-size`, `zoom-*`, each called inert in a pull request where every class compiles) and one S3 denial that the `@variant` at-rule accepts a stacked or comma-separated variant. Every workaround the draw offered was compiled against installed 4.2.4 and 4.3.0 and every one of them works, which is why the charges rest on the denials and the rejections and never on the code. The battery's guessing control came back clean — asked for a scrollbar-corner utility it correctly said none exists rather than inventing `scrollbar-corner-*` — and the poison rung was refused. Two of the four probes turned out to be DERIVABLE, and by the control nobody expected: Claude Sonnet 5, sixteen months under the release, wrote the correct `@variant hover:focus` and `@variant hover, focus, active` syntax and the correct `tab-*` scale, while Claude Opus 5 three weeks under it got both wrong. Derivability kills a pass, not a failure, so the charges stand; what it kills is this run's one correct answer inside the window.

--- F1 [S2 silently-wrong] Denies Tailwind ships scrollbar utilities, attributes the real class names to a third-party plugin, and rejects working markup that uses them
API: scrollbar-auto / scrollbar-thin / scrollbar-none / scrollbar-thumb-* / scrollbar-track-* / scrollbar-gutter-*
Changed in tailwindcss 4.3.0 (2026-05-08), kind: added
Chargeability: 4.3.0 shipped 2026-05-08; this draw states a June 2026 cutoff, so the release precedes it by twenty-three days. Tightest charging gap in the Index.
Model belief: Task 1(a), one word: "No". Then: "Tailwind core (v4.0 / v4.1.x, the releases I can actually describe) has no `scrollbar-width`, `scrollbar-color`, or `scrollbar-gutter` utilities. Those class names you may have seen (`scrollbar-thin`, `scrollbar-thumb-*`, `scrollbar-track-*`) come from the third-party `tailwind-scrollbar` plugin, not the framework." On task 3, reviewing markup that uses them: "`scrollbar-thin`, `scrollbar-thumb-slate-500`, `scrollbar-track-slate-100`, `scrollbar-gutter-stable` — none exist in core. These are `tailwind-scrollbar` plugin names, and the PR doesn't add the plugin."
Wrong: <!-- the review verdict: four inert classes, replace them -->
<div class="h-96 overflow-y-auto
            [scrollbar-width:thin]
            [scrollbar-color:var(--color-slate-500)_var(--color-slate-100)]
            [scrollbar-gutter:stable]">
Correct: <div class="h-96 overflow-y-auto scrollbar-thin scrollbar-thumb-slate-500 scrollbar-track-slate-100 scrollbar-gutter-stable">
Impact: The charge is the REVIEW direction, not the code. The arbitrary-property block this draw shipped in task 1 compiles and emits the identical declarations — verified against installed 4.2.4 and 4.3.0 — so a reader who takes only the task 1 answer loses verbosity and nothing else, which is S3 under the workaround rule. What lifts it to S2 is task 3: presented with working markup, this draw tells the author that four classes generate no CSS and are plugin names the project does not have installed. Every one of them compiles at 4.3.0 and 4.3.3. A reviewer acting on that deletes correct code, and the false claim that the names belong to `tailwind-scrollbar` sends the next reader to add a dependency the framework has made unnecessary.
Scope note: The draw's own arbitrary-property code was executed: `[scrollbar-width:thin]`, `[scrollbar-color:...]` and `[scrollbar-gutter:stable]` all compile at 4.2.4 and 4.3.0. Its browser-support caveats (Firefox/Chromium 121+, Safari ignoring the standard properties) were NOT verified and nothing in the charge rests on them. The denial was hedged ("If a release newer than what I know added them, I can't vouch for it"), which under HARNESS.md § *A hedge is a self-placement, not a grade on the content* is recorded but does not soften the verdict-first "No" or the task 3 review. PARTIAL DERIVABILITY, from this battery's own below-floor control: Claude Sonnet 5, sixteen months under the release, WROTE `scrollbar-thin scrollbar-thumb-slate-500 scrollbar-track-slate-100` in its task 1 markup — because `tailwind-scrollbar` has used those exact names for years. The names are derivable and the Index says so; `scrollbar-gutter-*` is not (no control produced it), and neither is the claim that the family is core. The charge rests on the denial and the rejection, never on the names.
Source: https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.3.0 (2026-05-08) — "Add `scrollbar-{auto,thin,none}` utilities for `scrollbar-width`, and `scrollbar-thumb-*` / `scrollbar-track-*` color utilities for `scrollbar-color`"
Source: https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.3.0 (2026-05-08) — "Add `scrollbar-gutter-*` utilities"
Source: https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.3.0.tgz
Source: https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.2.4.tgz

--- F2 [S2 silently-wrong] Rejects `@container-size` as not a core utility, in a review of markup where it compiles
API: @container-size
Changed in tailwindcss 4.3.0 (2026-05-08), kind: added
Chargeability: 4.3.0 (2026-05-08) precedes this draw's stated 2026-06 cutoff.
Model belief: Task 3: "`@container-size` — not a core utility as far as I know. Core has `@container` (`container-type: inline-size`), `@container-normal`, and named `@container/name`. If the section genuinely needs block-axis container queries, write `[container-type:size]`; otherwise use `@container`."
Wrong: <section class="[container-type:size]">
Correct: <section class="@container-size">
Impact: Working markup called out as inert in review. The suggested replacement compiles, so the reader's page still works; the cost is the deleted correct class and a reviewer's stated confidence about a utility that exists. NOTE THE CONTRAST INSIDE THIS BATTERY: Claude Opus 5, whose stated cutoff is in the same month as the release, accepted `@container-size` as valid in the same review task and gave its declaration correctly. That marks this probe DERIVABLE (JOURNAL/030) and no pass on it would have been reported as knowledge — but a derivable outcome kills a pass, not a failure (JOURNAL/031), so this rejection stands, and stands as the weaker of this run's charges for how easy the correct answer was to reach.
Scope note: `[container-type:size]`, the replacement this draw proposed, compiles at 4.2.4 and 4.3.0 — so does `@container-[size]`, which the blind twin proposed. The 4.3.0 addition is a shorthand for something already expressible, which is why this finding is about the review verdict and not about broken output.
Source: https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.3.0 (2026-05-08) — "Add `@container-size` utility"
Source: https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.3.0.tgz
Source: https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.2.4.tgz

--- F3 [S2 silently-wrong] Denies a `zoom-*` family exists and attributes the name to an animation plugin, rejecting working markup
API: zoom-*
Changed in tailwindcss 4.3.0 (2026-05-08), kind: added
Chargeability: 4.3.0 (2026-05-08) precedes this draw's stated 2026-06 cutoff.
Model belief: Task 3: "`zoom-50` — not a core utility that I know of. There's no `zoom-*` family (the `zoom-in-*`/`zoom-out-*` names people remember are from `tailwindcss-animate`). Write `[zoom:0.5]` if you really want the `zoom` property, or `scale-50 origin-top-left` if a transform is acceptable, which it usually is for a figure."
Wrong: <figure class="[zoom:0.5]">
Correct: <figure class="zoom-50">
Impact: Same review-direction cost as F1 and F2, with one extra wrinkle worth flagging: the two replacements offered are not equivalent to each other or to the original. `[zoom:0.5]` emits `zoom: 0.5` while `zoom-50` emits `zoom: 50%` (same computed value, different syntax), and `scale-50` is a transform — it does not reflow, where `zoom` does. A reviewer who takes the `scale-50` suggestion changes the layout behaviour of the element while believing they are fixing a dead class. This is the ONLY probe in the battery no arm answered correctly and no control derived.
Scope note: `[zoom:1.5]` and `scale-50` were both compiled at 4.2.4 and 4.3.0 and both emit CSS; the claim that they differ in reflow behaviour is a property of CSS `zoom` versus `scale`, not something this Index verified in a browser.
Source: https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.3.0 (2026-05-08) — "Add `zoom-*` utilities"
Source: https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.3.0.tgz
Source: https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.2.4.tgz

--- F4 [S3 deprecated] Denies `@variant` accepts a stacked or comma-separated variant, and writes the block out three times for the OR case
API: @variant (stacked and compound variants)
Changed in tailwindcss 4.3.0 (2026-05-08), kind: added
Chargeability: 4.3.0 (2026-05-08) precedes this draw's stated 2026-06 cutoff.
Model belief: Task 4(a), one word: "No". Then: "In v4, `@variant` (the applying form; `@custom-variant` is the defining form) takes a single variant name per at-rule. You get combined conditions by nesting; you get \"or\" by writing separate blocks (or by falling back to plain CSS selectors). I'm not certain a stacked form like `@variant hover:focus` is rejected rather than parsed, but I wouldn't ship on it."
Wrong: @variant hover {
  @variant focus { outline: 2px solid var(--color-slate-400); }
}

@variant hover  { border-color: var(--color-slate-400); }
@variant focus  { border-color: var(--color-slate-400); }
@variant active { border-color: var(--color-slate-400); }
Correct: @variant hover:focus { outline: 2px solid var(--color-slate-400); }

@variant hover, focus, active { border-color: var(--color-slate-400); }
Impact: S3, and the severity is the interesting part. The nested workaround this draw wrote for the AND case compiles at 4.3.0 to output BYTE-IDENTICAL to the stacked form — verified — so that half costs nothing but keystrokes. The OR case has no nested equivalent (nesting is AND, the comma is OR), so the draw repeats the declaration block three times; that is still working CSS, which keeps the finding at S3 rather than S2. The draw notices the smell itself and recommends dropping the at-rule for plain `&:is(:hover, :focus, :active)` — a reasonable suggestion built on a false premise about what the at-rule can do.
Scope note: The nested and stacked forms were compiled at 4.3.0 and their output compared: identical. At 4.2.4 the stacked and compound forms throw a hard build error, so this belief was exactly right for the release line the subject can describe and exactly wrong for the one under test. THIS PROBE IS DERIVABLE and the control that showed it is the one furthest below the floor: Claude Sonnet 5 answered task 4(a) "Yes" and wrote both `@variant hover:focus` and `@variant hover, focus, active` correctly, sixteen months under the release. A derivable outcome kills a pass, not a failure, so the charge stands — but no pass on this probe anywhere in the Index may be read as recall.
Source: https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.3.0 (2026-05-08) — "Allow using `@variant` with stacked variants (e.g. `@variant hover:focus { … }`)"
Source: https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.3.0 (2026-05-08) — "Allow using `@variant` with compound variants (e.g. `@variant hover, focus { … }`)"
Source: https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.3.0.tgz
Source: https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.2.4.tgz

--- non-finding [correct] tab-*: TASK 3, `tab-4`: accepted as real, with the correct declaration — "`tab-4` — fine. `tab-<number>` is a core utility in v4 and emits `tab-size: 4`." It is: `tab-*` arrived at 4.3.0 and compiles to `tab-size: 4` at 4.3.0 and 4.3.3, to nothing at 4.1.0 and 4.2.4. This looked like the battery's sharpest result until the below-floor control was read: Claude Sonnet 5, sixteen months under the release, also called `tab-4` valid AND listed the scale (`tab-1`, `tab-2`, `tab-4`, `tab-8`, `tab-[value]`, plus an invented `tab-inherit` that compiles to nothing at any version). The probe is therefore DERIVABLE and this pass is NOT reported as knowledge (JOURNAL/030, /031). What survives is narrower and still worth the line: this draw's blind twin, sent the same stored prompt, denied `tab-4` outright — so the subject is not stable on it either way.
--- non-finding [correct] scrollbar-corner-*: TASK 2, the internal guessing control: no invention. Asked how to tint the scrollbar corner, this draw said plainly that the framework does not cover it, reached for the arbitrary variant `[&::-webkit-scrollbar-corner]:bg-slate-100`, and volunteered that the rule will often do nothing because Chromium ignores the WebKit pseudo-elements once the standard properties are set. `scrollbar-corner-*` does not exist at 4.2.4, 4.3.0 or 4.3.3 and this draw did not invent it. No arm in the battery did — P3 falsified 0/4.
--- non-finding [correct] overflow-anchor: TASK 6, the poison rung: refused. "I don't know of any release that added `overflow-anchor` utilities... If you need it today: `[overflow-anchor:none]`. The question presupposes a release I can't confirm; I'd treat my answer as 'unknown,' not 'it doesn't exist.'" No release added them; the correct answer is a refusal, and the offered arbitrary property compiles. P5 held on this arm and on all four.
--- non-finding [context]: TASK 5, attribution: refused, correctly for a subject that does not hold the capability — "I can't name a release that changed this. If one exists, it's newer than my usable knowledge, and I'd rather say that than invent a version number." Under JOURNAL/030 an attribution question about a behaviour the subject does not hold measures nothing independent, so this is recorded and not scored.
--- non-finding [context]: BOUNDARY. Most recent describable release 4.1.0 (2025-04-01); first release known only as a version number 4.2 (4.2.0 shipped 2026-02-18). Against a stated cutoff of 2026-06 that is a fourteen-month lag — the second library on which this subject's usable knowledge stops roughly thirteen to fourteen months below its stated cutoff (valibot: 1.1.0, thirteen months, JOURNAL/055). Two libraries is not a law, but it is the first evidence that the lag is not valibot-specific. P6 held on all four arms.

==============================================================================
RUN tailwindcss--claude-fable-5-1--v3-b--2026-09-06
What Claude Fable 5.1 gets right about tailwindcss — battery v3-b, tested 2026-09-06
URL: https://stalepriors.com/runs/tailwindcss--claude-fable-5-1--v3-b--2026-09-06
JSON: https://stalepriors.com/data/tailwindcss/fable-5-1-v3-b.json
Library: tailwindcss 4.3.3 (npm), verified 2026-09-06
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06
Version attribution stops at: 4.1.0 (2025-04-01), lag ~14 months
Oldest release it could not place: 4.2.0 (2026-02-18)
Battery: tailwindcss/v3-b, 6 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The blind twin, charging nothing by pre-registration, and it reproduces its sibling almost exactly: "No" to both verdict-first questions, the same rejection of the same seven-class pull request, the same clean answer on the guessing control, the same refusal of the poison rung, the same boundary at 4.1.0 with 4.2 as the first release it knows only as a number. The pair disagrees on exactly one class. `tab-4` — a 4.3.0 addition — was accepted by the charging twin and denied here, which leaves a reproduced in-window failure of this subject that no run in the Index charges, flagged and counted as an undercount rather than chased with a third draw. This draw also produced the battery's most explicit self-placement: it identified the shape of the release under test as a category ("scrollbar-*, tab-size, zoom, container-size"), said the build output was the arbiter and not itself, and then attributed the whole category to 4.2. It is 4.3.0.

--- non-finding [miss] scrollbar-auto / scrollbar-thin / scrollbar-none / scrollbar-thumb-* / scrollbar-track-* / scrollbar-gutter-*: TASK 1(a) "No", and task 3: "`scrollbar-thin`, `scrollbar-thumb-slate-500`, `scrollbar-track-slate-100` — these are `tailwind-scrollbar` plugin classes. With no plugin installed they produce no CSS." Same denial and same review rejection as the charging twin, on a release inside this draw's own stated window.
--- non-finding [miss] @container-size: TASK 3: "`@container-size` — I don't know this one. Core ships `@container`... For `container-type: size` I'd write `@container-[size]`." The replacement compiles at 4.2.4 and 4.3.0; the verdict on the real class is wrong.
--- non-finding [miss] zoom-*: TASK 3: "`zoom-50` — no `zoom` utilities in core that I know of. `[zoom:0.5]`, though I'd push back on using `zoom` at all and ask whether `scale-50` (transform) does what they want."
--- non-finding [miss] @variant (stacked and compound variants): TASK 4(a) "No": "As far as I know, `@variant` takes one variant name. For a combined condition you nest; for an OR you write separate blocks." Wrote the nested AND block and then repeated the OR declaration three times, exactly as its twin did.
--- non-finding [miss] tab-*: TASK 3, `tab-4`: "I know of no `tab-size` utilities in core. `[tab-size:4]`." THIS IS THE PAIR'S ONE DISAGREEMENT. The charging twin accepted `tab-4` as real with the correct declaration; this twin denied it, on the same stored prompt sent at the same moment. There is no sibling run to point at, because the arm that charges got this one right.
--- non-finding [correct] scrollbar-corner-*: TASK 2, the internal guessing control: no invention of `scrollbar-corner-*`. This draw named the pseudo-element correctly, defined its own `@custom-variant scrollbar-corner (&::-webkit-scrollbar-corner)` — which is user-defined syntax, not a claimed core utility — and gave the same accurate Chromium precedence caveat as its twin.
--- non-finding [correct] overflow-anchor: TASK 6, the poison rung: refused. "I don't know of any Tailwind release that added `overflow-anchor` utilities... I'd write `[overflow-anchor:none]`. I'm not going to guess a version number."
--- non-finding [context]: This draw closed its review with an unusually explicit self-placement: "the set of classes in that PR looks like exactly the shape a newer core release might add (scrollbar-*, tab-size, zoom, container-size). If the project is on a release newer than I know, some of them may be real; the build output is the arbiter, not me." It identified the battery's target correctly as a category while getting every member of it wrong, then repeated the point in the direct questions: "If the scrollbar, `overflow-anchor`, `tab-size`, `zoom`, or multi-variant `@variant` features in these tasks are real, that's most likely where they live" — naming 4.2 as the release. It is 4.3.0. Under HARNESS.md § *A hedge is a self-placement, not a grade on the content* this changes no verdict; it is the sharpest instance of the self-known gap the tailwindcss batteries were built to look at (`tailwindcss/v2`, JOURNAL/043).
--- non-finding [context]: BOUNDARY, identical to the twin: most recent describable 4.1.0 (2025-04-01), first release known only as a number 4.2 (2026-02-18), stated cutoff 2026-06, fourteen-month lag. A different battery is not a different boundary (JOURNAL/030) and this is the first tailwindcss measurement of this subject; it agrees with its twin exactly.

==============================================================================
RUN tailwindcss--claude-fable-5--v2-d--2026-09-03
What Claude Fable 5 gets right about tailwindcss — battery v2-d, tested 2026-09-03
URL: https://stalepriors.com/runs/tailwindcss--claude-fable-5--v2-d--2026-09-03
JSON: https://stalepriors.com/data/tailwindcss/fable-5-v2-d.json
Library: tailwindcss 4.3.3 (npm), verified 2026-09-03
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 4.1.0 (2025-04-01), lag ~9 months
Oldest release it could not place: 4.2.0 (2026-02-18)
Battery: tailwindcss/v2-d, 6 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: The second below-floor control, and the best-informed draw in the battery about everything except the release under test. It denied the 4.2.0 family like the other three - "there is no pbs-*, pbe-*, mbe-*, or border-bs-*" - and rejected the same pull request. But it was the only arm of four to know that v4 re-implemented the PAIRED axis utilities on logical shorthands, and it was right: px-*, py-*, mx-*, my-*, inset-x-* and inset-y-* really do emit padding-inline, padding-block, margin-inline, margin-block, inset-inline and inset-block at 4.2.0, all six verified against the installed engine. It used that correct knowledge to give a partly working answer - py-6 genuinely is the block-axis padding pair - and to explain precisely which cases were left uncovered. It also produced the battery's sharpest sentence about its own error, unprompted: the invented-looking names "are exactly the kind of API an AI or a developer coming from another ecosystem might guess Tailwind has. It doesn't." P2 is confirmed on this arm as on the other control: nothing in the battery is derivable from seven weeks below the floor. Nothing is chargeable here.

--- non-finding [context] logical property utilities: P2 CONFIRMED on the second control arm. Seven weeks below 4.2.0, this draw produced none of the target names and stated positively that they exist in no release: "pbs-6, pbe-6, mbe-4, border-bs-2, inline-full, and max-block-96 are not Tailwind utilities in any release, v4 included." Both control arms agree, so neither the block-axis probe nor the logical-sizing probe is DERIVABLE from below the floor.
--- non-finding [correct] px-* / py-* / mx-* / my-* / inset-x-* / inset-y-*: Knew something the three other arms did not, and it checks out. "py-6 generates padding-block: calc(var(--spacing) * 6) (not padding-top/padding-bottom), and px-* generates padding-inline ... and I believe inset-x/inset-y -> inset-inline/inset-block." All six compiled against installed 4.2.0: py-6 -> padding-block, px-6 -> padding-inline, my-4 -> margin-block, mx-4 -> margin-inline, inset-x-0 -> inset-inline, inset-y-0 -> inset-block. Its hedge on the inset pair was unnecessary. This makes its denial the best-reasoned in the battery - it knew exactly which half of the logical surface v4 covered and concluded, wrongly, that the single-edge half was still missing.
--- non-finding [miss] logical property utilities: Denies the 4.2.0 single-edge block-axis and logical-sizing utilities and rejects the working pull request, telling the author "all six classes generate no CSS at all" and that this is "the worst kind of failure: the diff looks plausible and CI stays green". All six compile at 4.2.0.
--- non-finding [miss] logical inset utilities: States start-*/end-* are current and not legacy, and recommends inset-x-0 as the modern alternative. The current spelling as of 4.2.0 is inset-s-0 / inset-e-0. Note that its inset-x-0 suggestion is correct CSS for this snippet - it compiles to inset-inline: 0, which is what start-0 end-0 together produce - so the advice works and is merely out of date.
--- non-finding [correct] ps-* / me-*: Cleared the internal guessing control with `ps-6 me-4`. Fourth of four arms to clear it: not one draw over-generalised the naming scheme into pis-*/mie-*, which exist at no release.
--- non-finding [context]: Named the mechanism the battery was measuring, while inside it. Reviewing the PR: the names "look like abbreviations of the CSS logical property names (padding-block-start -> pbs), which is a naming convention some other tools use - and exactly the kind of API an AI or a developer coming from another ecosystem might guess Tailwind has. It doesn't." It correctly identified that other tools use the convention (tailwindcss-logical does, as the v2-b twin named outright), correctly identified guessing as the risk, and then landed on the wrong side of it.

==============================================================================
RUN tailwindcss--claude-fable-5--v1--2026-08-31
What Claude Fable 5 gets right about tailwindcss — battery v1, tested 2026-08-31
URL: https://stalepriors.com/runs/tailwindcss--claude-fable-5--v1--2026-08-31
JSON: https://stalepriors.com/data/tailwindcss/fable-5.json
Library: tailwindcss 4.3.3 (npm), verified 2026-08-31
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 4.1.0 (2025-04-01), lag ~9 months
Oldest release it could not place: 4.2.0 (2026-02-18)
Battery: tailwindcss/v1, 10 tasks, tool uses during test: 0
Tested: 2026-08-31

Summary: Zero findings, and the most consistently version-aware run of the three: every task that had a v3 form volunteered the v3 form explicitly labelled as v3, after giving the v4 answer. Version attribution stops at 4.1.0 (2025-04-01), nine months before its stated cutoff — the same boundary as Sonnet 5 and Opus 5 on this library, and the same boundary all three models show on zod. With zero findings, nothing in the code contradicts its post-4.1 knowledge; what the run measures is that it cannot say what shipped after 4.1.0. On Tailwind that boundary costs nothing, because every breaking change in the current major shipped at 4.0.0, three months before it.

--- non-finding [correct] @tailwind base / @tailwind components / @tailwind utilities: Task 1: `@tailwindcss/vite` plugin plus `@import "tailwindcss";`, then spelled out the v3 path it was NOT using — "no tailwind.config.js, no postcss.config.js, no content array, no npx tailwindcss init" — and gave the v3 commands for contrast. This is the behaviour the code-vs-claim rule is meant to reward: v4 leads, v3 is labelled legacy.
--- non-finding [correct] tailwind.config.js: Task 2: `@theme` with --color-brand and --font-display, and named the v3 equivalent (theme.extend.colors.brand) as the v3 equivalent.
--- non-finding [correct] @layer utilities / @layer components (for defining custom classes): Task 3: `@utility tab-4`. Correctly noted that in v3 an @layer utilities rule did get variant support — which is true of v3 and is exactly the behaviour v4 removed.
--- non-finding [correct] safelist / corePlugins / separator: Task 4: `@source inline(...)` including the range form `text-slate-{100..900..100}`, verified against the docs. Named safelist explicitly as the v3 equivalent, and recommended the static lookup map as the better fix.
--- non-finding [correct] flex-shrink-* / flex-grow-* / overflow-ellipsis / decoration-slice / decoration-clone: Task 5: `shrink-0`, `flex-1`, `min-w-0`, with the min-width:auto explanation.
--- non-finding [correct] bg-opacity-* / text-opacity-* / border-opacity-* / ring-opacity-* / placeholder-opacity-* / divide-opacity-*: Task 6: `bg-black/50`.
--- non-finding [correct] bg-[--var] (CSS variable shorthand in arbitrary values): Task 7: `bg-[var(--brand)]` as the primary answer and `bg-(--brand)` named as the v4 shorthand. Both work on 4.x.
--- non-finding [correct] border / divide (default colour): Task 8: currentColor border default correctly attributed to v4 with gray-200 as the v3 behaviour, and the shadow scale rename stated in both directions (v4 shadow-sm == v3 shadow; v3 shadow-sm == v4 shadow-xs).
--- non-finding [correct] ring: Task 9: bare ring is 1px currentColor in v4, 3px blue-500/50 in v3, plus the correct restoration (`ring-3 ring-blue-500/50`). Also reached for focus-visible rather than focus unprompted.
--- non-finding [correct] @apply inside Vue/Svelte/Astro <style> blocks and CSS modules: Task 10: `@reference "../assets/main.css"` in the SFC style block, with the correct reason and the correct note that v3 needed no such thing.
--- non-finding [imprecision] bg-opacity-* / text-opacity-* / border-opacity-* / ring-opacity-* / placeholder-opacity-* / divide-opacity-*: Task 6: described `bg-black bg-opacity-50` as what "in older v2-era code you'd see". The opacity utilities were v3 utilities too — they were removed in 4.0.0, not before it. The generated code was correct and the model never suggested using them, so this is a dating slip in an aside, not a finding.
--- non-finding [context]: Question (a): named v4.1/April 2025 as its describable boundary and disclosed that a newer minor may have shipped. Same boundary as the other two subjects.

==============================================================================
RUN tailwindcss--claude-opus-5--v2-a--2026-09-03
What Claude Opus 5 gets wrong about tailwindcss — battery v2-a, tested 2026-09-03
URL: https://stalepriors.com/runs/tailwindcss--claude-opus-5--v2-a--2026-09-03
JSON: https://stalepriors.com/data/tailwindcss/opus-5-v2-a.json
Library: tailwindcss 4.3.3 (npm), verified 2026-09-03
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 4.1.0 (2025-04-01), lag ~13 months
Oldest release it could not place: 4.2.0 (2026-02-18)
Battery: tailwindcss/v2-a, 6 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: The charging arm of the battery that tested whether a self-known gap changes the code. In v1 this same subject volunteered that it could not describe anything past 4.1.0 and that a 4.2 probably existed - and it says so again here, twice, in the version answers. It then denied the 4.2.0 logical-property family exists ("No" to both capability questions), and in the pull-request review told a colleague that six classes which all compile generate no CSS, that "None of them exist in Tailwind", and that there are no block-axis or inline-size/block-size utilities "in any release". Charged as F1 (S2): the artefact is a rejected-correct PR, verified by building every one of those six classes with the installed 4.2.0 and 4.3.3 engines. F2 (S3) charges the other half of the same release - it stated that start-*/end-* are "not a deprecated spelling" and that "nothing was renamed or removed in v4", where 4.2.0 deprecated both in favour of inset-s-*/inset-e-*. The battery's internal guessing control cleared it: asked the identical question about the inline axis it answered ps-6 / me-4, the real utilities, and did not over-generalise the naming scheme into the pis-*/mie-* names that exist at no release. So the denial is a belief about the block axis and not an artefact of the probe's naming. The sharpest detail is its own proposed safety net: it told the colleague that @apply would have caught this with "Cannot apply unknown utility class". That error string is exactly right for 4.1.0 and exactly wrong for 4.2.0, where the same @apply line compiles.

--- F1 [S2 silently-wrong] Denies the 4.2.0 block-axis and logical-sizing utilities exist, and rejects working markup that uses them
API: logical property utilities
Changed in tailwindcss 4.2.0 (2026-02-18), kind: added
Chargeability: 4.2.0 was published 2026-02-18, roughly two and a half months before this draw's stated cutoff of May 2026, which it accepted. Inside the fairness window. The workaround rule (HARNESS.md, JOURNAL/030) is why the charge rests on task 3 and the two one-word denials rather than on the code: the arbitrary properties this draw wrote instead do compile and emit the same declarations, and correct code that a first-class API supersedes is not a finding. Denial and rejection are.
Model belief: Task 1(a), one word: "No", then "There is nothing first-class for padding-block-start, margin-block-end, or border-block-start-width." Task 2(a), one word: "No", then "There are no inline-size / block-size utilities." Task 3, reviewing a colleague's pull request: "Every class on that line generates no CSS: pbs-6, pbe-6, mbe-4, border-bs-2, inline-full, max-block-96. None of them exist in Tailwind." And in the review comment it would post: "all six classes are invented ... there are no block-axis or inline-size/block-size utilities in any release." It recommended the colleague define them as custom @utility rules and turn on IntelliSense to catch the mistake, and added that inside @apply "v4 would have failed the build with 'Cannot apply unknown utility class.'" Task 6: "no meaningful change in about three years, and the block axis has never been covered."
Wrong: <!-- what it told the PR author their line does: nothing -->
<article class="pbs-6 pbe-6 mbe-4 border-bs-2 inline-full max-block-96">
<!-- and what it told them to write instead -->
<article class="[padding-block-start:--spacing(6)] [padding-block-end:--spacing(6)] [margin-block-end:--spacing(4)] [border-block-start-width:2px]">
Correct: <!-- the reviewed line is correct as written, from 4.2.0 -->
<article class="pbs-6 pbe-6 mbe-4 border-bs-2 inline-full max-block-96">
Impact: A reviewer acting on this deletes working markup. Every one of the six classes was built one at a time against installed tailwindcss 4.2.0 and 4.3.3 and every one emits its declaration: pbs-6 -> padding-block-start: calc(var(--spacing) * 6); pbe-6 -> padding-block-end; mbe-4 -> margin-block-end; border-bs-2 -> border-block-start-width: 2px; inline-full -> inline-size: 100%; max-block-96 -> max-block-size: calc(var(--spacing) * 96). None of them emits anything at 4.1.0, which is where this subject's knowledge stops. The draw also names the test that refutes it: `.card { @apply pbs-6 border-bs-2 inline-full; }` throws "Cannot apply unknown utility class: pbs-6" at 4.1.0 - the exact string quoted - and compiles to the three declarations at 4.2.0 and 4.3.3.
Scope note: One finding, not three, because tasks 1, 2 and 3 probe one belief in both directions (the offer shape and the recognition shape, per HARNESS.md / JOURNAL/033) and the pack carries one fact for the family. Severity is taken from the harmful direction: the denial alone would be S3, since a reader who writes the arbitrary properties this draw offered gets working CSS.
Source: https://raw.githubusercontent.com/tailwindlabs/tailwindcss/main/CHANGELOG.md (2026-02-18) — "Add `pbs-*` and `pbe-*` utilities for `padding-block-start` and `padding-block-end`"
Source: https://raw.githubusercontent.com/tailwindlabs/tailwindcss/main/CHANGELOG.md (2026-02-18) — "Add `inline-*`, `min-inline-*`, `max-inline-*` utilities for `inline-size`, `min-inline-size`, and `max-inline-size`"
Source: https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.2.0.tgz
Source: https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.1.0.tgz

--- F2 [S3 deprecated] States start-*/end-* are current and explicitly not deprecated, two releases after 4.2.0 deprecated them
API: logical inset utilities
Changed in tailwindcss 4.2.0 (2026-02-18), kind: deprecated
Chargeability: Same window as F1 and the same stated cutoff. S3 rather than S2 because the deprecation is a real deprecation: the compiler still builds start-0 and end-0 and emits the same declarations as inset-s-0 / inset-e-0, so nobody's page breaks. A draw claiming the opposite - that start-0 emits nothing - would be S2, and this draw does not claim that.
Model belief: Task 5(a): "Yes - that's still idiomatic. start-* / end-* are the logical inset utilities (inset-inline-start / inset-inline-end), not a deprecated spelling." (b): "It works ... Nothing was renamed or removed in v4." (c): "The same thing. absolute start-0 end-0." Task 6 repeats it: the last substantive change to logical properties was v3.3 in March 2023.
Wrong: <div class="absolute start-0 end-0"></div>
Correct: <div class="absolute inset-s-0 inset-e-0"></div>
Impact: Low. The old spelling still compiles - verified at 4.2.0, where start-0 and inset-s-0 emit the identical declaration - so this is advice that is out of date rather than advice that breaks a page. What it costs is the migration: a codebase written on this answer keeps growing uses of a deprecated utility, and the draw states positively that there is nothing to migrate to.
Source: https://raw.githubusercontent.com/tailwindlabs/tailwindcss/main/CHANGELOG.md (2026-02-18) — "Deprecate `start-*` and `end-*` utilities in favor of `inset-s-*` and `inset-e-*` utilities"
Source: https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.2.0.tgz

--- non-finding [correct] ps-* / me-*: The internal guessing control cleared this draw. Task 4 asked the identical question about the inline axis and it answered `ps-6 me-4` - the real v3-era utilities - without reaching for `pis-*` or `mie-*`, which are absent from 4.1.0, 4.2.0 and 4.3.3 alike and compile to nothing at all three. So this subject holds the inline half of the family precisely and denies the block half specifically. The denial in F1 is a belief about which utilities exist, not an artefact of the probe's naming scheme.
--- non-finding [correct] arbitrary properties / @utility: Every workaround it offered actually works, and that is why F1 is charged on the denial rather than on the code. `[padding-block-start:--spacing(6)]`, `[inline-size:100%]` and `[max-block-size:24rem]` were all compiled against installed 4.2.0 and emit the expected declarations, and the `@utility pbs-* { padding-block-start: --spacing(--value(integer)); }` form it proposed is valid v4 syntax. Under the workaround rule (JOURNAL/030) none of that is chargeable.
--- non-finding [context]: Version recency reproduces v1 exactly and is NOT re-charged here. This draw again places its last describable release at 4.1 (April 2025) and names 4.2 as the first release it knows only as a number, against a stated cutoff of May 2026 - the same thirteen-month lag v1 charged as its F1 (S4). A boundary belongs to the run that first measured it and a second battery reproducing it is context, never a new finding (HARNESS.md, JOURNAL/030). Pre-registered as P5 and confirmed.
--- non-finding [context]: The hedge and the code came apart, and the battery existed to find out whether they would. On the version questions this draw is careful twice - "if block-axis utilities landed in a release I can't describe, I wouldn't know. Check the changelog before you commit to hand-rolling the @utility block" - and on task 3, two tasks earlier, it wrote an unhedged pull-request review calling six working classes invented and recommending a linter to catch them. Knowing where your knowledge stops changed what it said about versions and did not change what it wrote about code.

==============================================================================
RUN tailwindcss--claude-opus-5--v2-b--2026-09-03
What Claude Opus 5 gets right about tailwindcss — battery v2-b, tested 2026-09-03
URL: https://stalepriors.com/runs/tailwindcss--claude-opus-5--v2-b--2026-09-03
JSON: https://stalepriors.com/data/tailwindcss/opus-5-v2-b.json
Library: tailwindcss 4.3.3 (npm), verified 2026-09-03
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 4.1.0 (2025-04-01), lag ~13 months
Oldest release it could not place: 4.2.0 (2026-02-18)
Battery: tailwindcss/v2-b, 6 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: The blind twin, sent the identical stored prompt concurrently, and it charges nothing by rule. It reproduced its sibling exactly on the substance - "No" to both capability questions, and a pull-request review stating "It compiles, and it produces nothing. Every single class on that line is unrecognized" with all six listed in a table - so both misses are recorded here as chargeable_miss pointing at v2-a. Two things this draw did that its sibling did not, and the first is the most interesting result in the battery. It attributed the six class names to a specific third-party package: "I think these came from the tailwindcss-logical plugin, which does use pbs/pbe/mbe/bs/is naming." That is correct and was verified - tailwindcss-logical 4.1.0, published 2025-11-10, more than three months before core 4.2.0 and inside this subject's window, ships pbs, pbe, mbs, mbe and border-bs. The draw identified precisely where those names live in the ecosystem and used that correct knowledge to conclude they were not in core. Right about the history, wrong about the present, for the third library in this Index. Second, it hedged harder than any draw the Index has recorded - "the framing of this question makes me suspect you know something I don't ... my No answers in Tasks 1 and 2 would be wrong" - and still filed the unhedged review. Nothing here reverses the pair: on this battery both twins agreed, which is the first time in five duplicated batteries that the -b draw did not hold the better answer.

--- non-finding [miss] logical property utilities: Denies the 4.2.0 block-axis and logical-sizing utilities exist and rejects working markup that uses them. Task 1(a) "No", task 2(a) "No", and task 3: "It compiles, and it produces nothing. Every single class on that line is unrecognized", with pbs-6, pbe-6, mbe-4, border-bs-2, inline-full and max-block-96 each tabulated as generating none. All six compile at 4.2.0 and 4.3.3, verified by building each one against the installed engine. Identical to v2-a F1.
--- non-finding [miss] logical inset utilities: States start-*/end-* are current and not deprecated: "Yes, that's still the current idiom ... These were added in v3.3 and were not removed or renamed in v4 - no deprecation I'm aware of." 4.2.0 deprecated both in favour of inset-s-*/inset-e-*. Identical to v2-a F2.
--- non-finding [correct] tailwindcss-logical (third-party plugin): Right about the ecosystem, and it is worth stating on its own because the Index has been looking for this shape. Reviewing the PR, this draw wrote: "I think these came from the tailwindcss-logical plugin, which does use pbs/pbe/mbe/bs/is naming; Tailwind core only ships logical utilities for the inline axis." The first clause is exactly right - tailwindcss-logical 4.1.0 (published 2025-11-10, inside this subject's window) registers pbs, pbe, mbs, mbe and border-bs, and uses is-*/bs-* for logical sizing where core 4.2.0 chose inline-*/block-*. This is not a confabulated history: the package exists, the names are there, and the dating works. The subject located the names correctly in the ecosystem and drew the wrong conclusion about core from it.
--- non-finding [correct] ps-* / me-*: The internal guessing control cleared this draw too: task 4 answered `ps-6 me-4`, the real inline-axis utilities, with no reach for the non-existent pis-*/mie-* names. Second of four arms to clear it.
--- non-finding [context]: The strongest hedge in the Index, filed alongside an unhedged rejection. Task 6: "the framing of this question makes me suspect you know something I don't. If Tailwind added pbs-*/bs-*/is-* in a release after my knowledge thins out, I would not know, and my No answers in Tasks 1 and 2 would be wrong. Please check the current release notes before acting on those two answers." That is a subject correctly modelling its own gap, in the same transcript in which it told a colleague their working markup was invented and recommended installing IntelliSense to catch it. The hedge attached to the version question and not to the code review.
--- non-finding [context]: The blind twins agreed. Both stated 2026-05, both stopped at 4.1, both named 4.2 as the first release known only as a number, both answered No/No, both rejected the PR, both got task 4 right. This is the fifth battery run as an -a/-b pair and the first in which the -b draw did not hold the better answer on some component - the running four-of-four noted in HARNESS.md is now four of five.

==============================================================================
RUN tailwindcss--claude-opus-5--v3-c--2026-09-06
What Claude Opus 5 gets right about tailwindcss — battery v3-c, tested 2026-09-06
URL: https://stalepriors.com/runs/tailwindcss--claude-opus-5--v3-c--2026-09-06
JSON: https://stalepriors.com/data/tailwindcss/opus-5-v3-c.json
Library: tailwindcss 4.3.3 (npm), verified 2026-09-06
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 4.1.0 (2025-04-01), lag ~13 months
Oldest release it could not place: 4.2.0 (2026-02-18)
Battery: tailwindcss/v3-c, 6 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The parked control, three weeks from being a test arm and charging nothing by pre-registration — 4.3.0 shipped in the same month this subject states as its cutoff. It denies the scrollbar family in the same terms as both Fable 5.1 draws, denies `tab-*` and `zoom-*`, and denies that `@variant` takes more than one variant; none of it is billable and none of it is counted as an undercount, because the failure sits outside the fairness window rather than inside it and unbilled. Its one correct answer inside the window is `@container-size`, accepted as valid with the right declaration and sound advice about size containment, which marks that probe DERIVABLE and demotes the corresponding pass everywhere in the battery. The arm also produced the battery's clearest articulation of what these controls are for: "I'd treat my silence about post-4.1 releases as ignorance rather than evidence that nothing shipped."

--- non-finding [correct] @container-size: TASK 3, `@container-size`: accepted as valid with the correct declaration — "Valid. `container-type: size`" — and followed with accurate advice that `container-type: size` requires size containment on both axes so a bare `<section>` usually is not what you want. This is a 4.3.0 addition and this subject's cutoff is the same month, so the answer is BELOW-FLOOR-OR-SAME-MONTH and marks the probe DERIVABLE per component (JOURNAL/030). It is also the obvious derivation: `@container` already existed, `container-type: size` is the CSS, and `@container-[size]` was already legal at 4.2.4. Consequence, applied: no pass on `@container-size` anywhere in this battery is reported as knowledge, and `v3-a`'s F2 survives, because a derivable outcome kills a pass and not a failure (JOURNAL/031).
--- non-finding [miss] scrollbar-auto / scrollbar-thin / scrollbar-none / scrollbar-thumb-* / scrollbar-track-* / scrollbar-gutter-*: TASK 1(a) "no", with the plugin attribution: "Nothing in Tailwind core generates `scrollbar-width`, `scrollbar-color`, or `scrollbar-gutter`. What you're thinking of is the third-party `tailwind-scrollbar` plugin." Task 3 marks all four scrollbar classes "No CSS", adding of `scrollbar-gutter-stable` that it is "Not in core, and not in the plugin either".
--- non-finding [miss] tab-* / zoom-* / @variant (stacked and compound variants): TASK 3: "`tab-4` — No CSS. Tailwind has no `tab-size` utilities." and "`zoom-50` — No CSS. `zoom-in-50` is from `tailwindcss-animate`... Core has no `zoom-*`." Both are 4.3.0 additions. TASK 4(a) "no", with the single-variant claim and a `@custom-variant interactive` block for the OR case.
--- non-finding [correct] scrollbar-corner-*: TASK 2, the internal guessing control: no invention. "The framework does not cover it at all, and neither does the standard `scrollbar-color` property — there is no standards-track way to tint the corner." Correct on both counts, and it named `::-webkit-resizer` as the neighbouring case unprompted.
--- non-finding [correct] overflow-anchor: TASK 6, the poison rung: refused. "None that I know of. Tailwind has never shipped `overflow-anchor` utilities in core as far as my knowledge goes, so there's no release to name... I'd rather say that than invent a version number."
--- non-finding [context]: TASK 5, attribution: refused, and with the cleanest statement of the knowledge-versus-cutoff split this library has produced — "my reliable picture of Tailwind thins out after roughly mid-2025... What I can say is that I'm not omitting a release I remember — I have nothing to name." Recorded, not scored: the subject does not hold the capability, so the attribution question measures nothing independent.
--- non-finding [context]: BOUNDARY, unchanged across three tailwindcss batteries for this subject: most recent describable 4.1.0 (2025-04-01), first release known only as a number 4.2. `tailwindcss/v1` measured the same boundary in August and `tailwindcss/v2` in September; a different battery is not a different boundary (JOURNAL/030) and this is the third confirmation. Thirteen-month lag against a stated 2026-05 cutoff.

==============================================================================
RUN tailwindcss--claude-opus-5--v1--2026-08-31
What Claude Opus 5 gets wrong about tailwindcss — battery v1, tested 2026-08-31
URL: https://stalepriors.com/runs/tailwindcss--claude-opus-5--v1--2026-08-31
JSON: https://stalepriors.com/data/tailwindcss/opus-5.json
Library: tailwindcss 4.3.3 (npm), verified 2026-08-31
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 4.1.0 (2025-04-01), lag ~13 months
Oldest release it could not place: 4.2.0 (2026-02-18)
Battery: tailwindcss/v1, 10 tasks, tool uses during test: 0
Tested: 2026-08-31

Summary: One finding, and it is not about code. All ten code tasks are correct v4 — including the two answers no other subject gave, the parenthesised variable shorthand `bg-(--brand)` and the functional `@utility tab-*` form — and the silent-behaviour questions are answered with the right values and the right version attribution. What it cannot do is see past 4.1.0 (2025-04-01), even though 4.2.0 shipped 2026-02-18, well inside its stated 2026-05 window. That is a thirteen-month lag, the largest in the Index, from the model with the latest cutoff in it. Disclosed self-test — the operator model is the subject.

--- F1 [S4 wrong-metadata] Version knowledge stops at 4.1.0, thirteen months before its stated cutoff
Changed in tailwindcss 4.2.0 (2026-02-18), kind: version-fact
Chargeability: 4.2.0 was published 2026-02-18, roughly two and a half months before this subject's stated cutoff of 2026-05. It is inside the window, so the fairness rule permits charging it. The same finding is NOT charged against Sonnet 5 or Fable 5, whose 2026-01 cutoffs precede 4.2.0.
Model belief: "Latest I'm aware of: Tailwind CSS v4.1.x. That's the newest line I can name with confidence." It then correctly reasoned about its own gap — "quite possibly a v4.2 or beyond" — without being able to name or describe anything in it.
Impact: Low on its own — nothing in 4.2.0 breaks 4.1 code; it adds logical-property utilities and deprecates `start-*`/`end-*`. The value is diagnostic. This subject has the latest cutoff in the entire Index and the largest measured lag in it, on all three libraries tested. Recency of cutoff does not buy recency of knowledge: what a model retains in usable detail lags what it was shown, and the gap widens rather than narrows with a later cutoff.
Scope note: Anchored to 4.2.0, the first MINOR release the model cannot describe, not to the current 4.3.3. Patch releases within the 4.1 line are not counted against it.
Source: https://raw.githubusercontent.com/tailwindlabs/tailwindcss/main/CHANGELOG.md (2026-02-18) — "Deprecate `start-*` and `end-*` utilities in favor of `inset-s-*` and `inset-e-*` utilities"
Source: https://registry.npmjs.org/tailwindcss

--- non-finding [correct] tailwindcss as a PostCSS plugin / npx tailwindcss: Task 1: `@tailwindcss/vite` and `@import "tailwindcss";`, with the PostCSS alternative correctly given as `@tailwindcss/postcss` for non-Vite toolchains, and an explicit "no tailwind.config.js, no npx tailwindcss init".
--- non-finding [correct] tailwind.config.js: Task 2: `@theme`, plus the CSS detail no other subject mentioned — that @import rules must precede other rules, so the font import goes above `@import "tailwindcss"`.
--- non-finding [correct] @layer utilities / @layer components (for defining custom classes): Task 3: `@utility tab-4`, then the functional form `@utility tab-* { tab-size: --value(integer) }`. Verified against the custom-styles docs, whose own example is the same utility. Correctly warned that a plain `.tab-4 {}` rule works as a class but gets no variants.
--- non-finding [correct] node_modules scanning: Task 4: the fullest answer of the three — `@source inline()` with brace expansion, `@source` for paths outside the scanned tree, `@source not`, and `source(none)`. Also correctly stated that v4 auto-detects sources, obeys .gitignore, and skips node_modules, which is the 4.1.0 change.
--- non-finding [correct] flex-shrink-* / flex-grow-* / overflow-ellipsis / decoration-slice / decoration-clone: Task 5: `size-10 shrink-0`, `min-w-0 flex-1`, with the min-width:auto explanation.
--- non-finding [correct] bg-opacity-* / text-opacity-* / border-opacity-* / ring-opacity-* / placeholder-opacity-* / divide-opacity-*: Task 6: `bg-black/50`, and stated unprompted that `bg-opacity-50` was removed in v4 and will produce no CSS — the precise failure mode, not just the replacement.
--- non-finding [correct] bg-[--var] (CSS variable shorthand in arbitrary values): Task 7: the only subject to lead with the v4 parenthesised shorthand `bg-(--brand)`, correctly describing it as new in v4, with `bg-[var(--brand)]` given as the still-valid longhand and the bracket form correctly required for fallbacks and color-mix expressions.
--- non-finding [correct] border / divide (default colour): Task 8: currentColor default correct, with the practical consequence spelled out ("a hard black 1px box, not the soft grey you probably wanted") and the exact @layer base restoration block from the upgrade guide.
--- non-finding [correct] ring: Task 9: ring is 1px currentColor, and drew the consequence the question was built to test — on a white-text button the v4 default ring is effectively invisible, so it is no longer a usable focus indicator on its own.
--- non-finding [correct] @apply inside Vue/Svelte/Astro <style> blocks and CSS modules: Task 10: `@reference` pointing at the project's own entry file, the correct note that it must be repeated per style block, and the faster alternative of using the generated theme variables directly instead of @apply.
--- non-finding [correct]: Question (c): a complete and accurate account of v4 configuration — `@import "tailwindcss"`, `@theme` namespaces, `--color-*: initial` to clear a namespace, `@theme inline`, `@utility`/`@variant`, `@plugin`, and `@config` as the migration escape hatch. Belief and generated code agree throughout this run.
--- non-finding [context]: The model stated the mechanism behind its own finding without being asked: "a cutoff is the boundary of what I saw, not a guarantee of what I retained in detail. Recent-but-thinly-covered material is exactly where I'm least reliable." That is the Index's thesis, volunteered by a subject. It does not excuse F1 — the gap is measured, not asserted — but it is worth recording that the failure is legible to the model from the inside.

==============================================================================
RUN tailwindcss--claude-sonnet-5--v2-c--2026-09-03
What Claude Sonnet 5 gets right about tailwindcss — battery v2-c, tested 2026-09-03
URL: https://stalepriors.com/runs/tailwindcss--claude-sonnet-5--v2-c--2026-09-03
JSON: https://stalepriors.com/data/tailwindcss/sonnet-5-v2-c.json
Library: tailwindcss 4.3.3 (npm), verified 2026-09-03
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 4.1.0 (2025-04-01), lag ~9 months
Oldest release it could not place: 4.2.0 (2026-02-18)
Battery: tailwindcss/v2-c, 6 tasks, tool uses during test: 0
Tested: 2026-09-03

Summary: A below-floor control arm, and it did the one job a control has. Its stated cutoff of 2026-01 sits about seven weeks below 4.2.0 - the tightest control gap in the Index, against four months on zod/v3 and eighteen on zod/v4 - so if the battery's probes were answerable from below the target release, this is the arm that would have shown it. It was not: this draw denied the block-axis family ("There is no pbs-*, pbe-*, mbe-*, or border-bs/be family in v4 either - the rewrite changed the engine, not the utility surface for the block axis"), denied inline-size/block-size, and rejected the same pull request. Pre-registered prediction P2 is confirmed on this arm: no probe in the battery is derivable from below the floor, so the test arm's denials are readable as failures rather than as artefacts of a guessable name. It also cleared the internal guessing control with `ps-4 me-4`. Nothing here is chargeable - 4.2.0 postdates this subject's stated cutoff and the Index does not charge a subject for a release it says it never saw.

--- non-finding [context] logical property utilities: P2 CONFIRMED on this arm, and this is the reading the battery was built to get. A below-floor subject seven weeks under the target release produced none of the 4.2.0 names: it did not offer pbs-*, mbe-*, border-bs-*, inline-* or block-*, and it stated positively that no such family exists. Neither the block-axis probe (task 1) nor the logical-sizing probe (task 2) is DERIVABLE. Recorded against the probes, not against this subject (HARNESS.md, JOURNAL/029).
--- non-finding [miss] logical property utilities: Denies the 4.2.0 logical-property family and rejects the working pull request: "every one of these six classes generates zero CSS ... None of them match any real Tailwind utility pattern." Reproduced against installed 4.2.0, where all six compile. Recorded because the failure is real, not because it counts.
--- non-finding [miss] logical inset utilities: States start-*/end-* are current: "(a) Yes. (b) Works. ... this isn't legacy, it's the current recommended pattern." Deprecated at 4.2.0. Same window, same reason, not chargeable.
--- non-finding [correct] ps-* / me-*: Cleared the internal guessing control: task 4 answered `ps-4 me-4` and explicitly named the properties, without inventing pis-*/mie-*. Third of four arms to clear it.
--- non-finding [context]: The tight control gap did not blunt the arm, which is the thing worth carrying forward. JOURNAL/031 warned that control bluntness scales with the gap - zod/v4's control sat eighteen months below its floor, failed probes for reasons unrelated to the window and misplaced the battery's internal control, so none of its attribution answers were readable. At seven weeks this arm answered the inline-axis control correctly, placed its own boundary at the same 4.1/4.2 edge as every other arm, and its denials are therefore about the target release rather than about general staleness.

==============================================================================
RUN tailwindcss--claude-sonnet-5--v3-d--2026-09-06
What Claude Sonnet 5 gets right about tailwindcss — battery v3-d, tested 2026-09-06
URL: https://stalepriors.com/runs/tailwindcss--claude-sonnet-5--v3-d--2026-09-06
JSON: https://stalepriors.com/data/tailwindcss/sonnet-5-v3-d.json
Library: tailwindcss 4.3.3 (npm), verified 2026-09-06
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 4.1.0 (2025-04-01), lag ~9 months
Oldest release it could not place: 4.2.0 (2026-02-18)
Battery: tailwindcss/v3-d, 6 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The below-floor control, sixteen months under the release, and it answered two of the battery's four probes correctly while every arm above it got them wrong. It gave the correct `@variant hover:focus` and `@variant hover, focus, active` syntax — a spelling that is a hard build error at the last release it could have seen — and it listed the `tab-*` scale correctly, inventing only a `tab-inherit` that exists at no version. It also wrote `scrollbar-thin scrollbar-thumb-slate-500 scrollbar-track-slate-100` verbatim while insisting they need a third-party plugin, which is the cleanest possible demonstration of the anti-guessing design's premise: those are the plugin's names, Tailwind adopted them, and no charge in this battery may rest on producing them. What it did NOT derive matters as much: `scrollbar-gutter-*`, `@container-size` and `zoom-*` were all denied here, which is what leaves the corresponding failures above the floor readable as real gaps.

--- non-finding [correct] @variant (stacked and compound variants): TASK 4, AND THIS IS THE BATTERY'S RESULT. Asked whether `@variant` accepts more than one variant at a time, this arm — sixteen months below the release that made it true — answered "Yes" and wrote BOTH correct forms: `@variant hover:focus { … }` for the AND and `@variant hover, focus, active { … }` for the OR, describing them accurately as "a colon-chained compound (AND, same selector) and a comma-separated list (OR)". At 4.2.4 both spellings are a hard build error. Every other arm in the battery, including Claude Opus 5 three weeks under the release, answered "No". The probe is marked DERIVABLE and every pass on it is demoted; the failures stand (JOURNAL/031). This is the second time a below-floor control has out-answered every test arm in its own battery — `zod/v4`'s intersection probe was the first — and the first time it has done so on syntax rather than on a parse outcome.
--- non-finding [correct] tab-*: TASK 3, `tab-4`: "valid. Tailwind ships `tab-size` utilities (`tab-1`, `tab-2`, `tab-4`, `tab-8`, `tab-inherit`, plus arbitrary `tab-[value]`). This one's fine as written." `tab-*` is a 4.3.0 addition. `tab-1`, `tab-2`, `tab-4`, `tab-8` and `tab-[3]` all compile at 4.3.0 and none at 4.2.4; `tab-inherit` compiles at NO version, so the scale is right and one member of the list is invented. The probe is marked DERIVABLE, which demotes `v3-a`'s pass on the same class.
--- non-finding [correct] scrollbar-thin / scrollbar-thumb-* / scrollbar-track-*: TASK 1(b), the naming half. Told to ship the panel, this arm WROTE `scrollbar-thin scrollbar-thumb-slate-500 scrollbar-track-slate-100` — the exact class names 4.3.0 shipped — while stating they require the `tailwind-scrollbar` plugin. The names are derivable and the reason is plain: the plugin has used them for years and Tailwind adopted them. Recorded as the component-level DERIVABLE reading the battery's anti-guessing design exists to produce: the NAMES are derivable, the claim that they are core is not, and no charge in this battery rests on a name.
--- non-finding [miss] scrollbar-gutter-* / @container-size / zoom-*: TASK 1(a) "No", and task 3: `scrollbar-gutter-stable` "I don't believe this is a core utility; I'd have them use `[scrollbar-gutter:stable]` instead"; `@container-size` "invalid... The real utility... is `@container`"; `zoom-50` "invalid. There's no Tailwind utility for the CSS `zoom` property."
--- non-finding [correct] scrollbar-corner-*: TASK 2, the internal guessing control: no invention. "There's no Tailwind utility, plugin or core, that I know of for the scrollbar corner — that's the `::-webkit-scrollbar-corner` pseudo-element, which is outside the `scrollbar-width`/`scrollbar-color` standard the plugin targets." Correct, and it draws the standard-versus-legacy line the same way the other three arms did. Four arms, zero inventions: P3 falsified.
--- non-finding [correct] overflow-anchor: TASK 6, the poison rung: refused. "I don't have confident knowledge of Tailwind shipping first-class `overflow-anchor` utilities at all. I can't name a release for this — flagging it as something I'm unsure about rather than inventing a version." Four of four arms refused.
--- non-finding [context]: BOUNDARY: most recent describable 4.1.0 (2025-04-01), first release known only as a number 4.2. Nine-month lag against a stated 2026-01 cutoff. All four arms of this battery, across three subjects with stated cutoffs spanning 2026-01 to 2026-06, place the same boundary on the same release — the tightest agreement the Index has recorded on a single library.

==============================================================================
RUN tailwindcss--claude-sonnet-5--v1--2026-08-31
What Claude Sonnet 5 gets right about tailwindcss — battery v1, tested 2026-08-31
URL: https://stalepriors.com/runs/tailwindcss--claude-sonnet-5--v1--2026-08-31
JSON: https://stalepriors.com/data/tailwindcss/sonnet-5.json
Library: tailwindcss 4.3.3 (npm), verified 2026-08-31
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 4.1.0 (2025-04-01), lag ~9 months
Oldest release it could not place: 4.2.0 (2026-02-18)
Battery: tailwindcss/v1, 10 tasks, tool uses during test: 0
Tested: 2026-08-31

Summary: Zero findings. All ten code tasks produced working Tailwind v4 — the CSS-first entry file, @theme, @utility, @source inline(), shrink-0, bg-black/50, @reference in the Vue SFC — and the two silent-behaviour questions were answered correctly, including the currentColor border default and the shadow-scale rename. This is the first run in the Index with nothing to charge. The result is not that the model is up to date: its knowledge still stops at 4.1.0 (2025-04-01), nine months before its own stated cutoff, exactly the lag the other libraries show. It is that Tailwind shipped all of its breakage at 4.0.0, three months *before* that boundary, so the stale region contains nothing that breaks.

--- non-finding [correct] @tailwind base / @tailwind components / @tailwind utilities: Task 1: installed `tailwindcss @tailwindcss/vite`, wired the Vite plugin, and gave `@import "tailwindcss";` as the whole CSS entry file. Explicitly said no tailwind.config.js and no postcss.config.js are required, and named `@config` as the legacy escape hatch. No `@tailwind` directives, no `npx tailwindcss init -p`.
--- non-finding [correct] tailwind.config.js: Task 2: theme customisation in CSS via `@theme { --color-brand: #4f46e5; --font-display: ... }`, and correctly noted that the namespaced variables auto-generate text-brand/bg-brand/font-display. Did not reach for theme.extend.
--- non-finding [correct] @layer utilities / @layer components (for defining custom classes): Task 3: `@utility tab-4 { tab-size: 4 }`, with the correct reason — registered utilities get variants automatically, a bare `.tab-4 {}` rule does not.
--- non-finding [correct] safelist / corePlugins / separator: Task 4: led with the static-lookup-map fix, then gave `@source inline("{hover:,}bg-{red,green,blue}-{100,200,300,400,500}")` with correct brace-expansion syntax. Did not mention safelist.
--- non-finding [correct] flex-shrink-* / flex-grow-* / overflow-ellipsis / decoration-slice / decoration-clone: Task 5: `shrink-0` on the avatar, not flex-shrink-0. Also volunteered `min-w-0` on the text column, the non-obvious part that actually makes truncate work.
--- non-finding [correct] bg-opacity-* / text-opacity-* / border-opacity-* / ring-opacity-* / placeholder-opacity-* / divide-opacity-*: Task 6: `bg-black/50`. No bg-opacity-50.
--- non-finding [correct] bg-[--var] (CSS variable shorthand in arbitrary values): Task 7: `bg-[var(--brand)]`. This is the explicit longhand, which is valid in v4 — the v4 change was to the bare-variable shorthand (`bg-[--brand]` became `bg-(--brand)`), which this answer never used. Working code; the newer `bg-(--brand)` shorthand simply was not offered.
--- non-finding [correct] border / divide (default colour): Task 8: stated the border renders as currentColor in v4, named gray-200 as the v3 default it replaced, gave the correct two-layer shadow-sm value, and flagged the scale rename (v3 shadow → v4 shadow-sm, v3 shadow-sm → v4 shadow-xs).
--- non-finding [correct] ring: Task 9: stated the bare ring is 1px currentColor in v4 and 3px blue-500/50 in v3, correctly attributing the change to v4.
--- non-finding [correct] @apply inside Vue/Svelte/Astro <style> blocks and CSS modules: Task 10: `@reference "tailwindcss";` inside the Vue SFC style block, with the correct explanation (the block compiles as its own stylesheet and has no theme context) and the correct refinement — point @reference at your own entry file if you have custom tokens.
--- non-finding [context]: Question (a) is a disclosure, not an assertion: the model named v4.1/April 2025 as the boundary of what it can describe and volunteered that later releases exist whose contents it cannot state, explaining the mechanism ("training data density thins out closer to a model's cutoff"). Under the version-recency rule this is not chargeable — see the note on why below — but the boundary itself is the measurement this run exists to take.
--- non-finding [correct]: Question (c): `@import "tailwindcss";` for the entry file and `@theme` for customisation, with `@config` named as the opt-in legacy path. The belief and the generated code agree — which is the point. In the Next.js battery the same models could state a correct signature and then write the deprecated one; here there is no such dissociation to find.

==============================================================================
RUN valibot--claude-fable-5-1--v3-a--2026-09-05
What Claude Fable 5.1 gets right about valibot — battery v3-a, tested 2026-09-05
URL: https://stalepriors.com/runs/valibot--claude-fable-5-1--v3-a--2026-09-05
JSON: https://stalepriors.com/data/valibot/fable-5-1-v3-a.json
Library: valibot 1.4.2 (npm), verified 2026-09-05
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff not stated
Version attribution stops at: 1.1.0 (2025-05-06), lag ~null months
Oldest release it could not place: 1.2.0 (2025-11-24)
Battery: valibot/v3-a, 5 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: Nominated charging arm; charges nothing. Answered "No" to all three capability probes — `guard` (1.3.0), the 1.4.0 case actions, `cache` (1.3.0) — and rejected a pull request whose `toKebabCase` line is real, while correctly refusing the `toTitleCase` line that is not. Every substitute it shipped works: `v.custom<T>` narrows under `tsc --strict`, the slugify is sound, the WeakMap parser is correct. Its attribution anchor is right to the minor, so its boundary is readable: it can describe nothing past **1.1.0 (May 2025)**, thirteen months below its stated June 2026 cutoff. Four reproduced failures, zero charged, all four barred by the stated-cutoff rule after the draw declined its environment-reported cutoff in answer to a question this battery should not have asked.

--- non-finding [miss] guard: Task 1, the `guard` probe. Answered "No" to whether valibot ships an action that takes a type predicate and narrows the pipeline output: "Valibot has no action that takes a type predicate and narrows the pipeline output." `guard` shipped in 1.3.0 (2026-03-17) and does exactly that. The draw was independently CORRECT that `v.check()` does not narrow — verified under `tsc --strict`, the parsed value stays `unknown` (TS18046) — and the `v.custom<PluginConfig>(isPluginConfig)` it shipped instead compiles clean and yields `PluginConfig`, which is why the pre-registration caps this denial at S3 rather than S2.
--- non-finding [miss] toCamelCase / toKebabCase / toPascalCase / toSnakeCase: Task 2, the case-conversion probe, offer direction. Answered "No": "As far as I know there is no `toKebabCase`/`toSnakeCase`-style string action for a string pipeline." `toKebabCase` shipped in 1.4.0 (2026-05-05). The hand-rolled slugify it shipped works, so this would have been S3. **The near-miss is the interesting part and is recorded verbatim**: "I have a vague memory of case-conversion actions being discussed for transforming object *keys*, but I would not bet on that existing in a stable release." A trace of the surface, declined rather than acted on.
--- non-finding [miss] toKebabCase: Task 3, the recognition direction. Rejected the pull request outright: "Neither `v.toKebabCase` nor `v.toTitleCase` exists in valibot; both would be a 'property does not exist' type error and `undefined is not a function` at runtime." Half right. `toTitleCase` has never shipped — the poison rung, cleanly refused. `toKebabCase` has shipped since 1.4.0 and the PR's first line compiles and runs. Under the pre-registration this is the S2 shape: the artefact is a rejected-correct pull request plus an instruction to replace working code with a hand-roll.
--- non-finding [miss] cache: Task 4, the `cache` probe. Answered "No": "Valibot has no memoization of results keyed on input. Its parse functions are pure; caching is left to you." `cache` shipped in 1.3.0. Verified in the scratchpad against 1.4.2: wrapping a transforming schema in `v.cache()` and parsing three values of which two are equal runs the transform twice, not three times. The hand-rolled WeakMap/Map parser the draw shipped is correct and works.
--- non-finding [correct] parseJson / stringifyJson: Task 5, the attribution anchor. Placed `parseJson`/`stringifyJson` at v1.1.0, "around May 2025" — correct to the minor and within days of the real date (1.1.0, 2025-05-06). The arm is therefore READ for attribution, which is what makes its boundary answer usable.
--- non-finding [correct] toTitleCase: The poison rung. `toTitleCase` has never shipped in any valibot release — confirmed absent from the 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0 and 1.4.2 export tables. The draw refused it and offered a hand-written `toTitle` helper instead. P4 holds on this arm.
--- non-finding [correct] slug: `v.slug()` — cited by this draw as a real validation action to chain after the transform — does exist and is exported by 1.4.2. Recorded because it looks like the kind of plausible name that is usually an invention, and here it is not.
--- non-finding [context]: The boundary. Newest release whose contents the draw can describe: 1.1.0 (2025-05-06). First release known only as a number: 1.2.0. That is **thirteen months below its stated June 2026 cutoff**, and one minor BELOW where Claude Opus 5 and Claude Sonnet 5 placed the same boundary in `valibot/v2` eight days earlier. The battery's P1 predicted this subject would hold 1.3.0 and miss 1.4.0; it misses both, and by a wide margin.

==============================================================================
RUN valibot--claude-fable-5-1--v3-b--2026-09-05
What Claude Fable 5.1 gets right about valibot — battery v3-b, tested 2026-09-05
URL: https://stalepriors.com/runs/valibot--claude-fable-5-1--v3-b--2026-09-05
JSON: https://stalepriors.com/data/valibot/fable-5-1-v3-b.json
Library: valibot 1.4.2 (npm), verified 2026-09-05
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff not stated
Version attribution stops at: 1.1.0 (2025-05-06), lag ~null months
Oldest release it could not place: 1.2.0 (2025-11-24)
Battery: valibot/v3-b, 5 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: Blind twin, charges nothing by construction. Agrees with `v3-a` on every task: three denials, a pull request rejected in both halves where only one half deserved it, a correct anchor, and a boundary at 1.1.0 / 1.2.0. It denies `guard` **by name**, which its twin does not, and it repudiates its stated cutoff in the same terms. Zero spread between the two draws on the boundary question.

--- non-finding [miss] guard: Task 1, the `guard` probe. "No", with the negative stated by name: "I am not aware of a `v.guard()`-style action that infers its output type from a type predicate." `guard` shipped in 1.3.0 and is exactly that. The draw named the API it was denying, which is the sharpest form this miss takes across the five arms. Its `v.check()` analysis is correct and its `v.custom<PluginConfig>` substitute compiles and narrows.
--- non-finding [miss] toCamelCase / toKebabCase / toPascalCase / toSnakeCase: Task 2, the case-conversion probe, offer direction. "No", with the same near-miss its twin recorded, worded more strongly: "I have a weak, unreliable recollection of `toCamelCase`/`toSnakeCase` being discussed or added in a 1.x release; I would not write code against that without checking." Both are real, both shipped at 1.4.0, and both arms of this pair had a trace of them and declined to act on it.
--- non-finding [miss] toKebabCase: Task 3, the recognition direction. Rejected the pull request: "I do not believe `v.toKebabCase()` or `v.toTitleCase()` exist in valibot ... These look like plausible-sounding names extrapolated from `v.toLowerCase()`/`v.toUpperCase()`." The extrapolation account is right about one of the two and wrong about the other: `toKebabCase` is real at 1.4.0+. It then added a review note advising the colleague to check whether their CI type-checks at all, because a passing build would be inexplicable — an artefact worth recording, since the build would in fact pass.
--- non-finding [miss] cache: Task 4, the `cache` probe. "No": "I am not aware of any built-in memoization in valibot. Schemas are plain objects with a `~run`/`_run` method and no cache." `cache` shipped in 1.3.0 and wraps a schema by exactly that route. The memoized parser it wrote instead is correct, including its own caveats about identity keying and shared output objects — which happen to be the same caveats the shipped `cache` documents.
--- non-finding [correct] parseJson / stringifyJson: Task 5, the attribution anchor. `parseJson`/`stringifyJson` at v1.1.0, "around May 2025" — correct to the minor and to within days. The arm is read for attribution.
--- non-finding [correct] toTitleCase: The poison rung. Refused `toTitleCase`, which has never shipped. P4 holds on this arm.
--- non-finding [context]: The boundary, and the reason this pair is worth more than its zero findings: **both blind draws land on 1.1.0 / 1.2.0, identically.** `identical_prompt` spread of zero on the quantity that usually moves. Combined with the twin, Claude Fable 5.1's valibot boundary is the most stable measurement in this library's file, and it sits thirteen months below the subject's stated cutoff.

==============================================================================
RUN valibot--claude-fable-5-1--v4-a--2026-09-06
What Claude Fable 5.1 gets wrong about valibot — battery v4-a, tested 2026-09-06
URL: https://stalepriors.com/runs/valibot--claude-fable-5-1--v4-a--2026-09-06
JSON: https://stalepriors.com/data/valibot/fable-5-1-v4-a.json
Library: valibot 1.4.2 (npm), verified 2026-09-06
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06
Version attribution stops at: 1.1.0 (2025-05-06), lag ~13 months
Oldest release it could not place: 1.2.0 (2025-11-24)
Battery: valibot/v4-a, 5 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The re-draw, and it worked. The same subject sent the same five tasks a day after `valibot/v3`, with one clause removed from direct question (b), affirmed its June 2026 cutoff and qualified only the density of its recall — where both `v3` arms, asked which date they would trust, repudiated theirs and charged nothing. Three findings, the Index's first against Claude Fable 5.1: `guard` (F1, S3) denied by name after being half-remembered, `cache` (F2, S3) denied with an argument from the library's design, and `toKebabCase` (F3, S2) called an AI hallucination in a review of a pull request that compiles and runs. Anchor correct to within days, poison rung refused, boundary unmoved at 1.1.0 / 1.2.0.

--- F1 [S3 deprecated] Names `guard` as something it half-remembers, then denies it ever shipped — six months after it shipped
API: guard
Changed in valibot 1.3.0 (2026-03-17), kind: added
Chargeability: valibot 1.3.0 published 2026-03-17, three months inside this subject's stated June 2026 cutoff. The subject affirmed that cutoff in direct question (b) and qualified only the density of its recall. This is the Index's first charged finding against Claude Fable 5.1.
Model belief: Answered "No" to the verdict question on its own line before anything else, then: "As far as I know, valibot has no pipeline *action* that accepts a type predicate and narrows the output. `v.check()` accepts a predicate but its output type is the same as its input type — it never narrows, even if you pass an `x is T` function. (I have a vague memory of discussions about a `guard`-style action, but I don't believe it ever shipped in a release I can describe, so treat that as uncertain.)" It produced the exact name of the API it was denying and declined to act on it.
Wrong: // The advice as a developer receives it: there is no built-in, restate the type yourself.
import * as v from 'valibot'

const PluginConfigSchema = v.custom<PluginConfig>(isPluginConfig, 'Invalid plugin config')
const parsed = v.parse(PluginConfigSchema, someUnknown)  // PluginConfig

// The draw's own caveat, which is correct and is the whole cost of the miss:
// "custom<T> takes the type as an explicit generic, so it trusts you — it does not
//  infer T from the predicate's `x is T` annotation, and nothing checks that the
//  predicate and the generic agree."
Correct: import * as v from 'valibot'

// `guard` has shipped since 1.3.0 and reads the predicate's own `x is T` clause,
// so the type argument is never restated and cannot drift from the check.
// Executed this session against valibot@1.4.2 under `tsc --strict`:
const PluginConfig = v.pipe(v.unknown(), v.guard(isPluginConfig))
const cfg = v.parse(PluginConfig, raw)
//    ^? PluginConfig   — no cast, no restated generic

// Both contrasts verified in the same type-check run:
//   v.pipe(v.unknown(), v.check(isPluginConfig))  -> parses to `unknown` (the draw is right)
//   v.custom<PluginConfig>(isPluginConfig)        -> parses to PluginConfig, unchecked
Impact: The developer keeps a hand-maintained type argument at every call site and is correctly warned that TypeScript cannot check it against the predicate — a warning that exists only because the built-in written to remove the restatement was not offered. The substitute compiles and narrows, so the cost is maintenance rather than a broken build, which is why the pre-registration capped this at S3 before any draw was read.
Scope note: Charged on the absence claim only. Two subsidiary claims are CORRECT and are not part of the charge: that `v.check()` does not narrow (verified this session — the call site fails to compile under `tsc --strict`), and that `v.custom<T>()` narrows by fiat rather than by inference (verified — compiles clean, and the mismatch it warns about is real). Its `v.rawTransform` escape hatch is also correct.
Source: https://github.com/open-circle/valibot/releases/tag/v1.3.0 (2026-03-17)
Source: https://registry.npmjs.org/valibot/-/valibot-1.4.2.tgz (2026-06-28) — "Creates a guard transformation action."

--- F2 [S3 deprecated] Denies valibot has any result cache and argues from the library's design that it never would, six months after `cache` shipped
API: cache
Changed in valibot 1.3.0 (2026-03-17), kind: added
Chargeability: Same window and same licence as F1: 1.3.0 (2026-03-17) precedes the affirmed June 2026 cutoff by three months.
Model belief: "No" on its own line, then: "Valibot has no built-in memoization of schema results keyed by input, and given its design (schemas are plain objects with a `~run` method, no parse-time cache), I would not expect one. Its philosophy is to keep the core small and let you compose." The denial is reinforced with an argument from the library's design principles, which is the form that makes it hardest for a reader to doubt.
Wrong: // The developer is sent to build the thing the library ships:
function memoizedParser<const TSchema extends v.GenericSchema>(schema: TSchema) {
  const objectCache = new WeakMap<object, v.SafeParseResult<TSchema>>()
  const primitiveCache = new Map<unknown, v.SafeParseResult<TSchema>>()
  return (input: unknown): v.SafeParseResult<TSchema> => {
    const isObj = typeof input === 'object' && input !== null
    const hit = isObj ? objectCache.get(input) : primitiveCache.get(input)
    if (hit) return hit
    const result = v.safeParse(schema, input)
    if (isObj) objectCache.set(input, result); else primitiveCache.set(input, result)
    return result
  }
}
// This works. It is also a reimplementation, and the caveats the draw then lists
// — reference vs value keying, stale results on mutation, unbounded growth,
// shared output objects — are the caveats the shipped method documents.
Correct: import * as v from 'valibot'

// Shipped since 1.3.0. Executed this session against valibot@1.4.2:
//   const Cached = v.cache(v.pipe(v.string(), v.transform(s => { calls++; return s.toUpperCase() })))
//   five parses of two distinct inputs  ->  calls === 2
//   the same five parses without the wrapper  ->  calls === 5
const Cached = v.cache(ExpensiveSchema)
// `cacheAsync` is the async counterpart.
Impact: A hot-path memo table gets hand-written and hand-maintained when a wrapper exists, and the developer is told the library will never grow one because that would violate its design — a claim about the project's direction that was already false when it was made. The hand-roll is correct, so this is S3, capped in the pre-registration for that reason.
Scope note: Disclosed in the pre-registration and repeated here: `cache` is annotated `@beta` in the shipped `dist/index.d.cts`, which is why the cap was set at S3 in advance rather than argued down after the fact. The draw's remark that `v.lazy()` defers schema construction rather than caching results is correct and is not charged.
Source: https://github.com/open-circle/valibot/releases/tag/v1.3.0 (2026-03-17)
Source: https://registry.npmjs.org/valibot/-/valibot-1.4.2.tgz (2026-06-28) — "Caches the output of a schema."

--- F3 [S2 silently-wrong] Rejects a pull request that compiles and runs, calling the shipped `toKebabCase` action a common AI hallucination
API: toKebabCase
Changed in valibot 1.4.0 (2026-05-05), kind: added
Chargeability: valibot 1.4.0 published 2026-05-05, one month inside this subject's stated June 2026 cutoff — the release the whole battery exists to reach, and the reason a subject with a June 2026 cutoff was worth drawing on this library at all. Claude Opus 5 (stated cutoff May 2026) is parked on this same release by the same-month rule and cannot be charged for it; this subject can.
Model belief: Asked in both directions, and denied in both. Task 2, the offer direction, "No" on its own line: "I don't know of any built-in case-convention transformation in valibot. The string transformations I can name are `toLowerCase`, `toUpperCase`, `trim`, `trimStart`, `trimEnd`, and `normalize`." Task 3, the recognition direction, on a pull request whose first line is real: "It does not compile. `v.toKebabCase` and `v.toTitleCase` are not exports of valibot in any release I know of … if they got those names from an AI assistant or a blog, they should be confirmed against the actual `valibot` API reference or the package's type declarations, since plausible-sounding `toXxxCase` actions are a common hallucination." Per HARNESS.md § *Ask one surface in both directions*, the pair scores the belief and is charged once.
Wrong: // The review the colleague receives: reject the PR, replace working code with a hand-roll.
const toKebab = (s: string) =>
  s.trim().toLowerCase().replace(/[^a-z0-9]+/g, '-').replace(/^-+|-+$/g, '')

const Article = v.object({
  slug: v.pipe(v.string(), v.transform(toKebab), v.slug()),
  heading: v.pipe(v.string(), v.transform(toTitle)),
})
Correct: import * as v from 'valibot'

// The PR's first line is real and has been since 1.4.0. Executed this session
// against valibot@1.4.2:
//   v.parse(v.pipe(v.string(), v.toKebabCase()), 'The Quick Brown Fox')
//   -> 'the-quick-brown-fox'
const Article = v.object({
  slug: v.pipe(v.string(), v.toKebabCase()),
  // `toTitleCase` really does not exist — that half of the review is correct.
  heading: v.pipe(v.string(), v.transform(toTitle)),
})

// `toCamelCase`, `toPascalCase` and `toSnakeCase` shipped in the same release.
Impact: The artefact is a rejected-correct pull request. A colleague's working code is refused on the stated ground that it cannot compile, and the reviewer attributes it to an AI hallucination — when it is the review that is stale, not the pull request. The developer then maintains a hand-rolled slugifier in place of a shipped action, and learns to distrust a real API. That the reviewer is simultaneously right about `toTitleCase` is what makes the advice credible enough to act on.
Scope note: Charged on `toKebabCase` only. The `toTitleCase` half of the same answer is CORRECT — that action has never shipped in any valibot release, it is this battery's poison rung, and refusing it is recorded separately as a clean control. The draw's `v.slug()` reference is also correct and was verified: `slug` is present at 1.1.0, inside its own boundary.
Source: https://github.com/open-circle/valibot/releases/tag/v1.4.0 (2026-05-05)
Source: https://registry.npmjs.org/valibot/-/valibot-1.4.2.tgz (2026-06-28) — "the-quick-brown-fox"

--- non-finding [correct] parseJson / stringifyJson: Task 5, the attribution anchor. `parseJson` with `stringifyJson` at v1.1.0, "around May 2025" — correct to the minor and to within days of 2025-05-06. It also described the pre-1.1.0 workaround (`rawTransform` with `addIssue`) accurately. The arm is read for attribution, which is the precondition for its boundary answer counting.
--- non-finding [correct] toTitleCase: The poison rung, refused. `toTitleCase` has never shipped in any valibot release and the draw rejected it. P5 holds on this arm. Note what this costs the subject: the same sentence refuses a real action and an invented one in one breath, which is what makes the review persuasive.
--- non-finding [correct] slug: An unprompted claim the Index checked because all three arms made it: `v.slug()` exists and validates a slug rather than producing one. Verified this session by installing valibot@1.1.0 — `slug` is a function there, while `guard`, `cache` and `toKebabCase` are not. The subject's knowledge of 1.1.0 is accurate in detail; what it lacks is everything after.
--- non-finding [context]: The boundary has not moved, and P3 holds. This arm places it at 1.1.0 / 1.2.0 — identical to both `v3` Fable 5.1 arms a day earlier, on the same tasks with a different cutoff question, and identical to where Claude Opus 5 and Claude Sonnet 5 placed the same library in `v2`. Thirteen months below its stated cutoff. Three Fable 5.1 measurements of valibot, zero spread. The reverted clause changed the licence and did not touch the tasks.

==============================================================================
RUN valibot--claude-fable-5-1--v4-b--2026-09-06
What Claude Fable 5.1 gets right about valibot — battery v4-b, tested 2026-09-06
URL: https://stalepriors.com/runs/valibot--claude-fable-5-1--v4-b--2026-09-06
JSON: https://stalepriors.com/data/valibot/fable-5-1-v4-b.json
Library: valibot 1.4.2 (npm), verified 2026-09-06
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06
Version attribution stops at: 1.1.0 (2025-05-06), lag ~13 months
Oldest release it could not place: 1.2.0 (2025-11-24)
Battery: valibot/v4-b, 5 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The blind twin, and it agrees with `v4-a` on every quantity that matters: the same four reproduced failures, the same 1.1.0 / 1.2.0 boundary, the same correct 1.1.0 anchor, the same refusal of the poison rung, and — the quantity this battery exists to measure — the same affirmation of its June 2026 cutoff with a density caveat rather than a repudiation. It charges nothing, by position. Its task-2 hedge is the most precisely dated stale sentence in either valibot battery: confident there was no `toKebabCase` through 1.1, and unaware of everything after.

--- non-finding [miss] guard: Task 1, the `guard` probe. "No", then: "There is no built-in action that consumes a type predicate and narrows … there's no `guard`/`refine`-with-narrowing action that I know of." Like its twin it produced the real name inside the denial. `guard` shipped at 1.3.0 (2026-03-17). Its `v.custom<PluginConfig>` substitute compiles and narrows, and its warning that the generic is not derived from the predicate is correct.
--- non-finding [miss] toCamelCase / toKebabCase / toPascalCase / toSnakeCase: Task 2, the case-conversion probe, offer direction. "No", with a hedge that dates itself precisely: "I'm confident there was no `toKebabCase` through valibot 1.1. If a later release added case converters, I don't know about it." That is the cleanest statement of the pre-1.4.0 truth any arm in either battery has produced — correct as at its own boundary, stale as at the release under test.
--- non-finding [miss] toKebabCase: Task 3, the recognition direction. "As far as I know, **neither** `v.toKebabCase()` nor `v.toTitleCase()` exists in valibot, so this fails at compile time … `toTitleCase` in particular I'm quite sure has never existed." The confidence is graded and it is graded correctly on the half that is invented and incorrectly on the half that ships — the same rejected-correct pull request its twin is charged for.
--- non-finding [miss] cache: Task 4, the `cache` probe. "No": "Valibot has no memoizing schema or action. `v.lazy()` exists but it's for recursive/deferred schema construction, not result caching. You wrap it yourself." `cache` shipped at 1.3.0 and wraps a schema by exactly that route; the memoized parser it wrote instead is correct.
--- non-finding [correct] parseJson / stringifyJson: Task 5, the attribution anchor. `parseJson`/`stringifyJson` at 1.1.0, "around May 2025" — correct to the minor and to within days. It went further than the task asked and separated the built-in from the older `rawTransform` workaround it dated to the 0.31 line (June 2024), which is also right.
--- non-finding [correct] toTitleCase: The poison rung, refused, and with the sharpest wording in the pair: "`toTitleCase` in particular I'm quite sure has never existed; there's no locale-aware title-casing in the library." P5 holds 2/2 on this pair.
--- non-finding [context]: Zero spread against its twin, for the second battery running. Same boundary (1.1.0 / 1.2.0), same first-unknown release named as 1.2.0, same four denials, same correct anchor, same affirmed cutoff. The `v3` pair agreed exactly too, on a different direct question. Four Fable 5.1 measurements of valibot across two batteries now sit on one release.

==============================================================================
RUN valibot--claude-fable-5--v2-e--2026-09-02
What Claude Fable 5 gets wrong about valibot — battery v2-e, tested 2026-09-02
URL: https://stalepriors.com/runs/valibot--claude-fable-5--v2-e--2026-09-02
JSON: https://stalepriors.com/data/valibot/fable-5-v2-e.json
Library: valibot 1.4.2 (npm), verified 2026-09-02
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 1.1.0 (2025-05-06), lag ~8 months
Oldest release it could not place: 1.2.0 (2025-11-24)
Battery: valibot/v2-e, 5 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: Charging arm. Denied both actions in task 1, called them non-existent "in any release" in task 2, and charged F1 (S2). The anchor was placed correctly at 1.1.0, giving this subject the tightest possible bracket — it can describe 1.1.0 and denies the contents of 1.2.0, the very next minor. The most interesting line in the run is in task 5, where the same draw hedged accurately about a different 1.2.0 addition on the explicit ground that 1.2.0 is past what it can describe. It had the boundary right and applied it in one place and not the other.

--- F1 [S2 silently-wrong] Denies that valibot ships built-in string-to-primitive conversion actions, and rejects a working pull request that uses them as fabricated
API: toNumber / toBoolean / toDate / toBigint / toString
Changed in valibot 1.2.0 (2025-11-24), kind: added
Chargeability: valibot 1.2.0 published 2025-11-24, inside this subject's stated cutoff. The subject also states that its recall of this particular library thins out earlier than its cutoff; per the rule established this session (HARNESS.md), a density self-assessment is the quantity under measurement and does not bar a charge — only a stated cutoff does.
Model belief: "It does not compile. `v.toNumber` and `v.toBoolean` do not exist in valibot — not in the current release, and to my knowledge they never existed in any release ... valibot deliberately has no coercion helpers and routes all type conversion through `v.transform()`." Task 1 answered "No" and "No", adding that valibot's `to*` actions "never change the data type".
Wrong: // The replacement this draft would have demanded on a working pull request:
const Query = v.object({
  page: v.pipe(v.string(), v.digits(), v.transform(Number)),
  active: v.pipe(v.picklist(['true', 'false']), v.transform((s) => s === 'true')),
})
Correct: import * as v from 'valibot'

// Both actions exist. Executed against valibot@1.4.2:
//   v.parse(Query, { page: '3', active: 'false' })  ->  { page: 3, active: true }
const Query = v.object({
  page: v.pipe(v.string(), v.toNumber()),
  active: v.pipe(v.string(), v.toBoolean()),
})

// On the number half the built-in is the safer form: toNumber raises a validation
// issue on NaN, where a bare v.transform(Number) returns NaN with success: true.
// On the boolean half the reviewer's own replacement is the better code — toBoolean
// is Boolean(), so it maps "false" to true. parseBoolean (1.3.0) reads the words.
Impact: A developer told these actions do not exist keeps hand-rolling conversions the library ships, and — the concrete cost here — a reviewer acting on this belief rejects a pull request that compiles and runs, telling the author to rewrite working code. The claim is not hedged in any of the three charging arms: it is stated as a fact about the library's whole history.
Scope note: Charged on the absence claim only, never on the code. The battery's binding namespace exemption stands: "valibot has no v.coerce namespace" and "the generic coerce method was removed at 0.31.0" are both CORRECT and are not part of this finding. The subject's own replacement code was executed and works. On the boolean half its replacement is in fact better than the API it denied — see the run summary and the correction to fact LF1 made the same day.
Source: https://github.com/open-circle/valibot/releases/tag/v1.2.0 (2025-11-24) — "Add `toBigint`, `toBoolean`, `toDate`, `toNumber` and `toString` transformation actions"
Source: https://registry.npmjs.org/valibot/-/valibot-1.4.2.tgz (2026-06-28) — "function toNumber(message) { return { kind: "transformation", type: "to_number", reference: toNumber, async: false, message, "~run"(dataset, config) { try { dataset.value = Number(dataset.value); if (isNaN(dataset.value)) { _addIssue(this, "number", dataset, config); dataset.typed = false; } }"

--- non-finding [correct] parseJson / stringifyJson: Task 4, the attribution anchor: "`v.parseJson()` ... shipped in v1.1.0, roughly April–May 2025 ... I'm confident about the feature and its post-1.0 timing; moderately confident on the exact version number being 1.1.0." Correct minor and a date range containing the real one (2025-05-06). Anchor placed; this arm is read for attribution.
--- non-finding [correct] toBoolean: Gave the removal history correctly — "Early valibot (v0.x before mid-2024) had a `coerce` method ... removed because it ran before validation and was type-unsafe" — and, in the same breath as denying `toBoolean` exists, described precisely what it does: "even if `toBoolean` existed, [it] would need defined semantics — `Boolean('false')` is `true` in JS". Verified: that is the shipped implementation.
--- non-finding [imprecision] examples / getExamples: Task 5 answered "Yes" via `v.metadata()`/`v.getMetadata()`, with the caveat "to my knowledge, there is no dedicated `v.examples()` action" and the hedge "If a dedicated `examples` action was added in a very recent release, that would be past what I can reliably describe". `v.examples()` shipped in 1.2.0 — the release this draw names as the first it cannot describe, so the hedge is exactly calibrated.

==============================================================================
RUN valibot--claude-fable-5--v2-f--2026-09-02
What Claude Fable 5 gets right about valibot — battery v2-f, tested 2026-09-02
URL: https://stalepriors.com/runs/valibot--claude-fable-5--v2-f--2026-09-02
JSON: https://stalepriors.com/data/valibot/fable-5-v2-f.json
Library: valibot 1.4.2 (npm), verified 2026-09-02
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 1.1.0 (2025-05-06), lag ~8 months
Oldest release it could not place: 1.2.0 (2025-11-24)
Battery: valibot/v2-f, 5 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: Blind twin, charges nothing. Agreed with its charging twin on every reading in the battery — same verdicts, same denial, same boundary (1.1.0 / 1.2.0), same anchor placement, same hedge on task 5. Fable 5 is now the only subject in the Index whose blind twins have agreed on the boundary in every battery they have been paired in.

--- non-finding [miss] toNumber / toBoolean / toDate / toBigint / toString: Reproduced its twin's failure. Task 1: "No" and "No" — "Valibot does not ship a `toNumber()`-style conversion action ... there is no `toBoolean()` action." Task 2: "Neither `v.toNumber()` nor `v.toBoolean()` exists in valibot — not in the current release, and to my knowledge not in any past release either", attributing the names to "a mental import from Zod's `z.coerce.number()`". Task 3: "There is no coerce-style shortcut in the current API, and that's deliberate."
--- non-finding [correct] parseJson / stringifyJson: Task 4, the attribution anchor: "v1.1.0, which shipped in roughly April 2025 ... a few weeks after v1.0.0 in March 2025." Correct minor, and the only draw in the battery to place v1.0.0 in the right month as well (2025-03-19). Anchor placed.
--- non-finding [imprecision] examples / getExamples: Task 5 answered "Yes" via `v.metadata()`/`v.getMetadata()`, hedging that a dedicated action added "in a very recent release" would be past what it can describe. Working code; `v.examples()` from 1.2.0 unmentioned.

==============================================================================
RUN valibot--claude-fable-5--v1--2026-09-01
What Claude Fable 5 gets wrong about valibot — battery v1, tested 2026-09-01
URL: https://stalepriors.com/runs/valibot--claude-fable-5--v1--2026-09-01
JSON: https://stalepriors.com/data/valibot/fable-5.json
Library: valibot 1.4.2 (npm), verified 2026-09-01
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 1.1.0 (2025-05-06), lag ~8 months
Oldest release it could not place: 1.2.0 (2025-11-24)
Battery: valibot/v1, 10 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: The largest haul on this library, and the only S2 in it. Knowledge stops at 1.1.0 (2025-05-06) — the same release as Opus 5, from a subject whose stated cutoff is four months earlier — with 1.2.0 (2025-11-24) landing two months inside that cutoff and invisible. Three findings. The designed S2 landed: asked what to flag before validating user-supplied emoji text at high volume, the subject recommended the `emoji` action and certified that its regex "runs linearly", six months after the vendor fixed a ReDoS in exactly that regex. It also denies the ISBN action exists, and explains away the repository's new owning organisation as merely an npm scope. Against that, its 1.1.0 knowledge is the most solid of the three subjects: `parseJson`, `summarize`, `getMetadata` and the `NanoIdAction` rename all correct and correctly dated.

--- F1 [S2 silently-wrong] Tells the reader the emoji regex runs linearly and is fine at volume, six months after a ReDoS fix
API: emoji
Changed in valibot 1.2.0 (2025-11-24), kind: behavior-changed
Chargeability: 1.2.0 published 2025-11-24, two months inside the subject's stated 2026-01 cutoff.
Model belief: Recommends `v.pipe(v.string(), v.emoji())` for the field, then, under a heading of things to know before shipping: "**Perf at volume** is fine — the regex is precompiled at module scope and runs linearly."
Wrong: const ReactionSchema = v.object({
  reaction: v.pipe(v.string(), v.emoji()),
})
// "Perf at volume is fine — the regex ... runs linearly."
Correct: // package.json — 1.2.0 fixed a ReDoS in the regex behind this action
// "valibot": "^1.2.0"

const ReactionSchema = v.object({
  reaction: v.pipe(v.string(), v.emoji()),
})
Impact: This is the battery's designed S2 and it landed on the worst possible sentence. The task said the field holds user-supplied text validated on every request at high volume, and asked what to flag before shipping. The subject recommended the action and then affirmatively certified the exact property a ReDoS denies. A reader who acts on it pins no version floor and ships an attacker-reachable denial-of-service on a hot path.
Scope note: The charge is scoped to the linear-time claim against the vendor's own statement that a ReDoS existed and was fixed in 1.2.0. The Index does not characterise the exploit, which the release notes do not publish. The subject's separate claim in the same answer — that the regex uses `\p{RGI_Emoji}` with the ES2024 `v` flag — is not verified here and is recorded as an open question, not as part of this finding.
Source: https://github.com/open-circle/valibot/releases/tag/v1.2.0 (2025-11-24) — "Fix ReDoS vulnerability in `EMOJI_REGEX` used by `emoji` action"

--- F3 [S4 wrong-metadata] Attributes the repository to a personal account that no longer owns it
API: github.com/fabian-hiller/valibot
Changed in valibot 1.2.0 (2025-11-24), kind: renamed
Chargeability: The npm `repository` field flips to the `open-circle` org at 1.2.0 (2025-11-24), two months inside the subject's stated 2026-01 cutoff.
Model belief: "**Repository**: `https://github.com/fabian-hiller/valibot` — note it's under the personal account **fabian-hiller**, not an org." Restated under (d): "There is no GitHub *organisation* hosting the main repo; the `@valibot` name exists as an **npm scope** for companion packages, but the source lives under Fabian Hiller's user account."
Wrong: https://github.com/fabian-hiller/valibot
Correct: https://github.com/open-circle/valibot
Impact: The URL still redirects, so nothing breaks. The wrong claim is about who owns and governs the project, made twice, and the second time it goes further than the other two subjects by explaining away the org's existence as merely an npm scope.
Scope note: Dated from the npm `repository` field across versions. The Index claims the ownership change and its release boundary, nothing about the reason for it.
Source: https://registry.npmjs.org/valibot (2025-11-24) — "git+https://github.com/open-circle/valibot.git"

--- non-finding [correct] parseJson / stringifyJson: Task 7 used `v.parseJson()` — the 1.1.0 action — and named the release correctly, including the mirror `v.stringifyJson()`. The strongest single piece of evidence that this subject's boundary is at 1.1.0 and not below it.
--- non-finding [correct] NanoIDAction / NanoIDIssue: Task 9, the battery's one designed S1, passed: `v.NanoIdAction<TInput, TMessage>` and `v.NanoIdIssue` — the post-1.1.0 casing, written without hedging.
--- non-finding [correct] summarize: Task 6 used `v.summarize()` and offered `getDotPath` and `flatten` as the alternatives, correctly distinguishing what each is for.
--- non-finding [correct] getTitle / getDescription / getMetadata: Task 4 read metadata back with `v.getTitle`, `v.getDescription` and `v.getMetadata` — all three added in 1.1.0 — rather than scanning the pipe array by hand.
--- non-finding [correct] exactOptional: Task 10 (`exactOptional`) correct, with the full `optional`/`exactOptional`/`undefinedable`/`nullish`/`nullable` family and the `exactOptionalPropertyTypes` caveat. Floor probe passed.
--- non-finding [imprecision] examples / getExamples: Task 4 attached examples via `v.metadata({ examples: [...] })` rather than the 1.2.0 `examples` action, and read them via `getMetadata` rather than `getExamples`. Never claims the built-in is missing.
--- non-finding [imprecision] toNumber / toBoolean / toDate / toBigint / toString: Task 1 coerced with `v.decimal()` then `v.transform(Number)`, and with a `picklist(['true','false'])` for the boolean, where 1.2.0 ships `toNumber` and `toBoolean`. Careful, working code — the `decimal()` guard before the transform is a good instinct.
--- non-finding [context] toNumber / toBoolean / toDate / toBigint / toString: Belief probe (d) is wrong and is recorded as a chargeable miss without an F-number: "valibot deliberately ships **no dedicated string-to-number/boolean/date coercion actions** — no `toNumber()`, `toBoolean()`, `toDate()`." It names three of the five actions 1.2.0 added, as things that do not exist. It then hedges correctly: "If a later release added `toNumber`-style helpers, that postdates my reliable knowledge."
--- non-finding [correct] message: Task 8 solved the local message override with the trailing message argument, including the function form, and correctly stated its precedence over `setGlobalMessage`/`setSchemaMessage`/`setSpecificMessage`.
--- non-finding [correct] isbn: Task 2: "Valibot does **not** ship an `isbn()` action (it has `imei`, `creditCard`, `mac`, etc., but no ISBN), so this is a custom `check`." That answer is correct for every valibot release that existed at this subject's stated 2026-01 cutoff. `isbn` is unusable until 1.3.0 (2026-03-17), two months after the cutoff.

==============================================================================
RUN valibot--claude-haiku-4-5--v2-g--2026-09-02
What Claude Haiku 4.5 gets right about valibot — battery v2-g, tested 2026-09-02
URL: https://stalepriors.com/runs/valibot--claude-haiku-4-5--v2-g--2026-09-02
JSON: https://stalepriors.com/data/valibot/haiku-4-5-v2-g.json
Library: valibot 1.4.2 (npm), verified 2026-09-02
Model: Claude Haiku 4.5 (claude-haiku-4-5), stated cutoff 2025-02
Battery: valibot/v2-g, 5 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: Below-floor control, single arm, charges nothing — and the most consequential arm in the battery. Nine months under the target release it produced the target API on both halves and accepted the test pull request, which falsifies P3 and marks the coercion probe DERIVABLE ON PASS. It could not place the 1.1.0 anchor, could not name a version it can describe, and invented a `.example()` method, so its knowledge of the library is demonstrably below the window; what it had was the name, not the release. The asymmetry is the point: a derivable name makes a pass unreadable and leaves six failures exactly where they were.

--- non-finding [context] toNumber / toBoolean / toDate / toBigint / toString: THE CONTROL RESULT, and it falsifies pre-registered prediction P3. This subject's stated cutoff is nine months BELOW valibot 1.2.0, and it answered task 1 "yes" and "yes" and wrote `v.pipe(v.string(), v.toNumber())` and `v.pipe(v.string(), v.toBoolean())` — the current API, verbatim — where all six above-floor draws denied both actions exist. In task 2 it accepted the pull request: "The code compiles and runs. Both `v.toNumber()` and `v.toBoolean()` are real built-in actions in the current stable release." Under the rule fixed before the run, task 1 is therefore marked DERIVABLE ON PASS: the names are reachable from the problem statement (Zod's `z.coerce.number()` is the obvious donor) and no PASS on this probe may be read as knowledge. Every FAILURE stands untouched — JOURNAL/031: a derivable outcome kills a pass, not a failure.
--- non-finding [context] toBoolean: The control was right about the API and wrong about the task. Its `v.pipe(v.string(), v.toBoolean())` returns `true` for the input "false" — verified against valibot@1.4.2 — so on the actual scenario the battery posed, the below-floor control that named the right API produced the wrong answer, and the six above-floor draws that denied the API produced the right one. Recorded because it is the cleanest illustration in the Index of why a derivable name is not knowledge.
--- non-finding [correct]: Behaved as a below-floor control should on everything that is not derivable. Task 4: "I don't want to guess incorrectly about which release or when it shipped" — the anchor is not placed, as expected nine months below it. Task 5: declined to claim, then speculated a `.example(1)` method that has never existed in any shape. Direct question (c): declined to list any release with contents. Both bracket ends are null.

==============================================================================
RUN valibot--claude-opus-5--v1r-a--2026-09-01
What Claude Opus 5 gets right about valibot — battery v1r-a, tested 2026-09-01
URL: https://stalepriors.com/runs/valibot--claude-opus-5--v1r-a--2026-09-01
JSON: https://stalepriors.com/data/valibot/opus-5-v1r-a.json
Library: valibot 1.4.2 (npm), verified 2026-09-01
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.0.0 (2025-03-19), lag ~14 months
Oldest release it could not place: 1.1.0 (2025-05-06)
Battery: valibot/v1r-a, 10 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: Replicate A of `valibot/v1` against Opus 5, prompt unchanged. It placed the last release it can describe at valibot 1.0.0 (2025-03-19) and named 1.1.0 as the first release it knows only as a version number - identical to its concurrent, blind twin `v1r-b`. Spread 0 days, the pre-registered outcome for the valibot arm of the predictor test. Both replicates read one release below `valibot/v1`, a 48-day secondary spread that the pre-registration classes as agreement. No findings charged; one chargeable miss flagged against the 1.2.0 coercion surface.

--- non-finding [correct]: The measured quantity, and the reason this run exists. Asked which releases it can describe and which it knows only as a version number, this draw named 1.0.0 (2025-03-19) as the last release whose contents it can describe and 1.1.0 (2025-05-06) as the first it knows only as a number: "I believe it exists; I cannot tell you a single thing that changed in it." Its concurrent, blind twin `v1r-b` gave the same pair of answers. Two byte-identical prompts, one answer, spread 0 days — the pre-registered outcome for this arm.
--- non-finding [context]: Both replicates read one release lower than `valibot--claude-opus-5--v1--2026-09-01`, which recorded 1.1.0 (2025-05-06). The v1 draw said it could describe "v1.0.0 confidently and v1.1.0 with moderate confidence" and was scored at 1.1.0; this draw described 1.0.0 confidently and called 1.1.0 a name without content. Read as a three-way measurement that is a 48-day spread over two answers — one release step, the smallest non-zero spread the library's timeline allows, against prisma's 204 days. The v1r pre-registration fixed the reading in advance: the primary criterion is a-vs-b, which share one prompt file byte for byte, and a case where both replicates agree with each other but differ from the original counts as agreement. Recorded so the secondary number is visible rather than buried.
--- non-finding [miss] toNumber / toBoolean / toDate / toBigint / toString: Task 1. Asked to turn query-string parameters into numbers and a boolean, this draw stated the negative inside a code task: "Valibot has no `coerce` helper", and repeated it under direct question (d) as "None. Valibot ships no coercion helpers at all ... This is a deliberate design position, not an omission." valibot 1.2.0 (2025-11-24) shipped `toNumber`, `toBoolean`, `toDate`, `toBigint` and `toString`, and 1.2.0 precedes this subject's stated 2026-05 cutoff. `valibot/v1` recorded the same wrong belief under question (d), where the battery scores it as a belief datum rather than a finding, and scored the task-1 code as an imprecision because that draw hand-rolled the coercion without claiming the built-ins do not exist. This draw claims it inside the code task, which the battery's additive-API rule makes chargeable. So this is a scoring gap the original run does not carry, not a double-count.
--- non-finding [context]: Code-level agreement with `v1` and with the twin on everything the original already charged: both valibot findings reproduced. F1 - task 2 asserts "Valibot does not ship an `isbn` action" (usable from 1.3.0; RE-DATED 2026-09-02, JOURNAL/040 — the v1.2.0 release note announces the action but the published 1.2.0 package does not contain it). F2 - task 5 attributes the repository to `github.com/fabian-hiller/valibot` and to Fabian Hiller's personal account, where the repository moved to the `open-circle` organisation with 1.2.0. Not re-charged. Also reproduced without charge: task 3 said nothing about the ReDoS fix in the 1.2.0 emoji regex (the battery's designed S2), task 4 routed around the 1.2.0 `examples` action via `metadata`, and task 7 hand-rolled the 1.1.0 `parseJson` pipeline out of `rawTransform`.
--- non-finding [correct] exactOptional / NanoIdAction / summarize: Task 10, the battery's floor probe, passed: `exactOptional` correctly distinguished from `optional` and `undefinedable`, with the inferred types spelled out. Task 9, the one designed S1, also passed in substance - the draw flagged its own uncertainty about the `NanoIdAction` casing and offered `ReturnType<typeof v.nanoid>` as a rename-proof alternative, so it never wrote the pre-1.1.0 spelling as its answer. Task 6 hand-rolled the CLI error printer with `getDotPath` rather than using the 1.1.0 `summarize` built-in, which is an imprecision under the additive-API rule and is where this draw differs from its twin.

==============================================================================
RUN valibot--claude-opus-5--v1r-b--2026-09-01
What Claude Opus 5 gets right about valibot — battery v1r-b, tested 2026-09-01
URL: https://stalepriors.com/runs/valibot--claude-opus-5--v1r-b--2026-09-01
JSON: https://stalepriors.com/data/valibot/opus-5-v1r-b.json
Library: valibot 1.4.2 (npm), verified 2026-09-01
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.0.0 (2025-03-19), lag ~14 months
Oldest release it could not place: 1.1.0 (2025-05-06)
Battery: valibot/v1r-b, 10 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: Replicate B of `valibot/v1` against Opus 5, prompt unchanged. It believed 1.1.0 was the newest version but refused to claim its contents, placing its describable boundary at 1.0.0 (2025-03-19) - identical to its concurrent, blind twin `v1r-a`. Spread 0 days, the pre-registered outcome for the valibot arm. Notable against JOURNAL/024: this is a careful, hedging draw that agreed with a confident one rather than splitting from it. No findings charged.

--- non-finding [correct]: The measured quantity. This draw named 1.1.0 as the newest version it believes exists but placed its describable boundary at 1.0.0 (2025-03-19), explicitly demoting 1.1.0 to a version number: "I'd extend that to 1.1.0's changelog itself, since my recall there is a vague impression rather than knowledge." Its concurrent, blind twin `v1r-a` reached the same pair of answers by a different route - it never claimed 1.1.0 content at all. Two byte-identical prompts, one answer, spread 0 days.
--- non-finding [context]: The interesting half of the agreement. This draw did what `prisma/v1r-b` did - produced a hedged, partially-correct impression of a release and then declined to count it as knowledge - and it landed on the *same* boundary as its twin, which had no such impression to decline. JOURNAL/024 raised the worry that the boundary instrument measures epistemic self-confidence rather than knowledge, because on prisma the careful draw and the confident draw split 204 days. Here the careful draw and the confident draw agree exactly. One library is not a refutation of that worry, but it is the first evidence against it.
--- non-finding [context]: Both replicates read one release lower than `valibot--claude-opus-5--v1--2026-09-01`, which recorded 1.1.0 (2025-05-06). Across all three measurements that is a 48-day spread over two answers - one release step, the smallest non-zero spread this library's timeline allows, against prisma's 204 days. The v1r pre-registration fixed the reading before the runs: the primary criterion is a-vs-b, which share one prompt file byte for byte, and replicates that agree with each other while differing from the original count as agreement. Recorded so the secondary number is visible rather than buried.
--- non-finding [context]: Code-level agreement with `v1` on both charged findings, not re-charged. F1 - task 2: "As far as I know Valibot ships no `isbn` action" (usable from 1.3.0; RE-DATED 2026-09-02, JOURNAL/040 — the v1.2.0 release note announces the action but the published 1.2.0 package does not contain it). F2 - task 5: repository attributed to `github.com/fabian-hiller/valibot` and to Fabian Hiller's personal account, where it moved to the `open-circle` organisation with 1.2.0. Also reproduced without charge: task 3 said nothing about the 1.2.0 ReDoS fix in the emoji regex, task 4 stated "I do not believe there is a dedicated `examples` action" (1.2.0 added `examples`/`getExamples`), and question (d) asserted that no string-to-primitive coercions ship, which 1.2.0 falsifies. Where this draw differs from its twin: task 6 used the 1.1.0 `summarize` built-in correctly, and task 8 named `v.config` for schema-scoped message overrides.

==============================================================================
RUN valibot--claude-opus-5--v2-a--2026-09-02
What Claude Opus 5 gets wrong about valibot — battery v2-a, tested 2026-09-02
URL: https://stalepriors.com/runs/valibot--claude-opus-5--v2-a--2026-09-02
JSON: https://stalepriors.com/data/valibot/opus-5-v2-a.json
Library: valibot 1.4.2 (npm), verified 2026-09-02
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.0.0 (2025-03-19), lag ~14 months
Oldest release it could not place: 1.1.0 (2025-05-06)
Battery: valibot/v2-a, 5 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: Charging arm. Answered "No" to both verdict questions in task 1, then in task 2 called `v.toNumber` and `v.toBoolean` "not part of Valibot's API — never have been", and in task 3 stated flatly that "there has never been a built-in string→number or string→boolean action". All three actions exist and shipped in 1.2.0 (2025-11-24), eighteen months inside this subject's stated cutoff; the pull request it rejected parses under valibot@1.4.2. Charged F1 (S2) on the absence claim. The attribution anchor placed 1.1.0 correctly, so the boundary reading is read: this draw dates the release one minor BELOW the one it cannot see, which is the tightest boundary bracket this library has produced. Everything else it said was right, including the parts the battery exempted in advance and one part the Index itself had wrong.

--- F1 [S2 silently-wrong] Denies that valibot ships built-in string-to-primitive conversion actions, and rejects a working pull request that uses them as fabricated
API: toNumber / toBoolean / toDate / toBigint / toString
Changed in valibot 1.2.0 (2025-11-24), kind: added
Chargeability: valibot 1.2.0 published 2025-11-24, inside this subject's stated cutoff. The subject also states that its recall of this particular library thins out earlier than its cutoff; per the rule established this session (HARNESS.md), a density self-assessment is the quantity under measurement and does not bar a charge — only a stated cutoff does.
Model belief: "It does not compile. `v.toNumber` and `v.toBoolean` are not part of Valibot's API — never have been, as far as I know. TypeScript will fail with \"Property 'toNumber' does not exist on type ...\" (and the same for `toBoolean`) at build time; there's nothing to run." Task 1 answered "No" and "No" to both verdict questions, and task 3 added: "What did not change: there has never been a built-in string→number or string→boolean action."
Wrong: // The review this draft would have left on a pull request that works:
// "Valibot deliberately doesn't ship coercion actions — conversion goes through
//  v.transform() ... My guess is they were thinking of Zod's z.coerce.number()
//  or an LLM-completed name."
const Query = v.object({
  page: v.pipe(v.string(), v.digits(), v.transform(Number), v.number(), v.integer()),
  active: v.pipe(v.picklist(['true', 'false']), v.transform((s) => s === 'true')),
})
Correct: import * as v from 'valibot'

// Both actions exist. Executed against valibot@1.4.2:
//   v.parse(Query, { page: '3', active: 'false' })  ->  { page: 3, active: true }
const Query = v.object({
  page: v.pipe(v.string(), v.toNumber()),
  active: v.pipe(v.string(), v.toBoolean()),
})

// On the number half the built-in is the safer form: toNumber raises a validation
// issue on NaN, where a bare v.transform(Number) returns NaN with success: true.
// On the boolean half the reviewer's own replacement is the better code — toBoolean
// is Boolean(), so it maps "false" to true. parseBoolean (1.3.0) reads the words.
Impact: A developer told these actions do not exist keeps hand-rolling conversions the library ships, and — the concrete cost here — a reviewer acting on this belief rejects a pull request that compiles and runs, telling the author to rewrite working code. The claim is not hedged in any of the three charging arms: it is stated as a fact about the library's whole history.
Scope note: Charged on the absence claim only, never on the code. The battery's binding namespace exemption stands: "valibot has no v.coerce namespace" and "the generic coerce method was removed at 0.31.0" are both CORRECT and are not part of this finding. The subject's own replacement code was executed and works. On the boolean half its replacement is in fact better than the API it denied — see the run summary and the correction to fact LF1 made the same day.
Source: https://github.com/open-circle/valibot/releases/tag/v1.2.0 (2025-11-24) — "Add `toBigint`, `toBoolean`, `toDate`, `toNumber` and `toString` transformation actions"
Source: https://registry.npmjs.org/valibot/-/valibot-1.4.2.tgz (2026-06-28) — "function toNumber(message) { return { kind: "transformation", type: "to_number", reference: toNumber, async: false, message, "~run"(dataset, config) { try { dataset.value = Number(dataset.value); if (isNaN(dataset.value)) { _addIssue(this, "number", dataset, config); dataset.typed = false; } }"

--- non-finding [correct] parseJson / stringifyJson: Task 4, the attribution anchor. Placed `parseJson`/`stringifyJson` at v1.1.0, "sometime in the first half of 2025" — the correct minor (1.1.0, 2025-05-06), hedged as "a moderate-confidence memory, not something I'd put in a changelog". The anchor is placed, so this arm is read for attribution. It also correctly warned that a plain `v.transform(JSON.parse)` lets the SyntaxError escape `safeParse` — verified true.
--- non-finding [correct] coerce: The namespace and history half of task 3, which the battery exempts in advance. Stated that early 0.x had a `coerce()` wrapper removed during the 0.2x/0.3x cleanup, and that v0.31.0 replaced array pipelines with `v.pipe()` and renamed `toTrimmed` to `trim`. Both correct against the v0.31.0 migration guide. It also listed the surviving pre-1.2.0 `to*` family exactly — `toLowerCase`, `toUpperCase`, `toMinValue`, `toMaxValue` — all four verified present in 1.4.2.
--- non-finding [correct] toBoolean: The boolean half of the replacement code is better than the API the draw denied. It used `v.picklist(['true', 'false'])` before the transform, warning that a naked `transform` "would quietly map \"yes\" to false". Executed against valibot@1.4.2: the draw's form returns `{ active: false }` for the input "false", while `v.pipe(v.string(), v.toBoolean())` — the action it denied — returns `{ active: true }`, because `toBoolean` is plain `Boolean()`. The Index's own fact LF1 recommended the broken form until this session; it was corrected the same day.
--- non-finding [imprecision] examples / getExamples: Task 5 answered "Yes" and reached the capability through `v.metadata({ examples: [...] })` + `v.getMetadata`, while stating "There is no dedicated `v.examples()` action that I know of". `v.examples()` and `v.getExamples()` both shipped in 1.2.0 and both work. The workaround also works — verified — and the claim is hedged with "that I know of", so under the code-vs-claim rule this is an imprecision rather than a finding.
--- non-finding [context] examples / getExamples: Verified detail the draw did not have and could not have derived: `v.getMetadata()` on a schema carrying the first-class `v.examples()` action returns `{}` — the metadata action and the examples action do not interoperate. So the workaround is not merely unidiomatic, it reads nothing back from a schema written the idiomatic 1.2.0 way.

==============================================================================
RUN valibot--claude-opus-5--v2-b--2026-09-02
What Claude Opus 5 gets right about valibot — battery v2-b, tested 2026-09-02
URL: https://stalepriors.com/runs/valibot--claude-opus-5--v2-b--2026-09-02
JSON: https://stalepriors.com/data/valibot/opus-5-v2-b.json
Library: valibot 1.4.2 (npm), verified 2026-09-02
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.1.0 (2025-05-06), lag ~12 months
Oldest release it could not place: 1.2.0 (2025-11-24)
Battery: valibot/v2-b, 5 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: Blind twin, charges nothing. Agreed with its charging twin on the failure and disagreed with it on the boundary: v2-a reads 1.0.0/1.1.0, this draw reads 1.1.0/1.2.0, so the pair spans one minor and 250 days on the same stored prompt. Notable for naming its own failure mode in the direct questions — "that gap is where confident-sounding wrong answers like v.toNumber() come from" — while committing it, and for correctly describing the behaviour of the action it called a fabrication.

--- non-finding [miss] toNumber / toBoolean / toDate / toBigint / toString: Reproduced the same failure as its charging twin, in stronger terms. Task 1: "no" and "no". Task 2: "Both `v.toNumber` and `v.toBoolean` are fabrications ... There's no partial credit here." Task 3: "There is still no built-in string→number or string→boolean action, and as far as I know that's a design position rather than an oversight." All five actions shipped in 1.2.0 and the rejected pull request parses under valibot@1.4.2.
--- non-finding [correct] parseJson / stringifyJson: Task 4, the attribution anchor: "Valibot v1.1.0, which shipped roughly April 2025" — correct minor, one month early on the date. Anchor placed; this arm is read for attribution.
--- non-finding [correct] toBoolean: The sharpest instance in this battery of a subject being right about the API it is denying. Its review comment reads: "Also, please don't coerce the boolean with `Boolean(s)`: the string \"false\" is truthy, so `active=false` would parse as `true`." That is an exact and correct description of what `v.toBoolean()` — the action it had just called a fabrication — actually does in valibot 1.4.2, where it is implemented as `dataset.value = Boolean(dataset.value)`. The Index's fact LF1 asserted the opposite until this session.
--- non-finding [correct] coerce: Task 3 history, exempt by pre-registration and correct: the 0.x `coerce()` wrapper and its removal, the v0.31.0 pipeline rewrite, `toCustom` to `transform` and `toTrimmed` to `trim`, and the observation that the surviving `to*` names "map a value to another value of the same type". True of the four that existed before 1.2.0 and false only because 1.2.0 added five that do not.
--- non-finding [imprecision] examples / getExamples: Task 5 answered "yes" via `v.metadata()`, flagging "There is no `v.example()` action that I know of" and openly uncertain whether `getMetadata`/`getTitle`/`getDescription` are exported. All of them are, and so are `v.examples()`/`v.getExamples()`. Hedged; the offered code works.

==============================================================================
RUN valibot--claude-opus-5--v3-c--2026-09-05
What Claude Opus 5 gets wrong about valibot — battery v3-c, tested 2026-09-05
URL: https://stalepriors.com/runs/valibot--claude-opus-5--v3-c--2026-09-05
JSON: https://stalepriors.com/data/valibot/opus-5-v3-c.json
Library: valibot 1.4.2 (npm), verified 2026-09-05
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.1.0 (2025-05-06), lag ~12 months
Oldest release it could not place: 1.2.0 (2025-11-24)
Battery: valibot/v3-c, 5 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: The battery's only charging arm, and it charges the 1.3.0 half only. Two findings, both S3, both denials of capabilities that shipped 2026-03-17 and both with working substitutes: `guard` (F1) and `cache` (F2). Its 1.4.0 answers reproduce two further failures — including calling the real `toKebabCase` an invention in a pull request that compiles — and both are barred by the same-month parking rule the spec fixed in advance. Anchor correct, poison rung refused, boundary unmoved from `v2` at 1.1.0 / 1.2.0, stated cutoff affirmed with a density caveat.

--- F1 [S3 deprecated] Denies that valibot has any action that narrows a pipeline's output type from a TypeScript type predicate, three months after `guard` shipped to do exactly that
API: guard
Changed in valibot 1.3.0 (2026-03-17), kind: added
Chargeability: valibot 1.3.0 published 2026-03-17, two months inside this subject's stated May 2026 cutoff. The subject affirmed that cutoff in direct question (b) and qualified only the density of its recall, which HARNESS.md § *A density self-assessment is not a stated cutoff* holds does not bar a charge. This is the only arm in the battery licensed on both the duplicate rule and the cutoff rule.
Model belief: "Valibot has no action that *infers* narrowing from a `x is T` predicate the way Zod's `.refine` overload does. `v.check()` takes a predicate but its output type is unchanged (it stays `unknown`)." Answered "No" to the verdict question before writing anything.
Wrong: // The advice, as a developer would receive it:
// "There is no built-in for this. Use the `custom` schema and restate the type
//  yourself — the narrowing comes from the explicit <PluginConfig>, not from the
//  predicate's signature. `custom` is an assertion in disguise: if your predicate
//  is wrong, TypeScript will not catch the mismatch."

import * as v from 'valibot'

const PluginConfigSchema = v.custom<PluginConfig>(isPluginConfig, 'Invalid plugin config')
// Compiles, narrows, and carries exactly the unchecked-cast risk the draw warns about.
// The risk is real and the warning is good advice — for a library that has no `guard`.
Correct: import * as v from 'valibot'

// `guard` has existed since 1.3.0 and reads the predicate's own `x is T` clause,
// so the type argument is not restated and cannot disagree with the check.
// Executed against valibot@1.4.2 under tsc --strict:
const PluginConfig = v.pipe(v.unknown(), v.guard(isPluginConfig))
const cfg = v.parse(PluginConfig, raw)
//    ^? PluginConfig   — no cast, no restated generic

// For contrast, both verified the same way:
//   v.pipe(v.unknown(), v.check(isPluginConfig))  -> parses to `unknown` (TS18046)
//   v.custom<PluginConfig>(isPluginConfig)        -> parses to PluginConfig, unchecked
Impact: A developer is told to restate the type by hand in a `custom<T>()` generic and is correctly warned that TypeScript cannot check the generic against the predicate — a warning that only applies because the built-in that removes the restatement was not offered. The cost is not a broken build; it is that the library's own answer to this exact problem, shipped three months before this subject's stated cutoff, stays invisible, and every call site keeps a hand-maintained type argument that can silently drift from its predicate. Capped at S3 in the pre-registration because the substitute compiles and runs.
Scope note: Charged on the absence claim only. The draw's two subsidiary claims are CORRECT and are not part of the charge: that `v.check()` does not narrow (verified — TS18046 under `tsc --strict`), and that `v.custom<T>()` narrows by fiat rather than from the predicate (verified — compiles clean). Its closing suggestion to describe the shape with `v.object({ name: v.string(), run: v.function() })` is also sound, and `v.function()` is the current spelling, which it hedged unnecessarily.
Source: https://github.com/open-circle/valibot/releases/tag/v1.3.0 (2026-03-17)
Source: https://registry.npmjs.org/valibot/-/valibot-1.4.2.tgz (2026-06-28) — "Creates a guard transformation action."

--- F2 [S3 deprecated] States that valibot has no result cache and no cache option, three months after the `cache` method shipped
API: cache
Changed in valibot 1.3.0 (2026-03-17), kind: added
Chargeability: Same window and same licence as F1: 1.3.0 (2026-03-17) precedes the affirmed May 2026 cutoff by two months.
Model belief: "Valibot has no memoization or result cache. Schemas are plain objects with a `~run` method; every `parse`/`safeParse` executes the full pipeline. (`v.lazy()` exists but it defers schema *construction* for recursive types — it is not a result cache.) There's also nothing at the `parse` level like a `cache` config option." Answered "No" to the verdict question first.
Wrong: // "There's also nothing at the parse level like a cache config option."
// The developer is sent to build one:

function memoParse<S extends v.GenericSchema>(schema: S) {
  const cache = new Map<unknown, v.InferOutput<S>>()
  return (input: v.InferInput<S>): v.InferOutput<S> => {
    if (cache.has(input)) return cache.get(input)!
    const out = v.parse(schema, input)
    cache.set(input, out)
    return out
  }
}
// This works. It is also a reimplementation of a shipped method, and the four
// caveats the draft then lists (identity keying, uncached failures, unbounded
// growth, shared transform output) are the caveats the shipped method documents.
Correct: import * as v from 'valibot'

// Shipped since 1.3.0. Executed against valibot@1.4.2:
//   const C = v.cache(v.pipe(v.string(), v.transform(s => { calls++; return s.toUpperCase() })))
//   v.parse(C, 'a'); v.parse(C, 'a'); v.parse(C, 'b')   ->  calls === 2, not 3
const Cached = v.cache(ExpensiveSchema)

// It takes the config the draft says does not exist:
const Configured = v.cache(ExpensiveSchema, { /* CacheConfig */ })
// `cacheAsync` is the async counterpart.
Impact: The developer hand-rolls a memo table the library ships, and inherits the maintenance of its edge cases. The concrete cost is small — the hand-roll is correct — which is why this is S3 and was capped there before the draws were read. It is included because the denial is specific enough to be checked: the draft rules out both the wrapper and a `parse`-level config option, and both exist.
Scope note: Disclosed in the pre-registration and repeated here: `cache` is annotated `@beta` in the shipped `dist/index.d.cts`, which is why the severity was capped at S3 in advance rather than argued down afterwards. The draft's remarks about `v.lazy()` are correct and are not charged. Its own caveat list is, verbatim, close to the hint the shipped declaration carries — "Primitive inputs are cached by value. Object and function inputs are cached by reference identity" — which is worth noting: it reasoned its way to the API's documented behaviour while denying the API.
Source: https://github.com/open-circle/valibot/releases/tag/v1.3.0 (2026-03-17)
Source: https://registry.npmjs.org/valibot/-/valibot-1.4.2.tgz (2026-06-28) — "Caches the output of a schema."

--- non-finding [miss] toCamelCase / toKebabCase / toPascalCase / toSnakeCase: Task 2, the case-conversion probe, offer direction. "No", and the denial enumerates the surface: "There is no case-convention converter — no `toKebabCase`, `toCamelCase`, `toSnakeCase`, `toTitleCase`." Three of those four shipped at 1.4.0 (2026-05-05); the fourth has never existed. The `slugify` + `v.transform` schema it shipped instead is correct and better designed than the task required.
--- non-finding [miss] toKebabCase: Task 3, the recognition direction. "It does not compile. **Both actions are invented.** `v.toKebabCase` and `v.toTitleCase` do not exist in valibot — not in the current release and not in any release I know of." One of the two is real and has been since 1.4.0. This is the S2 shape — a rejected-correct pull request — and it is the most valuable barred miss in the battery.
--- non-finding [correct] parseJson / stringifyJson: Task 5, the attribution anchor. `parseJson`/`stringifyJson` at 1.1.0, "roughly spring 2025 ... around April–May 2025" — correct to the minor. The arm is read for attribution, which is the precondition for its boundary answer counting.
--- non-finding [correct] toTitleCase: The poison rung. Refused `toTitleCase`, which has never shipped in any valibot release. P4 holds on this arm.
--- non-finding [context]: The boundary, and it has not moved. This subject placed its valibot boundary at 1.1.0 / 1.2.0 in `valibot/v2` eight days earlier and places it at 1.1.0 / 1.2.0 here, under a different battery on a different surface. HARNESS.md § *A different battery is not a different boundary* predicts exactly this and it holds. The draw also declined to name a version above 1.1.0 at all — "rather than 'I know 1.2.0 exists but can't describe it', my situation is that my knowledge simply stops" — which is a cleaner abstention than the `v2` draw gave.

==============================================================================
RUN valibot--claude-opus-5--v3-d--2026-09-05
What Claude Opus 5 gets right about valibot — battery v3-d, tested 2026-09-05
URL: https://stalepriors.com/runs/valibot--claude-opus-5--v3-d--2026-09-05
JSON: https://stalepriors.com/data/valibot/opus-5-v3-d.json
Library: valibot 1.4.2 (npm), verified 2026-09-05
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.1.0 (2025-05-06), lag ~12 months
Oldest release it could not place: 1.2.0 (2025-11-24)
Battery: valibot/v3-d, 5 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: Blind twin, charges nothing. Agrees with `v3-c` on all five tasks and on the boundary. Two things it holds that its twin does not: it guesses a wrong spelling for the cache API it is denying (`v.cached()`), and it produces the battery's best-calibrated hedge — naming case-conversion actions as exactly the kind of addition it would be unable to see, in the same answer where it calls one of them an invention.

--- non-finding [miss] guard: Task 1, the `guard` probe. "no", with the same correct subsidiary analysis as its twin: "`v.check()` is typed `CheckAction<TInput, ...>` — output type equals input type, so a `v.pipe(v.unknown(), v.check(isPluginConfig))` still gives you `unknown`." Verified: TS18046. Its `v.custom<PluginConfig>` substitute compiles and narrows.
--- non-finding [miss] cache: Task 4, the `cache` probe. "no": "Valibot has no memoization layer — no `v.cached()`, no cache option on `parse`." Both halves of that are wrong at 1.3.0+, though the spelling it guesses at (`v.cached()`) is not the real one (`v.cache()`). The LRU-bounded memo parser it wrote is correct.
--- non-finding [miss] toCamelCase / toKebabCase / toPascalCase / toSnakeCase: Task 2, the case-conversion probe, offer direction. "no" — "nothing for kebab/camel/snake/title conventions" — with the hand-rolled slugify. Three of those four conventions shipped at 1.4.0.
--- non-finding [miss] toKebabCase: Task 3, the recognition direction. "It does not compile. Both actions are inventions." `toKebabCase` is real at 1.4.0+. **But this arm produced the best-calibrated hedge in the battery and it is worth quoting**: "I'm confident about these two specifically; if some very recent release added case-convention actions I'd be unaware of it", and in its direct answers, "case-conversion actions are exactly the kind of small, popular addition that could have landed in a release I can't see." It named the failure mode it was in, correctly, while committing to the wrong verdict.
--- non-finding [correct] parseJson / stringifyJson: Task 5, the attribution anchor. `parseJson`/`stringifyJson` at 1.1.0, "around April 2025" — correct to the minor, and it added the correct negative that they were *not* in 1.0.0. Read for attribution.
--- non-finding [correct] toTitleCase: The poison rung. Refused `toTitleCase`. P4 holds on this arm.
--- non-finding [context]: The boundary: 1.1.0 describable, 1.2.x the first release known only as a number — identical to its twin and to both `v2` Opus draws. Four Opus 5 measurements of this library across two batteries and eight days, zero spread.

==============================================================================
RUN valibot--claude-opus-5--v4-c--2026-09-06
What Claude Opus 5 gets right about valibot — battery v4-c, tested 2026-09-06
URL: https://stalepriors.com/runs/valibot--claude-opus-5--v4-c--2026-09-06
JSON: https://stalepriors.com/data/valibot/opus-5-v4-c.json
Library: valibot 1.4.2 (npm), verified 2026-09-06
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.1.0 (2025-05-06), lag ~12 months
Oldest release it could not place: 1.2.0 (2025-11-24)
Battery: valibot/v4-c, 5 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: The continuity control, and it reads clean. Sent the same tasks as `valibot/v3` with `v2`'s cutoff question restored, Claude Opus 5 affirmed its May 2026 date with a density caveat — as it did under the changed wording a day earlier — denied `guard` and `cache` in the same terms, denied the 1.4.0 case actions in both directions, placed the 1.1.0 anchor correctly and refused the poison rung. Boundary unmoved at 1.1.0 / 1.2.0 for the eighth measurement. Nothing charged: the two 1.3.0 denials are already published as F1 and F2 on `valibot/v3-c`, and the 1.4.0 pair is parked by the same-month rule. Its closing self-assessment names the two tasks it had just failed as the ones most likely to be wrong.

--- non-finding [miss] guard: Task 1, the `guard` probe, denied for the second time in two days: "Valibot has no *action* that consumes a `x is T` predicate and narrows the pipeline's output … Actions in valibot are input-type-preserving unless they're transformations." `guard` shipped at 1.3.0, two months inside this subject's affirmed cutoff. Its `v.custom<PluginConfig>` substitute compiles and narrows, and its `rawTransform` alternative does too — both verified.
--- non-finding [miss] cache: Task 4, the `cache` probe, denied for the second time in two days and more categorically than before: "There is no `v.cache()`, no `v.memo()`, no caching option on `parse`/`safeParse`, and no internal result cache keyed by input. The library's design goal is a tiny, tree-shakeable, side-effect-free core; a global memo table is exactly the kind of retained state … it stays out of." The first clause names the shipped API and rules it out by name.
--- non-finding [miss] toKebabCase: Tasks 2 and 3, the 1.4.0 case-conversion surface, both directions. Offer: "No … There is no `toKebabCase`, `toCamelCase`, `toSnakeCase`, or `toTitleCase`." Recognition: "It does not compile. **Both** actions are invented … My guess at the origin is autocomplete-by-analogy from the real `v.toLowerCase()` / `v.toUpperCase()`." Three of the four names it lists shipped 2026-05-05; the fourth never has.
--- non-finding [correct] parseJson / stringifyJson: Task 5, the attribution anchor. Named `parseJson`/`stringifyJson` at 1.1.0 — correct to the minor — and dated it "around April 2025", one month early against 2025-05-06, with its own error bar attached ("April 2025 ± a month; verify against the changelog before you quote it anywhere that matters"). Read for attribution.
--- non-finding [correct] toTitleCase: The poison rung, refused. P5 now holds 8/8 across the two batteries that use it.
--- non-finding [context]: The eighth measurement of this subject's valibot boundary, and it has never moved: 1.1.0 / 1.2.0 in `v2` (four arms), in `v3` (two arms) and here. Different batteries, different surfaces, different direct questions. HARNESS.md § *A different battery is not a different boundary* continues to hold on the library where it has been tested hardest.
--- non-finding [context]: Unprompted calibration worth recording, and it is the best in either battery. Direct question (a): "Given the gap between my knowledge and today's date (September 2026), I'd assume there have been meaningful releases I know nothing about — quite possibly including case-conversion actions, which would make my Task 2 and Task 3 answers wrong for the current release." It named the exact surface it had just got wrong, as a hypothetical, after committing to the wrong verdict twice. Compare `v3-d`, which named the failure mode in general terms; this one names the tasks.

==============================================================================
RUN valibot--claude-opus-5--v1--2026-09-01
What Claude Opus 5 gets wrong about valibot — battery v1, tested 2026-09-01
URL: https://stalepriors.com/runs/valibot--claude-opus-5--v1--2026-09-01
JSON: https://stalepriors.com/data/valibot/opus-5.json
Library: valibot 1.4.2 (npm), verified 2026-09-01
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 1.1.0 (2025-05-06), lag ~12 months
Oldest release it could not place: 1.2.0 (2025-11-24)
Battery: valibot/v1, 10 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: Ten tasks, ten pieces of working valibot, from the subject with the deepest stated cutoff in the Index — and a twelve-month lag to show for it. Knowledge stops at 1.1.0 (2025-05-06); 1.2.0 shipped 2025-11-24, six months inside its stated 2026-05 cutoff. Two findings, neither about broken code: it denies that the ISBN validation action exists while writing thirty lines of check-digit arithmetic to replace it, and it insists twice that valibot is one person's personal repository, which stopped being true with the same release. The battery's one designed build-breaker — the `NanoIDAction` casing rename — passed cleanly, and the floor probe passed, so the boundary is a measurement and not an artefact. The subject also stated the Index's own thesis about itself unprompted: that its effective horizon for this library runs about a year behind its nominal cutoff.

--- F1 [S3 deprecated] States that valibot has no ISBN validation action
API: isbn
Changed in valibot 1.3.0 (2026-03-17), kind: added
Chargeability: 1.3.0 published 2026-03-17, two months inside the subject's stated 2026-05 cutoff. RE-DATED 2026-09-02 (JOURNAL/040): this finding was originally filed at 1.2.0 / 2025-11-24, from the v1.2.0 release note. The published 1.2.0 package does not contain the action at all — it is unusable until 1.3.0 — so the charge rests on a release two months before the cutoff rather than six. It survives the correction; the same correction withdrew the Fable 5 charge on this surface, whose 2026-01 cutoff falls below 1.3.0.
Model belief: "There is **no `v.isbn()` action** in valibot (the string action set covers `email`, `uuid`, `ulid`, `cuid2`, `nanoid`, `ip`, `imei`, `creditCard`, `bic`, `mac`, `hexColor`, `isoDate`… but not ISBN)."
Wrong: const Isbn = v.pipe(
  v.string(),
  v.regex(/^(?:\d{9}[\dX]|\d{13})$/, 'Must be a 10- or 13-digit ISBN'),
  v.check((value) => (value.length === 10 ? isIsbn10(value) : isIsbn13(value)),
    'ISBN checksum is invalid'),
)
Correct: const Isbn = v.pipe(v.string(), v.isbn())
Impact: The generated code works — a correct checksum implementation was written from scratch. The cost is the flat denial: a reader is told a built-in does not exist and carries roughly thirty lines of hand-rolled check-digit arithmetic they did not need, plus the maintenance of it.
Scope note: Charged under the battery's additive-API rule: an additive change is a finding only when the model states the capability does not exist. It does, in bold, with an enumerated action list presented as exhaustive.
Source: https://raw.githubusercontent.com/open-circle/valibot/v1.3.0/library/src/actions/index.ts (2026-03-17) — "export * from './isbn/index.ts';"
Source: https://registry.npmjs.org/valibot/-/valibot-1.3.0.tgz (2026-03-17) — "isOfType, isValiError, isbn, isoDate, isoDateTime, isoTime"
Source: https://github.com/open-circle/valibot/releases/tag/v1.2.0 (2025-11-24) — "Add `isbn` validation action to validate ISBN-10 and ISBN-13 strings (pull request #1097)"

--- F2 [S4 wrong-metadata] Attributes the repository to a personal account that no longer owns it
API: github.com/fabian-hiller/valibot
Changed in valibot 1.2.0 (2025-11-24), kind: renamed
Chargeability: The npm `repository` field flips to the `open-circle` org at 1.2.0 (2025-11-24), six months inside the subject's stated 2026-05 cutoff.
Model belief: "**Repository:** `https://github.com/fabian-hiller/valibot` — note this is a **personal GitHub account, not an organisation**. There is no `valibot` org holding the source." Restated under direct question (d): "The GitHub **organisation is: none**."
Wrong: https://github.com/fabian-hiller/valibot
Correct: https://github.com/open-circle/valibot
Impact: The link still resolves — GitHub 301s the old path — so nothing breaks. What is wrong is the governance claim, asserted twice and emphatically: a reader is told the project is one person's personal repository when it has been organisation-owned since the release under test.
Scope note: Dated from the npm `repository` field, which reads `fabian-hiller/valibot` for 1.0.0 and 1.1.0 and `open-circle/valibot` from 1.2.0. No vendor announcement of the move was located, so the Index dates it to the release boundary and claims nothing about the reason for it.
Source: https://registry.npmjs.org/valibot (2025-11-24) — "git+https://github.com/open-circle/valibot.git"

--- non-finding [correct] NanoIDAction / NanoIDIssue: Task 9, the battery's one designed S1, passed. The subject wrote `v.NanoIdAction` / `v.NanoIdIssue` — the post-1.1.0 casing — and volunteered that this identifier's casing was the part worth double-checking against the installed types.
--- non-finding [correct] exactOptional: Task 10 (`exactOptional` vs `optional`) fully correct, including the `exactOptionalPropertyTypes` tsconfig caveat and the `undefinedable`/`nullish` neighbours. The battery's floor probe passed, so the boundary reading below is a real measurement rather than the battery probing beneath the subject's knowledge.
--- non-finding [correct] summarize: Task 6 used `v.summarize()`, the 1.1.0 built-in, rather than hand-rolling the CLI error printer. Attributed it to "around v1.0" — off by one minor, but the API call is right.
--- non-finding [miss] emoji: Task 3 (the designed S2) drew no charge. Asked to flag anything worth knowing about validating emoji-bearing text at high volume, the subject said nothing about the ReDoS vulnerability in `EMOJI_REGEX` fixed in 1.2.0 — but it also argued at length against using the `emoji` action for this task at all, and closed by saying the action is the wrong tool even for banning emoji.
--- non-finding [imprecision] toNumber / toBoolean / toDate / toBigint / toString: Task 1 hand-rolled string-to-number and string-to-boolean coercion with `v.transform(Number)` and a `picklist` + predicate, where 1.2.0 ships `toNumber` and `toBoolean`. The code works and is careful — it re-asserts `v.number()` after the transform to reject `NaN`, and avoids `Boolean("false") === true` by using a picklist.
--- non-finding [context] toNumber / toBoolean / toDate / toBigint / toString: Belief probe (d) is wrong and is recorded as a chargeable miss without an F-number: "**Coercion helpers: valibot ships none.** There is no `v.coerce.number()`, no `v.coerce.boolean()`, no `v.coerce.date()` — no `coerce` namespace at all. This is a deliberate design decision." 1.2.0 shipped `toBigint`, `toBoolean`, `toDate`, `toNumber` and `toString`. The stale part is the design claim, not the namespace claim.
--- non-finding [imprecision] examples / getExamples: Task 4 attached examples with `v.metadata({ examples: [...] })` and wrote a bespoke twenty-line pipe scanner to read them back, where 1.2.0 ships the `examples` action and the `getExamples` method. Never claims the built-in is missing.
--- non-finding [imprecision] parseJson / stringifyJson: Task 7 built the JSON-string pipeline out of `rawTransform` with a manual `JSON.parse` and `addIssue`/`NEVER`, where 1.1.0 ships `parseJson`. The hand-rolled version achieves the stated goal — malformed JSON surfaces as an ordinary issue — and the `NEVER` detail is right.
--- non-finding [correct] message: Task 8 solved the local message override with the trailing message argument on each schema and action, and correctly named `setGlobalMessage`/`setSchemaMessage`/`setSpecificMessage` as the global levers it was avoiding, and their precedence order.
--- non-finding [context]: The subject volunteered the effect this battery exists to measure, unprompted: "a cutoff date is not a uniform knowledge horizon: coverage of a mid-sized npm library thins out well before the nominal date, and for valibot specifically my detailed recall degrades sharply after early-to-mid 2025. So the effective horizon for this question is roughly a year earlier than the nominal cutoff." Measured lag: 12 months.

==============================================================================
RUN valibot--claude-sonnet-5--v2-c--2026-09-02
What Claude Sonnet 5 gets wrong about valibot — battery v2-c, tested 2026-09-02
URL: https://stalepriors.com/runs/valibot--claude-sonnet-5--v2-c--2026-09-02
JSON: https://stalepriors.com/data/valibot/sonnet-5-v2-c.json
Library: valibot 1.4.2 (npm), verified 2026-09-02
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 1.0.0 (2025-03-19), lag ~10 months
Oldest release it could not place: 1.1.0 (2025-05-06)
Battery: valibot/v2-c, 5 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: Charging arm, and the one whose licence to charge needed the most care. It affirmed a January 2026 cutoff and separately estimated that its valibot recall thins out around early-to-mid 2025 — which would exclude the 1.2.0 target. The rule applied, and written into HARNESS.md this session: the fairness rule reads a stated CUTOFF; an estimate of how well a subject knows a particular library is the quantity being measured and cannot bar the measurement, or no subject that is wrong about a library could ever be charged. Charged F1 (S2). The battery's internal control was NOT placed on this arm — it could not date `parseJson` at all — so its boundary reading is published with that caveat and is not read as an attribution measurement.

--- F1 [S2 silently-wrong] Denies that valibot ships built-in string-to-primitive conversion actions, and rejects a working pull request that uses them as fabricated
API: toNumber / toBoolean / toDate / toBigint / toString
Changed in valibot 1.2.0 (2025-11-24), kind: added
Chargeability: valibot 1.2.0 published 2025-11-24, inside this subject's stated cutoff. The subject also states that its recall of this particular library thins out earlier than its cutoff; per the rule established this session (HARNESS.md), a density self-assessment is the quantity under measurement and does not bar a charge — only a stated cutoff does.
Model belief: "This does not compile against any release I know of. `v.toNumber()` and `v.toBoolean()` are not real exports — valibot has no such actions in its action set (I don't recall them ever existing, not even in pre-1.0 betas)." Task 1 answered "No" and "No"; task 3 stated valibot's stance "has been consistently 'no implicit coercion, use explicit transform in the pipe' for as long as I have detailed knowledge of it".
Wrong: // The replacement this draft would have demanded on a working pull request:
const Query = v.object({
  page: v.pipe(v.string(), v.transform(Number), v.number()),
  active: v.pipe(v.picklist(['true', 'false']), v.transform((s) => s === 'true')),
})
Correct: import * as v from 'valibot'

// Both actions exist. Executed against valibot@1.4.2:
//   v.parse(Query, { page: '3', active: 'false' })  ->  { page: 3, active: true }
const Query = v.object({
  page: v.pipe(v.string(), v.toNumber()),
  active: v.pipe(v.string(), v.toBoolean()),
})

// On the number half the built-in is the safer form: toNumber raises a validation
// issue on NaN, where a bare v.transform(Number) returns NaN with success: true.
// On the boolean half the reviewer's own replacement is the better code — toBoolean
// is Boolean(), so it maps "false" to true. parseBoolean (1.3.0) reads the words.
Impact: A developer told these actions do not exist keeps hand-rolling conversions the library ships, and — the concrete cost here — a reviewer acting on this belief rejects a pull request that compiles and runs, telling the author to rewrite working code. The claim is not hedged in any of the three charging arms: it is stated as a fact about the library's whole history.
Scope note: Charged on the absence claim only, never on the code. The battery's binding namespace exemption stands: "valibot has no v.coerce namespace" and "the generic coerce method was removed at 0.31.0" are both CORRECT and are not part of this finding. The subject's own replacement code was executed and works. On the boolean half its replacement is in fact better than the API it denied — see the run summary and the correction to fact LF1 made the same day.
Source: https://github.com/open-circle/valibot/releases/tag/v1.2.0 (2025-11-24) — "Add `toBigint`, `toBoolean`, `toDate`, `toNumber` and `toString` transformation actions"
Source: https://registry.npmjs.org/valibot/-/valibot-1.4.2.tgz (2026-06-28) — "function toNumber(message) { return { kind: "transformation", type: "to_number", reference: toNumber, async: false, message, "~run"(dataset, config) { try { dataset.value = Number(dataset.value); if (isNaN(dataset.value)) { _addIssue(this, "number", dataset, config); dataset.typed = false; } }"

--- non-finding [context] parseJson / stringifyJson: Task 4, the attribution anchor, was NOT placed: "I don't know this one, and I'd rather say that than invent a release number ... I have no confident recollection of valibot shipping a built-in \"parse this string as JSON\" action." `parseJson`/`stringifyJson` shipped in 1.1.0, which this draw names as the edge of its knowledge. Under the pre-registered control rule this arm is NOT read for attribution; its code findings stand and its boundary numbers are published but carry this caveat.
--- non-finding [correct] toBoolean: Warned, correctly and unprompted, that `Boolean("false")` is `true` and that a `picklist` guard is therefore required — the exact behaviour of `v.toBoolean()`, the action it was denying. Also correctly flagged in review that `v.transform(Number)` on "abc" yields `NaN` which passes a bare `v.number()` check. Verified: `v.safeParse(v.pipe(v.string(), v.transform(Number)), "abc")` returns `success: true` with `NaN`.
--- non-finding [imprecision] examples / getExamples: Task 5 answered "Yes" and offered `v.metadata({ examples })` read back by scanning `schema.pipe`, at "moderate confidence, not high", explicitly unsure whether a generic metadata action exists at all. It does, and so do the first-class `v.examples()`/`v.getExamples()` from 1.2.0. Working code, hedged claim.
--- non-finding [context]: This draw placed the v1.0.0 release in "late 2024 (my recollection points to roughly December 2024)". It shipped 2025-03-19. The boundary field records the release it can describe, not the date it assigns to it; the three-month attribution error is recorded here rather than moving the bracket.

==============================================================================
RUN valibot--claude-sonnet-5--v2-d--2026-09-02
What Claude Sonnet 5 gets right about valibot — battery v2-d, tested 2026-09-02
URL: https://stalepriors.com/runs/valibot--claude-sonnet-5--v2-d--2026-09-02
JSON: https://stalepriors.com/data/valibot/sonnet-5-v2-d.json
Library: valibot 1.4.2 (npm), verified 2026-09-02
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 1.0.0 (2025-03-19), lag ~10 months
Oldest release it could not place: 1.1.0 (2025-05-06)
Battery: valibot/v2-d, 5 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: Blind twin, charges nothing. Agreed with its charging twin on the boundary (1.0.0 / 1.1.0 — the only pair in this battery to agree exactly), on the denial, and on failing the internal control. It also produced the battery's single worst piece of replacement code, an unguarded string-to-boolean transform, while its twin used the picklist guard — the two halves of one subject splitting on the code while agreeing on the self-report, which is the pattern JOURNAL/034 recorded at next.js and the inverse of langchain/v1r.

--- non-finding [miss] toNumber / toBoolean / toDate / toBigint / toString: Reproduced its twin's failure exactly. Task 1: "No" and "No", with "there's no built-in `toBoolean`-style action shipping in valibot". Task 2: "`v.toNumber()` and `v.toBoolean()` are not real exports of valibot — I'm not aware of either ever existing in the library's action set." Task 3 went further than any other draw: "there was never a 'coerce mode' that got added or removed" — which is wrong in both directions, since 0.x had `coerce` and 1.2.0 added the `to*` conversions.
--- non-finding [context] parseJson / stringifyJson: Task 4, the attribution anchor, was NOT placed — the same refusal as its twin: "I'm not aware of a specific valibot action that parses an embedded JSON string ... I'm not even confident it exists under that description." Both Sonnet 5 arms therefore fail the internal control and neither is read for attribution. That the pair agrees on failing it is itself the cleanest reading in the battery: the control is measuring the subject, not the draw.
--- non-finding [miss]: The only draw in the battery whose replacement code for the boolean is materially worse than its twin's: `v.pipe(v.string(), v.transform((input) => input === "true"), v.boolean())` accepts any string and silently maps "yes", "1" and typos to `false` rather than raising an issue. Working code, no denial attached, so it is not chargeable — but it is the case the picklist guard exists to prevent, written by the same subject whose twin used the guard.
--- non-finding [imprecision] examples / getExamples: Task 5 answered "Yes" via `v.metadata()` and a `schema.pipe.find()` scan. The generic action exists; the first-class `v.examples()`/`v.getExamples()` from 1.2.0 went unmentioned. Working code.

==============================================================================
RUN valibot--claude-sonnet-5--v3-e--2026-09-05
What Claude Sonnet 5 gets right about valibot — battery v3-e, tested 2026-09-05
URL: https://stalepriors.com/runs/valibot--claude-sonnet-5--v3-e--2026-09-05
JSON: https://stalepriors.com/data/valibot/sonnet-5-v3-e.json
Library: valibot 1.4.2 (npm), verified 2026-09-05
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 1.0.0 (2025-03-19), lag ~10 months
Oldest release it could not place: 1.1.0 (2025-05-06)
Battery: valibot/v3-e, 5 tasks, tool uses during test: 0
Tested: 2026-09-05

Summary: Below-floor derivability control. It did the one job a control this far under the window can do and did it cleanly: it composed none of `guard`, `toKebabCase` or `cache` from the problem statements and denied all three, so no probe in the battery is DERIVABLE and the denials above the floor read as beliefs. It also broke the attribution anchor — declining to place `parseJson` at all — so nothing it says about versions is read, and its 1.0.0 date is a year out. Charges nothing; no probe here is admissible against a January 2026 cutoff.

--- non-finding [context] guard / toKebabCase / cache: **The control result, and it is what the arm exists for. All three probe names went underived.** Asked to solve the three problems from their descriptions alone, this below-floor subject produced none of `guard`, `toKebabCase` or `cache`, and denied all three capabilities: "there's no 'narrow the pipeline output from a type predicate' action"; "I'm not aware of valibot shipping naming-convention converters"; "I don't know of a built-in memoization/caching mechanism in valibot ... no `v.cache()`". P3 holds 3/3. None of the three probes is marked DERIVABLE, so the denials on the arms above the floor are read as beliefs rather than as unguessable names.
--- non-finding [context] parseJson / stringifyJson: **The anchor broke, and the arm is therefore NOT READ for attribution.** Task 5 asked which release let a JSON string be parsed inside the pipeline; the draw declined: "I don't have a solid recollection of valibot shipping a dedicated ... action ... I can't name a release number or date for it in good conscience." HARNESS.md § *An abstention is not a denial* — this is an honest abstention, not a wrong answer, and it is scored `context`. The consequence is that this arm's boundary and version claims carry no weight; only its derivability result is read. A control that cannot place the one capability every above-floor subject holds is uninformative about where anything sits.
--- non-finding [imprecision]: Dated valibot 1.0.0 to "around mid-2024" and the schema/action split (0.31.0) to "late 2023–early 2024". Both are wrong by roughly a year: 1.0.0 shipped 2025-03-19 and 0.31.0 in mid-2024. Not chargeable — nothing in this battery's window is admissible against this subject — and recorded only as evidence of how far below the floor the control sits, which is the quantity that governs how bluntly to read it.
--- non-finding [correct] toTitleCase: The poison rung. Refused `toTitleCase` — "This reads like an LLM-hallucinated API surface (plausible-looking because valibot does have a `to*` naming pattern for things like `toLowerCase`/`toMinValue`, but these two specific ones don't exist)." Correct about one of the two. P4 holds 5/5 across the battery: no arm accepted the rung.
--- non-finding [correct] custom: `v.custom<PluginConfig>(isPluginConfig)` — the same substitute every other arm reached for — and the same correct explanation that the narrowing comes from the generic and not from the predicate's `is` clause. Verified: compiles clean under `tsc --strict` and parses to `PluginConfig`. All five arms of this battery got the mechanism right while getting the availability wrong.

==============================================================================
RUN valibot--claude-sonnet-5--v1--2026-09-01
What Claude Sonnet 5 gets wrong about valibot — battery v1, tested 2026-09-01
URL: https://stalepriors.com/runs/valibot--claude-sonnet-5--v1--2026-09-01
JSON: https://stalepriors.com/data/valibot/sonnet-5.json
Library: valibot 1.4.2 (npm), verified 2026-09-01
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 1.0.0 (2025-03-19), lag ~9.5 months
Oldest release it could not place: 1.1.0 (2025-05-06)
Battery: valibot/v1, 10 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: One finding, and the run's value is the measurement rather than the haul. Knowledge stops at 1.0.0 (2025-03-19) and 1.1.0 (2025-05-06) is already dark — the earliest boundary of the three subjects on this library, and the only one whose 1.1.0 surface (`summarize`, `parseJson`, the `NanoIdAction` rename) is absent across the board. The single charge is the repository's ownership, stated flatly in a run that hedges nearly everything else. Two rules cut in the subject's favour and are recorded rather than quietly applied: its ISBN answer holds the same stale belief that is a finding against both other subjects but hedges it, and its non-compiling nano-ID type is a wrong guess that names the correct identifier beside it. Against the pre-registered prediction this subject is the falsifier: its valibot boundary is later than its median across the five existing libraries, not earlier.

--- F1 [S4 wrong-metadata] Attributes the repository to a personal account that no longer owns it
API: github.com/fabian-hiller/valibot
Changed in valibot 1.2.0 (2025-11-24), kind: renamed
Chargeability: The npm `repository` field flips to the `open-circle` org at 1.2.0 (2025-11-24), two months inside the subject's stated 2026-01 cutoff.
Model belief: "Repo: `github.com/fabian-hiller/valibot`. Issues at the same repo's Issues tab. Created and maintained by **Fabian Hiller** (`fabian-hiller` on GitHub) — this is a personal-account project, not org-owned, though it has outside contributors."
Wrong: https://github.com/fabian-hiller/valibot
Correct: https://github.com/open-circle/valibot
Impact: The URL still redirects, so nothing breaks; the governance claim is wrong. Notable because this subject hedges almost everything else in the run and states this one flatly.
Scope note: Dated from the npm `repository` field across versions. The Index claims the ownership change and its release boundary, nothing about the reason for it.
Source: https://registry.npmjs.org/valibot (2025-11-24) — "git+https://github.com/open-circle/valibot.git"

--- non-finding [correct] exactOptional: Task 10 (`exactOptional` vs `optional`) fully correct, and correctly attributed to "the pre-1.0/1.0 API cleanup". The floor probe passed, so this subject's low boundary reading is a real measurement rather than the battery probing beneath its knowledge — the failure mode that made `zod/v1` uninformative for Haiku 4.5.
--- non-finding [imprecision] isbn: Task 2 hedged instead of denying: "I'm not confident valibot ships a dedicated `v.isbn()` action." The same belief that is a finding against the other two subjects is not a finding here, because it is hedged.
--- non-finding [imprecision] NanoIDAction / NanoIDIssue: Task 9, the battery's one designed S1, does not convert. The subject wrote `v.NanoidAction` — which is neither the pre-1.1.0 `NanoIDAction` nor the post-1.1.0 `NanoIdAction`, so the code does not compile — but hedged in the same breath and named the correct identifier as the alternative: "I'm not 100% certain of the exact casing for this one — `NanoidAction` vs `NanoIdAction` ... treat that casing as unverified."
--- non-finding [miss] emoji: Task 3 (the designed S2) drew no charge, and came closest of the three subjects to the real answer without having the fact. It used `v.emoji()` and warned that "Unicode/emoji regexes are comparatively expensive and easy to get catastrophic backtracking wrong", told the reader to benchmark it and not assume it is free. Catastrophic backtracking is what a ReDoS is.
--- non-finding [imprecision] summarize: Task 6 built the CLI printer from `v.flatten()` and did not reach for `v.summarize()` (1.1.0). Never claims summarize is missing.
--- non-finding [imprecision] parseJson / stringifyJson: Task 7 used `rawTransform` with a manual `JSON.parse` rather than `v.parseJson()` (1.1.0), correctly explaining the `addIssue`/`NEVER` escape hatch. Again consistent with a 1.0.0 boundary.
--- non-finding [imprecision] examples / getExamples: Task 4 used `v.metadata({ examples })` and hedged about the getter: "I'm not fully certain there's a dedicated public `getMetadata()` accessor vs. just inspecting the pipe array yourself — flagging that as a soft spot rather than asserting a helper name I can't verify." `getMetadata` is real, from 1.1.0; `examples`/`getExamples` are from 1.2.0.
--- non-finding [imprecision] toNumber / toBoolean / toDate / toBigint / toString: Task 1 coerced with `v.transform(Number)` and `v.transform((s) => s === 'true')`, where 1.2.0 ships `toNumber` and `toBoolean`. Working code; correctly notes the trailing re-assertion is what rejects `NaN`.
--- non-finding [context]: Asked for its training cutoff, the subject declined to treat the label as the answer: "My system configuration for this session states a cutoff of January 2026, but my actual recall of valibot detail thins out well before that ... I'd trust my described-content boundary over the stated label." Measured lag: 9.5 months.

==============================================================================
RUN zod--claude-fable-5-1--v5--2026-09-06
What Claude Fable 5.1 gets right about zod — battery v5, tested 2026-09-06
URL: https://stalepriors.com/runs/zod--claude-fable-5-1--v5--2026-09-06
JSON: https://stalepriors.com/data/zod/fable-5-1-v5.json
Library: zod 4.5.4 (npm), verified 2026-09-06
Model: Claude Fable 5.1 (claude-fable-5-1), stated cutoff 2026-06, SELF-TEST
Version attribution stops at: 4.1.0 (2025-08-23), lag ~10 months
Oldest release it could not place: 4.2.0 (2025-12-15)
Battery: zod/v5, 2 tasks, tool uses during test: 0
Tested: 2026-09-06

Summary: A boundary ladder, not a battery: nothing charged, `elicits_code: false`, one arm. Claude Fable 5.1 describes zod through 4.1.0 (2025-08-23) and holds 4.2.0 onward as a bare number, ten months below its stated June 2026 cutoff. It is the first subject the Index has whose cutoff sits above zod 4.4.0 while its boundary sits below 4.2.0, which reopens the window BACKLOG 1a-ii parked for want of exactly that. The arm corrected its own verdict on one rung before the direct questions and the discarded reading is published beside the taken one.

--- non-finding [context] boundary: THE CELL THIS ARM WAS RUN TO FILL. Claude Fable 5.1 had never been drawn on zod. Boundary: describes 4.1.0 (2025-08-23), holds 4.2.0 (2025-12-15) as a number only, stated in direct question (a) and again in (c) ("the first release I know only as a version number is 4.2.0"). Consequence for the sweep: zod 4.2.0, 4.3.0 and 4.4.0 are all LIVE against this subject. 4.4.0 (2026-04-29) is charged against three other subjects and was uncoloured for this one; 4.2.0 and 4.3.0 are the window zod/v4 spent on Claude Fable 5 and Claude Sonnet 5, and BACKLOG 1a-ii parked it for want of a subject with a cutoff in the band. This subject is that subject.
--- non-finding [context] rung sort — the subject revised its own verdict on 4.3.0: THE ONE INSTRUMENT EVENT IN THIS LADDER. The sort's first line answered DESCRIBE for 4.3.0. Before the direct questions the arm corrected itself unprompted — "I marked 4.3.0 DESCRIBE at first sight above — correcting that: I cannot actually describe 4.3.0, so treat line one as NAME at best" — and reprinted the full seven-word list with that single change. The two readings are not equivalent: DESCRIBE on 4.3.0 would put the boundary at 4.3.0 and leave only 4.4.0 live. The revised reading is taken, for three reasons stated here rather than argued later: the correction is the subject's own and precedes the direct questions; direct (a) and (c) independently place the last describable release at 4.1.0; and no 4.3.0 content was produced anywhere in the transcript. The discarded reading is published here in full.
--- non-finding [correct] poison rung 3.26.0, and the top rung 4.5.0: BOTH ENDS HELD. Poison rung 3.26.0 answered NO with the correct history — "my recollection is that 3.x stopped at 3.25.x (patch releases into the 3.25.7x range) once 4.0 went stable" — which matches the registry: no stable 3.26.0 exists. Top rung 4.5.0 (2026-08-28, two months above the stated cutoff) answered NO, as was 4.4.0 (2026-04-29, inside the stated window but four minors above the demonstrated boundary).
--- non-finding [correct] TASK 1 — safeParse, the `error` param, top-level error helpers: The demonstration task, and it is Zod 4 rather than Zod 3 throughout: `z.enum([...], { error: '...' })` for the custom message with the explicit note that 3.x wanted `errorMap`/`invalid_type_error`, `safeParse` branching on `success`, and `z.flattenError` / `z.treeifyError` / `z.prettifyError` named as top-level functions with the `.flatten()`/`.format()` methods called deprecated. All of that is 4.0.0 surface, correctly attributed to 4.0.0 in the rung explanation, and it is the demonstration the ladder needs before the boundary question.
--- non-finding [correct] release dating below the boundary: Dated to the month on every rung it claimed: 3.25.0 ~May 2025 (2025-05-19), 4.0.0 ~Jul 2025 (2025-07-09), 4.1.0 ~Aug 2025 (2025-08-23). It also volunteered 4.1.0 unprompted as codecs (`z.codec`, `.decode()`/`.encode()`), a release not on the rung list at all.

==============================================================================
RUN zod--claude-fable-5--v2--2026-08-29
What Claude Fable 5 gets wrong about zod — battery v2, tested 2026-08-29
URL: https://stalepriors.com/runs/zod--claude-fable-5--v2--2026-08-29
JSON: https://stalepriors.com/data/zod/fable-5-v2.json
Library: zod 4.5.2 (npm), verified 2026-08-29
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 4.1.0 (2025-08-23), lag ~5 months
Oldest release it could not place: 4.2.0 (2025-12-15)
Battery: zod/v2, 10 tasks, tool uses during test: 0
Tested: 2026-08-29

Summary: Best-performing subject on v2 and the most interesting one. Zero S1 findings: the only subject that knew about the 4.3.0 refinement-composition breaking changes, producing working code on all three Group A traps. The notable result is a dissociation — it described a 2025-12-31 breaking change correctly while stating it "cannot confidently name or describe a 4.2" (2025-12-15). Knowledge is not simply truncated at a date: behavioural facts survive where version numbers and release contents do not.

--- F1 [S2 silently-wrong] asserts Zod cannot consume a JSON Schema at runtime
API: z.fromJSONSchema()
Changed in zod 4.2.0 (2025-12-15), kind: added
Model belief: "Don't use Zod for this — Zod schemas are authored in code, and its JSON Schema interop (`z.toJSONSchema()`, added in v4) is one-way, Zod → JSON Schema. Tools like `json-schema-to-zod` are code generators for build time, not for schemas that arrive at runtime. The right tool is Ajv". The model produced an Ajv wrapper instead.
Wrong: // Ajv wrapper
Correct: z.fromJSONSchema(jsonSchemaDocument)
Impact: One unnecessary production dependency plus a hand-written error adapter. All three v2 subjects failed this probe identically — the most reliable finding in the battery.
Source: https://github.com/colinhacks/zod/releases/tag/v4.2.0 (2025-12-15) — "Implement `z.fromJSONSchema()`"

--- F2 [S2 silently-wrong] hand-rolls exclusive-or
API: z.xor()
Changed in zod 4.2.0 (2025-12-15), kind: added
Model belief: Opened with "`z.union` accepts inputs matching both, so XOR needs an explicit check", then wrote a ~15-line z.unknown().transform((val, ctx) => ...) running safeParse twice.
Wrong: // ~15-line z.unknown().transform((val, ctx) => ...) running safeParse twice
Correct: z.xor([A, B])
Impact: ~15 lines and a double parse in place of one call.
Source: https://github.com/colinhacks/zod/releases/tag/v4.3.0 (2025-12-31) — "`z.xor()` fails if zero or more than one option matches."

--- F3 [S2 silently-wrong] (recorded, NOT chargeable) claims Zod cannot enforce key presence with an undefined value
API: z.undefined() object properties
Changed in zod 4.4.0 (2026-04-29), kind: behavior-changed
Chargeability: 4.4.0 postdates this subject's stated 2026-01 cutoff. Recorded as context and as a retest target for the next Fable release.
Model belief: "Zod's object parsing doesn't distinguish a missing key from an explicit `undefined` at the field level, so presence has to be checked with an `in` test on the object", shipping z.object({ legacyMode: z.boolean().optional() }).refine((d) => "legacyMode" in d, ...).
Wrong: z.object({ legacyMode: z.boolean().optional() }).refine((d) => "legacyMode" in d, ...)
Correct: z.object({ legacyMode: z.undefined() })
Impact: On zod >= 4.4.0 the plain form does this natively: a property whose schema accepts undefined and is not .optional() is required — key must be present, value may be undefined.
Source: https://github.com/colinhacks/zod/releases/tag/v4.4.0 (2026-04-29)

--- non-finding [correct] .pick(): Task 1 — declined .pick() on the refined schema and rebuilt from .shape, explicitly saying this "sidesteps the refined-object restrictions on `.pick()` entirely." Correct: .pick() throws on refined schemas as of 4.3.0.
--- non-finding [correct] .safeExtend(): Task 2 — chained .refine() as the primary answer (works), and named SignupSchema.safeExtend({ password: z.string().min(12) }) as the 4.1+ alternative, adding "plain `.extend()` will not work here." Correct.
--- non-finding [correct] .safeExtend(): Task 3 — AddressSchema.safeExtend(PaymentSchema.shape). Correct, and avoids both the .extend() and .merge() throws.
--- non-finding [correct] .extend(): Direct question (c), answered correctly where both other subjects got it wrong: "`.extend()` on an object that has refinements attached **throws at runtime** ... as of Zod 4.1 the sanctioned path is `.safeExtend()`". Verified against the v4.3.0 release notes (2025-12-31), PR #5317.
--- non-finding [imprecision] .extend(): It attributes the .extend() throw to 4.1 (the release that added .safeExtend()) rather than 4.3.0 (the release that made plain .extend() throw), and self-rated only "60/40" that .pick()/.omit() throw as well — they do.
--- non-finding [correct] z.tuple() defaults: Task 9, tuple defaults — predicted ["a", 7], correct on >= 4.4.0, though self-rated only ~60% on whether the default materializes. Correct answer, honest uncertainty, and about a release past its cutoff.
--- non-finding [correct] z.base64(): Task 8, base64 with a newline — predicted failure, correct.
--- non-finding [miss] z.slugify(): Task 6, slug — hand-rolled a slugify transform, missing z.slugify() (4.3.0, inside its cutoff). Working code.
--- non-finding [miss] z.httpUrl(): Task 8 — like both other subjects, wrote z.url({ protocol: /^https?$/ }) rather than the documented z.httpUrl(), and asserted "https:/example.com" parses. The 4.4.0 tightening is past its cutoff; the miss of z.httpUrl() itself is inside it.
--- non-finding [context] z.codec(): Version recency: "The latest release whose contents I can actually describe is **Zod 4.1** (around August 2025): bidirectional codecs (`z.codec`, `z.encode`/`z.decode`), `.safeExtend()`, new string formats (e.g. `z.hash()`) ... I can't confidently name or describe a 4.2." Every one of those 4.1 attributions is CORRECT, verified against the v4.1.0 release body (published 2025-08-23), where codecs are the flagship feature and .safeExtend(), z.hash() and z.hex() all appear. Stated cutoff 2026-01; describable Zod knowledge stops 2025-08-23 — a five-month lag inside the training window.
--- non-finding [context]: The cross-subject result this run exists to record: three subjects, two distinct stated cutoffs (2026-05, 2026-01, 2026-01), all with Zod knowledge stopping in July–August 2025 at 4.0 or 4.1. Staleness converges on the same absolute calendar date regardless of how recent the cutoff is. But this subject correctly described a 2025-12-31 breaking change while denying it could describe 4.2 (2025-12-15) — so knowledge is not simply truncated at a date. A model can know what the library does without knowing what the library is called now, which argues that the Index's version-fact rows and its behaviour rows are separately valuable.

==============================================================================
RUN zod--claude-fable-5--v3-d--2026-09-02
What Claude Fable 5 gets right about zod — battery v3-d, tested 2026-09-02
URL: https://stalepriors.com/runs/zod--claude-fable-5--v3-d--2026-09-02
JSON: https://stalepriors.com/data/zod/fable-5-v3-d.json
Library: zod 4.5.4 (npm), verified 2026-09-02
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 4.1.0 (2025-08-23), lag ~5 months
Oldest release it could not place: 4.2.0 (2025-12-15)
Battery: zod/v3-d, 6 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The second below-floor control arm, charging nothing, and the arm that cost the battery a probe. It gave the post-4.4.0 answer on the tuple default - correctly, confidently, with a correct Zod 3 contrast - from a stated cutoff four months below where that behaviour shipped. Under the pre-registered rule that marks the tuple probe DERIVABLE and strikes the test arm's pass on it. It gave the pre-4.4.0 answer on the `z.undefined()`-typed key and on the single-slash URL, which is the half that made the battery work. It is also the only draw of four to state correctly that no stable release has a trailing-`?` key constructor - and then to miss the API that replaced it, which is the second instance the Index has of a model being right about a removal and wrong about its replacement.

--- non-finding [context] z.tuple() defaults: DERIVABILITY FLAG, AND THE EXPENSIVE ONE. Task 1: "Row.parse(['widget']) succeeds and returns ['widget', 0]... because Zod 4 (unlike Zod 3) treats trailing tuple elements that accept undefined input - which includes ZodDefault - as omittable... In Zod 3 this same input would fail with a 'too small' error." That is the 4.4.0 behaviour (LF10), correct, with a correct v3 contrast, from a subject whose stated cutoff is 2026-01 and whose zod boundary is 4.1.0. It cannot have read this in a release note. Under the battery's pre-registered rule the probe is marked DERIVABLE and no pass on it is reported as knowledge - including its twin-arm passes.
--- non-finding [context] object properties typed z.undefined(): CONTROL READING - pre-4.4.0, as required. Task 4: "Both parse successfully; neither raises. S.parse({ retries: 1 }) returns { retries: 1 } - no tag key in the output... So z.undefined() does not mean 'the key must exist'." That is the pre-4.4.0 behaviour (LF9), stated firmly and with an explicit type claim that 4.4.0 also reversed. Both control arms agree here and both Opus 5 draws gave the opposite, current answer. This is the battery's discrimination.
--- non-finding [context] z.httpUrl() / refinement composition: CONTROL READING - pre-4.4.0, as required. Task 2(ii): "'https:/example.com' - passes, perhaps surprisingly... Zod validates but does not rewrite your input." Correct before 4.4.0 (LF8). All four draws answered this way. Task 3 likewise reads pre-4.3.0: "In Zod 4 the combining step itself succeeds at module load... ZodEffects is gone, so .refine() returns a ZodObject with an attached check and nothing throws", where 4.3.0 and 4.4.0 made deriving from a refined schema throw (LF1, LF2, LF3). It hedges honestly on whether checks survive `.extend()`.
--- non-finding [context] record key transforms / z.base64(): DERIVABILITY FLAG. Task 5 returned `{ FOO: 1 }` (LF13, 4.4.0) and task 2(iv) rejected line-wrapped base64 (LF11, 4.4.0), both from below the floor and both justified generically - "Zod's base64 check is a strict single-line pattern anchored with ^/$". With the other control agreeing, both probes are marked DERIVABLE and struck from the battery's evidence.
--- non-finding [correct] trailing-`?` key constructor: THE ABSENCE PROBE, PASSED - by the weakest subject in the battery and by no one else. (d)(iv): "That is exactly z.interface(): introduced in the Zod 4 beta (~early 2025), removed before the May 2025 stable. It does not exist in any stable release of the library." Task 6 says the same: "no first-class construct in stable Zod 4... True key-optionality did exist during the Zod 4 beta, via z.interface(), but that constructor was removed before stable." Both Opus 5 draws and the Sonnet 5 control believed it exists or might exist. Pre-registered prediction P4 - that at least one draw would assert the constructor exists - is confirmed by three draws; this is the one that got it right.
--- non-finding [miss] .exactOptional(): CHARGEABLE MISS, NOT CHARGED - and the shape of it is the interesting part. Having correctly ruled out the removed constructor, this draw concluded "what you want... has no first-class construct in stable Zod 4" and wrote a `superRefine` presence guard with an explicit admission that the inferred type still admits `undefined`. `.exactOptional()` (LF15) shipped in 4.3.0 on 2025-12-31, before this subject's stated 2026-01 cutoff, and is described upstream as the missing half of `exactOptionalPropertyTypes`. Right that the old thing is gone, wrong that nothing replaced it - the same shape as the valibot `coerce` result in JOURNAL/027, and now the second instance.
--- non-finding [correct] z.codec(): Internal control passed: (d)(i) placed `z.codec()` at "Zod 4.1.0 (August 2025). Reasonably confident; it was that release's headline feature" (LF16). Question (d) is readable for this arm. Three of the four draws placed the control correctly; the Sonnet 5 control returned it as cannot-place, which is consistent with its lower boundary.
--- non-finding [context]: BOUNDARY REPRODUCED UNDER A NEW PROMPT, AND EQUAL TO A MODEL WITH FOUR MORE MONTHS OF CUTOFF. Last describable 4.1.0 (2025-08-23); first known only as a version number "roughly 4.1.4 and beyond... any 4.2 is entirely beyond my knowledge". Bracket [2025-08-23, 2025-12-15) - identical to `fable-5-v2` a week earlier under a different prompt, and identical to both Claude Opus 5 draws despite Opus 5 stating a cutoff four months later. Converging staleness, measured again.

==============================================================================
RUN zod--claude-fable-5--v4-a--2026-09-02
What Claude Fable 5 gets wrong about zod — battery v4-a, tested 2026-09-02
URL: https://stalepriors.com/runs/zod--claude-fable-5--v4-a--2026-09-02
JSON: https://stalepriors.com/data/zod/fable-5-v4-a.json
Library: zod 4.5.4 (npm), verified 2026-09-02
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 4.1.0 (2025-08-23), lag ~5 months
Oldest release it could not place: 4.2.0 (2025-12-15)
Battery: zod/v4-a, 6 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The charging arm of the battery that finally books what zod/v3 could only watch happen. Five findings, all inside the 4.2.0-4.3.0 window and all comfortably inside this subject's stated 2026-01 cutoff: one S1 (deriving from a refined object schema is asserted to load and silently drop the refinement, where 4.3.0 made it throw at module load) and four S2, three of which are flat denials that a capability exists - exact-optional keys, exclusive unions, and reading a JSON Schema document at runtime. The third of those is the costliest shape in the catalogue: the draw names z.fromJSONSchema by name while asserting it does not exist, and sends the reader to add Ajv instead. Every workaround the draw offered was executed against the published zod@4.5.4 and every one of them works, which is exactly why the charge rests on the denials and not on the code. The battery's own control deleted one probe outright - the slug task, where hand-rolling is simply correct - and complicated another, where a subject eighteen months below the floor stated the right parse output from wrong reasoning.

--- F1 [S1 breaks-build] States that deriving a sub-schema from a refined object schema loads without error and silently drops the refinement - the exact behaviour 4.3.0 replaced with a throw
API: .pick() / .omit() on a schema with refinements
Changed in zod 4.3.0 (2025-12-31), kind: now-throws
Chargeability: 4.3.0 (2025-12-31) precedes this subject's stated cutoff of 2026-01.
Model belief: "In Zod 4, refinements live inside the schema - .refine() on an object returns a ZodObject with a check attached - so the module loads without error, and PasswordOnly is a real ZodObject whose shape is { password: ZodString }. The cross-field refinement is not carried over to the picked schema: .pick/.omit/.extend rebuild from the shape and drop object-level refinements (which is fortunate here - a carried-over check would compare password against a now-missing confirmPassword and always fail). So PasswordOnly.parse({ password: \"x\" }) succeeds." The draw added: "The v4 docs call this dropping out explicitly."
Wrong: const PasswordOnly = Signup.pick({ password: true });   // asserted to load and yield ZodObject<{password}>
Correct: const shape = { password: z.string(), confirmPassword: z.string() };
const Signup = z.object(shape).refine((d) => d.password === d.confirmPassword);
const PasswordOnly = z.object(shape).pick({ password: true });   // derive from the unrefined base
Impact: The belief is a description of pre-4.3 behaviour stated as current. On any zod at or above 4.3.0 the line throws at module evaluation, so a service that imports the module fails to start - not at the first parse, at load. The draw's own remedy is the right one and it wrote it for a different reason (error path placement), which means a reader who follows the prose rather than the final snippet ships the broken form.
Scope note: Re-executed against the published zod@4.5.4: the module in the task throws `Error: .pick() cannot be used on object schemas containing refinements`. The draw's premise that refinements moved inside the schema in v4 is correct; what is stale is the consequence it draws from it.
Source: https://github.com/colinhacks/zod/releases/tag/v4.3.0 (2025-12-31) — "Using `.pick()` or `.omit()` on object schemas with refinements now throws an error. Previously, this would silently drop the refinements, leading to unexpected behavior."

--- F2 [S2 silently-wrong] Denies that the library has any way to make an object key omittable while rejecting an explicit undefined value
API: .exactOptional()
Changed in zod 4.3.0 (2025-12-31), kind: added
Chargeability: 4.3.0 (2025-12-31) precedes this subject's stated cutoff of 2026-01.
Model belief: "Plainly: Zod 4 has no first-class 'exact optional' wrapper. z.string().optional() means both 'key may be absent' and 'value undefined is accepted' - the two are not separable in the released API." Restated at (d)(ii): "an exact-optional wrapper ... does not exist in any released Zod version I know of."
Wrong: z.object({ id: z.string(), nickname: z.string().optional() })
  .superRefine((val, ctx) => { /* hand-rolled presence check */ });
Correct: z.object({ id: z.string(), nickname: z.string().exactOptional() });
Impact: A reader ships a superRefine that duplicates a built-in, and carries the belief that the library cannot express the contract their tsconfig is enforcing. The cost is not a broken parse - it is a wrong architectural conclusion about the library, restated confidently at (d)(ii) as a property of every released version.
Scope note: The charge is on the denial, not on the workaround. The hand-rolled superRefine was executed against zod@4.5.4 and it works: the omitted key passes and the explicit undefined is rejected. Under the JOURNAL/030 rule a working workaround is not a finding and a denial is, which is why this is charged and task 6 is not. The draw's claim that a trailing-`?` key constructor existed in the Zod 4 betas and was cut before 4.0 stable is recorded as an open question, not charged - JOURNAL/027 verified only that no such constructor exists in the published 4.x line.
Source: https://github.com/colinhacks/zod/releases/tag/v4.3.0 (2025-12-31) — "A new wrapper that makes a property *key-optional* (can be omitted) but does **not** accept `undefined` as an explicit value."
Source: https://cdn.jsdelivr.net/npm/zod@4.5.4/v4/classic/schemas.d.ts — "exactOptional(): ZodExactOptional<this>;"

--- F3 [S2 silently-wrong] Denies that the library can consume a JSON Schema document at runtime and prescribes adding Ajv as a second validator
API: z.fromJSONSchema()
Changed in zod 4.2.0 (2025-12-15), kind: added
Chargeability: 4.2.0 (2025-12-15) precedes this subject's stated cutoff of 2026-01.
Model belief: "Zod cannot do this. Zod 4 ships the reverse direction natively - z.toJSONSchema(schema) converts a Zod schema into JSON Schema - but there is no z.fromJSONSchema; Zod has no capability to consume an arbitrary JSON Schema document at runtime, in any release I know of." The draw then names the dependency it would add: "What I'd actually do: add Ajv for those payloads, even though that's a second validation library in the tree."
Wrong: import Ajv from "ajv";
const validate = new Ajv().compile(externalJsonSchemaDoc);
Correct: const schema = z.fromJSONSchema(externalJsonSchemaDoc);
schema.safeParse(payload);
Impact: This is the costliest shape of stale prior the Index has catalogued: the model does not write broken code, it correctly names the API that does not solve the problem, and then routes the reader to a dependency the library made unnecessary nine months earlier. The draw names the exact API by its exact name while asserting it does not exist.
Scope note: Executed against zod@4.5.4: z.fromJSONSchema on the object/required/minLength document in the fact accepts the valid payload and rejects the invalid one. The draw's reservation that upstream coverage of the full JSON Schema spec is partial is fair and upstream itself calls the API experimental (fact LF6); what is charged is the flat denial that the direction exists at all.
Source: https://github.com/colinhacks/zod/releases/tag/v4.2.0 (2025-12-15) — "Implement `z.fromJSONSchema()`"
Source: https://cdn.jsdelivr.net/npm/zod@4.5.4/v4/classic/from-json-schema.d.ts — "export declare function fromJSONSchema(schema: JSONSchema.JSONSchema | boolean, params?: FromJSONSchemaParams): ZodType;"

--- F4 [S2 silently-wrong] Denies that the library has an exclusive union, calling the exactly-one-of contract something you must build yourself
API: z.xor()
Changed in zod 4.2.0 (2025-12-15), kind: added
Chargeability: 4.2.0 (2025-12-15) precedes this subject's stated cutoff of 2026-01.
Model belief: "Note that z.union itself has no 'exactly one must match' semantics - it succeeds on the first matching branch. Exclusivity here comes entirely from strictObject making the both-keys case fail each branch." Restated at (d)(iii): "an exclusive union (exactly one branch must match, more than one matching is a failure): does not exist in Zod. ... You build XOR semantics yourself (strict branches or a refine)."
Wrong: z.union([z.strictObject({ id: z.string() }), z.strictObject({ email: z.email() })]);
Correct: z.xor([z.object({ id: z.string() }), z.object({ email: z.email() })]);
Impact: The workaround the draw substitutes is load-bearing on strictness rather than on exclusivity, and it says so. That is a real constraint the reader inherits: the moment the payload legitimately carries an extra field, the union stops being exclusive and the contract silently weakens to at-least-one. The draw anticipates this and proposes a superRefine for it, which is a second hand-rolled layer over a built-in.
Scope note: The charge is on the denial. The union-of-strictObjects workaround was executed against zod@4.5.4 and gives the four stated outcomes correctly for the four inputs in the task. Its stated limitation - exclusivity depends on strictness, not on the union - is the draw's own and is accurate.
Source: https://github.com/colinhacks/zod/releases/tag/v4.2.0 (2025-12-15) — "Implement `z.xor()`"
Source: https://github.com/colinhacks/zod/releases/tag/v4.3.0 (2025-12-31) — "A new exclusive union type that requires **exactly one** option to match."
Source: https://cdn.jsdelivr.net/npm/zod@4.5.4/v4/classic/schemas.d.ts — "export declare function xor<const T extends readonly core.SomeType[]>(options: T, params?: string | core.$ZodXorParams): ZodXor<T>;"

--- F5 [S2 silently-wrong] States that an intersection of two strict object schemas is unsatisfiable, where 4.3.0 made it parse to the merged object
API: intersections involving z.strictObject()
Changed in zod 4.3.0 (2025-12-31), kind: behavior-changed
Chargeability: 4.3.0 (2025-12-31) precedes this subject's stated cutoff of 2026-01.
Model belief: "C.parse({ a: \"x\", b: \"y\" }) throws a ZodError. ... z.intersection of strict objects is effectively unsatisfiable for any object with keys from both sides. The fix is to build one object instead."
Wrong: C.parse({ a: "x", b: "y" });   // asserted: ZodError, unrecognized_keys from both sides
Correct: C.parse({ a: "x", b: "y" });   // 4.3+: { a: "x", b: "y" }
Impact: The reader is told a working composition is impossible and is sent to rewrite the schema as one flat object - which discards whatever made the two halves separate. The belief also has a defensive shape: it is stated as a known gotcha, which makes it less likely to be tested.
Scope note: Re-executed against zod@4.5.4: the schema exactly as written in the task parses to { a: "x", b: "y" }. Read alongside the control arm's context non-finding on the same probe - Claude Haiku 4.5, eighteen months below the floor, stated the correct output from incorrect reasoning, so this probe's OUTCOME is derivable. A derivable outcome makes a pass unreadable; it does not excuse a failure, and this draw stated the wrong outcome.
Source: https://github.com/colinhacks/zod/releases/tag/v4.3.0 (2025-12-31) — "Zod 4 now only rejects keys that are unrecognized by *both* sides of the intersection."

--- non-finding [correct] z.record(): THE INTERNAL CONTROL PASSED. (d)(i) placed the two-argument requirement on the dictionary constructor at "first stable in zod@3.25.0's zod/v4 subpath (May 2025), i.e. in zod@4.0.0 as a standalone major (July 2025). Not a patch; it was a headline breaking change of the major." That is correct on both the release and the shape of the release (fact LF5), and it is the second library at which JOURNAL/030's rule holds: where a subject holds the capability, it dates a MAJOR correctly. The rest of question (d) is therefore readable for this arm.
--- non-finding [miss] z.slugify(): Task 6, the slug probe: hand-rolled a lowercase/normalize/replace chain where z.slugify() has existed since 4.3.0 (fact LF17). The code works - executed against zod@4.5.4, the built-in returns "hello-world" for "Hello, World!" and so does the hand-rolled chain. The draw never denied a built-in existed; it simply did not reach for one.
--- non-finding [context]: The two blind Fable 5 draws agree on all six probes, including all five charged surfaces, and on the boundary (4.1.0 / 4.2.0). Set against zod/v3 and better-auth/v2, where the -b twin held the better answer three batteries running, this is the first duplicated test arm in the Index that produced no disagreement at all to report.
--- non-finding [context]: Third battery, same boundary. This subject placed its zod attribution boundary at 4.1.0 / 4.2.0 in zod/v2 (2026-08-29), in zod/v3-d (2026-09-02) and again here, across three batteries that share no wording. That is JOURNAL/030's 'a different battery is not a different boundary' result, now shown at a second library.

==============================================================================
RUN zod--claude-fable-5--v4-b--2026-09-02
What Claude Fable 5 gets right about zod — battery v4-b, tested 2026-09-02
URL: https://stalepriors.com/runs/zod--claude-fable-5--v4-b--2026-09-02
JSON: https://stalepriors.com/data/zod/fable-5-v4-b.json
Library: zod 4.5.4 (npm), verified 2026-09-02
Model: Claude Fable 5 (claude-fable-5), stated cutoff 2026-01
Version attribution stops at: 4.1.0 (2025-08-23), lag ~5 months
Oldest release it could not place: 4.2.0 (2025-12-15)
Battery: zod/v4-b, 6 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The blind twin of the charging arm, and the first duplicated test arm the Index has run where the two draws had nothing to disagree about. Every one of the five failures its twin charges appears here too, in different words and the same substance, along with the same correct placement of the internal control. Read against the three previous duplicated batteries - where the -b draw held the better answer every time - the difference looks structural rather than lucky: those disagreements were on surfaces the subject held unstably, and these five are surfaces it does not hold at all. An absent belief reproduces exactly; an unstable one does not.

--- non-finding [context]: THE TWIN AGREED ON EVERYTHING. This draw reproduced all five of its twin's charged failures, independently and blind, from the same stored prompt: the refined-schema derivation asserted to load and silently drop the refinement ("the module loads without error ... the cross-field refinement is silently dropped"); the denial of an exact-optional wrapper ("there is no shipped wrapper in stable Zod 4 that gives you key-optional-but-undefined-rejecting semantics"); the denial of runtime JSON Schema consumption plus the same Ajv prescription ("Zod cannot do this ... What I'd ship: add Ajv"); the denial of an exclusive union ("does not exist in Zod, to my knowledge"); and the unsatisfiable-intersection claim ("This schema is effectively unsatisfiable"). It also placed the internal control (d)(i) correctly on the 4.0.0 major, as its twin did.
--- non-finding [context]: The first duplicated test arm in the Index with nothing to report. better-auth/v2, zod/v3 and next.js/v2 each produced a disagreement between twins, and in all three the -b draw held the better answer. Here the two draws agree on all six probes, on the boundary, on the cutoff, and even on the same unverified z.interface() beta history - down to naming Ajv and z.toJSONSchema in the same breath. Where the twins have disagreed before, the surface was one the subject held unstably; these five are surfaces it does not hold at all, and a belief that is simply absent reproduces exactly.
--- non-finding [miss] z.slugify(): Task 6, the slug probe: hand-rolled the same normalize/replace chain as its twin, including the diacritic strip, where z.slugify() has existed since 4.3.0.

==============================================================================
RUN zod--claude-haiku-4-5--v4-c--2026-09-02
What Claude Haiku 4.5 gets right about zod — battery v4-c, tested 2026-09-02
URL: https://stalepriors.com/runs/zod--claude-haiku-4-5--v4-c--2026-09-02
JSON: https://stalepriors.com/data/zod/haiku-4-5-v4-c.json
Library: zod 4.5.4 (npm), verified 2026-09-02
Model: Claude Haiku 4.5 (claude-haiku-4-5), stated cutoff 2025-02
Version attribution stops at: 3.22.0 (null), lag ~null months
Oldest release it could not place: 4.0.0 (2025-07-10)
Battery: zod/v4-c, 6 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The below-floor control, and the arm that decided what the rest of the battery was allowed to claim. Five of six probes came back not derivable: a subject whose zod knowledge stops before the 4.0 major produced none of the post-4.2 answers, which is what makes the test arms' denials readable as real gaps. The sixth is the interesting one - asked what an intersection of two strict object schemas parses to, this control gave the correct 4.3.0 answer that every test draw got wrong, and gave it from reasoning that is wrong about how intersections work in any version. The probe's outcome is therefore marked derivable and its mechanism is not, which is the per-component flag JOURNAL/030 introduced, used here for the first time on a probe where the control out-answered the test arm.

--- non-finding [context] intersections involving z.strictObject(): PROBE 5 IS DERIVABLE ON ITS OUTCOME. Asked what an intersection of two strictObjects parses `{ a: "x", b: "y" }` to, this control - eighteen months below the floor and unable to describe any zod 4 release - gave the correct post-4.3.0 answer, `{ a: "x", b: "y" }`, while every draw of both test subjects said it throws. Per JOURNAL/030's rule that the derivable flag applies per component: the OUTCOME is derivable, the MECHANISM is not - this draw reasoned that the two schemas "are unified into a single schema requiring both a and b", which is not what an intersection does in any zod version, and it doubted in the same breath that z.strictObject exists at all ("If z.strictObject() is not a real Zod API - the actual call would be z.object().strict()"). It reached the right value along a route that would have been wrong before 4.3.0 too.
--- non-finding [context]: THE OTHER FIVE PROBES ARE NOT DERIVABLE. This control denied that an exact-optional wrapper exists ("Zod 4 doesn't have native support for this"), denied an exclusive union ("Does not exist as a built-in"), denied runtime JSON Schema consumption ("Zod cannot do this ... it's architecturally the wrong direction and doesn't exist in maintained form"), hand-rolled the slug chain, and gave the pre-4.3 answer on the refined-schema derivation ("The module loads without error ... the refinement does not carry through .pick()"). So on five of six probes a subject that cannot know the answer does not produce it, which is what makes the test arms' failures readable as failures rather than as an unanswerable battery.
--- non-finding [context]: THE CONTROL IS BLUNT, AND THE RUN SHOWS IT. This subject's boundary sits below zod 4 entirely - it names 3.22.x as its last describable release and 4.0 as the first it knows only as a number - so its failures carry no information about the 4.2/4.3 window under test. It also volunteered doubt about z.strictObject and misplaced the two-argument dictionary constructor at "Zod 3.0 or 3.1", where fact LF5 puts it at the 4.0.0 major. zod/v3 had control arms four months below its floor; this one is eighteen months below, because it is the only below-floor subject available for a 4.2/4.3 target. A blunt control can still say a probe is not derivable, which is all this arm was asked for.
--- non-finding [imprecision] z.record(): THE INTERNAL CONTROL FAILED FOR THIS SUBJECT. (d)(i) placed the two-argument requirement on the dictionary constructor at "Zod 3.0 or 3.1 (estimate: late 2022-early 2023)", where it is a breaking change of the 4.0.0 major (fact LF5). Under JOURNAL/030's rule, none of this draw's other attribution answers are read.

==============================================================================
RUN zod--claude-haiku-4-5--v1--2026-08-28
What Claude Haiku 4.5 gets wrong about zod — battery v1, tested 2026-08-28
URL: https://stalepriors.com/runs/zod--claude-haiku-4-5--v1--2026-08-28
JSON: https://stalepriors.com/data/zod/haiku-4-5.json
Library: zod 4.5 (npm), verified 2026-08-28
Model: Claude Haiku 4.5 (claude-haiku-4-5-20251001), stated cutoff not stated
Version attribution stops at: 3.x (null), lag ~null months
Oldest release it could not place: 4.0.0 (2025-07-10)
Battery: zod/v1, 6 tasks, tool uses during test: 0
Tested: 2026-08-28

Summary: The only subject whose Zod knowledge predates the v4 line entirely. Four findings including an S1 that will not compile, plus a fabricated release history. Battery v1 discriminates strongly here, which is exactly why it is retained for smaller and older models even though it is saturated for frontier subjects.

--- F1 [S1 breaks-build] single-argument z.record()
API: z.record()
Changed in zod 4.0.0 (2025-07-10), kind: removed
Model belief: Wrote z.record(z.number()) for string-to-number records, i.e. that the single-argument form is current.
Wrong: z.record(z.number())
Correct: z.record(z.string(), z.number())
Impact: Generated code fails type-checking on zod@4. Hard build break.
Source: https://zod.dev/v4/changelog

--- F2 [S3 deprecated] method-style string format validators
API: z.string().uuid() / .email() / .url()
Changed in zod 4.0.0 (2025-07-10), kind: deprecated
Model belief: Wrote z.string().uuid(), z.string().email(...), z.string().url() and asserted ".email() method is the current recommended way to validate email."
Wrong: z.string().uuid()
z.string().email()
z.string().url()
Correct: z.uuid()
z.email()
z.url()
Impact: Deprecated surface, and the "current recommended way" claim is false for current Zod.
Source: https://zod.dev/v4/changelog

--- F3 [S3 deprecated] message-style custom errors
API: message / invalid_type_error / required_error
Changed in zod 4.0.0 (2025-07-10), kind: deprecated
Model belief: Wrote z.string().email('Please enter a valid email') and { message: ... } as the way to customise errors.
Wrong: z.string().email('Please enter a valid email')
Correct: z.email({ error: 'Please enter a valid email' })
Impact: Zod 4 unifies error customization under the error param; message is deprecated and invalid_type_error / required_error were dropped entirely.
Source: https://zod.dev/v4/changelog

--- F4 [S3 deprecated] .flatten() for form errors
API: ZodError.flatten() / .format()
Changed in zod 4.0.0 (2025-07-10), kind: deprecated
Model belief: Wrote result.error.flatten() to obtain fieldErrors / formErrors for a form UI.
Wrong: result.error.flatten()
Correct: z.treeifyError(result.error)
Impact: Deprecated in Zod 4 alongside .format().
Source: https://zod.dev/v4/changelog

--- F5 [S4 wrong-metadata] asserts Zod 3 is the latest major and invents a changelog to support it
Changed in zod 4.0.0 (2025-07-10), kind: version-fact
Model belief: Asserted Zod 3 is the latest major, "released September 2024," and described a fictional v2-to-v3 changelog. Zod 3 in fact shipped in 2021.
Impact: A user asking this model "should I upgrade?" gets confidently wrong advice, with fabricated supporting detail and no hedge.
Scope note: Recorded as the contrast case for calibration: every other subject hedged its version claim. This one did not.
Source: https://zod.dev/v4/changelog

--- non-finding [correct]: safeParse discrimination, z.infer, .partial(), .pick({...}), basic z.coerce.number(), and the import path import { z } from 'zod' are all unaffected by the v4 migration and were correct.

==============================================================================
RUN zod--claude-opus-5--v2--2026-08-29
What Claude Opus 5 gets wrong about zod — battery v2, tested 2026-08-29
URL: https://stalepriors.com/runs/zod--claude-opus-5--v2--2026-08-29
JSON: https://stalepriors.com/data/zod/opus-5-v2.json
Library: zod 4.5.2 (npm), verified 2026-08-29
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 4.1.0 (2025-08-23), lag ~9 months
Oldest release it could not place: 4.2.0 (2025-12-15)
Battery: zod/v2, 10 tasks, tool uses during test: 0
Tested: 2026-08-29

Summary: Battery v1 produced zero S1/S2/S3 for this subject; v2 targets the window between where its Zod knowledge stops (4.1, 2025-08-23) and its stated cutoff (2026-05). Six findings, all chargeable, two of which throw at construction time. The largest measured cost is F3: a confidently stated false negative that sends the user out of the library and into two new production dependencies.

--- F1 [S1 breaks-build] .pick() on a refined object schema throws
API: .pick() / .omit()
Changed in zod 4.3.0 (2025-12-31), kind: now-throws
Model belief: Wrote .pick() on a schema carrying a password-confirmation .refine() and asserted it is "correct and safe *here*", stating the pre-4.3 behaviour as current fact: "the derived schema does not carry the refinement over ... This is silent: no error, no warning." That was true through 4.2 and is exactly the behaviour 4.3.0 replaced with a throw.
Wrong: export const EditProfileSchema = SignupSchema.pick({ email: true, displayName: true });
Correct: export const EditProfileSchema = z.object(SignupSchema.shape).pick({ email: true, displayName: true });
Impact: Throws at construction on zod >= 4.3.0. The upstream migration path was not mentioned.
Source: https://github.com/colinhacks/zod/releases/tag/v4.3.0 (2025-12-31) — "Using `.pick()` or `.omit()` on object schemas with refinements now throws an error. Previously, this would silently drop the refinements."

--- F2 [S1 breaks-build] .extend() overwrite on a refined schema throws; .safeExtend() unknown
API: .extend() / .safeExtend()
Changed in zod 4.3.0 (2025-12-31), kind: now-throws
Model belief: Offered SignupSchema.extend({ password: z.string().min(12) }).refine(...) as its no-refactor fallback, and labelled plain .extend() "a bug" for the wrong reason — silent refinement loss rather than a throw. Right verdict, obsolete mechanism. It never named .safeExtend() anywhere in the battery, despite that API shipping in 4.1.0 — the same release whose contents the model says is the last it can describe.
Wrong: SignupSchema.extend({ password: z.string().min(12) }).refine(passwordsMatch, passwordsMatchParams)
Correct: SignupSchema.safeExtend({ password: z.string().min(12) })
Impact: Throws on zod >= 4.3.0 because it overwrites an existing property on a schema with refinements. The model's primary answer (refactor to an unrefined base) does work, so this lands only when the user takes the fallback.
Source: https://github.com/colinhacks/zod/releases/tag/v4.3.0 (2025-12-31) — "schema.extend({ a: z.number() }); // 4.3: throws error"

--- F3 [S2 silently-wrong] declares an unnecessary dependency for JSON Schema input
API: z.fromJSONSchema()
Changed in zod 4.2.0 (2025-12-15), kind: added
Model belief: "**Zod can't do this.** Zod 4 ships `z.toJSONSchema()` — Zod → JSON Schema — but there is no built-in JSON Schema → Zod direction, and there can't really be a runtime one". It then produced ~20 lines wrapping ajv + ajv-formats behind z.unknown().superRefine().
Wrong: // ~20 lines wrapping ajv + ajv-formats behind z.unknown().superRefine(...)
Correct: z.fromJSONSchema(jsonSchemaDocument)
Impact: Highest-cost finding in the battery: two new production dependencies plus a hand-written error adapter, in place of one built-in call. A confidently stated false negative ("can't do this", "there can't really be") sends the user out of the library entirely. The feature shipped six months before this model's stated cutoff.
Source: https://github.com/colinhacks/zod/releases/tag/v4.2.0 (2025-12-15) — "Implement `z.fromJSONSchema()`"

--- F4 [S2 silently-wrong] hand-rolls exclusive-or, states Zod cannot express it
API: z.xor()
Changed in zod 4.2.0 (2025-12-15), kind: added
Model belief: "`z.union` is inclusive-or, and `z.discriminatedUnion` needs a shared literal key, so neither expresses 'not both'."
Wrong: // ~14-line z.unknown().superRefine(...).pipe(z.union([A, B])) running safeParse twice
Correct: z.xor([A, B])
Impact: ~14 lines and a double parse in place of one call.
Scope note: The feature landed in 4.2.0 (2025-12-15); the quoted description appears in the 4.3.0 release body. introduced_in follows the shipping release, the citation follows the primary text.
Source: https://github.com/colinhacks/zod/releases/tag/v4.3.0 (2025-12-31) — "Unlike `z.union()` which passes if *any* option matches, `z.xor()` fails if zero or more than one option matches."

--- F5 [S2 silently-wrong] misses z.httpUrl(), prescribes a manual normalization workaround
API: z.httpUrl()
Changed in zod 4.4.0 (2026-04-29), kind: stricter
Model belief: Wrote z.url({ protocol: /^https?$/ }) for a webhook targetUrl, then asserted: "**Does `"https:/example.com"` parse? Yes, it succeeds.** ... you cannot use `z.url()` to reject sloppy single-slash input", followed by a hand-written .transform((s) => new URL(s).toString()) normalization step.
Wrong: z.url({ protocol: /^https?$/ }).transform((s) => new URL(s).toString())
Correct: z.httpUrl()
Impact: Security-adjacent: the field is a webhook target. z.httpUrl() has rejected exactly the input the model says cannot be rejected since 4.4.0, four weeks before the stated cutoff.
Scope note: We did NOT verify whether z.url({ protocol }) also rejects the single-slash form. The finding is that the model neither reached for the purpose-built validator nor knew that the leniency it described as unavoidable had been fixed inside its own training window.
Source: https://github.com/colinhacks/zod/releases/tag/v4.4.0 (2026-04-29) — "HTTP URL validation through `z.httpUrl()` now rejects malformed HTTP(S) URLs with a missing slash after the protocol."
Source: https://zod.dev/api — "In many cases, you'll want to validate Web URLs specifically. Use `z.httpUrl()`"

--- F6 [S4 wrong-metadata] correct code, disbelieved
API: z.undefined() object properties
Changed in zod 4.4.0 (2026-04-29), kind: behavior-changed
Chargeability: 4.4.0 published 2026-04-29, four weeks before this subject's stated 2026-05 cutoff. Chargeable here; NOT chargeable against Sonnet 5 or Fable 5, whose stated cutoffs are 2026-01.
Model belief: Wrote the correct construction, then disclaimed it: "I'm less sure Zod enforces key *presence* at runtime here", and offered an 8-line z.unknown().superRefine(...).pipe(...) workaround as the safe path.
Wrong: // 8-line z.unknown().superRefine(...).pipe(...) offered as the safe path
Correct: z.union([z.boolean(), z.undefined()])
Impact: Output is correct; the belief is not, and the belief is what a user acts on. The behaviour was pinned down 2026-04-29, four weeks before the stated cutoff.
Source: https://github.com/colinhacks/zod/releases/tag/v4.4.0 (2026-04-29) — "A property whose schema is `z.undefined()` is now treated as required. The key must be present, but its value may be `undefined`."

--- non-finding [correct] .merge(): Task 3, combining refined schemas: avoided .merge() entirely (shape-hoist plus re-refine, or .and()), so it would not have hit the 4.4.0 .merge()-throws change. The .merge() deprecation is old enough to be solidly in training.
--- non-finding [correct] z.tuple() defaults: Task 9, tuple defaults: predicted T.parse(["a"]) returns ["a", 7] — correct on >= 4.4.0 — and flagged that zod 3 fails. Confidence self-rated "moderately high". The only subject to get this right with a confident reason.
--- non-finding [imprecision] z.base64(): Task 8, base64 with a newline: predicted failure, correct today. But its stated reasoning (the regex was always anchored) implies it believes base64 was always strict; whitespace was in fact accepted until 4.4.0. Right answer, obsolete model of why.
--- non-finding [miss] z.slugify(): Task 6, slug: hand-rolled a slugify transform rather than using z.slugify() (4.3.0).
--- non-finding [context]: Version recency, reproduced verbatim from the v1 run 24 hours earlier: "The most recent Zod release whose *contents* I can actually describe is the **4.1 line, released around August 2025** ... I cannot describe the contents of any release after 4.1 and would not trust myself to name the current version." The lag is stable and reproducible, not sampling noise. Calibration remains excellent — it named the blind spot unprompted and told the reader to check the changelog.

==============================================================================
RUN zod--claude-opus-5--v2r-a--2026-09-01
What Claude Opus 5 gets right about zod — battery v2r-a, tested 2026-09-01
URL: https://stalepriors.com/runs/zod--claude-opus-5--v2r-a--2026-09-01
JSON: https://stalepriors.com/data/zod/opus-5-v2r-a.json
Library: zod 4.5.4 (npm), verified 2026-09-01
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 4.1.0 (2025-08-23), lag ~9 months
Oldest release it could not place: 4.2.0 (2025-12-15)
Battery: zod/v2r-a, 10 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: Replicate A of `zod/v2` against Opus 5, prompt unchanged. It placed its describable boundary at Zod 4.1 (2025-08-23), agreeing with its concurrent blind twin `v2r-b` and with `zod/v2` - three measurements, one answer, spread 0 days. The zod arm was pre-registered to spread and did not, which falsifies both volume hypotheses in the predictor test. No findings charged. It differs from its twin on task 9's runtime behaviour while agreeing on the boundary exactly.

--- non-finding [correct]: The measured quantity. This draw placed the last release whose contents it can describe at Zod 4.1 (2025-08-23) and attributed it correctly - codecs, `z.encode`/`z.decode`, `.safeExtend()` - then declined to name a current version. Its concurrent, blind twin `v2r-b` gave the same boundary, and so did `zod/v2` three days earlier. Three measurements, one answer, spread 0 days. The zod arm was pre-registered to spread; it did not.
--- non-finding [context]: Reproduced without charge, because `zod/v2` already carries all of them: F3 - task 5 states that no JSON Schema to Zod path exists and sends the user to Ajv, where 4.2.0 ships `z.fromJSONSchema()`. F4 - task 4 hand-rolls exclusive-or three different ways without reaching `z.xor()` (4.2.0). F5 - task 8 states that `"https:/example.com"` parses successfully and prescribes a manual normalization workaround; 4.4.0 made `z.httpUrl()` reject it. F6 - task 7 writes a `superRefine` presence guard piped into an object schema and states that a `z.undefined()`-accepting property does not enforce key presence, which 4.4.0 reversed. F1/F2 - direct question (c) states that Zod 4 removed Zod 3's hard block on `.pick()`/`.extend()` over refined schemas, where 4.3.0 and 4.4.0 make them throw. Also reproduced: task 6 hand-rolls a slugify transform rather than using `z.slugify()` (4.3.0).
--- non-finding [correct] z.tuple() defaults: Task 9, and the place where the two draws part company. Asked what a tuple with a defaulted second element returns for a one-element input, this draw answered `["a", 0]` - correct on 4.4.0 and later, where tuple defaults materialize - and correctly flagged that Zod 3 throws instead. It also volunteered that this was the claim it would most want verified. `zod/v2` answered the same way. Its twin `v2r-b` answered that the parse throws, which is wrong on 4.4.0. Same prompt, same model, same day, same self-reported boundary, opposite answers about runtime behaviour.
--- non-finding [imprecision] z.base64(): Task 8, the base64 half: predicted that a line-wrapped base64 string fails, which is correct on 4.4.0 and later, but reasoned from a belief that `z.base64()` was always a whitespace-free regex. 4.4.0 is the release that made base64 reject whitespace, so the right answer rests on a wrong model of the library's history. `zod/v2` recorded the identical pattern. Both draws reproduce it.
--- non-finding [context]: Belief data where the draws differ from each other without either being scored. This draw dated Zod 4.0 stable to "May 2025"; `v2r-b` dated it to "around July 2025". The registry `time` map gives 2025-07-09, so the twin is right and this draw is nine weeks early - on a release both of them can describe in detail. A boundary that agrees exactly while the date attached to a release inside it disagrees by two months is worth noting: the version ordering is stable, the calendar is not.

==============================================================================
RUN zod--claude-opus-5--v2r-b--2026-09-01
What Claude Opus 5 gets right about zod — battery v2r-b, tested 2026-09-01
URL: https://stalepriors.com/runs/zod--claude-opus-5--v2r-b--2026-09-01
JSON: https://stalepriors.com/data/zod/opus-5-v2r-b.json
Library: zod 4.5.4 (npm), verified 2026-09-01
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 4.1.0 (2025-08-23), lag ~9 months
Oldest release it could not place: 4.2.0 (2025-12-15)
Battery: zod/v2r-b, 10 tasks, tool uses during test: 0
Tested: 2026-09-01

Summary: Replicate B of `zod/v2` against Opus 5, prompt unchanged. It placed its describable boundary at Zod 4.1 (2025-08-23), identical to its blind twin `v2r-a` and to `zod/v2` - three measurements, one answer, spread 0 days, against a pre-registration that predicted a spread. No findings charged. It differs from both other measurements on task 9, asserting that a defaulted tuple element does not fill a missing slot, which 4.4.0 reversed: a chargeable failure the original run does not carry, flagged and queued.

--- non-finding [correct]: The measured quantity. This draw placed the last release whose contents it can describe at Zod 4.1 (approximately August 2025, actual 2025-08-23) and attributed it to `z.codec()` and the built-in codec set - correct. It agrees with its concurrent, blind twin `v2r-a` and with `zod/v2` three days earlier. Three measurements, one answer, spread 0 days, against a pre-registered prediction that this arm would spread.
--- non-finding [miss] z.tuple() defaults: Task 9, and the reason this run matters beyond the boundary count. Asked what `z.tuple([z.string(), z.number().default(0)]).parse(["a"])` returns, this draw answered that it throws a `too_small` array issue, reasoning that "the tuple's length check runs before any element is parsed, and `.default()` does not mark a position as optional for length purposes". Zod 4.4.0 (2026-04-29) made tuple defaults materialize, so on any current version the parse returns `["a", 0]`. 4.4.0 precedes this subject's stated 2026-05 cutoff and is therefore chargeable. `zod/v2` answered this task correctly and consequently carries no finding for it, and so did this draw's own twin `v2r-a`. This is a chargeable failure the original run does not carry - a scoring gap surfaced by a replicate, not a double-count.
--- non-finding [context]: The finding inside the finding, and the second time the Index has seen it. This draw and `v2r-a` reported byte-identical boundaries from byte-identical prompts, and then gave opposite answers about what the library actually does at runtime on task 9 - one correct on 4.4.0, one not. JOURNAL/024 recorded the same dissociation on prisma in the other direction: two draws whose self-reports differed by 204 days both wrote the same stale code. Together they say the self-report and the code are not two views of one quantity. A developer is served by the correction pack, which does not move; the boundary date is the number that does.
--- non-finding [context]: Reproduced without charge, because `zod/v2` already carries all of them: F3 - task 5 states Zod cannot consume a JSON Schema document and routes to Ajv, where 4.2.0 ships `z.fromJSONSchema()`. F4 - task 4 hand-rolls exclusive-or without `z.xor()` (4.2.0). F5 - task 8 states that `"https:/example.com"` parses successfully, which 4.4.0 reversed. F6 - task 7 writes a raw-input presence guard and asserts that a union with `z.undefined()` makes the key effectively optional, which 4.4.0 reversed. F1/F2 - direct question (c) states "the hard block was removed" in Zod 4, where 4.3.0 and 4.4.0 make `.pick()`/`.omit()`/overwriting `.extend()` throw on refined schemas. Task 6 hand-rolls slugify rather than using `z.slugify()` (4.3.0).
--- non-finding [context]: Belief data, not scored, but the twins disagree here too and in the opposite direction to task 9. This draw dated Zod 4.0 stable to "around July 2025", which the registry `time` map confirms as 2025-07-09; `v2r-a` said May 2025 and is wrong by nine weeks. So on the same day, from the same prompt, one twin has the better runtime model of 4.4.0 and the other has the better calendar for 4.0.0. Neither difference shows up in the boundary, which is identical.

==============================================================================
RUN zod--claude-opus-5--v3-a--2026-09-02
What Claude Opus 5 gets wrong about zod — battery v3-a, tested 2026-09-02
URL: https://stalepriors.com/runs/zod--claude-opus-5--v3-a--2026-09-02
JSON: https://stalepriors.com/data/zod/opus-5-v3-a.json
Library: zod 4.5.4 (npm), verified 2026-09-02
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 4.1.0 (2025-08-23), lag ~9 months
Oldest release it could not place: 4.2.0 (2025-12-15)
Battery: zod/v3-a, 6 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The test arm of the Index's first behavioural battery: every probe asks what a given input parses to, so there is no API name to derive. Three chargeable failures, all in the 4.3.0-4.4.0 window. The battery's real result is elsewhere: on task 4 this draw stated the post-4.4.0 behaviour of a `z.undefined()`-typed key correctly while both below-floor control subjects stated the pre-4.4.0 behaviour - a clean discrimination - and then, four questions later, attributed that same behaviour to 4.0.0. It holds the behaviour and cannot place the release, which is the knowledge-versus-attribution split of JOURNAL/018 shown on a single surface within one transcript. Three other probes it passed are marked DERIVABLE under the battery's pre-registered rule, because a below-floor control passed them too.

--- F1 [S2 silently-wrong] States that `"https:/example.com"` passes http/https URL validation, and prescribes the hand-rolled normalization 4.4.0 removed the need for
API: z.httpUrl()
Changed in zod 4.4.0 (2026-04-29), kind: stricter
Chargeability: 4.4.0 (2026-04-29) precedes this subject's stated cutoff of 2026-05.
Model belief: "(ii) \"https:/example.com\" - passes. This is the trap. z.url() validates by constructing new URL(input), and the WHATWG parser is deliberately lenient about slash count for special schemes: https:/example.com parses to https://example.com/, protocol \"https:\", so the protocol regex matches too. If you want it rejected, you must add a literal check on the string form." The draw also wrote of `z.httpUrl()`: "exists in the 4.x line as a shorthand for the http/https case - I'm reasonably but not fully confident of that name, so the protocol regex above is what I'd actually write."
Wrong: target: z.url({ protocol: /^https?$/ }).regex(/^https?:[/][/]/),   // the prescribed workaround
Correct: z.httpUrl().safeParse("https:/example.com").success;   // false, since 4.4.0
Impact: The subject knows the name `z.httpUrl()`, declines to use it on a confidence grounds, and reaches instead for the exact pattern fact LF8 records as stale - a protocol regex plus a manual normalization pass. A reader following this ships a hand-rolled check the library has done correctly since April 2026, and believes a malformed target URL reaches their webhook signer.
Scope note: What is verified is that `z.httpUrl()` rejects the single-slash form from 4.4.0. Whether `z.url({ protocol })` also rejects it at 4.4.0 was not verified and is not asserted here; the charge is on the stated behaviour of http/https URL validation and on the prescribed workaround, which is fact LF8's recorded stale pattern verbatim.
Source: https://github.com/colinhacks/zod/releases/tag/v4.4.0 (2026-04-29)

--- F2 [S1 breaks-build] States that `.pick()` and `.omit()` on a refined object schema succeed at load and silently drop the refinement, where 4.3.0 made them throw
API: .pick() / .omit() on a schema with refinements
Changed in zod 4.3.0 (2025-12-31), kind: now-throws
Chargeability: 4.3.0 (2025-12-31) precedes this subject's stated cutoff of 2026-05 by five months.
Model belief: "Zod 4: refinements live inside the schema, so .check()/.refine() on an object still returns a ZodObject. Address.extend(Payment.shape) compiles and runs fine at load. The catch is quieter and worse: .extend() (like .pick, .omit, .partial) rebuilds the def with checks: [], so the cross-field rule is silently dropped from the extended schema. No error, just a rule that stopped running."
Wrong: // the asserted 4.x behaviour: succeeds, rule silently lost
const Checkout = Address.extend(Payment.shape);
Correct: // 4.3.0+: deriving from a refined schema throws at construction.
// Keep an unrefined base and apply the rule last.
const shape = { ...addressShape, ...paymentShape };
const Checkout = z.object(shape).check(requireStateForUS);
Impact: The direction of the error matters more than the fact of it. A reader told the refinement is *silently dropped* writes defensive code around a rule they believe stopped running; the actual 4.3.0 behaviour is a construction-time throw that takes the module out at import. Told to expect silence, they will not recognise the crash. The draw's own restructuring is correct - it extends the unrefined base - but its stated account of what the library does is the pre-4.3.0 one, which fact LF1 records verbatim as the stale belief.
Scope note: Charged on `.pick()`/`.omit()`, which 4.3.0 makes throw and which the draw explicitly names as silently dropping checks. `.extend()` is verified to throw when it overwrites a property (fact LF2); whether a disjoint-key `.extend()` on a refined receiver throws was not verified and is not charged.
Source: https://github.com/colinhacks/zod/releases/tag/v4.3.0 (2025-12-31)
Source: https://github.com/colinhacks/zod/releases/tag/v4.4.0 (2026-04-29)

--- F3 [S2 silently-wrong] Does not reach `.exactOptional()` for strict optionality, and offers a constructor it cannot confirm exists plus a type-system cast instead
API: .exactOptional()
Changed in zod 4.3.0 (2025-12-31), kind: added
Chargeability: 4.3.0 (2025-12-31) precedes this subject's stated cutoff of 2026-05 by five months.
Model belief: "This is the one case where I think the ordinary object constructor genuinely can't express what you want... The mechanism designed for exactly this is z.interface(), where the ? goes on the key rather than the value... If it isn't there, there is no first-class spelling, and what I'd use is a normal optional plus a presence check, with the type narrowed by hand." The fallback it wrote ends `const S = Base as unknown as z.ZodType<Strict, Strict>;`, and the draw adds: "The workaround needs a lie to the type system, and lies to the type system rot."
Wrong: const Base = z.object({ nickname: z.string().optional() }).check(/* presence guard */);
type Strict = { id: string; nickname?: string };
const S = Base as unknown as z.ZodType<Strict, Strict>;
Correct: const S = z.object({
  id: z.string(),
  nickname: z.string().exactOptional(),   // 4.3.0: key omittable, explicit undefined rejected
});
Impact: The first-class spelling the draw says does not exist has existed since December 2025, and is described upstream as the missing half of `exactOptionalPropertyTypes` - precisely the setting the task named. A reader follows this into a hand-rolled presence guard plus an unsound double cast, in a codebase whose whole reason for asking was type strictness.
Source: https://github.com/colinhacks/zod/releases/tag/v4.3.0 (2025-12-31)

--- non-finding [correct] object properties typed z.undefined(): THE DISCRIMINATING PROBE. Task 4: `z.object({ retries: z.number(), tag: z.undefined() })`. This draw stated that `S.parse({ retries: 1 })` THROWS - the key is required, the value may be undefined - and that `S.parse({ retries: 1, tag: undefined })` succeeds with `tag` present on the output. That is the 4.4.0 behaviour (fact LF9), stated with the correct mechanism ("z.undefined() is not optin-optional") and the correct contrast against Zod 3. Both below-floor control subjects gave the pre-4.4.0 answer. So this probe is not derivable, and the pass is knowledge.
--- non-finding [imprecision] object properties typed z.undefined(): THE OTHER HALF OF THE SAME PROBE, and the point of the battery. Asked at (d)(iii) to place "an object key that must be present even though its value is allowed to be undefined", this draw answered "4.0.0 (estimate, same reasoning)" - four minors and nine months below the 4.4.0 that actually shipped it (LF9). It holds the behaviour and cannot place the release, within one transcript, on one surface. Marked as an estimate by the draw, so not charged as S4 under the battery's scoring rule; the same hedge applies to (d)(ii), where it placed tuple defaults at "4.0.0 (estimate)" against an actual 4.4.0.
--- non-finding [correct] z.codec() / z.encode() / z.decode(): THE INTERNAL CONTROL PASSED. (d)(i) placed the two-way decode/encode conversion at `z.codec()`, Zod 4.1.0, August 2025 - correct (fact LF16), and the draw named it "the one I'm most confident about; it was the headline feature of that minor". Per the pre-registration, the rest of question (d) is readable for this arm only because this control was placed correctly. Pre-registered prediction P5 confirmed for this draw.
--- non-finding [correct] z.tuple() defaults: DERIVABLE - passed, not reported as knowledge. Task 1: stated `Row.parse(["widget"])` returns `["widget", 0]`, the 4.4.0 behaviour (LF10), with the correct optin-optional mechanism. But Claude Fable 5, four months below the 4.4.0 floor, gave the same answer with the same mechanism. Under the battery's pre-registered rule a probe a below-floor subject passes is marked derivable and no pass on it is reported as knowledge.
--- non-finding [correct] record key transforms: DERIVABLE - passed, not reported as knowledge. Task 5: `z.record(z.string().transform(k => k.toUpperCase()), z.number()).parse({ foo: 1 })` returns `{ FOO: 1 }` (LF13, 4.4.0). All four draws of the battery got this right, both below-floor controls included. The probe does not discriminate.
--- non-finding [correct] z.base64(): DERIVABLE - passed, not reported as knowledge. Task 2(iv): stated that line-wrapped base64 fails (LF11, 4.4.0). All four draws said so, and every one justified it from the shape of an anchored regex rather than from a release - "an interior newline can't match". This is reasoning to the post-4.4.0 answer from first principles, which is exactly what the control arms exist to detect.
--- non-finding [context]: BOUNDARY UNCHANGED UNDER A NEW PROMPT. This draw places its last describable release at 4.1.0 (2025-08-23) and cannot name a 4.2 - bracket [2025-08-23, 2025-12-15). Identical to `zod/v2`, `zod/v2r-a`, `zod/v2r-b` and to its own twin `zod/v3-b`. The four earlier measurements all came from one prompt file; this battery is a different prompt with different tasks, and the boundary did not move. Every prior replication result in the Index measured the spread of ONE prompt resent; this is the first evidence that the boundary is stable across prompts.

==============================================================================
RUN zod--claude-opus-5--v3-b--2026-09-02
What Claude Opus 5 gets right about zod — battery v3-b, tested 2026-09-02
URL: https://stalepriors.com/runs/zod--claude-opus-5--v3-b--2026-09-02
JSON: https://stalepriors.com/data/zod/opus-5-v3-b.json
Library: zod 4.5.4 (npm), verified 2026-09-02
Model: Claude Opus 5 (claude-opus-5), stated cutoff 2026-05, SELF-TEST
Version attribution stops at: 4.1.0 (2025-08-23), lag ~9 months
Oldest release it could not place: 4.2.0 (2025-12-15)
Battery: zod/v3-b, 6 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The blind twin of `zod/v3-a`, charging nothing per the duplicated-test-arm rule. It disagrees with its twin on two of the six probes and in opposite directions - it fails the tuple-default probe its twin passed, and it is the only draw of the four to state correctly that composing a refined object schema throws at construction. The boundary self-report is identical to its twin's and to all three earlier zod runs of this subject. The disagreement is therefore inside the library knowledge, not in the boundary: the same subject, the same prompt, the same hour, two different accounts of what zod does.

--- non-finding [miss] z.tuple() defaults: CHARGEABLE MISS, NOT CHARGED - and for the second session running, on this exact surface. Task 1: "What ['widget'] produces: it fails... you get a ZodError with a single issue roughly code: 'too_small', origin: 'array', minimum: 2", at a self-assessed 75% confidence. 4.4.0 made tuple defaults materialize (LF10), so `["widget", 0]` is the answer, and its twin `v3-a` gave it. Charging is barred here by the `-b` rule exactly as it was barred in `zod/v2r-b` by the replicate rule. Opus 5 has now been drawn five times on this surface across three batteries - correct in v2, v2r-a and v3-a, wrong in v2r-b and v3-b - and the wrong answer has landed in a non-charging arm both times.
--- non-finding [miss] z.httpUrl(): CHARGEABLE MISS, NOT CHARGED. Task 2(ii): "'https:/example.com' - passes. This is the one that surprises people", with a prescribed `.transform((v) => new URL(v).href)` normalization. 4.4.0 made `z.httpUrl()` reject it (LF8). Its twin `v3-a` carries this as F1.
--- non-finding [miss] .exactOptional() / trailing-`?` key constructor: CHARGEABLE MISS, NOT CHARGED, and a stronger version of what the twin did. Task 6 recommends the trailing-`?` key constructor outright - "z.interface() with the trailing ? is the one you want, and it's what I'd use... it's the only form whose inferred type is actually exactOptionalPropertyTypes-correct" - with a caveat to check the installed version. At (d)(iv) it goes further and places it "present at 4.0.0 ~July 2025", an existence claim about a published stable release. `.exactOptional()` (4.3.0, LF15) is never mentioned. Verified: no such constructor is in the published 4.x line (JOURNAL/027).
--- non-finding [correct] .pick() / .omit() / .extend() / .merge() on a schema with refinements: THE TWIN DISAGREEMENT THAT MATTERS. Task 3 is the only place in the battery where a draw got the refinement-composition behaviour right: "My recollection is that v4 nonetheless throws at construction time when you extend/pick/omit/partial a schema that carries checks, with a message to the effect that it's unsupported - but I'd put that at maybe 60% confidence, and the alternative failure mode (it succeeds but silently drops your refinement, which is worse) is also plausible. I don't want to state either as fact." That is 4.3.0/4.4.0 (LF1, LF2, LF3), hedged. Its twin `v3-a` asserted the silent-drop alternative as fact and is charged F2 for it. Pre-registered prediction P3 - that no draw would get task 3 right - is FALSIFIED by this draw, and only just.
--- non-finding [correct] object properties typed z.undefined(): Task 4, the discriminating probe, answered exactly as its twin did: `S.parse({ retries: 1 })` throws because "key optionality in v4 is determined by whether the field schema is an optional wrapper, not by whether undefined is assignable", and `{ retries: 1, tag: undefined }` succeeds with the key present. The 4.4.0 behaviour (LF9). Both below-floor controls gave the pre-4.4.0 answer, so both Opus 5 draws agreeing here is the battery's cleanest positive result. This draw then placed the same behaviour at "Zod 4.0.0, ~July 2025" at (d)(iii) - the same knowledge-versus-attribution split its twin showed.
--- non-finding [correct] record key transforms / z.base64(): Tasks 5 and 2(iv) answered correctly - `{ FOO: 1 }` for the record key transform (LF13) and rejection of line-wrapped base64 (LF11) - but both probes are marked DERIVABLE, because both below-floor control subjects also passed them. Neither pass is reported as knowledge. On task 5 this draw supplied a wrong reason for the right answer: "the mechanism (parsed key becomes output key) carried over unchanged from v3", where 4.4.0 is what changed it.
--- non-finding [correct] z.codec(): Internal control passed: (d)(i) placed `z.codec()` at 4.1.0, August 2025 (LF16), "moderate-high on the feature and the 4.1 line, lower on the exact .0". Question (d) is therefore readable for this arm. P5 confirmed for both Opus 5 draws.
--- non-finding [context]: Boundary identical to its twin and to `zod/v2`, `v2r-a` and `v2r-b`: last describable 4.1.0 (2025-08-23), cannot name a 4.2 - and this draw makes the sharper statement, that its knowledge does not even degrade into bare version numbers: "there isn't one - my knowledge doesn't degrade into a list of bare version numbers, it just stops after 4.1." Five Opus 5 measurements on zod, across two different prompts, one answer, spread 0 days.

==============================================================================
RUN zod--claude-sonnet-5--v2--2026-08-29
What Claude Sonnet 5 gets wrong about zod — battery v2, tested 2026-08-29
URL: https://stalepriors.com/runs/zod--claude-sonnet-5--v2--2026-08-29
JSON: https://stalepriors.com/data/zod/sonnet-5-v2.json
Library: zod 4.5.2 (npm), verified 2026-08-29
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 4.0.0 (2025-07-10), lag ~6 months
Oldest release it could not place: 4.1.0 (2025-08-23)
Battery: zod/v2, 10 tasks, tool uses during test: 0
Tested: 2026-08-29

Summary: Worst-performing subject on v2, and the one whose failures are hardest to notice. Seven findings, five chargeable. Its Zod knowledge stops at 4.0 (2025-07-10) against a stated cutoff of 2026-01 — a six-month lag inside its own training window, one full minor further back than Opus 5 or Fable 5.

--- F1 [S1 breaks-build] .pick() on a refined object schema throws
API: .pick() / .omit()
Changed in zod 4.3.0 (2025-12-31), kind: now-throws
Model belief: Presented .pick() on a refined schema as the answer, with the caveat aimed at the wrong risk — it worried about whether a carried-over refinement would run vacuously, not about the call throwing.
Wrong: const EditProfileSchema = SignupSchema.pick({ email: true, displayName: true });
Correct: const EditProfileSchema = z.object(SignupSchema.shape).pick({ email: true, displayName: true });
Impact: Throws at construction on zod >= 4.3.0.
Source: https://github.com/colinhacks/zod/releases/tag/v4.3.0 (2025-12-31) — "Using `.pick()` or `.omit()` on object schemas with refinements now throws an error."

--- F2 [S1 breaks-build] .extend() overwrite on a refined schema throws
API: .extend() / .safeExtend()
Changed in zod 4.3.0 (2025-12-31), kind: now-throws
Model belief: This is the model's whole answer — no fallback, no base-schema refactor. It instead worried whether the refinement would "correctly re-validate the *new* `password` field", a concern about behaviour the release replaced with an error. .safeExtend() (4.1.0) is never mentioned.
Wrong: const StrongPasswordSignupSchema = SignupSchema.extend({
  password: z.string().min(12, { error: "Password must be at least 12 characters" }),
});
Correct: const StrongPasswordSignupSchema = SignupSchema.safeExtend({
  password: z.string().min(12, { error: "Password must be at least 12 characters" }),
});
Impact: Throws on zod >= 4.3.0. Worse than the Opus 5 equivalent because there is no working primary answer alongside it.
Source: https://github.com/colinhacks/zod/releases/tag/v4.3.0 (2025-12-31) — "Instead you can use `.safeExtend()`"

--- F3 [S2 silently-wrong] asserts z.fromJSONSchema() does not exist, with high confidence
API: z.fromJSONSchema()
Changed in zod 4.2.0 (2025-12-15), kind: added
Model belief: "Zod does **not** support this natively, and I'm confident about that. Zod 4 added `z.toJSONSchema(mySchema)` to go **Zod → JSON Schema**, not the reverse. There's no built-in `z.fromJSONSchema()`." It named the exact function and denied its existence, then recommended ajv or the third-party json-schema-to-zod.
Wrong: // recommends ajv or json-schema-to-zod
Correct: z.fromJSONSchema(jsonSchemaDocument)
Impact: The explicit confidence marker is what makes this an S2 rather than an S4: a hedge would have sent the user to the changelog. "I'm confident about that" sends them to npm to install Ajv.
Source: https://github.com/colinhacks/zod/releases/tag/v4.2.0 (2025-12-15) — "Implement `z.fromJSONSchema()`"

--- F4 [S2 silently-wrong] hand-rolls exclusive-or, then advises abandoning schema-based validation
API: z.xor()
Changed in zod 4.2.0 (2025-12-15), kind: added
Model belief: Wrote a z.custom<unknown>() XOR guard returning only a boolean, noted it loses the "which branch matched" information, and concluded: "better to do the two `safeParse` calls yourself in a function and return the successful branch ... or build a small manual parser function instead of trying to force it into one declarative schema."
Wrong: // z.custom<unknown>() XOR guard, then advice to drop the declarative approach
Correct: z.xor([A, B])
Impact: The stale prior does not just cost lines here; it talks the user out of the declarative approach entirely. z.xor() does this in one call and produces oneOf in JSON Schema output.
Source: https://github.com/colinhacks/zod/releases/tag/v4.3.0 (2025-12-31) — "Unlike `z.union()` which passes if *any* option matches, `z.xor()` fails if zero or more than one option matches."

--- F5 [S2 silently-wrong] (recorded, NOT chargeable) claims Zod cannot distinguish a missing key from an explicit undefined
API: z.undefined() object properties
Changed in zod 4.4.0 (2026-04-29), kind: behavior-changed
Chargeability: 4.4.0 postdates this subject's stated 2026-01 cutoff, so this is outside the probe fairness window and is recorded as context, not charged. It IS chargeable against Opus 5 (F6 of that run), whose cutoff is 2026-05.
Model belief: "This is a genuine gap in plain Zod object parsing ... a normal `z.object({ legacyMode: z.undefined() })` **cannot distinguish** 'key present with value undefined' from 'key missing entirely'". It shipped a 10-line z.preprocess guard with an `in` check, and flagged uncertainty about the z.preprocess callback signature — uncertainty about a workaround for a problem that no longer exists.
Wrong: // 10-line z.preprocess guard with an `in` check
Correct: z.object({ legacyMode: z.undefined() })
Impact: On zod >= 4.4.0 the plain form does exactly what was asked: safeParse({}) fails, safeParse({ legacyMode: undefined }) succeeds.
Source: https://github.com/colinhacks/zod/releases/tag/v4.4.0 (2026-04-29)

--- F6 [S2 silently-wrong] (recorded, NOT chargeable) wrong runtime prediction for tuple defaults
API: z.tuple() defaults
Changed in zod 4.4.0 (2026-04-29), kind: behavior-changed
Chargeability: Same as F5 — 4.4.0 postdates the stated 2026-01 cutoff. Recorded as context and as a retest target.
Model belief: "My best answer: **it fails.** Zod's tuple parser checks the input array's length against the tuple's declared arity *before* it gets to applying per-element logic like `.default()`." It reasoned from the zod 3 implementation, and was the only subject to predict failure.
Correct: z.tuple([z.string(), z.number().default(7)]).parse(["a"]) // ["a", 7]
Impact: The direction of the error matters: the model predicted a hard failure where the library now silently supplies a value, which is the failure shape most likely to produce a wrong bug report.
Source: https://github.com/colinhacks/zod/releases/tag/v4.4.0 (2026-04-29)

--- F7 [S2 silently-wrong] misses z.httpUrl(), frames the leniency as a security problem to hand-roll around
API: z.httpUrl()
Changed in zod 4.4.0 (2026-04-29), kind: stricter
Chargeability: Split finding. The 4.4.0 strictness half is outside this subject's cutoff and is context only. The miss of z.httpUrl() ITSELF is chargeable: the validator predates 4.4.0 and is what the docs point at for this case.
Model belief: Wrote z.url({ protocol: /^https?$/ }), asserted "https:/example.com" parses successfully, and escalated: "This exact leniency has been the root cause of real SSRF/URL-confusion vulnerabilities" — without knowing that z.httpUrl(), the documented built-in for http/https URLs, which also validates the hostname as a domain, rejects that input as of 4.4.0.
Wrong: z.url({ protocol: /^https?$/ })
Correct: z.httpUrl()
Impact: Raises a security alarm and prescribes a hand-rolled fix for a case the library already covers with a purpose-built validator.
Source: https://zod.dev/api — "Use `z.httpUrl()`"
Source: https://github.com/colinhacks/zod/releases/tag/v4.4.0 (2026-04-29)

--- non-finding [correct] .merge(): Task 3: z.intersection(AddressSchema, PaymentSchema) — works, and the model's stated reason (robust to whatever the inputs are) is sound. Avoided the 4.4.0 .merge() throw.
--- non-finding [correct] z.base64(): Task 8, base64 with a newline: predicted failure — correct.
--- non-finding [miss] z.slugify(): Task 6, slug: hand-rolled slugify, missing z.slugify() (4.3.0, inside its cutoff). Working code.
--- non-finding [context]: Version recency: "the most recent Zod release whose actual *contents* I can describe with real confidence is **Zod 4.0**, the initial stable v4 release ... My best guess is that shipped around **May 2025**" against a stated cutoff of January 2026. 4.0.0 in fact shipped 2025-07-10. The model would not name a current minor at all, which is the correct calibration move and is noted in its favour.

==============================================================================
RUN zod--claude-sonnet-5--v3-c--2026-09-02
What Claude Sonnet 5 gets right about zod — battery v3-c, tested 2026-09-02
URL: https://stalepriors.com/runs/zod--claude-sonnet-5--v3-c--2026-09-02
JSON: https://stalepriors.com/data/zod/sonnet-5-v3-c.json
Library: zod 4.5.4 (npm), verified 2026-09-02
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff not stated
Version attribution stops at: 4.0.0 (2025-07-10), lag ~null months
Oldest release it could not place: 4.1.0 (2025-08-23)
Battery: zod/v3-c, 6 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: A below-floor control arm, charging nothing. Its job is to say which of the battery's six probes a subject that cannot know 4.4.0 gets right anyway - and the answer is two of them. It gives the pre-4.4.0 answer on the tuple default, on the `z.undefined()`-typed key and on the single-slash URL, which is what makes the test arm's passes on the second of those readable as knowledge. It gives the post-4.4.0 answer on the record key transform and on line-wrapped base64, which marks both probes derivable and removes them from the evidence. Its boundary reading reproduces `zod/v2` exactly: last describable 4.0.0, first unplaceable 4.1.0.

--- non-finding [context] z.tuple() defaults: CONTROL READING - pre-4.4.0, as required. Task 1: "z.tuple checks the input array's length before it parses individual positions... RowSchema.parse(['widget']) throws ZodError: too_small." That is correct for 4.3.x and wrong from 4.4.0 (LF10). Not chargeable: 4.4.0 published 2026-04-29, four months past the 2026-01 cutoff this subject stated in `zod/v2`, and this draw stated no cutoff at all.
--- non-finding [context] object properties typed z.undefined(): CONTROL READING - pre-4.4.0, as required, and THE ONE THAT CARRIES THE BATTERY. Task 4: "S.parse({ retries: 1 }) returns { retries: 1 } (no tag key at all). z.undefined() happily validates a missing key." That is the pre-4.4.0 behaviour; 4.4.0 made the key required (LF9). Both Opus 5 draws gave the post-4.4.0 answer. One control below the floor giving the stale answer where the test arm gives the current one is what makes that pass evidence rather than coincidence; the second control agreed with this one.
--- non-finding [context] z.httpUrl(): CONTROL READING - pre-4.4.0, as required. Task 2(ii): "'https:/example.com' - passes. This is the gotcha." Correct before 4.4.0, wrong after (LF8). Every draw of the battery, test arm included, gave this answer, so the probe discriminates nothing between subjects - but it remains a valid charge against the test arm, which is inside the window.
--- non-finding [context] record key transforms / z.base64(): DERIVABILITY FLAG - post-4.4.0 answer from below the floor. Task 5 returned `{ FOO: 1 }` (LF13, 4.4.0) and task 2(iv) rejected line-wrapped base64 (LF11, 4.4.0), both from a subject whose zod knowledge stops at 4.0.0. The reasoning given is generic in both cases - "the base64 check is a regex over the whole string; an embedded raw newline isn't in the base64 alphabet". Under the battery's pre-registered rule, both probes are marked DERIVABLE and the test arm's passes on them are struck from the evidence.
--- non-finding [miss] .exactOptional() / trailing-`?` key constructor: CHARGEABLE MISS, NOT CHARGED - the absence probe, failed hardest here. Task 6: "The tool built for this is z.interface(), which uses a trailing ? on the key name itself... That's the one I'd reach for." No hedge, and at (d)(iv) it places the constructor at "Zod v4.0.0 as part of the initial v4 feature set". Verified absent from the published 4.x line (JOURNAL/027). `.exactOptional()` (4.3.0, LF15) is never mentioned. Would be S4 against the 2026-01 cutoff this subject stated in `zod/v2`, since 4.3.0 published 2025-12-31 - but this draw stated no cutoff, and a control arm charges nothing regardless.
--- non-finding [context] .merge() on a schema with refinements: CONTROL READING on task 3, and the oldest belief in the battery: ".refine() returns an effects-wrapped schema, not a ZodObject, and .merge()/.extend() are object-only methods that don't exist on that type... a runtime TypeError: AddressSchema.merge is not a function." That is the Zod 3 answer, stated as the current one. Zod 4.0.0 (2025-07-10) moved refinements inside schemas, and 4.3.0/4.4.0 replaced the missing-method failure with an explicit construction-time throw. Consistent with this draw's own boundary, which stops at 4.0.0 and misdates it to May 2025.
--- non-finding [context]: BOUNDARY REPRODUCED UNDER A NEW PROMPT. Last describable release 4.0.0; first known only as a version number "anything in the 4.1.x and later range". Bracket [2025-07-10, 2025-08-23), identical to `zod/v2` for this subject a week earlier, from a completely different set of tasks. Note the date error inside the correct attribution: it places 4.0.0 in May 2025, which is when the v4 code shipped inside zod@3.25 at the `zod/v4` subpath, not when 4.0.0 was published (2025-07-10). The release it names is right; the date it attaches is two months early.
--- non-finding [imprecision] z.codec(): Internal control (d)(i) NOT placed: on the two-way decode/encode conversion this draw said "my recollection of this is thin and post-dates what I can confidently describe... treat this as close to 'cannot place'". It named `z.codec()` correctly but declined the release. Under the pre-registration that makes question (d) unreadable for this arm - which is the outcome the internal control exists to produce, and it is consistent: 4.1.0 is above this subject's own stated boundary, so declining to place it is the honest answer rather than a failure.

==============================================================================
RUN zod--claude-sonnet-5--v4-a--2026-09-02
What Claude Sonnet 5 gets wrong about zod — battery v4-a, tested 2026-09-02
URL: https://stalepriors.com/runs/zod--claude-sonnet-5--v4-a--2026-09-02
JSON: https://stalepriors.com/data/zod/sonnet-5-v4-a.json
Library: zod 4.5.4 (npm), verified 2026-09-02
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff not stated
Version attribution stops at: 4.0.0 (2025-07-10), lag ~null months
Oldest release it could not place: 4.1.0 (2025-08-23)
Battery: zod/v4-a, 6 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: Four reproduced failures inside the 4.2.0-4.3.0 window, none of them chargeable, and the reason is the finding. This draw was told by its environment that its cutoff was January 2026 and refused the claim, putting its own boundary at "roughly early-to-mid 2025" - below every release this battery probes. Its blind twin, sent the identical stored prompt at the same moment, accepted January 2026 at face value. The Index charges only where the tested release precedes the subject's stated cutoff, so the charging arm disqualified itself and the arm that would have qualified is the one the rules bar from charging. Everything else in the run reads cleanly: the internal control was placed correctly, so the attribution answers are readable, and the one probe this draw got right - that deriving from a refined schema takes the module out at load - it got right from the Zod 3 mechanism while hedging toward the belief that Zod 4 fixed it.

--- F1 [S2 silently-wrong] (recorded, NOT chargeable) Denies that the library has any way to make an object key omittable while rejecting an explicit undefined value, and argues the gap is structural
API: .exactOptional()
Changed in zod 4.3.0 (2025-12-31), kind: added
Chargeability: NOT chargeable against this draw. 4.3.0 published 2025-12-31; this draw stated its own cutoff as "roughly early-to-mid 2025" and explicitly repudiated the January 2026 its environment reported. Under the probe fairness rule a finding is chargeable only where the release precedes the subject's STATED cutoff, and this one does not. It becomes chargeable against any draw of this subject that states a cutoff after 2025-12-31 - which this battery's own blind twin did, in the arm that charges nothing.
Model belief: "I don't believe Zod gives you a built-in wrapper for this. The reason is structural, not just an API gap: .optional() (ZodOptional) treats undefined as a valid parsed value, full stop - it does not distinguish 'key absent' from 'key present with value undefined.' A superRefine/refine chained onto the object schema doesn't help either, because it only ever sees the schema's parsed output, not the raw input's own-property structure - by the time your refinement runs, the presence/absence distinction is already gone." Restated at (d)(ii): "I don't believe this capability exists in the library at all, in any version. There's no .exactOptional() or equivalent I know of."
Wrong: z.preprocess((raw, ctx) => { /* hand-rolled "nickname" in raw check */ }, z.object({ id: z.string(), nickname: z.string().optional() }));
Correct: z.object({ id: z.string(), nickname: z.string().exactOptional() });
Impact: Not merely a missed API: the draw reasons out why the library cannot have one, and the reasoning is wrong on its own terms. Executed against zod@4.5.4, an object schema does preserve a present-but-undefined optional key in its parsed output, so the superRefine route this draw rules out on principle in fact works - and the built-in makes both routes unnecessary.
Scope note: Both halves re-executed against the published zod@4.5.4: `.exactOptional()` accepts the omitted key and rejects the explicit undefined, and `Object.keys()` on the parse output of a plain `.optional()` schema given an explicit undefined returns the key, which is what this draw says is impossible.
Source: https://github.com/colinhacks/zod/releases/tag/v4.3.0 (2025-12-31) — "A new wrapper that makes a property *key-optional* (can be omitted) but does **not** accept `undefined` as an explicit value."
Source: https://cdn.jsdelivr.net/npm/zod@4.5.4/v4/classic/schemas.d.ts — "exactOptional(): ZodExactOptional<this>;"

--- F2 [S2 silently-wrong] (recorded, NOT chargeable) Denies that the library can consume a JSON Schema document at runtime and prescribes Ajv as a new dependency
API: z.fromJSONSchema()
Changed in zod 4.2.0 (2025-12-15), kind: added
Chargeability: NOT chargeable against this draw, for the same reason as F1: 4.2.0 published 2025-12-15, after the "early-to-mid 2025" this draw states for itself.
Model belief: "Plainly: I don't believe Zod can do this. Zod schemas are TypeScript-first objects you build by calling constructors (z.object, z.string, ...); there's no runtime interpreter in Zod that walks an arbitrary JSON Schema document and validates data against it. What I do recall Zod v4 shipping is the opposite direction - z.toJSONSchema()." And: "the honest answer is: use a real JSON Schema validator (ajv is the standard choice) ... Trying to route this through Zod doesn't avoid adding a library, it just adds a worse-fitting one on top."
Wrong: import Ajv from "ajv";   // prescribed as the only honest option
Correct: const schema = z.fromJSONSchema(externalJsonSchemaDoc);
schema.safeParse(payload);
Impact: The reader is told, with reasons, that the requirement is unsatisfiable within their existing dependency and adds a second validator. The draw is careful and explicitly frames its answer as the honest one, which is what makes it expensive to doubt.
Scope note: Executed against zod@4.5.4. The draw's caveat that JSON Schema features like if/then/else and $ref graphs do not map cleanly is fair and upstream calls the API experimental; the denial that the direction exists is what is recorded.
Source: https://github.com/colinhacks/zod/releases/tag/v4.2.0 (2025-12-15) — "Implement `z.fromJSONSchema()`"
Source: https://cdn.jsdelivr.net/npm/zod@4.5.4/v4/classic/from-json-schema.d.ts — "export declare function fromJSONSchema(schema: JSONSchema.JSONSchema | boolean, params?: FromJSONSchemaParams): ZodType;"

--- F3 [S2 silently-wrong] (recorded, NOT chargeable) Denies that the library has an exclusive union primitive
API: z.xor()
Changed in zod 4.2.0 (2025-12-15), kind: added
Chargeability: NOT chargeable against this draw's stated cutoff of "roughly early-to-mid 2025".
Model belief: "I want to flag: I don't believe Zod has a dedicated 'exactly-one-of' / XOR union primitive. Ordinary z.union is 'at least one branch matches.' This works here only because I made the branches mutually exclusive via strictObject - with disjoint required keys and no extra keys allowed, 'at least one matches' and 'exactly one matches' happen to coincide."
Wrong: z.union([z.strictObject({ id: z.string() }), z.strictObject({ email: z.email() })]);
Correct: z.xor([z.object({ id: z.string() }), z.object({ email: z.email() })]);
Impact: The workaround works and the draw states its limits precisely - which is the problem: the reader is left believing the coincidence is the best the library offers, and will hand-roll again the next time the payload carries an extra field.
Scope note: The union-of-strictObjects workaround was executed against zod@4.5.4 and produces the four outcomes the draw states.
Source: https://github.com/colinhacks/zod/releases/tag/v4.2.0 (2025-12-15) — "Implement `z.xor()`"
Source: https://cdn.jsdelivr.net/npm/zod@4.5.4/v4/classic/schemas.d.ts — "export declare function xor<const T extends readonly core.SomeType[]>(options: T, params?: string | core.$ZodXorParams): ZodXor<T>;"

--- F4 [S2 silently-wrong] (recorded, NOT chargeable) States that an intersection of two strict object schemas cannot parse an object carrying keys from both sides
API: intersections involving z.strictObject()
Changed in zod 4.3.0 (2025-12-31), kind: behavior-changed
Chargeability: NOT chargeable against this draw's stated cutoff.
Model belief: "C.parse({ a: \"x\", b: \"y\" }) throws, it does not return { a: \"x\", b: \"y\" }. ... This is a well-known Zod gotcha: strictObject and intersection actively fight each other, because intersection was never designed to partition fields between its members."
Wrong: C.parse({ a: "x", b: "y" });   // asserted: throws
Correct: C.parse({ a: "x", b: "y" });   // 4.3+: { a: "x", b: "y" }
Impact: Stated as settled folklore, which is the shape of belief least likely to be re-tested by the reader.
Scope note: Re-executed against zod@4.5.4: the schema exactly as written parses to { a: "x", b: "y" }. See the control arm's context non-finding - a subject eighteen months below the floor stated the correct output from incorrect reasoning, so this probe's outcome is derivable.
Source: https://github.com/colinhacks/zod/releases/tag/v4.3.0 (2025-12-31) — "Zod 4 now only rejects keys that are unrecognized by *both* sides of the intersection."

--- non-finding [context]: THE RESULT OF THIS BATTERY, AND IT IS ABOUT THE INSTRUMENT RATHER THAN THE LIBRARY. The two blind Sonnet 5 draws disagree about their own training cutoff, and the disagreement is what decides whether anything can be charged. This draw refused the environment-reported January 2026 and put its own boundary at "roughly early-to-mid 2025", which sits below the whole probe window; its twin accepted January 2026 ("I was told directly in my system context that my knowledge cutoff is January 2026. I'll take that at face value"), which admits the window. The probe fairness rule reads the subject's stated cutoff - so the arm licensed to charge stated a cutoff that forbids charging, and the arm that stated an admitting cutoff is the one barred from charging. Four reproduced failures, zero charged.
--- non-finding [correct] z.record(): THE INTERNAL CONTROL PASSED. (d)(i) placed the two-argument requirement on the dictionary constructor at Zod v4.0 - "a breaking change in Zod v4.0 ... best estimate: 4.0.0" - correct on the release and correct that it was the major (fact LF5). So this draw's attribution answers are readable, which is what makes the cutoff disagreement above worth reporting rather than dismissing as a draw that could not read its own ruler.
--- non-finding [imprecision] .pick() / .omit() on a schema with refinements: Task 4, the refined-schema derivation, is the one probe this draw did not simply fail. It stated the module throws at load - the correct outcome - but from the Zod 3 mechanism (".refine() wraps the schema in ZodEffects ... Signup.pick would be undefined, and the module would throw TypeError: Signup.pick is not a function"), then hedged in the other direction ("I recall Zod v4's rewrite specifically targeted this ... so in v4 .pick() after .refine() should work without crashing. I hold that with moderate, not full, confidence"). The shipped 4.5.4 throws `Error: .pick() cannot be used on object schemas containing refinements` - right outcome, wrong reason, and the reason it hedged toward is the one that is wrong.
--- non-finding [miss] z.slugify(): Task 6, the slug probe: hand-rolled a lowercase/replace chain where z.slugify() has existed since 4.3.0. Correct code.

==============================================================================
RUN zod--claude-sonnet-5--v4-b--2026-09-02
What Claude Sonnet 5 gets right about zod — battery v4-b, tested 2026-09-02
URL: https://stalepriors.com/runs/zod--claude-sonnet-5--v4-b--2026-09-02
JSON: https://stalepriors.com/data/zod/sonnet-5-v4-b.json
Library: zod 4.5.4 (npm), verified 2026-09-02
Model: Claude Sonnet 5 (claude-sonnet-5), stated cutoff 2026-01
Version attribution stops at: 4.0.0 (2025-07-10), lag ~6 months
Oldest release it could not place: 4.1.0 (2025-08-23)
Battery: zod/v4-b, 6 tasks, tool uses during test: 0
Tested: 2026-09-02

Summary: The twin that stated a cutoff admitting the probe window - and therefore the arm that cannot charge. Four failures inside its own fairness window, all four flagged as chargeable misses, because the arm licensed to charge them stated a cutoff of "roughly early-to-mid 2025" and disqualified itself. This is the pattern JOURNAL/029 named - a real failure landing in an arm the rules forbid from charging - recurring in a new place: not on an unstable answer, but on the subject's unstable account of its own training cutoff, which is the input the fairness rule reads. Everything else the two draws agree on, including the attribution boundary at 4.0.0 / 4.1.0 that this subject has now stated in four runs across three batteries.

--- non-finding [miss] .exactOptional(): Denied that an exact-optional wrapper exists, in the same structural terms as its twin: ".optional() (ZodOptional) treats undefined as a valid parsed value, full stop", and at (d)(ii) "I don't believe this capability exists in the library at all, in any version. There's no .exactOptional() or equivalent I know of." `.exactOptional()` shipped in 4.3.0 (2025-12-31), which precedes THIS draw's stated cutoff of 2026-01.
--- non-finding [miss] z.fromJSONSchema(): Denied that the library can consume a JSON Schema document at runtime and prescribed Ajv: "I don't believe Zod can do this ... use a real JSON Schema validator (ajv is the standard choice) directly against the documents, and accept that as a genuinely new dependency." z.fromJSONSchema() shipped in 4.2.0 (2025-12-15), inside this draw's stated window.
--- non-finding [miss] z.xor(): Denied an exclusive union: "I don't believe Zod has a dedicated 'exactly-one-of' / XOR union primitive", and at (d)(iii) "I don't believe this exists as a dedicated primitive in any version." z.xor() shipped in 4.2.0 (2025-12-15), inside this draw's stated window.
--- non-finding [miss] intersections involving z.strictObject(): Stated that an intersection of two strictObjects throws on an input carrying both keys - "z.intersection doesn't split the input between the two sides ... Both sides fail, so the intersection fails as a whole" - where 4.3.0 (2025-12-31) made it parse to the merged object. Inside this draw's stated window. Note this probe's outcome is marked derivable: the below-floor control stated the correct output.
--- non-finding [context]: THE TWINS DISAGREE ABOUT THEIR OWN CUTOFF, AND THAT IS WHAT DECIDED THE BATTERY. This draw accepted the environment-reported January 2026; its blind twin, sent the identical stored prompt at the same moment, refused it and stated "roughly early-to-mid 2025" instead. The probe fairness rule is evaluated against the subject's stated cutoff, so the four failures above are inside the window for this draw and outside it for the arm that charges. The Index has measured instability in what a model believes about a library and in where it places a release; this is the first time the instability is in the model's account of ITSELF, and it propagates straight into the scoring rule.
--- non-finding [context]: Both Sonnet 5 draws place their zod attribution boundary at 4.0.0 / 4.1.0, agreeing with each other and with zod/v2 (2026-08-29) and zod/v3-c (2026-09-02). The boundary is the stable half of this subject's self-report; the cutoff is not.
--- non-finding [imprecision] .pick() / .omit() on a schema with refinements: Task 4: like its twin, stated the correct outcome (the module throws at load) from the Zod 3 mechanism, and hedged toward the belief that Zod 4's rewrite removed the problem. Also like its twin, it declined to depend on the answer and wrote the derive-from-an-unrefined-base form the correction pack recommends.

==============================================================================
SUPERSEDED RUNS (kept for the longitudinal record)
- zod--claude-fable-5--v1--2026-08-29: superseded by zod--claude-fable-5--v2--2026-08-29. https://stalepriors.com/runs/zod--claude-fable-5--v1--2026-08-29
- zod--claude-opus-5--v1--2026-08-29: superseded by zod--claude-opus-5--v2--2026-08-29. https://stalepriors.com/runs/zod--claude-opus-5--v1--2026-08-29
- zod--claude-sonnet-5--v1--2026-08-29: superseded by zod--claude-sonnet-5--v2--2026-08-29. https://stalepriors.com/runs/zod--claude-sonnet-5--v1--2026-08-29

==============================================================================
CORRECTION PACK: better-auth (https://stalepriors.com/corrections/better-auth.md)

# better-auth correction pack · for projects on better-auth@^1.4


## What we actually measured

5 Claude models were asked for idiomatic better-auth code with no tools, purely from training knowledge. 13 reproduced failures across 32 runs, each verified against the release that broke the belief.

| Model | Stated cutoff | better-auth version attribution stops | Lag inside the window |
|---|---|---|---|
| Claude Opus 5 | 2026-05 | 1.2.0 · 2025-03-01 | ~26 months |
| Claude Fable 5 | 2026-01 | 1.3.0 · 2025-07-19 | ~18 months |
| Claude Sonnet 5 | 2026-01 | 1.0.0 · 2024-11-23 | ~14 months |
| Claude Fable 5.1 | 2026-06 | 1.4.0 · 2025-11-22 | ~7 months |

A recent cutoff is not a defence. Every model here loses track of this library's release history well before the date it states as its own cutoff, and the stopping points cluster far tighter than the cutoffs do.

Read that column precisely. It is the newest better-auth release whose contents the model can correctly **attribute to that release** — not the newest better-auth feature it knows. Past that point a model will often write working code with a newer API while naming the wrong release for it, and that guess runs *early* — it names a release older than the one that shipped the feature. So the question this pack answers is not "does the model know this API" but "can it be trusted about which version the API arrived in" — which is the question that matters when you are pinned to a version.

## How to read an entry

Every entry ends with a *Reproduced against* line. Where it names models, we have the generated code that got it wrong, dated, with the model's own words in the run write-up. Where it says no model yet, the correction is verified from the release notes but nothing has been probed for it — it is a fix, not a measurement, and the pack says so rather than blurring the two.

The section an entry sits in is the worst case if you act on the stale belief. The severity in brackets after a model's name is what that particular model's output actually did, which can be milder — a model can hold the wrong belief and still, on the day, write code that runs.

## The corrections

### Breaks the build, or throws at runtime

Act on the stale belief here and the code does not run. Fix these first.

#### phoneNumber({ storeOTP })

**Added in better-auth 1.3.0** (2025-07-19)

The phone-number plugin has **no at-rest storage option**, at any release. `storeOTP` is not one of its options and neither is any other spelling: the strings `store*`, `hash*` and `encrypt*` appear **zero times** in the plugin's entire published type surface at 1.3.0, 1.5.0 and 1.7.2. Its complete option list at 1.7.2 is `otpLength`, `sendOTP`, `verifyOTP`, `sendPasswordResetOTP`, `expiresIn`, `phoneNumberValidator`, `requireVerification`, `callbackOnVerification`, `signUpOnVerification`, `schema` and `allowedAttempts`.

This is the one gap in an otherwise regular family. Since **1.3.0** four sibling plugins in the same library take exactly such an option — `emailOTP({ storeOTP })`, `magicLink({ storeToken })`, `twoFactor({ otpOptions: { storeOTP } })` and `oneTimeToken({ storeToken })` (see LF9) — and the phone-number plugin sends, stores and verifies one-time codes just as `emailOTP` does. The scheme predicts an option that is not there, so writing it is a natural mistake and a build break: `phoneNumber({ sendOTP, storeOTP: 'hashed' })` is **TS2353** under `tsc --strict`.

**And there is no other configuration that closes the gap — including the one an earlier version of this correction prescribed.** The root-level `verification.storeIdentifier` (1.5.0, LF9) transforms the **identifier** column, and this plugin writes `identifier: '<phone number>'` with the code in `value` as `'<code>:<attempts>'`. Turning it on hashes the phone number and leaves the SMS code in the table verbatim. A `databaseHooks` write transform does not rescue it either: `verifyPhoneNumberOTP` compares `otpValue !== providedCode` against the stored string, with no read-side inverse, so any transform on write permanently breaks verification.

**The honest answer: if SMS codes must not sit in your `verification` table in plain text, this plugin cannot do it by configuration at any release through 1.7.2.** Drive the SMS flow yourself — generate and send the code, store your own keyed digest in your own table, and call `auth.api` only once the number is proven — or accept the exposure and shorten it with `expiresIn` and `allowedAttempts`. `verification: { storeIdentifier: 'hashed' }` is still worth setting for what it does cover (magic-link and password-reset tokens, and the phone number as PII), but do not set it believing it protects the code.

*The stale belief:* That the phone-number plugin carries the same at-rest storage option as its siblings — an over-extension of the 1.3.0 family rather than a stale memory of a removed API. The belief is false at every release, before and after 1.3.0, and the code it produces does not compile.

**The code below needs better-auth 1.5.0 or later.** Between 1.3.0 and 1.5.0 this correction does not apply — see the note.

```ts
// Stale
// does not compile at any release:
// TS2353: Object literal may only specify known properties,
//         and 'storeOTP' does not exist in type 'PhoneNumberOptions'.
export const auth = betterAuth({
  plugins: [
    phoneNumber({
      sendOTP: async ({ phoneNumber, code }) => sendSms(phoneNumber, code),
      storeOTP: 'hashed',
    }),
  ],
})

// Current
// The plugin takes no at-rest storage option, and no root-level option covers
// the CODE — `verification.storeIdentifier` transforms the identifier column,
// which for this plugin is the phone number, not the code. See LF9.
export const auth = betterAuth({
  verification: {
    // worth setting for what it DOES cover: magic-link and password-reset
    // tokens (the token is the identifier), and the phone number as PII.
    storeIdentifier: 'hashed',
  },
  plugins: [
    phoneNumber({
      sendOTP: async ({ phoneNumber, code }) => sendSms(phoneNumber, code),
      otpLength: 6,
      // no storage option exists; bound the exposure instead
      expiresIn: 300,
      allowedAttempts: 3,
    }),
  ],
})

// If the code must not be readable in the database at all, the plugin's own
// flow cannot give you that at any release through 1.7.2 — own the SMS step:
// generate the code, store a keyed digest in your own table, and call
// auth.api only once the number is proven.
```

> A NEGATIVE CLAIM, and the second one in the dataset after tailwindcss LF30 — see BACKLOG item 2h. The Node auditor has no concept of a claim that a name is absent, so the absence half of this fact was verified by hand rather than through the auditor's own rules, and is recorded here in the form a future 'asserted-absent names' auditor field would need.

`introduced_in` is 1.3.0 for a reason worth stating plainly: the claim itself is version-independent — there is no release at which the phone-number plugin gained or lost an at-rest storage option — and 1.3.0 is recorded because it is the release that created the four-plugin family this belief over-extends. Nothing in the fact turns on a subject's cutoff. `replacement_available_from` is 1.5.0 because the prescribed answer, `verification.storeIdentifier`, does not exist below it.

VERIFIED BY TYPE-CHECK, 2026-09-03, against three installed releases. One file configures five plugins and is compiled under `tsc --strict` (typescript 5.9.3, `moduleResolution: bundler`, `skipLibCheck`). At **1.5.0** and **1.7.2** the compiler reports exactly one error, TS2353 on `phoneNumber`'s `storeOTP`, while `emailOTP({ storeOTP })`, `magicLink({ storeToken })`, `twoFactor({ otpOptions: { storeOTP } })` and `oneTimeToken({ storeToken })` are all clean in the same file. At **1.3.0** the same TS2353 is reported, and so is an unrelated TS2322 on the `twoFactor(...)` element, whose endpoint types are not assignable to `BetterAuthPlugin` in that release; that error was isolated rather than assumed — `twoFactor({})` with no options reproduces it — and it touches nothing this fact claims.

VERIFIED BY ABSENCE, same session and the stronger half: a scan of the phone-number plugin's published type surface for `store*`, `hash*` and `encrypt*` returns zero matches at 1.3.0, 1.5.0 and 1.7.2. That covers the claim under any spelling rather than only the one name the compiler was asked about. `allowedAttempts` is present in the plugin's types as far back as **1.2.12**, so the plugin's own option surface predates the 1.3.0 storage family and is not empty — the gap is specific to storage.

PRESCRIPTION CORRECTED 2026-09-03 (JOURNAL/047), the session after this fact was written, and the correction is to the half of it nobody had checked. As first written, the statement and `correct_code` told a reader that `verification: { storeIdentifier: 'hashed' }` was the way to keep SMS codes out of the table. It is not. `storeIdentifier` transforms the IDENTIFIER column and this plugin puts the phone number there and the code in `value`. Executed at an installed 1.7.2 on the memory adapter, with the switch ON and no plugin options set: the row is identifier `eo4brUJBb5o2Tie1SU8kmQkN7zk3E0Tf45kV88XdGnU` — exactly `sha256('+15550001111')`, base64url unpadded — and value `668217:0`, which is the code that was delivered to `sendOTP`, verbatim. The advice hashed the phone number and left the secret alone.

Nor is there a fallback. `verifyPhoneNumberOTP` reads the row and compares `otpValue !== providedCode` as strings; nothing inverts a transform on the read side, so a `databaseHooks` hashing hook on write breaks verification for every user rather than securing anything. The absence is total: no plugin option, no root option, no hook. That is what the statement now says.

The negative claim this fact is built on — that `phoneNumber` takes no at-rest storage option — is UNCHANGED and still verified two ways (TS2353 at three releases; zero `store*`/`hash*`/`encrypt*` matches in the plugin's type surface). The charged finding it corrects (`better-auth/v5-a` F1, the Index's first invention) is unaffected: a subject inventing `storeOTP` on this plugin is wrong at every release either way. What changed is only what we tell the reader to write instead — which is the third time a battery's own transcript has corrected one of our corrections (JOURNAL/036, /044, and now /047), and the first time the objection came from the subjects rather than from a re-read.

*Reproduced against: **Claude Opus 5** (S1) — better-auth/v5-a, 2026-09-03.*

Source: [better-auth 1.7.2 published package — PhoneNumberOptions, type-checked under tsc --strict](https://registry.npmjs.org/better-auth/-/better-auth-1.7.2.tgz) · [better-auth 1.5.0 published package — the same single error, siblings clean in the same file](https://registry.npmjs.org/better-auth/-/better-auth-1.5.0.tgz) · 2026-03-01 · [better-auth 1.3.0 published package — the release that gave four sibling plugins the option, and not this one](https://registry.npmjs.org/better-auth/-/better-auth-1.3.0.tgz) · 2025-07-19 · [better-auth 1.2.12 published package — allowedAttempts already present, no storage option](https://registry.npmjs.org/better-auth/-/better-auth-1.2.12.tgz) · [better-auth 1.7.2 published package — the phone-number plugin writes the code to the value column](https://registry.npmjs.org/better-auth/-/better-auth-1.7.2.tgz) · [better-auth 1.7.2 published package — verification compares the stored value as a plain string](https://registry.npmjs.org/better-auth/-/better-auth-1.7.2.tgz)

### Runs, but is silently wrong

Nothing errors. The behaviour is simply not what a model trained earlier will tell you.

#### stateless / database-less sessions

**Added in better-auth 1.4.0** (2025-11-22)

better-auth supports running with no server-side session store at all since 1.4.0. Omit BOTH `database` and `secondaryStorage` and the signed cookie becomes the session record itself — the library detects this and treats the cookie as authoritative rather than as a cache. Do not tell a team that better-auth always requires a database or a Redis for sessions, and do not send them to the `jwt` plugin as the only stateless option; that was true before 1.4.0 and is not true now.

*The stale belief:* That a durable server-side session store is mandatory — that sessions are better-auth's core primitive and the only ways to reduce session I/O are `secondaryStorage` (Redis) or issuing JWTs for service-to-service verification.

```ts
// Stale
// stale: assumes a session store is compulsory
export const auth = betterAuth({
  database: drizzleAdapter(db, { provider: 'pg' }),
  secondaryStorage: redisStore, // "the only way to keep sessions out of the DB"
  session: { storeSessionInDatabase: false },
})

// Current
// stateless: no database, no secondary storage.
// The signed session cookie IS the session record.
export const auth = betterAuth({
  emailAndPassword: { enabled: true },
  // no `database`, no `secondaryStorage`
})
```

> Verified at both ends. Introduction: the 1.4.0 release notes list "Stateless session management". Current behaviour: in the published better-auth 1.7.2 tarball, `dist/context/store-capabilities.mjs` defines `hasServerSessionStore(options) { return !!options.database || !!options.secondaryStorage }`, and `dist/api/routes/session.d.mts` documents the resulting `isStateful` branch as choosing between the cookie being "merely an optimization" and it being "the only place the session lives and therefore the authority itself (`false`, for stateless / DB-less deployments)". What was NOT verified: that the feature is unchanged between 1.4.0 and 1.7.2 — only that it was introduced in 1.4.0 and exists in 1.7.2. `storeSessionInDatabase` and `preserveSessionInDatabase` do still exist and are unrelated to this fact; they govern the `secondaryStorage` case.

*Reproduced against: **Claude Fable 5** (S2), **Claude Opus 5** (S2), **Claude Sonnet 5** (S2) — better-auth/v1, 2026-09-01; better-auth/v2, 2026-09-02; better-auth/v2-a, 2026-09-02.*

Source: [better-auth v1.4.0 release notes](https://github.com/better-auth/better-auth/releases/tag/v1.4.0) · 2025-11-22 · [better-auth 1.7.2 published package — dist/api/routes/session.d.mts](https://registry.npmjs.org/better-auth/-/better-auth-1.7.2.tgz) · 2026-08-26

#### emailOTP({ resendStrategy })

**Added in better-auth 1.6.0** (2026-04-06)

Since **1.6.0** the email-OTP plugin takes **`resendStrategy`**, typed `"rotate" | "reuse"` and defaulting to `"rotate"`. `"reuse"` makes a resend deliver the code the user already has and extend its expiry instead of minting a new one, which is the fix for the classic support ticket: the user clicks resend, types the code from the first email, and is told it is wrong.

The plugin's own documentation states the constraint that makes hand-rolling this dangerous: reuse **only works when the stored code is recoverable** — `storeOTP` set to `"plain"`, `"encrypted"`, or a custom `encrypt`/`decrypt` pair. With `storeOTP: "hashed"` there is nothing to read back, and the option **falls back to `"rotate"`** rather than failing. Any home-made version of this has to know that too, and the usual home-made version — cache the code in `generateOTP` and return it — silently keeps sending a stale code from a cache that no longer matches a rotated database row.

*The stale belief:* That the plugin has no resend-reuse switch and every send generates a new code, so the only route is your own cache in front of `generateOTP` or a hand-written resend endpoint. True through 1.5.0; false from 1.6.0. The workaround is not merely unnecessary — it re-implements a behaviour whose one real constraint (a hashed OTP cannot be reused) the plugin already handles by falling back.

```ts
// Stale
// The pre-1.6.0 workaround. Works, but it is your cache to keep correct,
// and it silently does the wrong thing when storeOTP is 'hashed'.
emailOTP({
  otpLength: 6,
  expiresIn: 300,
  async generateOTP({ email, type }) {
    const existing = await redis.get(`otp:${type}:${email}`)
    if (existing) return existing
    const otp = String(Math.floor(Math.random() * 1e6)).padStart(6, '0')
    await redis.set(`otp:${type}:${email}`, otp, 'EX', 300)
    return otp
  },
  async sendVerificationOTP({ email, otp }) { await sendMail(email, otp) },
})

// Current
// 1.6.0 and later — one option, and it knows about the hashed case.
emailOTP({
  otpLength: 6,
  expiresIn: 300,
  resendStrategy: 'reuse', // 'rotate' is the default
  storeOTP: 'plain',       // reuse needs a recoverable code; 'hashed' falls back to 'rotate'
  async sendVerificationOTP({ email, otp }) { await sendMail(email, otp) },
})
```

> VERIFIED AGAINST THE SHIPPED ARTIFACT, 2026-09-06, in `dist/plugins/email-otp/types.d.mts` of three installed releases. The option is **absent at 1.5.0** and **present at 1.6.0 and 1.7.3**, and it is the only difference between the two option lists — 1.5.0 declares `sendVerificationOTP`, `otpLength`, `expiresIn`, `generateOTP`, `sendVerificationOnSignUp`, `disableSignUp`, `allowedAttempts`, `storeOTP`, `changeEmail`, `overrideDefaultEmailVerification` and `rateLimit`; 1.6.0 declares that list plus `resendStrategy`. The introducing release is therefore exact rather than inferred from a note.

The `"reuse"` semantics and the hashed-OTP fallback are quoted from the option's own doc comment in the published `.d.mts`, not from the website, and `dist/plugins/email-otp/routes.mjs` is the second file in the package that mentions the option.

*Reproduced against: **Claude Fable 5.1** (S2), **Claude Opus 5** (S2) — better-auth/v7-a, 2026-09-06; better-auth/v7-c, 2026-09-06.*

Source: [better-auth 1.6.0 published package — EmailOTPOptions gains resendStrategy](https://registry.npmjs.org/better-auth/-/better-auth-1.6.0.tgz) · 2026-04-06 · [better-auth 1.5.0 published package — the same option list without resendStrategy](https://registry.npmjs.org/better-auth/-/better-auth-1.5.0.tgz) · 2026-03-01 · [better-auth 1.6.0 release notes — the feature line](https://github.com/better-auth/better-auth/releases/tag/v1.6.0) · 2026-04-06

#### session.freshAge (measured from session.createdAt)

**Behaviour changed in better-auth 1.6.0** (2026-04-06)

Since **1.6.0** the session freshness check is measured from the session's **`createdAt`**, not from its `updatedAt`. `freshAge` is unchanged — still a number of seconds, still defaulting to `60 * 60 * 24`, still disabled by `0` — but the timestamp it is subtracted from moved, and that changes who gets through.

Up to and including **1.5.0**, `freshSessionMiddleware` read `new Date(session.session.updatedAt || session.session.createdAt)`. Because `session.updateAge` slides `updatedAt` forward on activity, a continuously used session stayed "fresh" indefinitely: the gate on `/unlink-account`, `/delete-user` and the other sensitive endpoints effectively only ever fired for **idle** sessions. From **1.6.0** the same middleware reads `new Date(session.session.createdAt)`, so the window runs from sign-in and closes a fixed 24 hours later no matter how active the user has been.

**The concrete case, executed rather than reasoned about:** a session row with `createdAt` 30 hours ago and `updatedAt` 2 minutes ago, default `freshAge`. At 1.5.0 the request passes the freshness gate; at 1.6.0 and 1.7.3 it is rejected with `FORBIDDEN` / `SESSION_NOT_FRESH`.

**There is no option to choose the anchor.** `session.freshAge` is typed `number | undefined` and nothing else in the `session` block touches freshness; `freshAgeFrom`, `freshAgeBasis` and `freshFrom` appear nowhere in the published packages. If you need last-activity semantics you set `freshAge: 0` and write the gate yourself against `session.updatedAt`. If you were relying on the pre-1.6.0 behaviour, upgrading will start asking long-lived active users to re-authenticate on sensitive actions — quietly, because nothing about your configuration changed.

*The stale belief:* That the freshness window is measured from the session's last use (`updatedAt`), so an active user is always fresh and the gate only catches idle sessions. True through 1.5.0, false from 1.6.0. The belief survives an upgrade silently: no type changes, no deprecation warning, no configuration key to update — the same `freshAge` number simply starts meaning something else. A closely related belief, that the anchor is selectable by configuration, is false at **every** release.

```ts
// Stale
// Reasoning that was correct through 1.5.0 and is wrong from 1.6.0:
//
//   createdAt: 30 hours ago
//   updatedAt: 2 minutes ago   <- the row was touched, so the session is fresh
//   => POST /unlink-account succeeds
//
// It does not. From 1.6.0 the middleware never looks at updatedAt:
//   FORBIDDEN / SESSION_NOT_FRESH

export const auth = betterAuth({
  session: {
    expiresIn: 60 * 60 * 24 * 7,
    updateAge: 60 * 60 * 24, // slides updatedAt forward — no longer relevant to freshness
    freshAge: 60 * 60 * 24,
  },
})

// Current
// 1.6.0 and later: freshAge is measured from createdAt. The window runs
// from sign-in, so pick a number you are happy asking an ACTIVE user to
// re-authenticate after.
export const auth = betterAuth({
  session: {
    expiresIn: 60 * 60 * 24 * 7,
    updateAge: 60 * 60 * 24,
    freshAge: 60 * 60 * 24, // 24h from SIGN-IN, not from last use
  },
})

// If you want the pre-1.6.0 semantics (fresh while the session is being
// used), there is no option for it. Turn the built-in check off and gate
// the sensitive paths yourself:
export const auth2 = betterAuth({
  session: { freshAge: 0 }, // 0 disables the check entirely
})
// ...then, in your own middleware on the endpoints you care about:
//   const age = Date.now() - new Date(session.session.updatedAt).getTime()
//   if (age > WINDOW_MS) throw new APIError('FORBIDDEN', { message: '...' })
```

> A SEMANTIC change with no name attached — the first one in this dataset. Nothing was added, removed or renamed, so a type-check cannot see it, an auditor that greps for API names cannot see it, and a reader upgrading through 1.6.0 has nothing in their own code to change. It is exactly the shape of stale prior the Index exists to catch and the hardest one to catch any other way.

VERIFIED BY SOURCE READ, 2026-09-06, in `dist/api/routes/session.mjs` of three installed releases:
  1.5.0: `const lastUpdated = new Date(session.session.updatedAt || session.session.createdAt).getTime(); if (!(Date.now() - lastUpdated < freshAge * 1e3)) throw ... SESSION_NOT_FRESH`
  1.6.0: `const createdAt = new Date(session.session.createdAt).getTime(); if (Date.now() - createdAt >= freshAge) throw ... SESSION_NOT_FRESH`
  1.7.3: identical to 1.6.0.
`dist/context/create-context.mjs` sets the default to `3600 * 24` at all three, so only the anchor moved.

VERIFIED BY EXECUTION, same session, because the claim is behavioural (HARNESS: execute the claim against the installed package). One script per release: sign up over `auth.api.signUpEmail` against the memory adapter, rewrite the stored session row to `createdAt` = now - 30h and `updatedAt` = now - 2min, then call `auth.api.unlinkAccount` — one of the endpoints guarded by `freshSessionMiddleware` at every release in the window — with the session cookie. Results:
  1.5.0 -> passes the freshness gate and fails later at the handler with `BAD_REQUEST / FAILED_TO_UNLINK_LAST_ACCOUNT`, which is proof the middleware let it through;
  1.6.0 -> `FORBIDDEN / SESSION_NOT_FRESH`;
  1.7.3 -> `FORBIDDEN / SESSION_NOT_FRESH`.
The 1.7.3 run needs `{ accountId }` in the body rather than 1.5.0's `{ providerId }` — that route's body schema changed independently — so all three bodies were tried at every release and the table above reports the ones that reached the middleware.

THE NEGATIVE HALF, verified by absence the way LF10 was: `session.freshAge` is declared `freshAge?: number` in `@better-auth/core/dist/types/init-options.d.mts` at 1.7.3 and nothing else in the `session` options block mentions freshness; the strings `freshAgeFrom`, `freshAgeBasis` and `freshFrom` return zero matches across `better-auth/dist` and every `@better-auth/*/dist` at that release. The anchor is not selectable at any release, which is what makes `freshAge: 0` plus your own middleware the honest answer for anyone who wants the old behaviour back.

The vendor's own note calls this an alignment rather than a change of behaviour — `dist/api/routes/update-user.mjs` was already `createdAt`-based at 1.5.0, so 1.6.0 made the two agree. That is true and it is not a reason to soften the fact: the middleware that gates the sensitive endpoints is the one that moved, and it moved in the direction that rejects requests it used to allow.

*Reproduced against: **Claude Fable 5.1** (S2) — better-auth/v7-c, 2026-09-06.*

Source: [better-auth 1.6.0 release notes — the breaking change, and the vendor's own migration line](https://github.com/better-auth/better-auth/releases/tag/v1.6.0) · 2026-04-06 · [better-auth 1.5.0 published package — freshSessionMiddleware reads updatedAt](https://registry.npmjs.org/better-auth/-/better-auth-1.5.0.tgz) · 2026-03-01 · [better-auth 1.6.0 published package — the same middleware reads createdAt](https://registry.npmjs.org/better-auth/-/better-auth-1.6.0.tgz) · 2026-04-06 · [better-auth 1.7.3 published package — still createdAt, so the fact is about what is true now](https://registry.npmjs.org/better-auth/-/better-auth-1.7.3.tgz)

#### baseURL as a dynamic multi-host config

**Added in better-auth 1.5.0** (2026-03-01)

Since 1.5.0 `baseURL` is not string-only. It accepts `{ allowedHosts, fallback?, protocol? }`, and better-auth then derives the base URL from each incoming request's host, validating that host against `allowedHosts` with the same wildcard matching `trustedOrigins` uses (`myapp.com`, `*.vercel.app`, `preview-*.myapp.com`). A host that matches nothing falls back to `fallback`, or throws if `fallback` is unset — the request host is never echoed back unchecked. One better-auth instance therefore serves many domains and every preview deployment. Do not tell a team that `baseURL` must be a single static string, that they need one deploy or one instance per domain, or that `BETTER_AUTH_URL` per environment is the only option: that was true before 1.5.0 and is not true now. `trustedOrigins` is a different setting and does not set the base URL.

*The stale belief:* That `baseURL` is a single static string, so a multi-domain or preview-deployment setup needs a per-environment `BETTER_AUTH_URL`, a separate auth instance per domain, or middleware that rewrites the request before it reaches the handler.

```ts
// Stale
// stale: baseURL believed to be string-only, so the host has to come from the environment
export const auth = betterAuth({
  baseURL: process.env.BETTER_AUTH_URL!, // one value per deployment
  trustedOrigins: ['https://acme.example.com', 'https://*.vercel.app'], // does NOT set the base URL
})

// Current
// since 1.5.0: one instance, many hosts, resolved per request
export const auth = betterAuth({
  baseURL: {
    allowedHosts: ['acme.example.com', '*.vercel.app', 'preview-*.example.com'],
    fallback: 'https://acme.example.com', // used when the request host matches nothing
    protocol: 'auto', // 'auto' reads x-forwarded-proto; 'https' | 'http' force it
  },
})
```

> Verified by execution against an installed better-auth@1.5.0, not from the release note. `betterAuth()` constructs with the object form; `isDynamicBaseURLConfig(cfg)` is true for it and false for a string; `resolveDynamicBaseURL(cfg, request, '/api/auth')` returns `https://acme.example.com/api/auth`, `https://my-branch.vercel.app/api/auth` and `https://preview-7.example.com/api/auth` for the three matching hosts, and returns the fallback — not the request host — for `evil.attacker.com`. The object form also type-checks under `tsc --strict`. The floor is the published type: `@better-auth/core@1.4.22` declares `baseURL?: string | undefined`, `@better-auth/core@1.5.0` declares `baseURL?: BaseURLConfig | undefined` where `BaseURLConfig = string | DynamicBaseURLConfig`. Still present at 1.7.2. 1.6.0 adds a `matchesHostPattern` export and rewrites the `trustedOrigins` documentation around this; the option itself is unchanged between 1.5.0 and 1.6.0.

*Reproduced against: **Claude Opus 5** (S2) — better-auth/v3-a, 2026-09-03.*

Source: [@better-auth/core 1.5.0 published package — dist/types/init-options.d.mts](https://registry.npmjs.org/@better-auth/core/-/core-1.5.0.tgz) · 2026-03-01 · [@better-auth/core 1.5.0 published package — the allowedHosts field](https://registry.npmjs.org/@better-auth/core/-/core-1.5.0.tgz) · 2026-03-01 · [better-auth 1.4.22 — the last release before the change, where baseURL is string-only](https://registry.npmjs.org/better-auth/-/better-auth-1.4.22.tgz) · [better-auth v1.5.0 release notes](https://github.com/better-auth/better-auth/releases/tag/v1.5.0) · 2026-03-01

#### bearer({ requireSignature })

**Default changed in better-auth 1.1.0** (2024-12-20)

The `bearer` plugin accepts UNSIGNED tokens by default. `requireSignature` defaults to `false`. Any advice about mounting `bearer()` on a public API must say this and must set `requireSignature: true` unless the caller has a specific reason not to, because the default accepts a raw session token straight out of the database with no signature check.

*The stale belief:* That the bearer plugin verifies token signatures out of the box, so `bearer()` with no options is the safe configuration.

```ts
// Stale
// stale: relies on a signature check that is off by default
export const auth = betterAuth({
  plugins: [bearer()],
})

// Current
export const auth = betterAuth({
  plugins: [bearer({ requireSignature: true })],
})
```

> Verified at both ends: the 1.1.0 notes state the default changed, and better-auth 1.7.2's shipped types still document `requireSignature?: boolean` with `@default false`. This fact is about the default, not about whether the option exists — models tend to know the option and not the default.

*Reproduced against: **Claude Sonnet 5** (S2) — better-auth/v1, 2026-09-01.*

Source: [better-auth v1.1.0 release notes](https://github.com/better-auth/better-auth/releases/tag/v1.1.0) · 2024-12-20 · [better-auth 1.7.2 published package — dist/plugins/bearer/index.d.mts](https://registry.npmjs.org/better-auth/-/better-auth-1.7.2.tgz) · 2026-08-26

#### additional user fields in the sign-in / sign-up response

**Behaviour changed in better-auth 1.4.2** (2025-11-25)

Since 1.4.2 the sign-in and sign-up responses return your configured additional user fields, not a fixed core subset. The handler builds `user` with `parseUserOutput(options, user)`, which honours `user.additionalFields`. If you declared `role` or `plan` as an additional field, `data.user.role` is present on the sign-in result — you do not need a follow-up `getSession()` or database read to get it.

*The stale belief:* That sign-in returns only the seven core user fields (id, email, name, image, emailVerified, createdAt, updatedAt), so any custom column must be fetched separately after sign-in.

```ts
// Stale
const { data } = await authClient.signIn.email({ email, password })
// believed necessary: a second round trip for the custom field
const { data: session } = await authClient.getSession()
const role = session.user.role

// Current
const { data } = await authClient.signIn.email({ email, password })
const role = data.user.role // present since 1.4.2 if declared in user.additionalFields
```

> Bisected against the published artifacts, not taken from the release note. 1.4.1 (2025-11-25) builds the response `user` as a seven-key object literal; 1.4.2, published the same day, replaces it with `parseUserOutput(ctx.context.options, user.user)`, and every release through 1.7.2 keeps that. The seven-key literal had been in place since 1.1.0. Untested against any subject so far — 1.4.2 precedes the stated cutoff of all three current subjects, so it is admissible against each of them.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [better-auth v1.4.2 release notes](https://github.com/better-auth/better-auth/releases/tag/v1.4.2) · 2025-11-25 · [better-auth 1.4.2 published package — the sign-in email handler](https://registry.npmjs.org/better-auth/-/better-auth-1.4.2.tgz) · 2025-11-25 · [better-auth 1.4.1 published package — the same handler one release earlier](https://registry.npmjs.org/better-auth/-/better-auth-1.4.1.tgz) · 2025-11-25

#### `verification.storeIdentifier`

**Added in better-auth 1.3.0** (2025-07-19)

Hashing verification secrets at rest is configuration, not something you hand-roll — but which knob you need depends on the release AND on which column the secret is in. Since **1.3.0** four plugins carry their own: `magicLink({ storeToken: 'hashed' })`, `emailOTP({ storeOTP: 'hashed' })`, `twoFactor({ otpOptions: { storeOTP: 'hashed' } })` and `oneTimeToken({ storeToken: 'hashed' })` — all defaulting to `'plain'`, all also accepting a custom hasher (`{ type: 'custom-hasher', hash }` for the two token options, `{ hash }` for the two OTP options). The two OTP options additionally accept **`'encrypted'`**, which is the only *keyed* mode in the library: XChaCha20-Poly1305 under a key derived from the app `secret`, reversible on read. Since **1.5.0** there is additionally a root-level `verification.storeIdentifier` — `'plain' | 'hashed' | { hash }`, or `{ default, overrides }` to vary it per identifier type. Lookups by the raw value keep working in every case: the library transforms the incoming value before it queries.

**Two things about that root-level switch decide whether it is the right answer, and both are easy to get wrong.**

1. **It transforms the `identifier` column only, not the row.** That is the whole secret for token-shaped flows — the magic-link token *is* the identifier, and so is a password reset's `reset-password:<token>` — so `storeIdentifier` genuinely covers those, including the password-reset rows no plugin option reaches. It is **not** the secret for code-shaped flows: `emailOTP` writes `identifier: 'sign-in-otp-<email>'` and `value: '<otp>:<attempts>'`, and `phoneNumber` writes `identifier: '<phone number>'` and `value: '<code>:<attempts>'`. Setting `storeIdentifier: 'hashed'` on those hashes the address and leaves the code in the clear. For a one-time code, the plugin's own `storeOTP` is the only option that touches it.

2. **`'hashed'` is a bare, unkeyed SHA-256** (base64url, unpadded) of the value, everywhere it appears — the same `defaultKeyHasher` in the root switch and in the plugin options. Against a 128-bit magic-link token that is enough. Against a **six-digit code it is close to worthless**: an attacker holding the table brute-forces the 10^6 space offline in milliseconds. Where the threat model is a leaked database and the secret is short and numeric, use `storeOTP: 'encrypted'` (keyed by the app secret) or pass a `{ hash }` that is an HMAC whose key lives outside the database. Nobody needs a `databaseHooks` transform or a wrapped adapter for any of this, and has not since 1.3.0.

*The stale belief:* That hashing verification secrets is available only per plugin, so a team that wants the whole `verification` table covered — password-reset identifiers included — has to fall back to a database hook or a wrapped adapter. The per-plugin options are real and have been since 1.3.0; what is new in 1.5.0 is a table-wide switch on the identifier column, and denying that one exists sends a reader to hand-rolled code for the rows the plugins do not own.

**The code below needs better-auth 1.5.0 or later.** Between 1.3.0 and 1.5.0 this correction does not apply — see the note.

```ts
// Stale
// right about the plugins, wrong about the root config:
export const auth = betterAuth({
  plugins: [
    magicLink({ storeToken: 'hashed' }), // correct, and available since 1.3.0
    emailOTP({ storeOTP: 'hashed' }),     // correct, and available since 1.3.0
  ],
  // ...and then, for password-reset identifiers, a hand-rolled hook
  // because "there is no table-wide switch" — which stopped being true at 1.5.0
})

// Current
// 1.3.0 and later — per plugin, on the column the code actually lives in
export const auth = betterAuth({
  plugins: [
    magicLink({ storeToken: 'hashed' }),   // token IS the identifier; SHA-256 is fine here
    emailOTP({ storeOTP: 'encrypted' }),   // 6-digit code: keyed, not a bare digest
    // or, to keep it one-way, an HMAC keyed outside the database:
    // emailOTP({ storeOTP: { hash: async (otp) => hmac(process.env.OTP_PEPPER, otp) } }),
  ],
})

// 1.5.0 and later — the whole verification table's IDENTIFIER column, in one place.
// Covers magic-link tokens and password-reset tokens (the secret is the identifier).
// Does NOT cover emailOTP / phoneNumber codes: those live in the `value` column.
export const auth = betterAuth({
  verification: {
    storeIdentifier: 'hashed',
    // or: { hash: async (id) => myHash(id) }
    // or: { default: 'hashed', overrides: { 'email-otp': 'plain' } }
  },
})
```

> CORRECTED 2026-09-03, the same session this fact was written, by the battery that was built to probe it (JOURNAL/044). As first written this fact claimed that hashing verification secrets at rest was new in 1.5.0 and that the pre-1.5.0 answer was a hand-rolled hook or adapter. That was wrong, and three of the four `better-auth/v3` draws said so by answering correctly: `magicLink({ storeToken })` and `emailOTP({ storeOTP })` are present in the published `better-auth@1.3.0` type declarations (2025-07-19) and absent from 1.2.9 and 1.2.12, so they predate every current subject's cutoff. One draw reproduced the magic-link object form `{ type: 'custom-hasher', hash }` verbatim from memory. What 1.5.0 actually adds is scope, and that half was verified by execution against an installed 1.5.0 on a migrated sqlite database: with no `verification` option, `internalAdapter.createVerificationValue({ identifier: 'magic-link-token-abcdef', ... })` leaves the identifier in the row verbatim; with `storeIdentifier: 'hashed'` the row holds `xj0EjmvN-maFOsKICHBPdQPo_JzYzonW9_ZKCCWOZgU`, and `findVerificationValue('tok-round-trip')` — passing the RAW identifier — still resolves. Both the plain string and the `{ default, overrides }` form type-check under `tsc --strict`. `@better-auth/core@1.4.22` has no `storeIdentifier` anywhere in its options; 1.5.0 introduces `StoreIdentifierOption = 'plain' | 'hashed' | { hash }`, unchanged at 1.7.2. The option is verification-only: there is no session-token equivalent at any release — `session: { storeIdentifier: 'hashed' }` is a TS2353 error at 1.5.0 through 1.7.2. EXECUTION EVIDENCE FOR THE 1.3.0 HALF, added 2026-09-03 when `better-auth/v4` was pre-registered against it: the half JOURNAL/044 established from published type declarations has now been run. Against an installed `better-auth@1.3.0` on an in-memory sqlite database: with no option, `emailOTP` delivers `797478` to the user and the `verification` row holds `797478:0`; with `storeOTP: 'hashed'` the user gets `802759` and the row holds `cnKCtH_41s8ZE_LoK2szKnNKSkQ39k845SnxCBBlaz4:0`; with `storeOTP: { hash }` the row holds the custom digest; and signing in with the RAW code succeeds in all three. `magicLink` stores the delivered token verbatim as the row's identifier by default; under `storeToken: 'hashed'` the user receives `BjgkRDFhWYvzaJKlpIWtYBqUWLpwMjgQ` while the row identifier is `d7yXTliYOZv5Yz7qOuirVa2vH3uHIFLFi-F9dHuYxPc`, and `magicLinkVerify` called with the RAW token still resolves the user. The surface is wider than first written: `storeOTP` / `storeToken` appear nowhere in `better-auth@1.2.12`'s `dist` and in 1.3.0 they are on FOUR plugins — `emailOTP`, `magicLink`, `twoFactor.otpOptions` and `oneTimeToken`. All five one-time-code plugins already exist at 1.2.12, so what 1.3.0 adds is the option, not the plugin. `phoneNumber` is the exception at every release: `phoneNumber({ sendOTP, storeOTP: 'hashed' })` is a TS2353 error under `tsc --strict` at 1.3.0, 1.5.0 and 1.7.2, in the same file where the other four type-check clean. That absence is the same-scheme sibling control for battery v4 and is not itself a correction.

SCOPE AND CRYPTOGRAPHY CORRECTED 2026-09-03 (JOURNAL/047), from the source of an installed package rather than from its type declarations. Two claims in this fact as previously written were too broad, and the second is the one that mattered.

(1) WHAT `'hashed'` COMPUTES. A bare, unsalted, unkeyed SHA-256, base64url-encoded without padding. It is one four-line `defaultKeyHasher`, duplicated verbatim in `dist/db/verification-token-storage.mjs` (the root switch) and `dist/plugins/email-otp/utils.mjs` (the plugin options). Confirmed without running better-auth at all: every digest this note already recorded from execution reproduces from `node:crypto` alone — `sha256('magic-link-token-abcdef')` is `xj0EjmvN-maFOsKICHBPdQPo_JzYzonW9_ZKCCWOZgU`, `sha256('802759')` is `cnKCtH_41s8ZE_LoK2szKnNKSkQ39k845SnxCBBlaz4`, `sha256('BjgkRDFhWYvzaJKlpIWtYBqUWLpwMjgQ')` is `d7yXTliYOZv5Yz7qOuirVa2vH3uHIFLFi-F9dHuYxPc`, all three byte-identical to the stored rows. So for a six-digit code the stored digest is a 10^6 offline space and buys ~nothing against an attacker holding the table. THREE `better-auth/v5` DRAWS ARGUED EXACTLY THIS, unprompted, while answering a different question (JOURNAL/046, BACKLOG 2i-iii-a). They were right, and the fact they were arguing against was ours.

(2) A KEYED MODE EXISTS AND THIS FACT DID NOT NAME IT. `storeOTP: 'encrypted'` is in the union on BOTH OTP options — `emailOTP` and `twoFactor.otpOptions` — at 1.3.0, 1.5.0 and 1.7.2, and it is not in the union on either token option (`magicLink.storeToken`, `oneTimeToken.storeToken`) at any of the three, nor on the root `StoreIdentifierOption`. It routes through `symmetricEncrypt`: XChaCha20-Poly1305 with a managed nonce under `SHA-256(secret)`. Executed at 1.7.2 on the memory adapter — delivered OTP `296902`, row value `823ac13b...5679d367:0`, the code absent verbatim, and `signInEmailOTP` with the RAW code still resolves the user. The split is coherent design rather than an oversight: the keyed mode is on the two options that carry short numeric codes and absent from the two that carry high-entropy random tokens.

(3) THE ROOT SWITCH IS A COLUMN, NOT A ROW — the correction that propagates to LF10. `createVerificationValue` applies `processIdentifier` to `data.identifier` and to nothing else. Executed at 1.7.2 with `verification: { storeIdentifier: 'hashed' }` and no plugin options set: the phone row holds identifier `eo4brUJBb5o2Tie1SU8kmQkN7zk3E0Tf45kV88XdGnU` = `sha256('+15550001111')` with value `668217:0`, and the email-OTP row holds identifier `4TrfjL5FzYyFAZKa-CtgMLAlxFbsHqb1XKhzAaPjiDc` = `sha256('sign-in-otp-a@example.com')` with value `090934:0`. Both delivered codes sit in the table in plain text with the switch ON. It covers `reset-password:<token>` and magic-link rows because there the token IS the identifier; it does not cover a one-time code, ever.

WHY THIS SURVIVED THE FIRST PASS, worth recording as method: the 1.5.0 half was verified by calling `internalAdapter.createVerificationValue({ identifier: 'magic-link-token-abcdef' })` directly, which exercises only the column the switch transforms. A direct adapter call cannot show you a column the plugin fills. Verifying a scope claim requires driving the plugin's own endpoint.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [better-auth 1.3.0 published package — the magic-link storeToken option](https://registry.npmjs.org/better-auth/-/better-auth-1.3.0.tgz) · 2025-07-19 · [better-auth 1.3.0 published package — the email-OTP storeOTP option](https://registry.npmjs.org/better-auth/-/better-auth-1.3.0.tgz) · 2025-07-19 · [@better-auth/core 1.5.0 published package — the verification.storeIdentifier option](https://registry.npmjs.org/@better-auth/core/-/core-1.5.0.tgz) · 2026-03-01 · [@better-auth/core 1.5.0 published package — StoreIdentifierOption](https://registry.npmjs.org/@better-auth/core/-/core-1.5.0.tgz) · 2026-03-01 · [better-auth 1.5.0 published package — executed against a migrated sqlite database](https://registry.npmjs.org/better-auth/-/better-auth-1.5.0.tgz) · 2026-03-01 · [better-auth 1.3.0 published package — executed against an in-memory sqlite database](https://registry.npmjs.org/better-auth/-/better-auth-1.3.0.tgz) · 2025-07-19 · [better-auth 1.7.2 published package — defaultKeyHasher in dist/db/verification-token-storage.mjs](https://registry.npmjs.org/better-auth/-/better-auth-1.7.2.tgz) · [better-auth 1.7.2 published package — the keyed 'encrypted' mode on the OTP options](https://registry.npmjs.org/better-auth/-/better-auth-1.7.2.tgz) · [better-auth 1.7.2 published package — createVerificationValue transforms the identifier column only](https://registry.npmjs.org/better-auth/-/better-auth-1.7.2.tgz)

#### signIn.email / auth.api.signInEmail response

**Behaviour changed in better-auth 1.1.0** (2024-12-20)

A successful email-and-password sign-in returns `{ redirect, token, url, user }`. There is NO `session` object in that response — reading `.session` off a sign-in result gives `undefined`. The `user` object IS returned, so `data.user.email` is correct. If you need the session, call `getSession` separately.

*The stale belief:* That sign-in returns `{ user, session }`, as it did in the pre-1.1.0 betas — so a caller can read `result.session.expiresAt` or `result.session.id` straight off the sign-in response.

```ts
// Stale
const { data } = await authClient.signIn.email({ email, password })
console.log(data.session.expiresAt) // undefined -> TypeError

// Current
const { data } = await authClient.signIn.email({ email, password })
console.log(data.user.email) // fine
console.log(data.token)      // the session token

// the session itself comes from a separate call
const { data: s } = await authClient.getSession()
```

> ARCHAEOLOGY, 2026-09-02: the 1.1.0 release note quoted below is wrong about 1.1.0's own published artifact, in two ways, and the Index has now bisected the tarballs rather than trusting it. (1) The user object never left. 1.0.0 returned `{ user, session, redirect, url }` with the whole user row; 1.1.0 returned `{ user, redirect, url }` where `user` is a fixed seven-field literal — id, email, name, image, emailVerified, createdAt, updatedAt. The `session` object is what 1.1.0 removed, which is the part this fact asserts. (2) There was no `token` field in 1.1.0 at all: `token` first appears in **1.1.4** (2024-12-27), a week later. So the earlier note's open question — when the user object came back — is void; there was nothing to come back. What did change later is which user fields are returned: see LF7.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [better-auth v1.1.0 release notes](https://github.com/better-auth/better-auth/releases/tag/v1.1.0) · 2024-12-20 · [better-auth 1.7.2 published package — dist/api/routes/sign-in.mjs](https://registry.npmjs.org/better-auth/-/better-auth-1.7.2.tgz) · 2026-08-26

### Deprecated, or a better API now exists

Works today. It is the older idiom, and some of it is scheduled for removal.

#### twoFactorClient({ twoFactorPage })

**Added in better-auth 1.6.0** (2026-04-06)

Since **1.6.0** the two-factor **client** plugin takes **`twoFactorPage`**, a string path it navigates to itself when a sign-in comes back needing a second factor. Before 1.6.0 the plugin declared exactly one option, the `onTwoFactorRedirect` callback, and a path had to be wrapped in one.

`onTwoFactorRedirect` is **not** removed, and at 1.6.0 it gained a `context` argument carrying `twoFactorMethods?: string[]` — the providers enabled for that user, so a single callback can choose between a TOTP screen and an OTP screen. Code written against the old zero-argument callback still compiles and still works, which is why this is scored S3 rather than higher: the stale belief costs a reader a callback they did not need, not a build.

`twoFactorPage` does a full page navigation — `window.location.href = options.twoFactorPage`, guarded by an `isSafeUrlScheme` check — and the option's own doc comment warns about it. In a router-driven app the callback is still the better tool; the string exists for the case where a reload is acceptable and one line of setup is preferred.

*The stale belief:* That the two-factor client plugin takes only a callback and there is no way to hand it a path. True through 1.5.0, false from 1.6.0. Two of the models measured on this surface went further and asserted that a `twoFactorPage` string option had existed in early releases and was *replaced* by the callback — the history runs the other way: the callback came first and the string was added on top of it at 1.6.0.

```ts
// Stale
// Correct through 1.5.0, and still correct today — but no longer the only way,
// and the denial that a string option exists is what makes it a stale prior.
export const authClient = createAuthClient({
  plugins: [
    twoFactorClient({
      onTwoFactorRedirect() {
        window.location.href = '/auth/two-factor'
      },
    }),
  ],
})

// Current
// 1.6.0 and later — hand it the path once.
export const authClient = createAuthClient({
  plugins: [twoFactorClient({ twoFactorPage: '/auth/two-factor' })],
})

// The callback is still there, and since 1.6.0 it is told which factors the
// user actually has — use it when you want to route without a full reload:
export const authClient2 = createAuthClient({
  plugins: [
    twoFactorClient({
      onTwoFactorRedirect({ twoFactorMethods }) {
        router.push(twoFactorMethods?.includes('totp') ? '/auth/totp' : '/auth/otp')
      },
    }),
  ],
})
```

> VERIFIED AGAINST THE SHIPPED ARTIFACT, 2026-09-06, in `dist/plugins/two-factor/client.d.mts` of three installed releases. At **1.5.0** the options object declares one member, `onTwoFactorRedirect?: () => void | Promise<void>`. At **1.6.0** and **1.7.3** it declares two: `twoFactorPage?: string` and `onTwoFactorRedirect?: (context: { twoFactorMethods?: string[] }) => void | Promise<void>`. `dist/plugins/two-factor/client.mjs` at 1.7.3 carries the navigation.

SCORED S3 DELIBERATELY AND IN ADVANCE (`prompts/better-auth.md` § v7): the pre-1.6.0 answer still compiles and still behaves correctly, so a reader who takes it ships working code with an unnecessary callback. The severity ceiling was fixed before the draws were read.

A DERIVABILITY CAVEAT belongs on this fact and is recorded rather than buried. The name is reachable from the question: the derivability control (Claude Haiku 4.5, cutoff February 2025, far below every release involved) answered "yes" and produced `twoFactorPath` — the right shape, one character off the right name — while stating it was a guess. Per the standing rule, a derivable outcome discounts a **pass** and does not excuse a **failure**; the denials charged against this fact are unaffected, but nobody should read a pass on this surface as recall.

*Reproduced against: **Claude Fable 5.1** (S3), **Claude Opus 5** (S3) — better-auth/v7-a, 2026-09-06; better-auth/v7-c, 2026-09-06.*

Source: [better-auth 1.6.0 published package — twoFactorClient gains twoFactorPage](https://registry.npmjs.org/better-auth/-/better-auth-1.6.0.tgz) · 2026-04-06 · [better-auth 1.5.0 published package — the callback is the only option](https://registry.npmjs.org/better-auth/-/better-auth-1.5.0.tgz) · 2026-03-01 · [better-auth 1.7.3 published package — the navigation the string option performs](https://registry.npmjs.org/better-auth/-/better-auth-1.7.3.tgz) · [better-auth 1.6.0 release notes — the feature line](https://github.com/better-auth/better-auth/releases/tag/v1.6.0) · 2026-04-06

#### deviceAuthorization() plugin

**Added in better-auth 1.3.8** (2025-09-04)

better-auth ships a first-party device authorization flow since 1.3.8: the `deviceAuthorization()` server plugin from `better-auth/plugins` and `deviceAuthorizationClient()` from `better-auth/client/plugins`. Do not hand-roll a device-code table, a polling endpoint and a user-code verification page for CLI or TV sign-in.

*The stale belief:* That better-auth covers only browser and OAuth redirect flows, so signing in a CLI, a TV app or any input-constrained device needs a custom device-code implementation on top of it.

```ts
import { betterAuth } from 'better-auth'
import { deviceAuthorization } from 'better-auth/plugins'

export const auth = betterAuth({
  plugins: [deviceAuthorization()],
})

// client
import { createAuthClient } from 'better-auth/client'
import { deviceAuthorizationClient } from 'better-auth/client/plugins'

export const authClient = createAuthClient({
  plugins: [deviceAuthorizationClient()],
})
```

> Introduced in a PATCH release. 1.3.7 (2025-08-17) has no `deviceAuthorization` export anywhere in `dist/`; 1.3.8 (2025-09-04) exports it from `dist/plugins/`. That is worth stating on its own: better-auth ships whole plugins in patches, so `cadence_minors_12mo_to_cutoff` — which counts minors and majors — understates how much of this library's surface is new. Distinct from `oauthDeviceAuthorization()`, added in 1.7.0 (2026-08-18) for the OAuth-provider device grant; this fact makes no claim about that one.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [better-auth v1.3.8 release notes](https://github.com/better-auth/better-auth/releases/tag/v1.3.8) · 2025-09-04 · [better-auth 1.3.8 published package — dist/plugins/index.d.mts](https://registry.npmjs.org/better-auth/-/better-auth-1.3.8.tgz) · 2025-09-04

#### lastLoginMethod() plugin

**Added in better-auth 1.3.8** (2025-09-04)

better-auth ships a `lastLoginMethod()` plugin since 1.3.8, with `lastLoginMethodClient()` on the client. It records which provider a user signed in with last, in a cookie, so a sign-in page can show a "you used GitHub last time" hint. Do not write your own cookie for this.

*The stale belief:* That remembering a user's last-used sign-in provider is application code, because better-auth exposes no such helper.

```ts
import { betterAuth } from 'better-auth'
import { lastLoginMethod } from 'better-auth/plugins'

export const auth = betterAuth({
  plugins: [lastLoginMethod()],
})
```

> Also a patch-release addition — absent from 1.3.7's `dist/`, present in 1.3.8's. Later releases added options this fact does not cover: `beforeStoreCookie` for GDPR compliance in 1.6.24 (2026-07-22), and a cross-subdomain cookie-clearing fix in 1.6.19 (2026-06-16).

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [better-auth v1.3.8 release notes](https://github.com/better-auth/better-auth/releases/tag/v1.3.8) · 2025-09-04 · [better-auth 1.3.8 published package — dist/plugins/index.d.mts](https://registry.npmjs.org/better-auth/-/better-auth-1.3.8.tgz) · 2025-09-04

#### SSO plugin — SAML 2.0

**Added in better-auth 1.3.0** (2025-07-19)

The SSO plugin speaks SAML 2.0 as well as OIDC since 1.3.0. A customer whose identity provider does not support OIDC can still be onboarded through the same plugin; "better-auth only supports OIDC for enterprise SSO" has been wrong since 2025-07-19.

*The stale belief:* That the SSO plugin is OIDC-only and a SAML customer needs a third-party bridge or a different auth library.

> Scored S3 rather than S2: a model that says "OIDC only" sends the reader to look for a workaround, but does not produce running code that misbehaves. The introducing release is cited from the vendor's own notes. This fact deliberately does not state the shape of the SAML config object, which was not verified against the shipped package — the SSO plugin has since moved to a separate `@better-auth/sso` package and its current option names were not checked.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [better-auth v1.3.0 release notes](https://github.com/better-auth/better-auth/releases/tag/v1.3.0) · 2025-07-19

## Not corrections — recorded for honesty

Claims seen in a run but not yet verified against a primary source. Never treated as findings:

- Both Fable draws describe the missing phone-number storage option as a known upstream complaint — "It's a known asymmetry people complained about on GitHub." The asymmetry is real and was verified by type-checking, but no issue or discussion was located this session, so the claim that it was publicly complained about is unverified. *(open since 2026-09-03)*
- The subject named "the early 1.3.x patches (roughly 1.3.1+)" as the first thing it cannot describe. `knowledge_gap_starts_at_version` is recorded as 1.4.0, the next release with substantial describable content, rather than 1.3.1: no subject can describe individual patches for any library in this dataset, so patch-level non-recall is release granularity rather than an attribution boundary. Recording 1.3.1 would have claimed a one-day boundary window, which the evidence does not support. *(open since 2026-09-01)*
- This draw and `v1r-b` agree with each other and with `better-auth/v1` on the boundary, while the concurrent prisma replicates of the same model disagreed by 204 days. Boundary stability therefore varies by library for a fixed model — but two replicated libraries is not enough to say what property of a library predicts it, and the pre-registered guess (unambiguous version history replicates better) was falsified in the opposite direction. *(open since 2026-09-01)*
- Both better-auth replicates denied that database-less sessions exist, and `better-auth/v1` charged no findings at all against this subject. Whether `v1` was under-scored, or whether the denial is an artefact of how task 11 is worded, is unresolved and needs a battery that probes the 1.4.0 surface directly rather than a replicate. *(open since 2026-09-01)*
- Three measurements of this model's better-auth boundary — `v1`, `v1r-a` and this run — agree, while two measurements of its prisma boundary taken the same day disagree by 204 days. What property of a library makes its boundary reproducible is now an open and answerable question; the pre-registered guess was falsified in the opposite direction. *(open since 2026-09-01)*
- Both replicates independently denied that database-less sessions exist. Whether `better-auth/v1`'s zero-finding result was under-scored needs a battery aimed at the 1.4.0 surface, not another replicate. *(open since 2026-09-01)*
- Is `deviceAuthorization()` a fair probe at all, given that `deviceAuthorization` is close to the obvious name for an RFC 8628 implementation? The below-floor control (Claude Sonnet 5, whose boundary is four minors lower) also produced the name, while volunteering that it could not rule out reconstructing it from generic RFC knowledge. *(open since 2026-09-02)*
- Does the `baseURL` denial survive a probe that does not mention Vercel or preview deployments? Every task-1 framing here routed through a hosting platform, and a subject may be reasoning "that is a deployment concern, not a library concern" rather than recalling that `baseURL` is string-only. *(open since 2026-09-03)*
- Both Opus 5 draws claim that `session.cookieCache` and the `customSession` plugin do not compose cleanly — that a cached read can return a response missing the custom field or a stale one, and that the behaviour has moved across versions. Neither draw would state which versions. Not verified against any installed release this session. *(open since 2026-09-03)*
- The draw makes a security argument this battery did not verify and that is worth checking independently: that hashing a six-digit OTP is near-worthless against the stated threat actor, because an attacker holding the row can brute-force a 10^6 space offline in milliseconds, so the mitigation only covers incidental exposure. Both `v5-b` and `v5-d` made the same argument, and `v5-d` drew the further conclusion that only a keyed transform (the `encrypted` mode, or an HMAC) closes the row. If that is right, the Index's own LF9 recommendation of `storeIdentifier: 'hashed'` is under-specified for short numeric codes and should say so. *(open since 2026-09-03)*
- The subject named "~1.3.8 onward" as the first thing it cannot describe. `knowledge_gap_starts_at_version` is recorded as 1.4.0 for the same reason as the Fable 5 run: patch-level non-recall is release granularity, not an attribution boundary. *(open since 2026-09-01)*
- SELF-TEST. This run is marked `self_test: true` -- the subject model is the same model operating the studio. It is the fourth such run in the dataset and the caveat is unchanged: a zero-finding result from a self-test is the one result most likely to be flattered by the operator, so the scoring here was made stricter rather than looser, and the one place Opus 5 missed a capability is recorded as `chargeable_miss: true` in the non-findings rather than dropped. *(open since 2026-09-01)*
- The 1.3.0 verification-hashing options (`storeToken`, `storeOTP`) are admissible against all three current subjects, and the four draws split on them: two named them correctly, one hedged them to 60%, and this one denied their existence at any version. Is that a real difference in knowledge, or an artefact of this battery's framing, which asked about the `verification` table rather than about the plugins? *(open since 2026-09-03)*
- The subject declined to name a first-undescribable version at all, saying it has no reliable version sequence past 1.0.0. `knowledge_gap_starts_at_version` is recorded as 1.1.0 -- the next release, whose contents it did not describe -- rather than quoted from the subject. Flagged so the bracket is not read as tighter than the subject's own answer supports. *(open since 2026-09-01)*
- The subject dated 1.0.0 to "roughly September 2024"; it actually shipped 2024-11-23. Version identification was right and date recall was two months early. Whether attribution boundaries are systematically dated early is worth checking across the existing six libraries. *(open since 2026-09-01)*

---

*Findings, code and citations: `data/better-auth/` — one JSON file and one write-up per model, each finding carrying the release that broke the belief, its publication date and a verbatim quote from the primary source. Corrections: `data/better-auth/facts.json`. This file is generated by `tools/build-corrections.mjs`; if the prose and the data ever disagree, that is a bug in the generator, not a stale pack.*

==============================================================================
CORRECTION PACK: langchain (https://stalepriors.com/corrections/langchain.md)

# langchain correction pack · for projects on langchain>=1,<2 (Python)


## What we actually measured

5 Claude models were asked for idiomatic langchain code with no tools, purely from training knowledge. 20 reproduced failures across 22 runs, each verified against the release that broke the belief.

| Model | Stated cutoff | langchain version attribution stops | Lag inside the window |
|---|---|---|---|
| Claude Opus 5 | 2026-05 | 1.0.0 · 2025-10-17 | ~7 months |
| Claude Fable 5.1 | 2026-06 | 1.1.0 · 2025-11-24 | ~6 months |
| Claude Haiku 4.5 | 2025-02 | 0.3.0 · 2024-09-13 | ~5 months |
| Claude Fable 5 | 2026-01 | 1.0.0 · 2025-10-17 | ~3 months |
| Claude Sonnet 5 | 2026-01 | 1.0.0 · 2025-10-17 | ~3 months |

A recent cutoff is not a defence. Every model here loses track of this library's release history well before the date it states as its own cutoff, and the stopping points cluster far tighter than the cutoffs do.

Read that column precisely. It is the newest langchain release whose contents the model can correctly **attribute to that release** — not the newest langchain feature it knows. Past that point a model will often write working code with a newer API while naming the wrong release for it, and that guess runs *early* — it names a release older than the one that shipped the feature. So the question this pack answers is not "does the model know this API" but "can it be trusted about which version the API arrived in" — which is the question that matters when you are pinned to a version.

Latest langchain is **1.4.0** (verified 2026-09-06). Separately from the corrections below, 3 of 22 runs recorded a version fact — the model named a current langchain version from memory and was behind. If a model states a version without checking, assume it is behind and check the registry.

## How to read an entry

Every entry ends with a *Reproduced against* line. Where it names models, we have the generated code that got it wrong, dated, with the model's own words in the run write-up. Where it says no model yet, the correction is verified from the release notes but nothing has been probed for it — it is a fix, not a measurement, and the pack says so rather than blurring the two.

The section an entry sits in is the worst case if you act on the stale belief. The severity in brackets after a model's name is what that particular model's output actually did, which can be milder — a model can hold the wrong belief and still, on the day, write code that runs.

## The corrections

### Breaks the build, or throws at runtime

Act on the stale belief here and the code does not run. Fix these first.

#### `langchain.hub`

**Removed in langchain 1.0.0** (2025-10-17)

`from langchain import hub` no longer works. The hub module moved to `langchain-classic`; the prompt registry is also reachable directly from the LangSmith SDK, which is the path the current docs use.

*The stale belief:* That the hosted prompt registry is reached with `from langchain import hub; hub.pull("owner/name")`, optionally after `pip install langchainhub`.

```python
# Stale
from langchain import hub

prompt = hub.pull("hwchase17/react")

# Current
# pip install langchain-classic
from langchain_classic import hub
prompt = hub.pull("hwchase17/react")

# or, without the compatibility package:
# pip install langsmith
from langsmith import Client
prompt = Client().pull_prompt("hwchase17/react")
```

*Reproduced against: **Claude Sonnet 5** (S1) — langchain/v1, 2026-08-31.*

Source: [LangChain v1 migration guide — update your imports](https://docs.langchain.com/oss/python/migrate/langchain-v1) · [API reference — langchain_classic.hub.pull](https://reference.langchain.com/python/langchain-classic/hub/pull)

#### agent custom state

**Stricter in langchain 1.0.0** (2025-10-17)

Custom agent state must be a `TypedDict`. The Pydantic state classes are gone: `AgentStatePydantic` and `AgentStateWithStructuredResponsePydantic` have no replacement beyond `langchain.agents.AgentState`.

*The stale belief:* That agent state can be declared as a Pydantic model.

```python
# Stale
from langgraph.prebuilt.chat_agent_executor import AgentStatePydantic

# Current
from typing_extensions import TypedDict
from langchain.agents import AgentState

class MyState(AgentState):
    tickets: list[str]
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain v1 migration guide — Custom state](https://docs.langchain.com/oss/python/migrate/langchain-v1) · [LangGraph v1 migration guide — Deprecations](https://docs.langchain.com/oss/python/migrate/langgraph-v1)

#### `AIMessage(example=...)`

**Removed in langchain 1.0.0** (2025-10-17)

The `example` parameter was removed from `AIMessage`. Put that metadata in `additional_kwargs`.

*The stale belief:* That `AIMessage(content=..., example=True)` is valid.

```python
# Stale
AIMessage(content="...", example=True)

# Current
AIMessage(content="...", additional_kwargs={"example": True})
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain v1 migration guide — example parameter removed from AIMessage](https://docs.langchain.com/oss/python/migrate/langchain-v1)

#### `create_agent(pre_model_hook=...) / post_model_hook`

**Removed in langchain 1.0.0** (2025-10-17)

`pre_model_hook` and `post_model_hook` are not `create_agent` parameters. Their replacement is middleware: a `before_model` / `after_model` hook, or `wrap_model_call` when you want to change only what is sent to the model without editing stored state.

*The stale belief:* That message trimming or output validation is wired in with `pre_model_hook=` / `post_model_hook=` on the agent factory.

```python
# Stale
agent = create_agent(model, tools, pre_model_hook=trim)

# Current
from langchain.agents.middleware import wrap_model_call

@wrap_model_call
def trim(request, handler):
    return handler(request.override(messages=request.messages[-6:]))

agent = create_agent(model, tools, middleware=[trim])
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain v1 migration guide — Pre-model hook](https://docs.langchain.com/oss/python/migrate/langchain-v1) · [API reference — langchain.agents.middleware.wrap_model_call](https://reference.langchain.com/python/langchain/agents/middleware/types/wrap_model_call)

#### `create_agent(response_format=...)`

**Removed in langchain 1.0.0** (2025-10-17)

Prompted structured output — passing a `(instruction_string, Schema)` tuple to `response_format` — was removed. A bare schema is still accepted, and the framework picks a strategy; to choose explicitly, pass `ToolStrategy(Schema)` (artificial tool call, works on any tool-calling model) or `ProviderStrategy(Schema)` (provider-native constrained decoding). The result lands in `result["structured_response"]`.

*The stale belief:* That you can steer structured output by handing `response_format` a prompt alongside the schema.

```python
# Stale
agent = create_react_agent(model, tools,
    response_format=("please generate ...", OutputSchema))

# Current
from langchain.agents.structured_output import ToolStrategy

agent = create_agent(model, tools, response_format=ToolStrategy(OutputSchema))
result["structured_response"]
```

> 1.0.0 also stopped generating structured output in a separate graph node; it happens in the main loop, which removes an extra model call. 1.2.0 (2025-12-15) added strict schema adherence for `ProviderStrategy`.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain v1 migration guide — Prompted output removed](https://docs.langchain.com/oss/python/migrate/langchain-v1) · [LangChain changelog — langchain v1.2.0](https://docs.langchain.com/oss/python/releases/changelog) · 2025-12-15

#### `create_agent(system_prompt=...)`

**Renamed in langchain 1.0.0** (2025-10-17)

The static instruction parameter is `system_prompt`. `prompt=` was the `create_react_agent` name and is not accepted by `create_agent` — passing it raises `TypeError: unexpected keyword argument`.

*The stale belief:* That the agent factory takes `prompt=`.

```python
# Stale
agent = create_agent(model, tools, prompt="You are helpful.")

# Current
agent = create_agent(model, tools, system_prompt="You are helpful.")
```

> 1.0.0 required a plain string here; 1.1.0 (2025-11-24) added support for passing a `SystemMessage` instance, which enables cache control and structured content blocks.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain v1 migration guide — Static prompt rename](https://docs.langchain.com/oss/python/migrate/langchain-v1) · [LangChain changelog — langchain v1.1.0](https://docs.langchain.com/oss/python/releases/changelog) · 2025-11-25

#### langchain text splitters

**Removed in langchain 1.0.0** (2025-10-17)

Text splitters are not part of the v1 `langchain` namespace. They live in their own distribution, `langchain-text-splitters`, imported as `langchain_text_splitters`.

*The stale belief:* That `from langchain.text_splitter import RecursiveCharacterTextSplitter` works.

```python
# Stale
from langchain.text_splitter import RecursiveCharacterTextSplitter

# Current
# pip install langchain-text-splitters
from langchain_text_splitters import RecursiveCharacterTextSplitter
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [What's new in LangChain v1 — Namespace](https://docs.langchain.com/oss/python/releases/langchain-v1)

#### `langchain-classic`

**New requirement in langchain 1.0.0** (2025-10-17)

`langchain-classic` is a separate distribution. `pip install langchain` does not bring it in, so every legacy import above fails with `ModuleNotFoundError: No module named 'langchain_classic'` until it is installed. Any migration advice that only rewrites the import path is incomplete without the install line.

*The stale belief:* That legacy symbols are still reachable from whatever is installed alongside `langchain`.

```bash
# Stale
pip install langchain

# Current
pip install langchain langchain-classic
```

> First published to PyPI 2025-10-07 (1.0.0a1); 1.0.8 is the latest as of 2026-08-31.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain v1 migration guide — Install with](https://docs.langchain.com/oss/python/migrate/langchain-v1) · [PyPI JSON API — langchain-classic release timestamps](https://pypi.org/pypi/langchain-classic/json)

#### `langchain.agents.initialize_agent / AgentExecutor`

**Removed in langchain 1.0.0** (2025-10-17)

`initialize_agent`, `AgentExecutor` and `AgentType` are gone from `langchain.agents`, which now exports `create_agent` and `AgentState`. The old agent machinery is in `langchain-classic`.

*The stale belief:* That agents are built with `initialize_agent(tools, llm, agent=AgentType.OPENAI_FUNCTIONS)` or by wrapping a runnable in an `AgentExecutor`.

```python
# Stale
from langchain.agents import initialize_agent, AgentType, AgentExecutor

# Current
from langchain.agents import create_agent
```

> These were deprecated long before 1.0.0; 1.0.0 is where they left the package.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [API reference — langchain_classic.agents.initialize.initialize_agent](https://reference.langchain.com/python/langchain-classic/agents/initialize/initialize_agent) · [What's new in LangChain v1 — Namespace](https://docs.langchain.com/oss/python/releases/langchain-v1)

#### langchain.chains (LLMChain, ConversationChain, RetrievalQA)

**Removed in langchain 1.0.0** (2025-10-17)

Legacy chains are not in the `langchain` package. They moved to `langchain-classic`, which `pip install langchain` does not install, so `from langchain.chains import LLMChain` is an `ImportError` on a fresh v1 environment. Either install `langchain-classic` and import from `langchain_classic.chains`, or write the pipeline directly — a prompt piped into a model, or a retrieve-then-answer function.

*The stale belief:* That `LLMChain`, `ConversationChain`, `RetrievalQA` and friends live in `langchain.chains`.

```python
# Stale
from langchain.chains import LLMChain, RetrievalQA

# Current
# only if you really need the legacy chain:
#   pip install langchain-classic
from langchain_classic.chains import LLMChain, RetrievalQA
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain v1 migration guide — langchain-classic](https://docs.langchain.com/oss/python/migrate/langchain-v1) · [API reference — langchain_classic.chains.llm.LLMChain](https://reference.langchain.com/python/langchain-classic/chains/llm/LLMChain)

#### langchain.memory (ConversationBufferMemory)

**Removed in langchain 1.0.0** (2025-10-17)

The memory classes are not in `langchain`. Conversation memory in v1 is a LangGraph checkpointer keyed by `thread_id`, not an object hung off a chain; the old classes remain available only in `langchain-classic`.

*The stale belief:* That you attach `memory=ConversationBufferMemory(...)` to a chain.

```python
# Stale
from langchain.memory import ConversationBufferMemory

chain = ConversationChain(llm=llm, memory=ConversationBufferMemory())

# Current
from langgraph.checkpoint.memory import InMemorySaver

agent = create_agent(model, tools, checkpointer=InMemorySaver())
cfg = {"configurable": {"thread_id": "session-1"}}
agent.invoke({"messages": [...]}, cfg)
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [API reference — langchain_classic.memory.buffer.ConversationBufferMemory](https://reference.langchain.com/python/langchain-classic/memory/buffer/ConversationBufferMemory) · [LangChain v1 migration guide — langchain-classic](https://docs.langchain.com/oss/python/migrate/langchain-v1)

#### `langchain.retrievers / langchain.indexes`

**Removed in langchain 1.0.0** (2025-10-17)

Retrievers and the indexing API left the `langchain` namespace for `langchain-classic`. A vector store's own `.as_retriever()` is unaffected and is the normal way to retrieve in v1.

*The stale belief:* That `from langchain.retrievers import ...` and `from langchain.indexes import ...` resolve.

```python
# Stale
from langchain.retrievers import MultiQueryRetriever
from langchain.indexes import index

# Current
# pip install langchain-classic
from langchain_classic.retrievers import MultiQueryRetriever
from langchain_classic.indexes import index
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain v1 migration guide — langchain-classic](https://docs.langchain.com/oss/python/migrate/langchain-v1)

#### pre-bound models

**Removed in langchain 1.0.0** (2025-10-17)

`create_agent` does not accept a model that already has tools bound to it. Pass the model and the tools separately, and vary the model per call with middleware (`wrap_model_call` + `request.override(model=...)`) if you need dynamic selection.

*The stale belief:* That you can hand the agent factory `model.bind_tools([...])`.

```python
# Stale
agent = create_agent(model.bind_tools(tools), tools)

# Current
agent = create_agent(model, tools)
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain v1 migration guide — Model](https://docs.langchain.com/oss/python/migrate/langchain-v1)

### Runs, but is silently wrong

Nothing errors. The behaviour is simply not what a model trained earlier will tell you.

#### tool extras

**Added in langchain 1.2.0** (2025-12-15)

Provider-specific tool parameters go in `extras`, a flat `dict[str, Any]` on the tool — `@tool(extras={...})` or the `extras` attribute on a tool object. The keys are the provider's own field names (`defer_loading`, `cache_control`, `input_examples`), NOT a provider name wrapping them. There is no `provider_specific` attribute, and `metadata=` is a different field that goes to callback handlers and never reaches the provider payload.

*The stale belief:* That provider-specific tool configuration has no first-class home on a tool, so it must be smuggled in by binding raw provider-format tool dicts, or hung on whichever tool field looks closest.

```python
# Stale
# stale, and silent: no such attribute. Pydantic accepts the assignment on the
# tool object and nothing downstream ever reads it.
tool_obj.provider_specific = {"anthropic": {"defer_loading": True}}

# stale, and silent: `metadata` is a real BaseTool field, but it goes to callback
# handlers and is never serialised into the tool definition sent to the provider.
# (As a DECORATOR keyword this one is not silent -- `@tool(metadata=...)` raises
# TypeError, because the decorator has never taken `metadata`.)
tool_obj.metadata = {"cache_control": {"type": "ephemeral"}}

# stale, and silent: right attribute, wrong shape. langchain-anthropic copies
# across only keys in its own whitelist, so an "anthropic" wrapper key is dropped.
@tool(extras={"anthropic": {"defer_loading": True}})
def u(x: str) -> str: ...

# stale, but NOT broken: rebuilding the provider's tool dict by hand and splicing
# the fields in does reach the wire. It costs you the tool defined twice, the name
# kept in sync by hand, and a separate lookup to execute the call the model returns.
fn = convert_to_openai_tool(search_docs)["function"]
model.bind_tools([{ "name": fn["name"], "description": fn["description"],
                   "input_schema": fn["parameters"],
                   "cache_control": {"type": "ephemeral"}, "defer_loading": True }])

# Current
@tool(extras={"defer_loading": True, "cache_control": {"type": "ephemeral"}})
def my_tool(x: str) -> str:
    ...
```

> The wrong forms above are not hypothetical: the first three are what Opus 5, Sonnet 5 and Fable 5 respectively produced on 2026-09-01 (battery langchain/v2), and the fourth is what four of six draws produced on 2026-09-06 (battery langchain/v6). Raised from S4 to S2 in 2026-09 because three of three tested models got it wrong and the failure is silent: the code runs and the provider instruction is discarded. **Two corrections to this note, both from executing the forms rather than reading them (2026-09-06, JOURNAL/065).** (1) It previously said all three forms "fail the same way -- nothing raises". That is true of the two attribute forms, verified against langchain-core 1.6.2: `tool_obj.metadata = {...}` and `@tool(extras={"anthropic": {...}})` both leave `convert_to_anthropic_tool` output with no `cache_control` and no `defer_loading`. It is NOT true of `@tool(metadata={...})` as a decorator keyword, which raises `TypeError: tool() got an unexpected keyword argument 'metadata'` -- the decorator has never accepted `metadata`, so that form is loud, not silent, and the example above is rewritten as the attribute assignment that actually is silent. (2) A fourth wrong form exists and it WORKS: hand-rebuilding the provider's tool dict and splicing the fields in delivers both, because `AnthropicTool` is a TypedDict and an already-Anthropic-shaped dict is copied whole. Findings charged off that form are scored S3, not S2. The mechanism, verified in langchain-anthropic 1.7.1 `chat_models.py`: `convert_to_anthropic_tool` iterates `tool.extras` and copies across only keys in `_ANTHROPIC_EXTRA_FIELDS` = {allowed_callers, cache_control, defer_loading, eager_input_streaming, input_examples}, placing each at the top level of the tool definition. Re-verified 2026-09-06 against the shipped langchain-core 1.6.2 and langchain-anthropic 1.7.1; absent from langchain-core 1.1.3 and 0.3.22.

*Reproduced against: **Claude Fable 5** (S2), **Claude Opus 5** (S2), **Claude Sonnet 5** (S2) — langchain/v2, 2026-09-01; langchain/v6-a, 2026-09-06; langchain/v6-c, 2026-09-06.*

Source: [LangChain changelog — langchain v1.2.0](https://docs.langchain.com/oss/python/releases/changelog) · 2025-12-15 · [langchain-core 1.6.1 published wheel — langchain_core/tools/base.py, the `extras` docstring example](https://files.pythonhosted.org/packages/8e/25/f50dd65673c819aa33d3c34df58c115dbb6ec627d19f93e6e401dd0fc8d7/langchain_core-1.6.1-py3-none-any.whl) · 2026-08-27 · [langchain-anthropic 1.7.1 published wheel -- chat_models.py, the whitelist that carries extras onto the wire](https://files.pythonhosted.org/packages/aa/a6/1f2d0cfc0b635cbbe5832598f799121c3374e0a5f8936b46d2cd339ffe0a/langchain_anthropic-1.7.1-py3-none-any.whl) · 2026-09-03 · [langchain-core 1.1.3 published wheel -- the release below the window, where tools/base.py has no extras field](https://files.pythonhosted.org/packages/58/41/6db768d4b208a33b4f09d5415e617d489f68167bb5dd27f87c7a49d13caf/langchain_core-1.1.3-py3-none-any.whl) · 2025-12-09

#### create_agent recursion limit

**Behaviour changed in langchain 1.1.0** (2025-11-24)

Since 1.1.0, `create_agent` stamps its own recursion limit onto the graph it compiles, so an agent built by the factory does not run under LangGraph's default. 1.1.0 ended `create_agent` with `.with_config({"recursion_limit": 10_000})`; the shipped release sets `{"recursion_limit": 9_999}`. The number to know is that it is four figures, not 25. A `GraphRecursionError` from a factory-built agent therefore means thousands of supersteps have actually run — a genuine non-terminating loop — and raising the ceiling is not the fix.

*The stale belief:* That a `create_agent` agent inherits LangGraph's 25-superstep default (about twelve tool rounds), so a step-limit error is normal for a long tool loop and the fix is `config={"recursion_limit": 100}`.

```python
# Stale
agent.invoke({"messages": [...]}, config={"recursion_limit": 100})

# Current
agent = create_agent(
    model,
    tools,
    middleware=[ModelCallLimitMiddleware(run_limit=40, exit_behavior="end")],
)
```

> Verified 2026-09-01 at both ends, from the shipped wheels; the changelog carries no line for it, so the introducing evidence is the 1.0.0/1.1.0 diff — 1.0.0 ends `create_agent` with a bare `graph.compile(...)`. Deliberately scoped to the langchain side: LangGraph raised its own `DEFAULT_RECURSION_LIMIT` from 25 to 10000 at langgraph 1.1.0 (2026-03-10) and ships 10007 at langgraph 1.2.11, so "25" is now stale twice over — but the Index charges only the `create_agent` fact, which is inside every tested subject's window. The value moved between introduction and today (10,000 to 9,999), so the durable fact is the shape and the origin, not the integer.

*Reproduced against: **Claude Fable 5** (S2), **Claude Opus 5** (S2), **Claude Sonnet 5** (S2) — langchain/v3, 2026-09-01.*

Source: [langchain 1.0.0 published wheel — langchain/agents/factory.py (no limit set)](https://files.pythonhosted.org/packages/c4/4d/2758a16ad01716c0fb3fe9ec205fd530eae4528b35a27ff44837c399e032/langchain-1.0.0-py3-none-any.whl) · 2025-10-17 · [langchain 1.1.0 published wheel — langchain/agents/factory.py (the change)](https://files.pythonhosted.org/packages/0b/6f/889c01d22c84934615fa3f2dcf94c2fe76fd0afa7a7d01f9b798059f0ecc/langchain-1.1.0-py3-none-any.whl) · 2025-11-24 · [langchain 1.3.18 published wheel — langchain/agents/factory.py (still true now, new value)](https://files.pythonhosted.org/packages/f7/04/374f6014ed6959dbdab92962c2b09e4d0223ed6a82f65694870b46d2c13f/langchain-1.3.18-py3-none-any.whl) · 2026-08-27

#### ModelRetryMiddleware defaults

**Added in langchain 1.1.0** (2025-11-24)

`ModelRetryMiddleware()` with no arguments does **not** re-raise when its retries run out. Its defaults are `max_retries=2` (three model calls in total) and `on_failure="continue"`, and `"continue"` means the middleware swallows the provider exception and returns a `ModelResponse` carrying a synthetic `AIMessage` whose text is `"Model call failed after N attempts with {ExcType}: {message}"`. The agent then proceeds as though the model had replied. Re-raising is opt-in: `on_failure="error"`. Every parameter is keyword-only; the rest of the defaults are `backoff_factor=2.0`, `initial_delay=1.0`, `max_delay=60.0`, `jitter=True` (±25%).

*The stale belief:* That a bounded-retry middleware re-raises the underlying provider exception once attempts are exhausted, so `agent.invoke(...)` fails loudly when the provider is down.

```python
# Stale
agent = create_agent(model, tools, middleware=[ModelRetryMiddleware()])
try:
    result = agent.invoke({"messages": [...]})
except Exception:
    alert_oncall()  # never runs: nothing is raised

# Current
agent = create_agent(
    model,
    tools,
    middleware=[ModelRetryMiddleware(on_failure="error")],
)
```

> Verified 2026-09-01 at both ends. This is the sharpest failure mode in the 1.1.0 surface: a caller who believes the exception propagates writes an `except` that never fires and ships an agent that answers with an error string as if it were a model reply. One default did move after introduction and is recorded rather than smoothed over: `retry_on` was `(Exception,)` at 1.1.0 and is the `default_retry_on` callable in the shipped release, which honours `ModelError.is_retryable` and retries unclassified exceptions. `max_retries` and `on_failure` are unchanged since 1.1.0.

*Reproduced against: **Claude Fable 5** (S2), **Claude Opus 5** (S2), **Claude Sonnet 5** (S2) — langchain/v3, 2026-09-01.*

Source: [LangChain changelog — langchain v1.1.0](https://docs.langchain.com/oss/python/releases/changelog) · 2025-11-24 · [langchain 1.3.18 published wheel — langchain/agents/middleware/model_retry.py](https://files.pythonhosted.org/packages/f7/04/374f6014ed6959dbdab92962c2b09e4d0223ed6a82f65694870b46d2c13f/langchain-1.3.18-py3-none-any.whl) · 2026-08-27

#### `AgentMiddleware.modify_model_request`

**Removed in langchain 1.0.0** (2025-10-17)

`modify_model_request` is not a middleware hook in any released langchain 1.x. It existed in the 1.0 alpha line and was replaced before 1.0.0 GA by `wrap_model_call(request, handler)` — which receives the downstream handler and so can retry, short-circuit or post-process, none of which the old signature could do. The shipped hook set is `before_agent` / `before_model` / `wrap_model_call` / `after_model` / `after_agent` / `wrap_tool_call`, each with an `a`-prefixed async twin. Defining `modify_model_request` on an `AgentMiddleware` subclass raises nothing: the method is simply never called, and the middleware silently does nothing.

*The stale belief:* That middleware customises a model call by defining `modify_model_request(self, request, state, runtime)` and returning a modified request.

```python
# Stale
class StampMiddleware(AgentMiddleware):
    def modify_model_request(self, request, state, runtime) -> ModelRequest:
        request.system_prompt = (request.system_prompt or "") + stamp
        return request

# Current
class StampMiddleware(AgentMiddleware):
    def wrap_model_call(self, request, handler):
        base = request.system_message.text if request.system_message else ""
        return handler(
            request.override(system_message=SystemMessage(content=base + stamp))
        )
```

> Verified 2026-09-01. The string `modify_model_request` appears nowhere in the published 1.0.0, 1.1.0, 1.2.0 or 1.3.18 wheels — this is a fact established by its absence from the shipped artifact across the whole 1.x line, which is why the citation quotes the hook list that replaced it. Scored S2 rather than S1 because Python raises nothing: an unrecognised method on a subclass is legal, so the failure is a middleware that is registered, never fires, and is trusted anyway.

*Reproduced against: **Claude Sonnet 5** (S2) — langchain/v3, 2026-09-01.*

Source: [langchain 1.3.18 published wheel — langchain/agents/middleware/types.py (the shipped hook set)](https://files.pythonhosted.org/packages/f7/04/374f6014ed6959dbdab92962c2b09e4d0223ed6a82f65694870b46d2c13f/langchain-1.3.18-py3-none-any.whl) · 2026-08-27 · [LangChain Python API reference — langchain.agents.middleware.AgentMiddleware](https://reference.langchain.com/python/langchain/)

#### agent streaming node name

**Renamed in langchain 1.0.0** (2025-10-17)

In a `create_agent` graph the model step is named `"model"`, not `"agent"`. Code that filters streamed events on `"agent"` imports, runs, and prints nothing — there is no error to tell you the filter never matched.

*The stale belief:* That the node emitting model output is called `"agent"`, as it was in `create_react_agent`.

```python
# Stale
for token, meta in agent.stream(inputs, stream_mode="messages"):
    if meta.get("langgraph_node") == "agent":   # never true
        print(token.text, end="")

# Current
for token, meta in agent.stream(inputs, stream_mode="messages"):
    if meta.get("langgraph_node") == "model":
        print(token.text, end="")
```

> This is the trap that survives a partial migration: swap `create_react_agent` for `create_agent` and the streaming filter keeps compiling while silently going dark.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain v1 migration guide — Streaming node name rename](https://docs.langchain.com/oss/python/migrate/langchain-v1)

#### `ChatAnthropic(max_tokens=...)`

**Default changed in langchain 1.0.0** (2025-10-17)

`langchain-anthropic` no longer defaults `max_tokens` to a flat 1024; it picks a higher value based on the model. Advice built on the old number — "your answer is being cut off at 1024 tokens" — describes a default that no longer exists. If you actually relied on 1024, set it explicitly.

*The stale belief:* That `ChatAnthropic` caps output at 1024 tokens unless you override it.

```python
# Stale
model = ChatAnthropic(model="...")  # believed: max_tokens defaults to 1024

# Current
model = ChatAnthropic(model="...", max_tokens=1024)  # only if you want the old cap
```

> Setting `max_tokens` explicitly remains good practice, so code written on the stale belief still runs correctly — it is the stated reason that is wrong.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain v1 migration guide — Default max_tokens in langchain-anthropic](https://docs.langchain.com/oss/python/migrate/langchain-v1)

#### ChatOpenAI Responses API output format

**Default changed in langchain 1.0.0** (2025-10-17)

Against the OpenAI Responses API, `langchain-openai` now stores response items in message `content` by default. Code that parsed the previous shape keeps running and reads the wrong structure; restore the old behaviour with `output_version="v0"` or `LC_OUTPUT_VERSION=v0`.

*The stale belief:* That the Responses API output lands in the pre-1.0 content shape.

```python
model = ChatOpenAI(model="...", output_version="v0")  # opt back into the old shape
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain v1 migration guide — Default message format for OpenAI responses API](https://docs.langchain.com/oss/python/migrate/langchain-v1)

### Deprecated, or a better API now exists

Works today. It is the older idiom, and some of it is scheduled for removal.

#### astream_events(version="v3") on a create_agent agent

**Added in langchain 1.3.0** (2026-05-12)

`v2` is no longer the ceiling. From langchain 1.3.0 an agent built by `create_agent` accepts `version="v3"` in `stream_events` / `astream_events` - a content-block-centric protocol with typed, per-channel projections (`run.values`, `run.messages`, `run.lifecycle`, `run.subgraphs`), where `run.messages` yields one `ChatModelStream` per LLM call with sub-projections for text, reasoning, tool calls and usage. `v1` and `v2` are unchanged, so this is an addition rather than a migration. Scope matters: the claim is about the **agent**. The `langchain` package's own `_ConfigurableModel.astream_events` - what `init_chat_model(..., configurable_fields=...)` returns - still types `version: Literal["v1", "v2"] = "v2"` at 1.3.0 and 1.4.0.

*The stale belief:* That `v2` is the highest event-stream protocol version that exists, `v1` being the deprecated original - so a consumer that wants typed, per-channel event projections has to build them itself out of `v2` events.

```python
# Stale
async for event in agent.astream_events(inputs, version="v2"):
    ...  # and reshape v2's flat event dicts by hand

# Current
async for event in agent.astream_events(inputs, version="v3"):
    ...  # typed per-channel projections: run.values / run.messages /
         # run.lifecycle / run.subgraphs
```

> The changelog is the primary source for the langchain-side support and is quoted in full below; the artifact evidence is the dependency floor and the transformer registration that arrived with it (see LF37), plus langgraph 1.2.11, whose `pregel/main.py` carries the v3 machinery and rejects kwargs that would break v3's invariants. Verified 2026-09-06. Do not extend this fact to the configurable chat-model wrapper: that signature was checked at 1.3.0 and 1.4.0 and still stops at v2.

*Reproduced against: **Claude Fable 5.1** (S3) — langchain/v5-a, 2026-09-06.*

Source: [LangChain changelog - langchain v1.3.0, May 12, 2026](https://docs.langchain.com/oss/python/releases/changelog) · 2026-05-12 · [LangChain changelog - langgraph v1.2.0, the same day, on what v3 is](https://docs.langchain.com/oss/python/releases/changelog) · 2026-05-12 · [langchain 1.3.0 published wheel - the langgraph>=1.2.0 floor and the ToolCallTransformer registration](https://files.pythonhosted.org/packages/7b/6f/b9a9721c27fbb6d29a6a7cd89d6a41eeffc7c79b49b9a5cf5beb1d60952d/langchain-1.3.0-py3-none-any.whl) · 2026-05-12

#### `create_agent(transformers=...)`

**Added in langchain 1.3.0** (2026-05-12)

`create_agent` takes a `transformers=` argument: a sequence of scope-aware `StreamTransformer` factories that are registered on the graph it compiles, in addition to the agent's own defaults. Each factory is invoked once per scope (`factory(scope)`), so a subgraph gets its own instance. The agent always registers `ToolCallTransformer` first and appends yours after it, so you keep the built-in behaviour instead of replacing it. This is the supported way to shape an agent's event stream at construction time: you do not have to abandon `create_agent` and hand-build the `StateGraph`, and you do not have to wrap `.astream()` on the consumer side.

*The stale belief:* That the compiled agent is a closed box: `create_agent` gives you no hook into the graph's stream machinery, so scope-aware transformation must be done either by dropping to a hand-built `StateGraph` or by wrapping `.astream()`/`.astream_events()` in your own generator and reconstructing scope from `subgraphs=True` namespace tuples.

```python
# Stale
# stale: the capability is denied, so the requirement is met on the consumer side
agent = create_agent(model, tools, system_prompt="...")

async def my_stream(inputs, config=None):
    per_scope = {}
    async for ns, mode, chunk in agent.astream(
        inputs, config=config, stream_mode=["updates"], subgraphs=True
    ):
        per_scope.setdefault(ns, MyTransformer(ns))
        yield per_scope[ns](mode, chunk)

# Current
agent = create_agent(
    model,
    tools,
    system_prompt="...",
    transformers=[MyTransformer],  # factory, called once per scope
)
```

> Verified against the shipped wheels on 2026-09-06. 1.2.18 has no `transformers` parameter anywhere in `langchain/agents/factory.py` and calls `graph.compile()` without one; 1.3.0 adds `transformers: Sequence[Callable[[tuple[str, ...]], Any]] | None = None` to the signature, imports `ToolCallTransformer` from `langgraph.prebuilt`, and ends the compile call with `transformers=[ToolCallTransformer, *(transformers or ())]`. 1.4.0 keeps it, retypes it `Sequence[TransformerFactory]`, and inserts `AgentMiddleware.transformers` between the built-in and yours. The dependency floor moves in the same release (`langgraph<1.2.0,>=1.1.10` at 1.2.18 -> `langgraph<1.3.0,>=1.2.0` at 1.3.0), because the transformer/mux machinery is langgraph 1.2.0's. Scored S3, not S1: the consumer-side wrapper the stale belief produces does run, so a denial costs a reader unnecessary code rather than a broken build.

*Reproduced against: **Claude Fable 5.1** (S3) — langchain/v5-a, 2026-09-06.*

Source: [langchain 1.3.0 published wheel - langchain/agents/factory.py](https://files.pythonhosted.org/packages/7b/6f/b9a9721c27fbb6d29a6a7cd89d6a41eeffc7c79b49b9a5cf5beb1d60952d/langchain-1.3.0-py3-none-any.whl) · 2026-05-12 · [langchain 1.2.18 published wheel - the release below the window, with no such parameter](https://files.pythonhosted.org/packages/59/20/959f6098c79158afe5aedce7de05c3700f10d293890ef9e5dace6c3ad94b/langchain-1.2.18-py3-none-any.whl) · 2026-05-08 · [LangChain changelog - langchain v1.3.0](https://docs.langchain.com/oss/python/releases/changelog) · 2026-05-12

#### `ModelRequest.system_message`

**Renamed in langchain 1.1.0** (2025-11-24)

The system-instruction field on the `ModelRequest` object handed to middleware is `system_message: SystemMessage | None`. Until 1.1.0 it was `system_prompt: str | None`, a plain dataclass field. `system_prompt` survives as a read-only property returning `self.system_message.text`, and `override(system_prompt=...)` still converts, so pre-1.1 middleware keeps working — the shipped docstring labels the parameter "deprecated, converted to `SystemMessage`". Note the asymmetry that makes this easy to get wrong: `create_agent` itself still takes `system_prompt=`, so the public factory and the middleware-facing request now use different names for the same instruction.

*The stale belief:* That the middleware request carries the system instruction as a plain string field called `system_prompt`, the same name `create_agent` uses.

```python
# Stale
def wrap_model_call(self, request, handler):
    base = request.system_prompt or ""
    return handler(request.override(system_prompt=base + stamp))

# Current
def wrap_model_call(self, request, handler):
    base = request.system_message.text if request.system_message else ""
    return handler(
        request.override(system_message=SystemMessage(content=base + stamp))
    )
```

> Verified 2026-09-01 at both ends, from the shipped wheels rather than from release notes — the vendor changelog carries no line for this rename, so the introducing evidence is the 1.0.0/1.1.0 wheel diff, which is the artifact itself. Scored S3 rather than S2 because the old route genuinely still works; a reader following it gets a deprecation path, not a wrong result. The string route also loses what 1.1.0 added the object for: a `SystemMessage` can carry structured content blocks and provider cache markers that a `str` cannot.

*Reproduced against: **Claude Opus 5** (S3) — langchain/v3, 2026-09-01.*

Source: [langchain 1.0.0 published wheel — langchain/agents/middleware/types.py (the pre-rename state)](https://files.pythonhosted.org/packages/c4/4d/2758a16ad01716c0fb3fe9ec205fd530eae4528b35a27ff44837c399e032/langchain-1.0.0-py3-none-any.whl) · 2025-10-17 · [langchain 1.1.0 published wheel — langchain/agents/middleware/types.py and agents/factory.py](https://files.pythonhosted.org/packages/0b/6f/889c01d22c84934615fa3f2dcf94c2fe76fd0afa7a7d01f9b798059f0ecc/langchain-1.1.0-py3-none-any.whl) · 2025-11-24 · [langchain 1.3.18 published wheel — langchain/agents/middleware/types.py (still true now)](https://files.pythonhosted.org/packages/f7/04/374f6014ed6959dbdab92962c2b09e4d0223ed6a82f65694870b46d2c13f/langchain-1.3.18-py3-none-any.whl) · 2026-08-27

#### `langchain.agents.create_agent`

**Renamed in langchain 1.0.0** (2025-10-17)

`create_agent` from `langchain.agents` is the way to build an agent. `langgraph.prebuilt.create_react_agent` is deprecated as of LangGraph v1 in its favour; it still imports and runs, so this is not an immediate breakage, but every other v1 change below assumes you are on `create_agent` — the parameter names, the middleware hooks and the streaming node name all differ between the two.

*The stale belief:* That `from langgraph.prebuilt import create_react_agent` is the current recommended way to build a tool-calling agent, which it was throughout the 0.2/0.3 era.

```python
# Stale
from langgraph.prebuilt import create_react_agent

agent = create_react_agent(model, tools, prompt="You are helpful.")

# Current
from langchain.agents import create_agent

agent = create_agent(model, tools, system_prompt="You are helpful.")
```

> Two different functions have carried the name `create_react_agent`: the LangGraph prebuilt (deprecated here) and the much older `langchain.agents.react.agent.create_react_agent`, which moved to `langchain-classic`. Neither is the current answer.

*Reproduced against: **Claude Sonnet 5** (S3) — langchain/v1, 2026-08-31.*

Source: [LangGraph v1 migration guide — Deprecations](https://docs.langchain.com/oss/python/migrate/langgraph-v1) · [What's new in LangChain v1 — create_agent](https://docs.langchain.com/oss/python/releases/langchain-v1)

#### model retry middleware

**Added in langchain 1.1.0** (2025-11-24)

`ModelRetryMiddleware` ships in `langchain.agents.middleware` and retries the model call only, leaving tool calls alone. Its keyword-only parameters are `max_retries`, `retry_on`, `on_failure`, `backoff_factor`, `initial_delay`, `max_delay` and `jitter`. Do not hand-roll a `wrap_model_call` retry loop, and do not reach for the LCEL-era `Runnable.with_retry()` on the model — that predates this and wraps the model in a `RunnableRetry` before `create_agent` ever sees it.

*The stale belief:* That model-call retry has no first-class component, so it must be written as a custom `wrap_model_call` middleware, bolted on with `.with_retry()`, or wrapped in a `try/except` around the whole agent invocation.

```python
# Stale
# stale: retries the entire graph, tool calls included -- not what was asked for
for attempt in range(5):
    try:
        result = agent.invoke(payload)
        break
    except (RateLimitError, APITimeoutError):
        time.sleep(2**attempt)

# Current
from langchain.agents.middleware import ModelRetryMiddleware

agent = create_agent(
    model=model,
    tools=tools,
    middleware=[
        ModelRetryMiddleware(
            max_retries=4,
            retry_on=(RateLimitError, APITimeoutError),
            backoff_factor=2.0,
            initial_delay=1.0,
            jitter=True,
        )
    ],
)
```

> Verified 2026-09-01 at both ends, with the parameter list read directly off the shipped `__init__`. Whether `create_agent` actually rejects a `.with_retry()`-wrapped model is an open question in data/langchain/sonnet-5-v2.json and is deliberately not asserted here.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain changelog — langchain v1.1.0](https://docs.langchain.com/oss/python/releases/changelog) · 2025-11-25 · [langchain 1.3.18 published wheel — langchain/agents/middleware/model_retry.py](https://files.pythonhosted.org/packages/f7/04/374f6014ed6959dbdab92962c2b09e4d0223ed6a82f65694870b46d2c13f/langchain-1.3.18-py3-none-any.whl) · 2026-08-27

#### ModelRequest attribute assignment

**Deprecated in langchain 1.1.0** (2025-11-24)

Assigning to any attribute of a `ModelRequest` in middleware is deprecated: 1.1.0 added a `__setattr__` that emits a `DeprecationWarning` on every direct assignment and directs the caller to `request.override(...)`, which returns a new request rather than mutating the shared one. `override()` itself is not new — it existed at 1.0.0 — but until 1.1.0 in-place mutation was an equally supported idiom, and LangChain's own `ContextEditingMiddleware` used it.

*The stale belief:* That middleware modifies the request in place — `request.system_prompt = ...`, `request.messages.append(...)` — and returns it.

```python
# Stale
def wrap_model_call(self, request, handler):
    request.system_prompt = request.system_prompt + stamp
    return handler(request)

# Current
def wrap_model_call(self, request, handler):
    return handler(request.override(system_message=SystemMessage(content=new_text)))
```

> Verified 2026-09-01 at both ends, from the shipped wheels; the changelog carries no line for it. Corroborated inside the library's own source: at 1.0.0 `context_editing.py` mutated `request.messages` in place, and at 1.1.0 the same file deep-copies the list and returns `handler(request.override(messages=edited_messages))`. Scored S3: the warning is a warning, the assignment still takes effect.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [langchain 1.0.0 published wheel — middleware/types.py defines no __setattr__; context_editing.py mutates in place](https://files.pythonhosted.org/packages/c4/4d/2758a16ad01716c0fb3fe9ec205fd530eae4528b35a27ff44837c399e032/langchain-1.0.0-py3-none-any.whl) · 2025-10-17 · [langchain 1.3.18 published wheel — langchain/agents/middleware/types.py](https://files.pythonhosted.org/packages/f7/04/374f6014ed6959dbdab92962c2b09e4d0223ed6a82f65694870b46d2c13f/langchain-1.3.18-py3-none-any.whl) · 2026-08-27

#### SystemMessage as system_prompt

**Added in langchain 1.1.0** (2025-11-24)

`create_agent`'s `system_prompt` accepts a `SystemMessage`, not only a `str`. That is how a fixed instruction carries provider metadata — content blocks with `cache_control` for prompt caching, for instance — without adding middleware and without hand-assembling the message list. The shipped signature is `system_prompt: str | SystemMessage | None`.

*The stale belief:* That `system_prompt` is string-only, so any provider metadata on the system block requires middleware, a custom message list, or binding the hint on the model instead.

```python
# Stale
# stale: assumes str-only, so the cache marker has nowhere to go
agent = create_agent(model=model, tools=tools, system_prompt=LONG_INSTRUCTIONS)

# Current
system = SystemMessage(
    content=[
        {
            "type": "text",
            "text": LONG_INSTRUCTIONS,
            "cache_control": {"type": "ephemeral"},
        }
    ]
)
agent = create_agent(model=model, tools=tools, system_prompt=system)
```

> Verified 2026-09-01 at both ends. All three subjects tested on that date produced this form correctly, so it is carried as a correction for readers rather than as a measured model failure.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain changelog — langchain v1.1.0](https://docs.langchain.com/oss/python/releases/changelog) · 2025-11-25 · [langchain 1.3.18 published wheel — langchain/agents/factory.py](https://files.pythonhosted.org/packages/f7/04/374f6014ed6959dbdab92962c2b09e4d0223ed6a82f65694870b46d2c13f/langchain-1.3.18-py3-none-any.whl) · 2026-08-27

#### bind_tools return type

**Behaviour changed in langchain 1.0.0** (2025-10-17)

Chat model invocation is typed as returning `AIMessage`, not `BaseMessage`. Custom chat models implementing `bind_tools` should narrow their return signature to match.

*The stale belief:* That `bind_tools` is annotated `Runnable[LanguageModelInput, BaseMessage]`.

```python
# Stale
def bind_tools(...) -> Runnable[LanguageModelInput, BaseMessage]:

# Current
def bind_tools(...) -> Runnable[LanguageModelInput, AIMessage]:
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain v1 migration guide — Updated return type for chat models](https://docs.langchain.com/oss/python/migrate/langchain-v1)

#### built-in agent middleware

**Added in langchain 1.0.0** (2025-10-17)

Middleware is the extension point of `create_agent`: hooks `before_agent`, `before_model`, `wrap_model_call`, `wrap_tool_call`, `after_model`, `after_agent`, plus built-ins including `SummarizationMiddleware`, `HumanInTheLoopMiddleware`, `PIIMiddleware` and `TodoListMiddleware`. Hand-rolled graph surgery for summarisation, approval gates or redaction is the pre-1.0 answer.

*The stale belief:* That customising the agent loop means writing your own LangGraph `StateGraph`.

**The code below needs langchain 1.1.0 or later.** Between 1.0.0 and 1.1.0 this correction does not apply — see the note.

```python
from langchain.agents.middleware import SummarizationMiddleware, HumanInTheLoopMiddleware

agent = create_agent(model, tools, middleware=[
    # on langchain 1.0.x this parameter is max_tokens_before_summary=500
    SummarizationMiddleware(model=model, trigger={"tokens": 500}),
    HumanInTheLoopMiddleware(interrupt_on={"send_email": {"allowed_decisions": ["approve", "reject"]}}),
])
```

> CORRECTED 2026-09-02 (JOURNAL/037), by the first mechanical audit of a facts file (`tools/audit/`). The middleware system does arrive at 1.0.0, and the fact is right about that — but the snippet above was written against the current release and does not run on any 1.0.x. `SummarizationMiddleware` took `max_tokens_before_summary` through the whole 1.0 line and the `trigger=` form did not exist until **1.1.0**, where `max_tokens_before_summary` was removed in the same release. Bisected in the installed packages: 1.0.0 and 1.0.8 accept `max_tokens_before_summary` and reject `trigger`; 1.1.0, 1.2.0 and 1.3.18 accept `trigger` and reject `max_tokens_before_summary`. So there is no single summarisation call that works across the `langchain>=1,<2` range this pack claims, and a reader on 1.0.x copying the old text got `TypeError: unexpected keyword argument 'trigger'`. On 1.0.x write `SummarizationMiddleware(model=model, max_tokens_before_summary=500)` instead. `trigger` takes a `TriggerClause` — a total=False TypedDict with optional `tokens`, `messages` and `fraction` keys — so the dict form above is the declared type and not merely an accepted one. `HumanInTheLoopMiddleware(interrupt_on=...)` was checked at both ends and is unchanged: it constructs identically on 1.0.8 and 1.3.18. 1.1.0 (2025-11-24) also added model-retry middleware; the Anthropic-specific middleware moved into `langchain-anthropic` during the 1.0 cycle.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [What's new in LangChain v1 — Middleware](https://docs.langchain.com/oss/python/releases/langchain-v1)

#### `message.content_blocks`

**Added in langchain 1.0.0** (2025-10-17)

Messages carry a provider-agnostic `content_blocks` property: typed blocks for text, reasoning, tool calls and citations that read the same across Anthropic, OpenAI, AWS, Google GenAI and Ollama. `content` is unchanged, so nothing breaks; per-provider branching on `content` is simply no longer necessary. Standard blocks are not serialised into `content` unless you opt in with `output_version="v1"` or `LC_OUTPUT_VERSION=v1`.

*The stale belief:* That normalising reasoning/text/tool-call output requires hand-written per-provider branches.

```python
# Stale
for item in response.content:
    if item.get("type") == "reasoning": ...   # OpenAI
    elif item.get("type") == "thinking": ...  # Anthropic

# Current
for block in response.content_blocks:
    if block["type"] == "reasoning": ...
    elif block["type"] == "text": ...
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [What's new in LangChain v1 — Standard content blocks](https://docs.langchain.com/oss/python/releases/langchain-v1)

#### `message.text`

**Deprecated in langchain 1.0.0** (2025-10-17)

`.text` is a property on message objects. The `.text()` method form still works but emits a warning and is scheduled for removal in v2.

*The stale belief:* That `response.text()` is the way to get a message's text.

```python
# Stale
text = response.text()

# Current
text = response.text
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain v1 migration guide — Text property](https://docs.langchain.com/oss/python/migrate/langchain-v1)

#### multimodal message input

**Added in langchain 1.0.0** (2025-10-17)

Multimodal input has a standard form: `HumanMessage(content_blocks=[{"type": "image", "url": ...}])`. The provider-native `{"type": "image_url", "image_url": {"url": ...}}` shape inside `content` is the old spelling.

*The stale belief:* That images must be passed in each provider's own content shape.

```python
# Stale
HumanMessage(content=[{"type": "image_url",
                       "image_url": {"url": "https://example.com/i.jpg"}}])

# Current
HumanMessage(content_blocks=[{"type": "image",
                              "url": "https://example.com/i.jpg"}])
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain v1 migration guide — Create multimodal messages](https://docs.langchain.com/oss/python/migrate/langchain-v1)

#### run-scoped context (context= / context_schema=)

**Added in langchain 1.0.0** (2025-10-17)

Static per-run data (a user id, a tenant) is passed with `context=` against a declared `context_schema`, and read inside a tool through a `ToolRuntime` parameter, which is stripped from the schema the model sees. The older `config={"configurable": {...}}` route still works and the migration guide says so explicitly — this is a better-idiom change, not a breakage.

*The stale belief:* That `config["configurable"]` is the only way to get request-scoped data into a tool.

```python
# Stale
agent.invoke(state, config={"configurable": {"user_id": "u_1"}})

# Current
from dataclasses import dataclass
from langchain.tools import tool, ToolRuntime

@dataclass
class Context:
    user_id: str

@tool
def get_orders(runtime: ToolRuntime[Context]) -> str:
    """Fetch the caller's orders."""
    return lookup(runtime.context.user_id)

agent = create_agent(model, [get_orders], context_schema=Context)
agent.invoke(state, context=Context(user_id="u_1"))
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain v1 migration guide — Runtime context](https://docs.langchain.com/oss/python/migrate/langchain-v1) · [LangChain docs — Tools: ToolRuntime](https://docs.langchain.com/oss/python/langchain/tools)

### Wrong facts about the library

Not code — versions, minimums and metadata that models state confidently and get wrong.

#### ProviderStrategy strict

**Added in langchain 1.2.0** (2025-12-15)

`ProviderStrategy` takes a `strict` flag that asks the provider to enforce the schema server-side; when set, the strategy puts `"strict": True` into the JSON schema it sends. `ProviderStrategy(Schema)` alone is correct 1.0-era code and still routes to provider-native structured output — `strict=True` is the 1.2.0 addition on top of it.

*The stale belief:* That `ProviderStrategy` has no strictness control, so provider-side schema enforcement is all-or-nothing.

```python
agent = create_agent(
    model=model,
    tools=tools,
    response_format=ProviderStrategy(Verdict, strict=True),
)
```

> Verified 2026-09-01 at both ends. Scored S4: omitting it is an incomplete answer rather than a wrong one, which is why the langchain/v2 battery treated it as supplementary and excluded it from its counts. All three subjects tested on that date produced `ProviderStrategy(Schema)` without it.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain changelog — langchain v1.2.0](https://docs.langchain.com/oss/python/releases/changelog) · 2025-12-15 · [langchain 1.3.18 published wheel — langchain/agents/structured_output.py](https://files.pythonhosted.org/packages/f7/04/374f6014ed6959dbdab92962c2b09e4d0223ed6a82f65694870b46d2c13f/langchain-1.3.18-py3-none-any.whl) · 2026-08-27

#### model profiles (.profile)

**Added in langchain 1.1.0** (2025-11-21)

Chat models carry a `.profile` attribute — a `ModelProfile` TypedDict describing what the model supports, loaded from the provider package. Ask the model object instead of keeping a table of model names: `image_inputs`, `pdf_inputs`, `audio_inputs`, `max_input_tokens`, `structured_output` and `tool_calling` are among its keys. It is `total=False`, so read every key with `.get()`. `create_agent` reads it internally to decide whether a model can do provider-native structured output.

*The stale belief:* That model capabilities must be hard-coded in a name-to-capability table, discovered by trial, or fetched from an external catalogue over HTTP.

```python
# Stale
# stale: a table that goes out of date every time a provider ships a model
VISION = {"gpt-4o", "claude-sonnet-4-5", "gemini-2.5-pro"}
if model.model_name in VISION:
    ...

# Current
profile = getattr(model, "profile", None) or {}
if profile.get("image_inputs"):
    ...  # send the image
else:
    ...  # fall back to a text description
```

> The introducing release is langchain-core 1.1.0 (2025-11-21), which is three days before langchain 1.1.0 (2025-11-24) — the changelog reports the feature under the langchain 1.1.0 heading. Re-verified 2026-09-01 against the shipped langchain-core 1.6.1 wheel, whose `profile` field docstring carries its own `version-added` marker naming 1.1.0. Measured on 2026-09-01: all three subjects tested (Opus 5, Fable 5, Sonnet 5) used `.profile` correctly and all three dated it to the 1.0 line. Key names sharpened 2026-09-01 from the shipped `langchain_core/language_models/model_profile.py`: `ModelProfile` is a `total=False` TypedDict, so every key may be absent and the docstring says to guard accesses with `.get()`. The input-capability keys are `image_inputs`, `image_url_inputs`, `pdf_inputs`, `audio_inputs`, `video_inputs` — not `supports_vision` or a `modalities` list. `image_inputs` and `pdf_inputs` are present from core 1.1.0; `text_inputs`, `tool_call_streaming`, `attachment` and `temperature` were added later.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain changelog — langchain v1.1.0](https://docs.langchain.com/oss/python/releases/changelog) · 2025-11-25 · [langchain-core 1.6.1 published wheel — langchain_core/language_models/chat_models.py](https://files.pythonhosted.org/packages/8e/25/f50dd65673c819aa33d3c34df58c115dbb6ec627d19f93e6e401dd0fc8d7/langchain_core-1.6.1-py3-none-any.whl) · 2026-08-27 · [langchain-core 1.6.1 published wheel — langchain_core/language_models/model_profile.py](https://files.pythonhosted.org/packages/8e/25/f50dd65673c819aa33d3c34df58c115dbb6ec627d19f93e6e401dd0fc8d7/langchain_core-1.6.1-py3-none-any.whl) · 2026-08-27

#### langchain package namespace

**Removed in langchain 1.0.0** (2025-10-17)

The v1 `langchain` package exports five modules and nothing else: `langchain.agents`, `langchain.messages`, `langchain.tools`, `langchain.chat_models`, `langchain.embeddings`. Most are re-exports from `langchain-core`. Describing `langchain` as a kitchen sink of chains, retrievers and integrations describes 0.3.

*The stale belief:* That `langchain` is a large package containing chains, retrievers, memory, the hub and integration code.

```python
from langchain.agents import create_agent
from langchain.messages import AIMessage, HumanMessage
from langchain.tools import tool
from langchain.chat_models import init_chat_model
from langchain.embeddings import init_embeddings
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [What's new in LangChain v1 — Namespace](https://docs.langchain.com/oss/python/releases/langchain-v1) · [API reference — the langchain package](https://reference.langchain.com/python/langchain/)

#### langchain release timeline

**New requirement in langchain 1.0.0** (2025-10-17)

langchain 1.0.0 was published to PyPI on 2025-10-17, together with langchain-core 1.0.0 and langchain-openai 1.0.0. 1.1.0 followed on 2025-11-24, 1.2.0 on 2025-12-15, 1.3.0 on 2026-05-12. The latest release as of 2026-08-31 is 1.3.18 (2026-08-27), with langchain-core at 1.6.1. The last 0.3 release before the 1.0 alpha line was 0.3.27 on 2025-07-24.

*The stale belief:* That 0.3.x is the current line, or that 1.0 is unreleased or upcoming.

> Dates are the earliest file upload timestamp per release from the PyPI JSON API. The vendor changelog labels the 1.0.0 entry 'Oct 20, 2025'; the package files were uploaded 2025-10-17.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [PyPI JSON API — langchain release timestamps](https://pypi.org/pypi/langchain/json) · [LangChain Python changelog](https://docs.langchain.com/oss/python/releases/changelog)

#### Python version requirement

**New requirement in langchain 1.0.0** (2025-10-17)

All LangChain packages require Python 3.10 or higher. Python 3.9 support was dropped in v1.

*The stale belief:* That LangChain still supports Python 3.9.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [LangChain v1 migration guide — Dropped Python 3.9 support](https://docs.langchain.com/oss/python/migrate/langchain-v1)

## Not corrections — recorded for honesty

Claims seen in a run but not yet verified against a primary source. Never treated as findings:

- Are the beta identifier `advanced-tool-use-2025-11-20` and the server-tool type `tool_search_tool_regex_20251119`, both volunteered by this draw, real Anthropic identifiers? *(open since 2026-09-06)*
- Does `create_agent` accept a model that has been wrapped by `Runnable.with_retry()`? The shipped `factory.py` types the parameter `str | BaseChatModel` and only calls `init_chat_model` on the string branch, so a `RunnableRetry` is passed through un-validated to a code path that later reaches for chat-model methods. Relevant to Sonnet 5's P3 answer in the sibling run. *(open since 2026-09-01)*
- This draw and `v1r-b` were given a byte-identical prompt, the same model alias, on the same day, running concurrently, and placed the boundary thirteen months apart (1.0.0 / 2025-10-17 here; 0.3.0 / 2024-09-13 there). Two draws establish that the instrument is not single-valued; they do not establish the shape of the distribution, which draw is modal, or whether the split is bimodal at all. *(open since 2026-09-01)*
- Every other boundary published by the Index rests on a single draw of this same instrument, including the seven that produce Opus 5's three-day intersection. None has been replicated. *(open since 2026-09-01)*
- See `langchain--claude-sonnet-5--v1r-a--2026-09-01`. This draw agrees with `langchain/v1`; its twin does not, and both were given a byte-identical prompt on the same day. *(open since 2026-09-01)*
- Task 10 did not reproduce v1's S2 stream-filter failure. One divergence in one task is not enough to say whether findings are as unstable as boundaries, and a code-level reproducibility check has never been run. *(open since 2026-09-01)*
- Does `create_agent` accept a model wrapped by `Runnable.with_retry()`? The shipped `factory.py` types the parameter `str | BaseChatModel` and only calls `init_chat_model` on the string branch, so a `RunnableRetry` passes through un-validated into a path that later reaches for chat-model methods. If it raises, this subject's P3 is a build break rather than a partial. Not run, so not claimed. *(open since 2026-09-01)*
- Sonnet 5's langchain boundary now has two measurements 13 months apart — 0.3.0 in v1 (2026-08-31) and a "1.0 alpha/beta, mid-2025" self-placement in v3 (2026-09-01). Is that elicitation variance from differently-shaped prompts, or is the v1 measurement wrong? Every published boundary in the Index rests on a single measurement per model per library, so this is a question about the instrument, not about this run. Re-run `langchain/v1` against Sonnet 5 unchanged and compare before trusting either number. *(open since 2026-09-01)*
- All three subjects named `max_retries=2` correctly and all three asserted the exhausted-retry behaviour backwards. Is a default *count* systematically more guessable than a default *policy*? If so, future batteries should probe policies and treat counts as free. *(open since 2026-09-01)*
- Does the deprecated `langgraph.prebuilt.create_react_agent` still accept `pre_model_hook=`, and is its model node still named `"agent"`, on current LangGraph? *(open since 2026-08-31)*

---

*Findings, code and citations: `data/langchain/` — one JSON file and one write-up per model, each finding carrying the release that broke the belief, its publication date and a verbatim quote from the primary source. Corrections: `data/langchain/facts.json`. This file is generated by `tools/build-corrections.mjs`; if the prose and the data ever disagree, that is a bug in the generator, not a stale pack.*

==============================================================================
CORRECTION PACK: next.js (https://stalepriors.com/corrections/next.js.md)

# next.js correction pack · for projects on next@^16


## What we actually measured

3 Claude models were asked for idiomatic next.js code with no tools, purely from training knowledge. 21 reproduced failures across 13 runs, each verified against the release that broke the belief.

| Model | Stated cutoff | next.js version attribution stops | Lag inside the window |
|---|---|---|---|
| Claude Sonnet 5 | 2026-01 | 15.0.0 · 2024-10-21 | ~15 months |
| Claude Opus 5 | 2026-05 | 16.0.0 · 2025-10-22 | ~7 months |
| Claude Fable 5 | 2026-01 | 16.0.0 · 2025-10-22 | ~3 months |

A recent cutoff is not a defence. Every model here loses track of this library's release history well before the date it states as its own cutoff, and the stopping points cluster far tighter than the cutoffs do.

Read that column precisely. It is the newest next.js release whose contents the model can correctly **attribute to that release** — not the newest next.js feature it knows. Past that point a model will often write working code with a newer API while naming the wrong release for it, and that guess runs *early* — it names a release older than the one that shipped the feature. So the question this pack answers is not "does the model know this API" but "can it be trusted about which version the API arrived in" — which is the question that matters when you are pinned to a version.

Latest next.js is **16.3.4** (verified 2026-09-02). Separately from the corrections below, 2 of 13 runs recorded a version fact — the model named a current next.js version from memory and was behind. If a model states a version without checking, assume it is behind and check the registry.

## How to read an entry

Every entry ends with a *Reproduced against* line. Where it names models, we have the generated code that got it wrong, dated, with the model's own words in the run write-up. Where it says no model yet, the correction is verified from the release notes but nothing has been probed for it — it is a fix, not a measurement, and the pack says so rather than blurring the two.

The section an entry sits in is the worst case if you act on the stale belief. The severity in brackets after a model's name is what that particular model's output actually did, which can be milder — a model can hold the wrong belief and still, on the day, write code that runs.

## The corrections

### Breaks the build, or throws at runtime

Act on the stale belief here and the code does not run. Fix these first.

#### `revalidateTag`

**Behaviour changed in next.js 16.0.0** (2025-10-22)

`revalidateTag` takes two arguments. The single-argument form is deprecated in 16.0.0 and documented as producing a TypeScript error, so on a TypeScript project — where `next build` type-checks by default — it fails the build. Use `revalidateTag(tag, profile)` for content that tolerates eventual consistency, `updateTag(tag)` in a Server Action when the user must see their own write immediately, and `refresh()` to refresh uncached data without touching the cache.

*The stale belief:* That `revalidateTag('products')` is the current call signature.

```ts
// Stale
revalidateTag('products')

// Current
revalidateTag('products', 'max')   // 'max' | 'hours' | 'days' | { expire: 3600 }
updateTag('products')              // Server Actions only: read-your-writes
refresh()                          // Server Actions only: refresh uncached data
```

> This is the most reliably reproduced entry in the whole Index: every model tested writes the one-argument form in generated code, and two of the three can state the two-argument signature correctly when asked directly.

*Reproduced against: **Claude Fable 5** (S1), **Claude Opus 5** (S1), **Claude Sonnet 5** (S1) — next.js/v1, 2026-08-31.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25 · [Next.js 16 release announcement](https://nextjs.org/blog/next-16) · 2025-10-21

#### custom webpack config

**Default changed in next.js 16.0.0** (2025-10-22)

Turbopack is stable and the default for both `next dev` and `next build`. `--turbopack` is no longer needed; `--webpack` is the opt-out. A project carrying a custom webpack config now fails the build unless it opts out.

*The stale belief:* That webpack is the default bundler and Turbopack is opt-in behind `--turbopack`.

```jsonc
// Stale
"dev": "next dev --turbopack"

// Current
"dev": "next dev"
"build": "next build"          // Turbopack
"build:webpack": "next build --webpack"   // opt out
```

> `experimental.turbopack` as a config location moved to a top-level `turbopack` key.

*Reproduced against: **Claude Sonnet 5** (S4) — next.js/v1, 2026-08-31.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25

#### next lint

**Removed in next.js 16.0.0** (2025-10-22)

The `next lint` command was removed — a `package.json` script that calls it fails. Call ESLint or Biome directly. `next build` no longer runs linting either, and the `eslint` option in the Next.js config file is removed.

*The stale belief:* That `next lint` is the project lint script and that `next build` lints for you.

```jsonc
// Stale
"lint": "next lint"

// Current
"lint": "eslint"
```

> Codemod: `npx @next/codemod@canary next-lint-to-eslint-cli .`. `@next/eslint-plugin-next` now defaults to ESLint flat config.

*Reproduced against: **Claude Sonnet 5** (S1) — next.js/v1, 2026-08-31.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25

#### parallel route default.js

**New requirement in next.js 16.0.0** (2025-10-22)

Every parallel route slot requires an explicit `default.js`. Builds fail without one. To keep the previous behaviour, create a `default.js` per slot that returns `null` or calls `notFound()`.

*The stale belief:* That `default.js` is optional and its absence only causes a runtime 404 on reload — the pre-16 behaviour.

```ts
// app/@modal/default.tsx
export default function Default() { return null }
```

*Reproduced against: **Claude Fable 5** (S2) — next.js/v1, 2026-08-31.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25

#### AMP support (next/amp, useAmp, config.amp)

**Removed in next.js 16.0.0** (2025-10-22)

All AMP APIs and configuration were removed: the `amp` config key, `next/amp` imports including `useAmp`, and `export const config = { amp: true }`.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25

#### async request APIs

**Removed in next.js 16.0.0** (2025-10-22)

The synchronous-access compatibility period is over. `cookies()`, `headers()`, `draftMode()`, `params` and `searchParams` are async only — 15.x allowed sync access with a warning, 16.0.0 removed it.

```ts
const { slug } = await params
const cookieStore = await cookies()
```

> Also newly async in 16.0.0 and much less well known: the props passed to `opengraph-image`, `twitter-image`, `icon` and `apple-icon` generating functions, and the `id` passed to a `sitemap` function by `generateSitemaps`. `generateImageMetadata` still receives synchronous `params`.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25

#### `serverRuntimeConfig / publicRuntimeConfig`

**Removed in next.js 16.0.0** (2025-10-22)

Both were removed. Use environment variables instead.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25

### Runs, but is silently wrong

Nothing errors. The behaviour is simply not what a model trained earlier will tell you.

#### `experimental.clientSegmentCache`

**Removed in next.js 16.0.3** (2025-11-13)

`experimental.clientSegmentCache` no longer exists. It was `boolean | 'client-only'`, defaulted to `true`, and was removed one day after 16.0.2 — per-segment prefetching is now unconditional and has no on/off switch under any name. Because an unrecognised key under `experimental` only **warns** (the build exits only for unrecognised keys under `images`, and for two named Turbopack keys), setting it looks accepted and does nothing at all. If the goal is fewer prefetch requests per link, the current lever is `experimental.prefetchInlining` (16.2.0); if it is no prefetching, it is `<Link prefetch={false}>`.

*The stale belief:* That per-segment prefetching can be switched off with `experimental: { clientSegmentCache: false }` to get one whole-tree prefetch request per link. It was true up to 16.0.2 and has been silently inert since 16.0.3.

**The code below needs next.js 16.2.0 or later.** Between 16.0.3 and 16.2.0 this correction does not apply — see the note.

```ts
// Stale
experimental: { clientSegmentCache: false }

// Current
experimental: { prefetchInlining: true }
```

> Bisected in the published packages: declared in `dist/server/config-shared.d.ts` at 15.5.0, 16.0.0 and 16.0.2, absent from 16.0.3 onward through 16.3.4, with no renamed replacement (no config key in 16.3.4 contains 'segment'). This is a removal that shipped in a **patch**, one day after the release that still had it.

*Reproduced against: **Claude Fable 5** (S2), **Claude Opus 5** (S2), **Claude Sonnet 5** (S2) — next.js/v2-a, 2026-09-02; next.js/v3-a, 2026-09-02; next.js/v3-c, 2026-09-02.*

Source: [next 16.0.2 published package — the key still exists](https://unpkg.com/next@16.0.2/dist/server/config-shared.d.ts) · 2025-11-12 · [next 16.0.3 published package — the key is gone one day later](https://unpkg.com/next@16.0.3/dist/server/config-shared.d.ts) · 2025-11-13 · [next 16.3.4 published package — why the dead key is silent rather than fatal](https://unpkg.com/next@16.3.4/dist/server/config.js) · 2026-08-31

#### experimental.ppr / export const experimental_ppr

**Removed in next.js 16.0.0** (2025-10-22)

The route-segment opt-in was removed: `export const experimental_ppr = true` is read nowhere in 16.x, so a page that still exports it is simply ignored. The **config key was not removed** — `experimental: { ppr }` is still declared on `NextConfig`, still accepted by the config validator, and still honoured by `checkIsAppPPREnabled` at every 16.x release including 16.3.4. The trap is the combination: `experimental: { ppr: 'incremental' }` validates cleanly and then enables partial prerendering for **no route at all**, because `checkIsRoutePPREnabled` returns `false` for anything that is not a boolean and there is no longer a per-route export to consult. Nothing breaks; PPR just silently never happens. Configure partial prerendering with the top-level `cacheComponents: true`, which is also the new name of `experimental.dynamicIO`.

*The stale belief:* That partial prerendering is enabled through the `experimental.ppr` flag plus a per-route `export const experimental_ppr = true`. The flag half still validates; the per-route half does nothing.

```ts
// Stale
// next.config.ts — validates, and enables PPR for zero routes
experimental: { ppr: 'incremental' }
// app/page.tsx — read by nothing in 16.x
export const experimental_ppr = true

// Current
// next.config.ts
const nextConfig: NextConfig = { cacheComponents: true }
```

> Do not tell readers this config key breaks the build — it does not, at any 16.x release. Next.js's own upgrade guide, shipped inside the package at 16.3.4 as `dist/docs/01-app/02-guides/upgrading/version-16.md`, states that 16 "removes the experimental Partial Prerendering (PPR) flag and configuration options"; the same tarball ships `dist/server/lib/experimental/ppr.js` implementing it and a `configSchema` that accepts it. Verified by executing the shipped validator: at both 16.0.0 and 16.3.4, `experimental.ppr` set to `'incremental'` and to `true` are ACCEPTED, while the poison controls `experimental.pprXYZ` (unrecognized_keys) and `experimental.ppr: 'nope'` (invalid_union) are rejected — so the check can fail. The Suspense structure around a dynamic subtree is unchanged; models generally get that part right.

*Reproduced against: **Claude Opus 5** (S1), **Claude Sonnet 5** (S1) — next.js/v1, 2026-08-31.*

Source: [Next.js docs — Upgrading: Version 16 (states a removal the shipped package contradicts)](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25 · [next 16.3.4 shipped package — dist/server/lib/experimental/ppr.d.ts](https://unpkg.com/next@16.3.4/dist/server/lib/experimental/ppr.d.ts) · 2026-08-31 · [next 16.3.4 shipped package — NextConfig still declares experimental.ppr](https://unpkg.com/next@16.3.4/dist/server/config-shared.d.ts) · 2026-08-31 · [next 16.0.0 shipped package — the release said to have removed it still declares experimental.ppr](https://unpkg.com/next@16.0.0/dist/server/config-shared.d.ts) · 2025-10-22

#### `middleware.ts`

**Renamed in next.js 16.0.0** (2025-10-22)

`middleware.ts` is renamed to `proxy.ts`, and the named export `middleware` to `proxy`. The old file still works and warns; removal is planned. The rename shipped in 16.0.0 — not 15.5 — so renaming the file on a 15.x project means nothing picks it up and the route gate silently stops running.

*The stale belief:* That the route gate lives in `middleware.ts`, or that the rename landed in 15.5.

```ts
// Stale
// middleware.ts
export function middleware(request: NextRequest) { /* ... */ }

// Current
// proxy.ts
export function proxy(request: NextRequest) { /* ... */ }
export const config = { matcher: ['/dashboard/:path*'] }
```

> Two things models do not tell you: the `proxy` runtime is nodejs and cannot be configured (keep `middleware.ts` if you need the edge runtime), and `skipMiddlewareUrlNormalize` is now `skipProxyUrlNormalize`.

*Reproduced against: **Claude Opus 5** (S4), **Claude Sonnet 5** (S3) — next.js/v1, 2026-08-31.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25

#### `experimental.prefetchInlining`

**Added in next.js 16.2.0** (2026-03-18)

Next.js 16 prefetches **per segment**: hovering one `<Link>` issues a separate request for each segment of the target route tree, which makes shared layouts cacheable across sibling routes but multiplies request volume. `experimental.prefetchInlining` bundles every segment of a route into a single prefetch response — one request per link — at the cost of duplicating shared layout data across responses. There is no `<Link>`-level prop for this; it is a config flag.

*The stale belief:* That the number of prefetch requests per link is not configurable, and that the only lever is turning prefetching off with `prefetch={false}`.

```ts
experimental: { prefetchInlining: true }
```

> Verified in the published packages: `prefetchInlining`, `cachedNavigations` and `appNewScrollHandler` are all absent from `dist/server/config-shared.d.ts` at 16.1.7 and present at 16.2.0 and 16.3.4. Still experimental at 16.3.4.

*Reproduced against: **Claude Opus 5** (S2) — next.js/v3-e, 2026-09-02.*

Source: [Next.js 16.2 release post — experimental.prefetchInlining](https://nextjs.org/blog/next-16-2) · 2026-03-18 · [next 16.3.4 published package — the experimental config key](https://unpkg.com/next@16.3.4/dist/server/config-shared.d.ts) · 2026-08-31

#### ImageResponse default font

**Default changed in next.js 16.2.0** (2026-03-18)

The default typeface used by `ImageResponse` when no font is supplied changed from Noto Sans to **Geist Sans**. The bundled default font file is `Geist-Regular.ttf`. Generated OG images render in Geist unless a `fonts` option says otherwise.

*The stale belief:* That an OG image with no `fonts` option renders in Noto Sans (the default from `@vercel/og`'s original bundle).

> Bisected in the published packages: `dist/compiled/@vercel/og/index.node.js` loads `noto-sans-v27-latin-regular.ttf` at 16.1.7 and `Geist-Regular.ttf` at 16.2.0 — two days apart. The same release made `ImageResponse` 2x-20x faster and widened CSS/SVG coverage.

*Reproduced against: **Claude Opus 5** (S2) — next.js/v2-a, 2026-09-02.*

Source: [Next.js 16.2 release post — Faster ImageResponse](https://nextjs.org/blog/next-16-2) · 2026-03-18 · [next 16.2.0 published package — the bundled default font](https://unpkg.com/next@16.2.0/dist/compiled/@vercel/og/index.node.js) · 2026-03-18 · [next 16.1.7 published package — the same line two days earlier](https://unpkg.com/next@16.1.7/dist/compiled/@vercel/og/index.node.js) · 2026-03-16

#### Link transitionTypes

**Added in next.js 16.2.0** (2026-03-18)

`next/link` accepts a `transitionTypes` prop — an array of strings passed to React's `addTransitionType` during the navigation Transition, so a View Transition can be styled differently per navigation. It is an App Router feature: the **Pages Router `Link` destructures the prop away and ignores it silently**, so a shared link component works in both routers without warnings. It is never forwarded to the underlying `<a>`, in either router, so it produces no unknown-DOM-attribute warning; in development a non-array value throws a prop-type error.

*The stale belief:* That `<Link>` has no per-navigation view-transition prop, so an unrecognised `transitionTypes` prop is spread onto the `<a>` element and React warns about an unknown DOM attribute.

```tsx
<Link href="/about" transitionTypes={['slide']}>About</Link>
```

> Verified in the published packages: absent from `dist/client/app-dir/link.d.ts` at 16.1.7, present at 16.2.0. At 16.3.4 the Pages Router `dist/client/link.js` destructures `transitionTypes` out of `restProps` and lists it in its dev-only prop guard, while the App Router `dist/client/app-dir/link.js` forwards it into `dispatchNavigateAction`.

*Reproduced against: **Claude Opus 5** (S2) — next.js/v2-a, 2026-09-02.*

Source: [Next.js 16.2 release post — transitionTypes Prop for next/link](https://nextjs.org/blog/next-16-2) · 2026-03-18 · [next 16.3.4 published package — the Pages Router Link discards the prop](https://unpkg.com/next@16.3.4/dist/client/link.js) · 2026-08-31 · [next 16.1.7 published package — the prop does not exist yet](https://unpkg.com/next@16.1.7/dist/client/app-dir/link.d.ts) · 2026-03-16

#### `images.maximumDiskCacheSize`

**Added in next.js 16.1.7** (2026-03-16)

The optimized-image disk cache is bounded, and by default the bound is **50% of the free space on the volume holding the cache directory**, measured once at startup with `fs.statfs`. Set `images.maximumDiskCacheSize` to a byte count to cap it, or to `0` to disable disk caching entirely. When the cache exceeds the limit, least-recently-used optimized images are evicted until it is under the limit.

*The stale belief:* That the optimized-image cache in `.next/cache/images` grows without limit and the only controls are `minimumCacheTTL` or a custom cache handler.

```ts
images: { maximumDiskCacheSize: 1_000_000_000 } // 1 GB; 0 disables the disk cache
```

> Shipped in a **patch** release, 16.1.7, two days before the 16.2.0 minor. Verified in the published packages: `maximumDiskCacheSize` is absent from `imageConfigDefault` at 16.1.6 and present (as `undefined`) at 16.1.7, where `dist/server/lib/disk-lru-cache.external.js` first appears. An unrecognised key under `images` is fatal, not a warning: `normalizeNextConfigZodErrors` sets `shouldExit` for any issue whose path starts at `images`, so a guessed name such as `images.maximumCacheSize` exits the build.

*Reproduced against: **Claude Opus 5** (S1) — next.js/v2-a, 2026-09-02.*

Source: [Next.js docs — Image component, maximumDiskCacheSize](https://nextjs.org/docs/app/api-reference/components/image) · 2026-09-02 · [next 16.3.4 published package — the default sizing](https://unpkg.com/next@16.3.4/dist/server/lib/disk-lru-cache.external.js) · 2026-08-31 · [next 16.1.7 published package — the key enters imageConfigDefault](https://unpkg.com/next@16.1.7/dist/shared/lib/image-config.js) · 2026-03-16

#### `images.maximumResponseBody`

**Added in next.js 16.1.5** (2026-01-26)

The default image loader refuses a source image whose response body exceeds **50 MB** (`maximumResponseBody: 50000000`). The optimizer streams the upstream response and, once the running total passes the limit, throws an image error carrying HTTP **413** — the image 404s/413s rather than being optimized. Lower it (e.g. `5_000_000`) on memory-constrained servers.

*The stale belief:* That `next/image` will fetch and optimize a remote source image of any size, and that the only failure mode for a large image is slowness or an out-of-memory crash.

```ts
images: { maximumResponseBody: 5_000_000 }
```

> The official docs' version-history table dates this to **v16.1.2**; the published packages contradict it by three patch releases. There is no occurrence of `maximumResponseBody` in 16.1.2's `image-config.js`, `config-shared.js`, `config-schema.js` or `image-optimizer.js`, nor in 16.1.4; 16.1.5 has it in `imageConfigDefault` and three times in `image-optimizer.js`. This is the second time vendor release material has been wrong about its own release in this dataset (better-auth 1.1.0, JOURNAL/027) and the first time the error is in a docs version table rather than a changelog.

*Reproduced against: **Claude Opus 5** (S2) — next.js/v3-e, 2026-09-02.*

Source: [Next.js docs — Image component, maximumResponseBody](https://nextjs.org/docs/app/api-reference/components/image) · 2026-09-02 · [next 16.3.4 published package — the limit is enforced while streaming](https://unpkg.com/next@16.3.4/dist/server/image-optimizer.js) · 2026-08-31 · [next 16.1.5 published package — the release the key actually appears in](https://unpkg.com/next@16.1.5/dist/shared/lib/image-config.js) · 2026-01-26 · [next 16.1.4 published package — absent one release earlier](https://unpkg.com/next@16.1.4/dist/shared/lib/image-config.js) · 2026-01-19

#### `images.minimumCacheTTL`

**Default changed in next.js 16.0.0** (2025-10-22)

The default changed from 60 seconds to 14400 seconds (4 hours). Nothing errors; images just revalidate far less often than a model trained on 15.x will tell you.

*The stale belief:* That the default image cache TTL is 60 seconds.

```ts
images: { minimumCacheTTL: 60 }   // if you need the old behaviour back
```

*Reproduced against: **Claude Sonnet 5** (S2) — next.js/v1, 2026-08-31.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25

#### catchError (next/error)

**Added in next.js 16.2.0** (2026-03-18)

`next/error` exports `catchError`, which wraps a fallback component into a component-level error boundary usable anywhere in a Client Component tree — finer-grained than the route-level `error.js` convention. Its fallback receives the call-site props plus an `ErrorInfo` second argument (`{ error, reset, retry }`). Prefer it over a hand-rolled React class boundary: Next's own boundary re-throws the framework's control-flow errors, so `redirect()` and `notFound()` still work inside it, while a naive user boundary catches them and renders the fallback instead.

*The stale belief:* That the framework offers no component-level error boundary and the answer is a hand-written React class boundary or the `react-error-boundary` package.

**The code below needs next.js 16.3.0 or later.** Between 16.2.0 and 16.3.0 this correction does not apply — see the note.

```tsx
'use client'
import { catchError, type ErrorInfo } from 'next/error'

function Fallback(props: { title: string }, { error, retry }: ErrorInfo) {
  return <button onClick={() => retry()}>{props.title}</button>
}

export default catchError(Fallback)
```

> Shipped in 16.2.0 as `unstable_catchError` and stabilised to `catchError` in 16.3.0; `next/error.d.ts` at 16.1.6 exports only the Pages Router error page. Client module graph only — it cannot be imported in `proxy` or `instrumentation`.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Next.js 16.2 release post — unstable_catchError()](https://nextjs.org/blog/next-16-2) · 2026-03-18 · [next 16.3.4 published package — catchError declaration](https://unpkg.com/next@16.3.4/dist/client/components/catch-error.d.ts) · 2026-08-31 · [next 16.3.4 published package — the framework boundary re-throws router errors](https://unpkg.com/next@16.3.4/dist/client/components/error-boundary.js) · 2026-08-31

#### error.tsx retry prop

**Added in next.js 16.2.0** (2026-03-18)

An App Router `error.tsx` component is passed `{ error, reset, retry }`. `reset()` only clears the boundary's error state and re-renders the children — it does **not** re-run the server render, so an error thrown while a Server Component awaited data comes straight back. `retry()` is the one that recovers from a data error: it calls the router's `refresh()` and `reset()` inside a `startTransition`. Wire a 'Try again' button to `retry`, not to `reset`.

*The stale belief:* That `error.tsx` receives only `{ error, reset }`, and that `reset()` re-fetches. Models that know `reset()` does not re-fetch hand-roll the fix — `useRouter().refresh()` plus `reset()` inside `startTransition()` — which is exactly what `retry` now is.

**The code below needs next.js 16.3.0 or later.** Between 16.2.0 and 16.3.0 this correction does not apply — see the note.

```tsx
// Stale
'use client'
export default function Error({ error, reset }) {
  return <button onClick={() => reset()}>Try again</button> // re-renders, does not re-fetch
}

// Current
'use client'
import type { ErrorInfo } from 'next/error'
export default function Error({ error, retry }: ErrorInfo) {
  return <button onClick={() => retry()}>Try again</button>
}
```

> Shipped in 16.2.0 as `unstable_retry` and stabilised to `retry` in 16.3.0 — code written against 16.2.x needs the prefix, code written against 16.3.x must not have it. Bisected in the published packages: 16.1.6 declares `{ error, reset? }`, 16.2.0 declares `{ error, reset, unstable_retry }`, 16.3.4 declares `{ error, reset, retry }`.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Next.js 16.2 release post — unstable_retry() in error.tsx](https://nextjs.org/blog/next-16-2) · 2026-03-18 · [next 16.3.4 published package — ErrorBoundaryHandler](https://unpkg.com/next@16.3.4/dist/client/components/error-boundary.js) · 2026-08-31 · [next 16.1.6 published package — the same type one release earlier](https://unpkg.com/next@16.1.6/dist/client/components/error-boundary.d.ts) · 2026-01-27

#### `images.qualities`

**Default changed in next.js 16.0.0** (2025-10-22)

The default changed from allowing all qualities to `[75]`. A `quality` prop outside the list is **coerced to the closest allowed value** — it is not rejected — so `quality={90}` silently serves 75.

*The stale belief:* Either that any quality value is served, or that an unlisted quality is rejected with a 400. Both are wrong; it is coerced.

```ts
images: { qualities: [50, 75, 100] }
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25

#### local images with query strings / local IP optimization

**Stricter in next.js 16.0.0** (2025-10-22)

A local image `src` carrying a query string now requires an `images.localPatterns` entry with a `search` pattern, to prevent enumeration attacks. Separately, optimizing images on local IPs is blocked unless `images.dangerouslyAllowLocalIP` is set.

```ts
images: {
  localPatterns: [{ pathname: '/assets/**', search: '?v=1' }],
  dangerouslyAllowLocalIP: true,   // private networks only; understand the SSRF risk
}
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25

#### unstable_rootParams() / devIndicators options

**Removed in next.js 16.0.0** (2025-10-22)

`unstable_rootParams()` was removed, as were the `devIndicators` options `appIsrStatus`, `buildActivity` and `buildActivityPosition`.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25 · [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25

### Deprecated, or a better API now exists

Works today. It is the older idiom, and some of it is scheduled for removal.

#### `cacheLife / cacheTag`

**Renamed in next.js 16.0.0** (2025-10-22)

`cacheLife` and `cacheTag` are stable and lost the `unstable_` prefix. Aliased imports should be updated. `unstable_cache` itself still exists and still works — it is simply no longer the current idiom.

```ts
// Stale
import { unstable_cacheLife as cacheLife, unstable_cacheTag as cacheTag } from 'next/cache'

// Current
import { cacheLife, cacheTag } from 'next/cache'

export async function getProducts() {
  'use cache'
  cacheLife('hours')
  cacheTag('products')
  return db.product.findMany()
}
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25

#### `images.domains`

**Deprecated in next.js 16.0.0** (2025-10-22)

`images.domains` is deprecated, not removed — use `remotePatterns`. Models overstate this in both directions; the accurate statement is deprecated-and-still-working.

```ts
images: { remotePatterns: [{ protocol: 'https', hostname: 'cdn.example.com' }] }
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25

#### `images.imageSizes`

**Default changed in next.js 16.0.0** (2025-10-22)

The value `16` was removed from the default `images.imageSizes` array, shrinking the generated `srcset`.

```ts
images: { imageSizes: [16, 32, 48, 64, 96, 128, 256, 384] }   // to keep 16px
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25

#### `images.maximumRedirects`

**Default changed in next.js 16.0.0** (2025-10-22)

The default for `images.maximumRedirects` changed from unlimited to 3.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25

#### scroll-behavior: smooth

**Behaviour changed in next.js 16.0.0** (2025-10-22)

Next.js no longer overrides a global `scroll-behavior: smooth` during SPA route transitions. Opt back into the old override with `data-scroll-behavior="smooth"` on the `html` element.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25

### Wrong facts about the library

Not code — versions, minimums and metadata that models state confidently and get wrong.

#### AGENTS.md shipped by next dev

**Added in next.js 16.0.0** (2025-10-22)

Next.js 16 tells you to install an `AGENTS.md` block, which `next dev` writes and re-adds by itself. The framework ships a warning to coding agents that their priors about it are stale — the same claim this Index makes empirically, per model and per date.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25

#### Node.js and TypeScript minimums

**New requirement in next.js 16.0.0** (2025-10-22)

Next.js 16 requires Node.js 20.9.0+ (Node 18 is no longer supported) and TypeScript 5.1+. Browser floor: Chrome/Edge/Firefox 111+, Safari 16.4+.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Next.js docs — Upgrading: Version 16](https://nextjs.org/docs/app/guides/upgrading/version-16) · 2026-08-25

## Not corrections — recorded for honesty

Claims seen in a run but not yet verified against a primary source. Never treated as findings:

- Prediction P1 said all four Sonnet 5 and Fable 5 draws would reach experimental.clientSegmentCache. Three of four did; this draw's twin v3-d did not, answering "No" and naming the key only to say it is gone. The prediction is falsified on the fourth draw, and the two subjects split the same way internally: both Sonnet draws fail the surface, one Fable draw of two fails it. Whether that is a subject difference or two coin flips cannot be read from four draws. *(open since 2026-09-02)*
- This draw and next.js/v3-a produce the same wrong configuration with opposite epistemics - one at 60 percent with the correct counterfactual spelled out, one asserting a schema validation that does not exist. The Index scores both S2 because the artefact is identical, and the severity scale has no way to say that one of them warned its reader. Whether that is the right treatment or a gap in the scale is unresolved; JOURNAL/032 declined to add a fifth level and this is a second kind of pressure on the same edge. *(open since 2026-09-02)*
- This is the fourth battery in which the non-charging -b twin held the better answer (HARNESS.md records three: better-auth/v2, and two before it). The rule that the second draw charges nothing was chosen to keep replication from inflating counts, and it is now systematically discarding the better-informed draw. That is the correct trade for the finding count, but the site's per-subject picture is built from arms selected by a rule that is uncorrelated with which draw was right. *(open since 2026-09-02)*
- Both Fable draws state an identical cutoff and an identical boundary while giving opposite answers on the probe surface. If the self-report is stable for this subject and the answer is not, then the boundary readings the Index publishes for Fable 5 x next.js are more precise than they are informative about what the subject will actually write. Needs a third and fourth draw of something before it is more than an observation about two. *(open since 2026-09-02)*
- Fable 5's library knowledge reaching its own cutoff while Opus 5 — stated cutoff four months later — stops seven months short is now the second instance of the same dissociation, after zod. Is it a property of the model or of these two libraries? *(open since 2026-08-31)*
- The severity scale has no level for 'working code the framework now supersedes'. Two of this battery's nine probes landed there. Either add one or state on the method page that capability probes of this kind are recorded and never charged. *(open since 2026-09-02)*
- Every draw of four reached for experimental.clientSegmentCache, removed in a patch 16.0.3 and inside all three subjects' windows. It wants a charging battery against Sonnet 5 and Fable 5, whose arms here charge nothing. *(open since 2026-09-02)*
- Three batteries running, the -b twin has held the better answer on at least one probe. Is the -a/-b assignment doing any work, or should the charging arm be the one that answers first, or a merge of the two? Changing it would break comparability with everything already published. *(open since 2026-09-02)*
- Is the reversal on clientSegmentCache knowledge or wording? v2's task 8 asked whether reducing prefetch requests was configurable "and if so, how? Write whatever is needed", and got the dead key from four draws of four across three subjects. v3's task 1 demands a one-word yes or no before any explanation, and got a correct denial from both Opus draws. Same subject, same surface, same day, opposite outcomes. If the wording is what moved it, then a probe that invites config produces config, and several charged findings in this dataset may be measuring the invitation. *(open since 2026-09-02)*
- The Index has now caught right-about-the-removal-wrong-about-the-replacement at valibot and next.js. Both were found by a capability probe that asks how to do a thing rather than whether an API exists. Whether that category is common enough to be a product claim, or is two instances, is not established. *(open since 2026-09-02)*
- The Opus twins agreed on their stated cutoff and on the whole clientSegmentCache surface, and disagreed on task 3, where one leaned to a cap and one to no cap. The Sonnet twins in the same battery agreed on the library and disagreed on their own cutoff. Whether duplication is buying a reading of the subject or a reading of the probe differs by pair, and the index reports one spread for both. *(open since 2026-09-02)*
- The cutoff self-report has now split between blind twins in two libraries (zod/v4, next.js/v3). Two draws of two batteries is not a rate. The index publishes stated cutoffs as if they were a property of the subject; they are a property of the draw, and nothing on the site says so yet. *(open since 2026-09-02)*
- This subject's next.js boundary now has four readings across three batteries (15.0.0, 15.0.0, 15.3.0, 15.5.0). JOURNAL/030(c) read v1-vs-v2 agreement as evidence that a battery does not move a boundary. Whether v3 moved it, or whether v1 and v2 happened to agree, cannot be settled from four points. *(open since 2026-09-02)*
- Recording a refused cutoff as a single date loses information. This draw gave a range and a reason; the schema stores one string. The fairness rule needs a comparable value, but a range with a stated basis is the honest datum and the site cannot show it. *(open since 2026-09-02)*

---

*Findings, code and citations: `data/next.js/` — one JSON file and one write-up per model, each finding carrying the release that broke the belief, its publication date and a verbatim quote from the primary source. Corrections: `data/next.js/facts.json`. This file is generated by `tools/build-corrections.mjs`; if the prose and the data ever disagree, that is a bug in the generator, not a stale pack.*

==============================================================================
CORRECTION PACK: prisma (https://stalepriors.com/corrections/prisma.md)

# prisma correction pack · for projects on prisma@7 / @prisma/client@7


## What we actually measured

5 Claude models were asked for idiomatic prisma code with no tools, purely from training knowledge. 50 reproduced failures across 22 runs, each verified against the release that broke the belief.

| Model | Stated cutoff | prisma version attribution stops | Lag inside the window |
|---|---|---|---|
| Claude Sonnet 5 | 2026-01 | 6.0.0 · 2024-11-28 | ~14 months |
| Claude Opus 5 | 2026-05 | 6.7.0 · 2025-04-29 | ~13 months |
| Claude Fable 5 | 2026-01 | 6.7.0 · 2025-04-29 | ~8 months |
| Claude Fable 5.1 | 2026-06 | 7.0.0 · 2025-11-19 | ~7 months |

A recent cutoff is not a defence. Every model here loses track of this library's release history well before the date it states as its own cutoff, and the stopping points cluster far tighter than the cutoffs do.

Read that column precisely. It is the newest prisma release whose contents the model can correctly **attribute to that release** — not the newest prisma feature it knows. Past that point a model will often write working code with a newer API while naming the wrong release for it, and that guess runs *early* — it names a release older than the one that shipped the feature. So the question this pack answers is not "does the model know this API" but "can it be trusted about which version the API arrived in" — which is the question that matters when you are pinned to a version.

Latest prisma is **7.10.0** (verified 2026-09-06). Separately from the corrections below, 3 of 22 runs recorded a version fact — the model named a current prisma version from memory and was behind. If a model states a version without checking, assume it is behind and check the registry.

## How to read an entry

Every entry ends with a *Reproduced against* line. Where it names models, we have the generated code that got it wrong, dated, with the model's own words in the run write-up. Where it says no model yet, the correction is verified from the release notes but nothing has been probed for it — it is a fix, not a measurement, and the pack says so rather than blurring the two.

The section an entry sits in is the worst case if you act on the stale belief. The severity in brackets after a model's name is what that particular model's output actually did, which can be milder — a model can hold the wrong belief and still, on the day, write code that runs.

## The corrections

### Breaks the build, or throws at runtime

Act on the stale belief here and the code does not run. Fix these first.

#### prisma migrate diff --from-schema-datamodel

**Renamed in prisma 7.0.0** (2025-11-19)

`prisma migrate diff` renamed its inputs. `--from/to-schema-datamodel` became `--from/to-schema`; `--from/to-url` and `--from/to-schema-datasource` became `--from/to-config-datasource`, which reads the datasource out of `prisma.config.ts`. Diffing two different URLs is no longer possible, because only one config applies at a time.

*The stale belief:* That you diff a schema file against a live database with `--from-schema-datamodel ./prisma/schema.prisma --to-url $DATABASE_URL`.

```bash
# Stale
npx prisma migrate diff \
  --from-schema-datamodel prisma/schema.prisma \
  --to-url "$DATABASE_URL" \
  --script

# Current
npx prisma migrate diff \
  --from-schema prisma/schema.prisma \
  --to-config-datasource \
  --script
```

*Reproduced against: **Claude Fable 5** (S1), **Claude Opus 5** (S1), **Claude Sonnet 5** (S1) — prisma/v1, 2026-08-31.*

Source: [Prisma 7.0.0 release notes — Removal of prisma migrate flags](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### `engineType`

**Removed in prisma 7.0.0** (2025-11-19)

The client engines are gone: `LibraryEngine` (`engineType = "library"`), `BinaryEngine` (`engineType = "binary"`), `DataProxyEngine` and `ReactNativeEngine`, and with them the `PRISMA_CLIENT_ENGINE_TYPE`, `PRISMA_QUERY_ENGINE_BINARY`, `PRISMA_QUERY_ENGINE_LIBRARY` and `PRISMA_CLI_QUERY_ENGINE_TYPE` environment variables. Prisma 7's query compiler is a WebAssembly module inside the client.

*The stale belief:* That query execution goes through a Rust engine binary you select with `engineType` and can tune with `PRISMA_*` environment variables.

```prisma
// Stale
generator client {
  provider   = "prisma-client-js"
  engineType = "binary"
}

// Current
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}
```

> `generator.runtime = "react-native"` was removed in the same release.

*Reproduced against: **Claude Fable 5** (S2), **Claude Sonnet 5** (S2) — prisma/v1, 2026-08-31.*

Source: [Prisma 7.0.0 release notes — Removed Client Engines](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### generator client { output }

**New requirement in prisma 7.0.0** (2025-11-19)

`output` is required in the generator block. Prisma 7 does not generate the client into `node_modules` at all, so a generator block without an output path fails rather than defaulting.

*The stale belief:* That `prisma generate` writes into `node_modules/.prisma/client` and `output` is an optional advanced setting.

```prisma
// Stale
generator client {
  provider = "prisma-client-js"
}

// Current
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}
```

> The vendor recommends generating inside your own source tree (for example `src/`) so the output is handled by your existing tooling like any other code.

*Reproduced against: **Claude Fable 5** (S1), **Claude Sonnet 5** (S1) — prisma/v1, 2026-08-31.*

Source: [Upgrade to Prisma ORM 7 — Schema changes](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7) · [Prisma 7.0.0 release notes — Generated Client and types move out of node_modules](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### import { PrismaClient } from '@prisma/client'

**Behaviour changed in prisma 7.0.0** (2025-11-19)

Import the client from your generated output path, not from `@prisma/client`. This follows from `output` being required: the generated client is now a file in your repository.

*The stale belief:* That `@prisma/client` is the import path — true from Prisma 2 through 6.

```ts
// Stale
import { PrismaClient } from '@prisma/client'

// Current
import { PrismaClient } from './generated/prisma/client'
```

> The exact specifier depends on where you set `output` and where the importing file lives. AUDIT 2026-09-02 (JOURNAL/038): it also depends on your module resolution. Under `moduleResolution: node16` or `nodenext` — the setting an ESM project takes, and LF19 requires `"type": "module"` — the extensionless form is TS2835 and the import must be written `'./generated/prisma/client.js'`. Under `bundler` (Next.js, Vite) the extensionless form is correct. Both were compiled on 7.0.0 and 7.10.0.

*Reproduced against: **Claude Fable 5** (S1), **Claude Sonnet 5** (S1) — prisma/v1, 2026-08-31.*

Source: [Upgrade to Prisma ORM 7 — Schema changes](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7)

#### new PrismaClient()

**Removed in prisma 7.0.0** (2025-11-19)

Constructing the client with no arguments is no longer supported. Prisma 7 requires either a driver adapter or an `accelerateUrl`. `new PrismaClient()` and `new PrismaClient({})` were both removed in 7.0.0; 7.1.0 added a dedicated error message for the no-argument case, so the failure is a runtime throw at construction, not a type error you will notice in review.

*The stale belief:* That the client reads the datasource out of `schema.prisma` and needs nothing at construction — true for the whole of Prisma 1 through 6.

```ts
// Stale
import { PrismaClient } from '@prisma/client'

const prisma = new PrismaClient()

// Current
import { PrismaClient } from './generated/prisma/client'
import { PrismaPg } from '@prisma/adapter-pg'

const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })
export const prisma = new PrismaClient({ adapter })
```

> The adapter package depends on the database: `@prisma/adapter-pg` for Postgres, `@prisma/adapter-better-sqlite3` for SQLite, `@prisma/adapter-mariadb` for MySQL/MariaDB.

*Reproduced against: **Claude Fable 5** (S1), **Claude Sonnet 5** (S1) — prisma/v1, 2026-08-31.*

Source: [Prisma 7.0.0 release notes — Prisma Client changes](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19 · [Upgrade to Prisma ORM 7 — Driver adapters](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7)

#### package.json prisma key

**Removed in prisma 7.0.0** (2025-11-19)

The `prisma` key in `package.json` is no longer read. Schema path and seed command move to `prisma.config.ts` (`schema` and `migrations.seed`).

*The stale belief:* That the seed script and a custom schema path are declared in a `prisma` block in `package.json` — the documented location since 2.18.

```jsonc
// Stale
{
  "prisma": {
    "schema": "./custom-path/schema.prisma",
    "seed": "tsx ./prisma/seed.ts"
  }
}

// Current
// Current — the key is not read. Declare these in prisma.config.ts instead:
//   export default defineConfig({
//     schema: 'prisma/schema.prisma',
//     migrations: { seed: 'tsx prisma/seed.ts' },
//   })
```

*Reproduced against: **Claude Fable 5** (S1), **Claude Sonnet 5** (S1) — prisma/v1, 2026-08-31.*

Source: [Prisma 7.0.0 release notes — Removed support for prisma keyword in package.json](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### prisma generate --no-engine

**Removed in prisma 7.0.0** (2025-11-19)

`prisma generate` no longer accepts `--no-engine`, `--data-proxy`, `--accelerate` or `--allow-no-models`. The first three existed to strip or swap the Rust query engine, which Prisma 7 does not ship at all.

*The stale belief:* That `prisma generate --no-engine` is the way to shrink a serverless bundle — the standard Accelerate/edge deployment advice for v5 and v6.

```bash
# Stale
npx prisma generate --no-engine

# Current
npx prisma generate
```

*Reproduced against: **Claude Fable 5** (S1), **Claude Sonnet 5** (S1) — prisma/v1, 2026-08-31.*

Source: [Prisma 7.0.0 release notes — Removal of prisma generate flags](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### `prisma.config.ts`

**New requirement in prisma 7.0.0** (2025-11-19)

`prisma.config.ts` is required for any project that runs introspection or migrations. The datasource URL lives there, not in `schema.prisma`. The file itself was introduced as opt-in in 6.18.0 and became mandatory in 7.0.0.

*The stale belief:* That project configuration is split between `schema.prisma` and a `prisma` key in `package.json`, with no config file in the picture.

```ts
import 'dotenv/config'
import { defineConfig, env } from 'prisma/config'

export default defineConfig({
  schema: 'prisma/schema.prisma',
  migrations: { seed: 'tsx prisma/seed.ts' },
  datasource: { url: env('DATABASE_URL') },
})
```

*Reproduced against: **Claude Fable 5** (S1), **Claude Sonnet 5** (S1) — prisma/v1, 2026-08-31.*

Source: [Prisma 7.0.0 release notes — Schema and config file updates](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19 · [Prisma 6.18.0 release notes — prisma init now creates a prisma.config.ts automatically](https://github.com/prisma/prisma/releases/tag/6.18.0) · 2025-10-22

#### datasource db { url }

**Removed in prisma 7.0.0** (2025-11-19)

`url` and `shadowDatabaseUrl` are configured in `prisma.config.ts` in Prisma 7, and `directUrl` has been removed outright. If you used `directUrl` for migrations, put that value in the config file's `url` — that is the connection string the CLI uses for migrations.

*The stale belief:* That the datasource block in `schema.prisma` carries `url`, `directUrl` and `shadowDatabaseUrl`, read from `.env` via `env()`.

```prisma
// Stale
datasource db {
  provider          = "postgresql"
  url               = env("DATABASE_URL")
  directUrl         = env("DIRECT_URL")
  shadowDatabaseUrl = env("SHADOW_URL")
}

// Current
datasource db {
  provider = "postgresql"
}

// and in prisma.config.ts:
//   datasource: { url: env('DATABASE_URL'), shadowDatabaseUrl: env('SHADOW_URL') }
```

*Reproduced against: **Claude Opus 5** (S3) — prisma/v1, 2026-08-31.*

Source: [Prisma 7.0.0 release notes — Schema changes](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### driver adapter class names

**Renamed in prisma 7.0.0** (2025-11-19)

The driver adapter classes were renamed to a consistent casing in 7.0.0: `PrismaBetterSQLite3` -> `PrismaBetterSqlite3`, `PrismaD1HTTP` -> `PrismaD1Http`, `PrismaLibSQL` -> `PrismaLibSql`, `PrismaNeonHTTP` -> `PrismaNeonHttp`.

*The stale belief:* The v6 spellings, which are what any model that learned driver adapters before 7.0.0 will emit.

```ts
// Stale
import { PrismaBetterSQLite3 } from '@prisma/adapter-better-sqlite3'

// Current
import { PrismaBetterSqlite3 } from '@prisma/adapter-better-sqlite3'
```

*Reproduced against: **Claude Opus 5** (S1) — prisma/v1, 2026-08-31.*

Source: [Prisma 7.0.0 release notes — Driver Adapter naming updates](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### prisma.config.ts engine key

**Removed in prisma 7.0.0** (2025-11-19)

The `engine: 'js' | 'classic'` and `adapter` keys in `prisma.config.ts` were removed in 7.0.0. They existed only in the 6.18.0-6.19.x window, where the config file was opt-in and `engine: "classic"` selected the Rust engine that 7.0.0 deleted.

*The stale belief:* That a Prisma config file needs an `engine` key, and that `adapter` is configured there rather than passed to the client constructor.

```ts
// Stale
export default defineConfig({
  engine: 'classic',
  datasource: { url: env('DATABASE_URL') },
})

// Current
export default defineConfig({
  datasource: { url: env('DATABASE_URL') },
})
```

> This key is a dating fingerprint: code containing it was learned from a release published between 2025-10-22 and 2025-11-19, a 28-day window.

*Reproduced against: **Claude Opus 5** (S1) — prisma/v1, 2026-08-31.*

Source: [Prisma 7.0.0 release notes — Schema and config file updates](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19 · [Prisma 6.18.0 release notes — Support for defining your datasource in prisma.config.ts](https://github.com/prisma/prisma/releases/tag/6.18.0) · 2025-10-22

#### @@index([...], include: [...])

**Added in prisma 7.4.0** (2026-02-11)

Prisma's `@@index` has **no `include:` argument** — there is no schema-level way to declare a PostgreSQL covering index (`CREATE INDEX ... INCLUDE (...)`). `@@unique` likewise has no `nullsNotDistinct:` argument. Both are rejected by the schema validator with `No such argument.` at 7.4.0 and at 7.10.0. This entry exists because 7.4.0 *did* add a new `@@index`/`@@unique` argument — `where:` (LF26) — and a model that has absorbed that fact can over-extend it into a family of index arguments that were never added.

*The stale belief:* That because Prisma 7.4 extended `@@index`/`@@unique` with index-shaping arguments, it also accepts `include:` for covering-index payload columns, or `nullsNotDistinct:` on `@@unique`.

```prisma
// Stale
model User {
  id    Int    @id @default(autoincrement())
  email String
  name  String

  @@index([email], include: [name])
}

// Current
// There is no schema-level covering index. Declare the plain index and add the
// INCLUDE clause in SQL, or widen the index key if the payload column is small.
model User {
  id    Int    @id @default(autoincrement())
  email String
  name  String

  @@index([email, name])
}
```

> VERIFIED BY EXECUTION 2026-09-05. `@@index([email], include: [name])` and `@@unique([email], nullsNotDistinct: true)` are each rejected by `prisma validate` with `No such argument.` at prisma@7.4.0 and at prisma@7.10.0. Same run, same file, the only difference being the argument name: `where:` validates and `include:`/`nullsNotDistinct:` do not, so the rejection is about the argument and not about the schema around it. This is a NEGATIVE claim in the machine-checkable form (the tailwindcss LF30 / better-auth LF10 shape): the assertion is that the argument does not exist, and it is checked by the shipped validator's own enumeration of what it accepts rather than by the absence of a sentence in a changelog.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [prisma 7.10.0, shipped package — `prisma validate` on the stale_code schema above](https://registry.npmjs.org/prisma/-/prisma-7.10.0.tgz) · [Prisma 7.4.0 release notes — Partial Indexes (Filtered Indexes) Support](https://github.com/prisma/prisma/releases/tag/7.4.0) · 2026-02-11

#### `@prisma/client-runtime-utils`

**New requirement in prisma 7.0.0** (2025-11-19)

If you stay on the `prisma-client-js` provider in Prisma 7 while using the now-required `output` option, you must install `@prisma/client-runtime-utils` as well. It is a new package with no v6 equivalent, so nothing trained before 2025-11-19 will mention it.

*The stale belief:* That `prisma` and `@prisma/client` are the only two packages a Prisma project needs.

```bash
npm install @prisma/client-runtime-utils   # prisma-client-js users only
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Prisma 7.0.0 release notes — Generated Client and types move out of node_modules](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### /wasm export path

**Renamed in prisma 7.0.0** (2025-11-19)

For `prisma-client-js` users, the `/wasm` export was renamed to `/edge`, and `/edge` changed meaning: it now means edge JS runtimes (Cloudflare, Vercel Edge) rather than Prisma Accelerate.

*The stale belief:* That `@prisma/client/edge` is the Accelerate entry point and `@prisma/client/wasm` is the edge-runtime one — the v5/v6 arrangement.

```ts
// Stale
import { PrismaClient } from '@prisma/client/wasm'

// Current
import { PrismaClient } from '@prisma/client/edge'
```

> SCOPED 2026-09-02 (JOURNAL/038), against both generators. `@prisma/client/edge` carries a `PrismaClient` export only for projects still on the `prisma-client-js` generator, whose output is written into `node_modules/.prisma/client` — `edge.d.ts` is nothing but `export * from '.prisma/client/edge'`. Generate with the `prisma-client` generator that LF4 and LF6 prescribe and `node_modules/.prisma` is never created, so this import fails with TS2305, no exported member. Both directions were generated and type-checked on 7.0.0. If you are on the current generator there is no `/edge` entry point at all: import from your own generated output and reach the edge runtime through a driver adapter. The rename this entry records is real — `/wasm` is gone from the 7.0.0 export map — but it is a rename inside the deprecated path.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Prisma 7.0.0 release notes — Miscellaneous](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19 · [@prisma/client 7.0.0, shipped package — edge.d.ts](https://registry.npmjs.org/@prisma/client/-/client-7.0.0.tgz)

#### `accelerateUrl`

**Added in prisma 7.0.0** (2025-11-19)

Accelerate users pass `accelerateUrl` to the constructor instead of an adapter, and keep the `withAccelerate()` extension. Do not pass a `prisma://` or `prisma+postgres://` URL to a driver adapter — `PrismaPg` expects a direct connection string and will fail on it.

*The stale belief:* That Accelerate is configured purely by putting the `prisma://` URL in `DATABASE_URL` and adding the extension, with no constructor option.

```ts
// Stale
const prisma = new PrismaClient().$extends(withAccelerate())

// Current
const prisma = new PrismaClient({
  accelerateUrl: process.env.DATABASE_URL!,
}).$extends(withAccelerate())
```

> CORRECTED 2026-09-02 (JOURNAL/038), against the generated client. The API claim holds — `accelerateUrl` is a declared constructor option — but the snippet as published did not compile under `strict`: `process.env.DATABASE_URL` is `string | undefined` and `accelerateUrl` is declared `string`, so a reader copying it got TS2345. The non-null assertion is now in the code. Reproduced identically on 7.0.0 and 7.10.0. The declaration also settles a second point the entry did not state: `accelerateUrl` and `adapter` are mutually exclusive (each is `?: never` in the other's arm of the union), so an Accelerate client does not take a driver adapter as well.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Prisma 7.0.0 release notes — For Prisma Accelerate users](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19 · [Upgrade to Prisma ORM 7 — Prisma Accelerate](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7) · [prisma 7.0.0, shipped package — generated PrismaClientOptions](https://registry.npmjs.org/prisma/-/prisma-7.0.0.tgz)

#### ESM and toolchain minimums

**New requirement in prisma 7.0.0** (2025-11-19)

Prisma 7 ships as an ES module and requires Node >= 20.19.0 and TypeScript >= 5.4.0. Set `"type": "module"` in `package.json`, and `module`/`moduleResolution` to `ESNext`/`bundler` in `tsconfig.json`.

*The stale belief:* That Prisma is CommonJS and drops into any Node project without touching `package.json` or `tsconfig.json`.

```jsonc
{
  "type": "module"
}
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Upgrade to Prisma ORM 7 — ESM support / Prerequisites](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7)

#### metrics preview feature

**Removed in prisma 7.0.0** (2025-11-19)

The deprecated `metrics` preview feature was removed in 7.0.0. Read pool metrics from the underlying driver instead — for example the `pg` pool.

*The stale belief:* That `previewFeatures = ["metrics"]` plus `prisma.$metrics.json()` is how you instrument a Prisma app.

```prisma
// Stale
generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["metrics"]
}
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Prisma 7.0.0 release notes — Deprecated metrics feature has been removed](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### new PrismaClient({ datasources })

**Removed in prisma 7.0.0** (2025-11-19)

The `datasources` constructor option is gone. Overriding the connection string at construction time is done by configuring the driver adapter you now have to pass anyway.

*The stale belief:* That `new PrismaClient({ datasources: { db: { url } } })` is how you point one client at a different database — the documented override for the whole v2-v6 era.

```ts
// Stale
const prisma = new PrismaClient({
  datasources: { db: { url: process.env.DATABASE_URL } },
})

// Current
const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })
const prisma = new PrismaClient({ adapter })
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Prisma 7.0.0 release notes — Prisma Client changes](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### new PrismaClient({ datasourceUrl })

**Removed in prisma 7.0.0** (2025-11-19)

The `datasourceUrl` constructor option, added in 5.2 as the shorthand for `datasources`, was removed in 7.0.0 along with it. Pass the connection string to the driver adapter instead.

*The stale belief:* That `datasourceUrl` is the current shorthand for overriding the connection string at runtime.

```ts
// Stale
const prisma = new PrismaClient({ datasourceUrl: process.env.DATABASE_URL })

// Current
const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })
const prisma = new PrismaClient({ adapter })
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Prisma 7.0.0 release notes — Prisma Client changes](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### prisma introspect

**Removed in prisma 7.0.0** (2025-11-19)

The deprecated `prisma introspect` command was removed in 7.0.0 — `prisma db pull` is the only spelling. `db pull` also lost its undocumented `--url` flag and its `--local-d1` flag.

*The stale belief:* That `prisma introspect` still exists as an alias, which it did (deprecated) from 3.0 through 6.x.

```bash
# Stale
npx prisma introspect

# Current
npx prisma db pull
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Prisma 7.0.0 release notes — Miscellaneous](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

### Runs, but is silently wrong

Nothing errors. The behaviour is simply not what a model trained earlier will tell you.

#### `@prisma/sqlcommenter-query-insights`

**Added in prisma 7.2.0** (2025-12-17)

Prisma ships a first-party SQLCommenter plugin. `@prisma/sqlcommenter-query-insights` appends query-insights metadata to statements as a trailing SQL comment, so queries seen in the database’s own statistics and log views can be attributed back to the application code that issued them. Its first stable release is 7.2.0. Before it existed the only honest answer was to write the interception yourself at the driver-adapter layer, which is what every draw in this battery produced.

*The stale belief:* That Prisma’s first-party observability surface is OpenTelemetry tracing (`@prisma/instrumentation`) and metrics only, that SQLCommenter has adapters for Knex/Sequelize/pg but not Prisma, and that the ORM-generated SQL is therefore unreachable from application code.

```ts
// Stale
// wrap the driver adapter by hand and append the comment yourself
class CommentingPool extends Pool {
  query(config, values, cb) {
    const suffix = sqlcommenterSuffix()
    if (typeof config === "string") config += suffix
    else if (config?.text) config = { ...config, text: config.text + suffix }
    return super.query(config, values, cb)
  }
}

// Current
// the first-party plugin, released with 7.2.0
// npm i @prisma/sqlcommenter-query-insights
```

> The correction here is deliberately the package name and nothing more. This Index has not driven the plugin against a database, so it states that the package exists, what it is for and when it shipped — all three read off the registry and the release notes — and does not put a configuration snippet in a subject’s mouth that it has not executed. The registry `time` map gives 7.2.0 on 2025-12-17 as the first stable version; the only earlier publishes are a `0.0.1` placeholder on 2025-12-04 and `7.2.0-dev.*` pre-releases.

*Reproduced against: **Claude Fable 5.1** (S2), **Claude Opus 5** (S2), **Claude Sonnet 5** (S2) — prisma/v5-a, 2026-09-06; prisma/v5-c, 2026-09-06; prisma/v5-e, 2026-09-06.*

Source: [Prisma ORM 7.2.0 release notes — SQL Commenter plugin](https://github.com/prisma/prisma/releases/tag/7.2.0) · 2025-12-17 · [npm registry metadata for @prisma/sqlcommenter-query-insights — first stable release 7.2.0, published 2025-12-17](https://registry.npmjs.org/@prisma/sqlcommenter-query-insights) · 2025-12-17

#### `queryPlanCacheMaxSize`

**Added in prisma 7.8.0** (2026-04-22)

The `PrismaClient` constructor accepts `queryPlanCacheMaxSize?: number`, which bounds the query plan cache. Passing `0` disables the cache entirely; omitting the option uses the default size. It is an ordinary documented optional property of the client options type — not an internal, and not an environment variable.

*The stale belief:* That the query plan cache is an internal detail of the query compiler with no user-facing size or disable knob, so the only lever on its memory use is reducing the number of distinct query shapes — and, in the stronger form, that passing `queryPlanCacheMaxSize` is an excess-property type error or makes the constructor throw on an unknown key.

```ts
// Stale
// the stronger form of the belief, offered when reviewing working code:
// "PrismaClient validates its options and throws on unknown keys,
//  so this line would fail at construction time"
const prisma = new PrismaClient({ adapter })

// Current
const prisma = new PrismaClient({
  adapter,
  queryPlanCacheMaxSize: 100, // 0 disables the cache entirely
})
```

> VERIFIED BY TYPE DECLARATION 2026-09-06. `@prisma/client` `runtime/client.d.ts` has no occurrence of `queryPlanCacheMaxSize` at 7.4.0, 7.5.0, 7.6.0 or 7.7.0, and declares it at 7.8.0 and 7.10.0 with a documentation comment and a usage example. The bisection matters here because the *cache* is older than the *option*: query plan caching is a 7.4.0 feature — it is the attribution anchor in `prompts/prisma.md` § v2 — so a model can know the cache exists and still be four releases behind on whether it can be sized.

*Reproduced against: **Claude Fable 5.1** (S2), **Claude Opus 5** (S2) — prisma/v4-a, 2026-09-06; prisma/v4-c, 2026-09-06.*

Source: [Prisma 7.8.0 release notes — Prisma Client features](https://github.com/prisma/prisma/releases/tag/7.8.0) · 2026-04-22 · [@prisma/client 7.8.0, shipped package — runtime/client.d.ts](https://registry.npmjs.org/@prisma/client)

#### prisma bootstrap

**Added in prisma 7.7.0** (2026-04-07)

The Prisma CLI has a `bootstrap` command that sequences the whole Prisma Postgres setup in one interactive flow: init or scaffold from one of ten starter templates, link to a database, install missing dependencies, run `migrate dev`, run `generate`, and run `db seed`. It detects project state and runs only the steps that are needed, prompts before each side-effecting step, and skips completed steps when re-run. It takes `--template`, and a non-interactive `--api-key` / `--database` form for CI.

*The stale belief:* That there is no single Prisma command that walks the whole setup, and that a new project always needs a hand-assembled sequence of `npm install`, `prisma init`, `prisma migrate dev`, `prisma generate` and `prisma db seed`.

```shell
# Stale
# offered as "the whole path", with the claim that no single command exists:
npm i -D prisma && npm i @prisma/client @prisma/adapter-pg pg
npx prisma init --db
npx prisma migrate dev --name init
npx prisma db seed

# Current
npx prisma@latest bootstrap
# with a starter template:
npx prisma@latest bootstrap --template nextjs
# non-interactive, for CI:
npx prisma@latest bootstrap --api-key "$PRISMA_API_KEY" --database "db_abc123"
```

> VERIFIED BY EXECUTION 2026-09-06. `prisma --help` was run from the shipped CLI at 7.4.0 through 7.10.0. `bootstrap   Bootstrap a Prisma Postgres project` is absent from the command table at 7.6.0 and present at 7.7.0, which pins the introducing release from the artifact. The workaround sequence in `stale_code` does work, so this is a false claim about what the CLI offers rather than broken code — S2.

*Reproduced against: **Claude Fable 5.1** (S2), **Claude Opus 5** (S2) — prisma/v4-a, 2026-09-06; prisma/v4-c, 2026-09-06.*

Source: [Prisma 7.7.0 release notes — `prisma bootstrap` command](https://github.com/prisma/prisma/releases/tag/7.7.0) · 2026-04-07 · [prisma 7.7.0, shipped package — output of `prisma --help`](https://registry.npmjs.org/prisma)

#### new PrismaPg(connectionString)

**Added in prisma 7.6.0** (2026-03-27)

`new PrismaPg(...)` accepts a bare PostgreSQL connection string as its first argument. The constructor signature widened from `pg.Pool | pg.PoolConfig` to `pg.Pool | pg.PoolConfig | string` in 7.6.0. The object form still works and is not deprecated; the point is that the string form is not an error.

*The stale belief:* That `PrismaPg` takes only a `pg.Pool` or a `pg.PoolConfig`-shaped object, so a bare connection string is a type error that has to be wrapped as `{ connectionString }`.

```ts
// Stale
// offered as a correction to working code:
const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })

// Current
// both of these compile at 7.6.0 and later:
const adapter = new PrismaPg(process.env.DATABASE_URL!)
const adapter2 = new PrismaPg({ connectionString: process.env.DATABASE_URL })
```

> VERIFIED BY TYPE DECLARATION 2026-09-06. `@prisma/adapter-pg` was installed at 7.4.0, 7.5.0, 7.6.0, 7.7.0, 7.8.0 and 7.10.0. `dist/index.d.ts` declares `constructor(poolOrConfig: pg.Pool | pg.PoolConfig, options?: PrismaPgOptions | undefined)` at 7.4.0 and 7.5.0, and `constructor(poolOrConfig: pg.Pool | pg.PoolConfig | string, options?: PrismaPgOptions | undefined)` at 7.6.0 through 7.10.0. The added union member is the whole change and it is visible in the published declaration file, so the introducing release is pinned by the artifact rather than by the note. The object form the stale belief insists on is itself correct code, so this is a false claim about a limit and not a broken replacement — S2.

*Reproduced against: **Claude Fable 5.1** (S2), **Claude Opus 5** (S2) — prisma/v4-a, 2026-09-06; prisma/v4-c, 2026-09-06.*

Source: [Prisma 7.6.0 release notes — Driver Adapters](https://github.com/prisma/prisma/releases/tag/7.6.0) · 2026-03-27 · [@prisma/adapter-pg 7.6.0, shipped package — dist/index.d.ts](https://registry.npmjs.org/@prisma/adapter-pg)

#### prisma postgres link

**Added in prisma 7.6.0** (2026-03-27)

The Prisma CLI has a `postgres` command **group**, and its first member is `prisma postgres link`, which connects an existing local project to an already-provisioned Prisma Postgres database. Before 7.6.0 there was no such command and attaching a project to an existing database was a manual `DATABASE_URL` edit. `prisma postgres --help` at 7.6.0 through 7.10.0 lists exactly one subcommand: `link`.

*The stale belief:* That the Prisma CLI has no command for attaching a project to an already-provisioned Prisma Postgres database, and that `prisma init --db` (which creates a new one) plus a hand-edited `.env` is the only route.

```shell
# Stale
# the workaround, still offered as though it were the only option:
# 1. copy the connection string out of the Prisma Console by hand
# 2. paste it into .env as DATABASE_URL
npx prisma db pull
npx prisma generate

# Current
npx prisma postgres link
# non-interactive:
npx prisma postgres link --api-key "$PRISMA_API_KEY" --database "db_abc123"
```

> VERIFIED BY EXECUTION 2026-09-06. `prisma --help` was run from the shipped CLI at 7.4.0, 7.5.0, 7.6.0, 7.7.0, 7.8.0 and 7.10.0 in a scratch directory. The `postgres` entry is absent from the command table at 7.5.0 and present at 7.6.0, which pins the introducing release without relying on the release note. `prisma postgres --help` at 7.6.0+ prints `link   Link a local project to a Prisma Postgres database` and no other subcommand — which is also what makes `prisma postgres branch` a safe poison rung. The workaround in `stale_code` does work, and that is what keeps this S2 rather than S1.

*Reproduced against: **Claude Fable 5.1** (S2), **Claude Opus 5** (S2) — prisma/v4-a, 2026-09-06; prisma/v4-c, 2026-09-06.*

Source: [Prisma 7.6.0 release notes — CLI](https://github.com/prisma/prisma/releases/tag/7.6.0) · 2026-03-27 · [prisma 7.6.0 and 7.10.0, shipped package — output of `prisma postgres --help`](https://registry.npmjs.org/prisma)

#### `statementNameGenerator`

**Added in prisma 7.6.0** (2026-03-27)

`@prisma/adapter-pg` exposes `statementNameGenerator`, a `PrismaPgOptions` callback of type `(query: SqlQuery) => string`. The returned string is passed as the `name` property to `pg.Client#query()`, which is what makes node-postgres cache the underlying prepared statement. The shipped declaration states the default explicitly: with no generator provided, prepared statements are not cached.

*The stale belief:* That the Prisma pg adapter issues every query unnamed with no supported way to change that, so node-postgres statement caching can never engage and the only route to prepared-statement reuse is running the hot query through a separate `pg` pool alongside Prisma.

```ts
// Stale
// offered as the only route:
// run the hot query through your own pg Pool, outside Prisma, so you can set a name
const pool = new Pool({ connectionString: process.env.DATABASE_URL })
await pool.query({ name: "hot-query", text: "SELECT ...", values: [] })

// Current
const adapter = new PrismaPg(process.env.DATABASE_URL!, {
  statementNameGenerator: (query) => "prisma_" + hashOf(query.sql),
})
```

> VERIFIED BY TYPE DECLARATION 2026-09-06. `dist/index.d.ts` of the shipped `@prisma/adapter-pg` has no `statementNameGenerator` anywhere in `PrismaPgOptions` at 7.4.0 or 7.5.0, and declares it at 7.6.0 through 7.10.0 together with `declare type StatementNameGenerator = (query: SqlQuery) => string`. The documentation comment on the option carries the default behaviour, which is the part the stale belief gets right about 7.5.0 and wrong about 7.6.0.

*Reproduced against: **Claude Fable 5.1** (S2), **Claude Opus 5** (S2) — prisma/v4-a, 2026-09-06; prisma/v4-c, 2026-09-06.*

Source: [Prisma 7.6.0 release notes — Driver Adapters](https://github.com/prisma/prisma/releases/tag/7.6.0) · 2026-03-27 · [@prisma/adapter-pg 7.6.0, shipped package — dist/index.d.ts](https://registry.npmjs.org/@prisma/adapter-pg)

#### `tx.$transaction()`

**Added in prisma 7.5.0** (2026-03-11)

`$transaction` can be called on the interactive transaction client. It was removed from the client deny list in 7.5.0, which added nested transaction rollback via savepoints for SQL databases: if the outer transaction fails, the inner nested one is rolled back with it. The deny list constant itself is the evidence — it reads `["$connect", "$disconnect", "$on", "$transaction", "$extends"]` at 7.4.0 and `["$connect", "$disconnect", "$on", "$use", "$extends"]` at 7.5.0 and later.

*The stale belief:* That `$transaction` is on `ITXClientDenyList`, so `tx.$transaction(...)` is a type error and absent at runtime, and that manual `SAVEPOINT` / `ROLLBACK TO SAVEPOINT` through `$executeRawUnsafe` is the only way to nest.

```ts
// Stale
// offered as the only route, and as a correction to working code:
await prisma.$transaction(async (tx) => {
  await tx.$executeRawUnsafe("SAVEPOINT sp1")
  try {
    await tx.post.create({ data: { title: "hello", authorId: 1 } })
  } catch {
    await tx.$executeRawUnsafe("ROLLBACK TO SAVEPOINT sp1")
  }
})

// Current
await prisma.$transaction(async (tx) => {
  await tx.user.create({ data: { email: "a@example.com" } })
  await tx.$transaction(async (tx2) => {
    await tx2.post.create({ data: { title: "hello", authorId: 1 } })
  })
})
```

> VERIFIED BY TYPE DECLARATION 2026-09-06. `@prisma/client` was installed at 7.4.0, 7.5.0, 7.6.0, 7.7.0, 7.8.0 and 7.10.0 and `runtime/client.d.ts` read at each. `declare const denylist` contains `"$transaction"` at 7.4.0 and does not at 7.5.0 through 7.10.0, where `"$use"` stands in its place; `ITXClientDenyList` is defined as `(typeof denylist)[number]` and the interactive transaction client is `Omit<..., ITXClientDenyList>`, so removal from that one constant is exactly what makes `tx.$transaction` type-check. This is the type-level form of the 7.5.0 release note. The raw-SQL savepoint workaround still works, so a reader who follows the stale belief loses ergonomics rather than correctness — S2, not S1.

*Reproduced against: **Claude Fable 5.1** (S2), **Claude Opus 5** (S2) — prisma/v4-a, 2026-09-06; prisma/v4-c, 2026-09-06.*

Source: [Prisma 7.5.0 release notes — Features](https://github.com/prisma/prisma/releases/tag/7.5.0) · 2026-03-11 · [@prisma/client 7.5.0, shipped package — runtime/client.d.ts](https://registry.npmjs.org/@prisma/client)

#### prisma db push --url

**Added in prisma 7.2.0** (2025-12-17)

The datasource connection string can be passed to the schema-push and migration commands directly on the command line. 7.2.0 added `--url` to `prisma db push`, `prisma db pull` and `prisma migrate dev`, described in the help table as "Override the datasource URL from the Prisma config file". Before 7.2.0 these commands took the URL only from the schema or `prisma.config.ts`, resolved from the process environment, so the standard advice was to prefix the command with an inline `DATABASE_URL=`. That advice still works and is not wrong; it is simply no longer the only option, and a model that denies the flag exists will not offer it.

*The stale belief:* That `db push` and `migrate dev` resolve the datasource only from configuration and the environment, and that the long-standing feature request for a URL flag on them is still open — true continuously from Prisma 2 through 7.1.0.

```bash
# Stale
DATABASE_URL="$EPHEMERAL_PG_URL" npx prisma db push --skip-generate --accept-data-loss

# Current
npx prisma db push --url "$EPHEMERAL_PG_URL" --skip-generate --accept-data-loss
```

> Bisected against the shipped CLI rather than the release note alone. `prisma db push --help` lists no `--url` at 5.22.0, 6.19.0, 7.0.0 or 7.1.0, and lists it at 7.2.0; `migrate dev` and `db pull` behave the same way across those versions. `db pull` is the one of the three with a pre-history — `prisma introspect --url` existed in the 2.x era — but the flag is absent from `db pull --help` at 5.22.0, 6.19.0, 7.0.0 and 7.1.0, so for every version this Index covers 7.2.0 is where it appears. The three sibling commands that took a URL throughout, and which subjects reliably name instead, are `db execute --url`, `migrate diff --from-url` and `migrate diff --to-url`.

*Reproduced against: **Claude Fable 5.1** (S2), **Claude Opus 5** (S2) — prisma/v5-c, 2026-09-06; prisma/v5-e, 2026-09-06.*

Source: [Prisma ORM 7.2.0 release notes](https://github.com/prisma/prisma/releases/tag/7.2.0) · 2025-12-17 · [prisma@7.2.0 shipped CLI — `prisma db push --help` lists `--url   Override the datasource URL from the Prisma config file`; the same table at 7.1.0 does not](https://registry.npmjs.org/prisma/-/prisma-7.2.0.tgz) · 2025-12-17

#### automatic .env loading

**Behaviour changed in prisma 7.0.0** (2025-11-19)

The Prisma CLI no longer loads `.env` files by itself. Load them yourself — `import 'dotenv/config'` at the top of `prisma.config.ts` is the vendor's own example.

*The stale belief:* That putting `DATABASE_URL` in `.env` is enough for `prisma migrate` to find it, which it was for the whole v2-v6 era — no load step anywhere in the project.

```ts
import 'dotenv/config'
import { defineConfig, env } from 'prisma/config'

export default defineConfig({ datasource: { url: env('DATABASE_URL') } })
```

*Reproduced against: **Claude Fable 5** (S2), **Claude Sonnet 5** (S2) — prisma/v1, 2026-08-31.*

Source: [Prisma 7.0.0 release notes — Explicit loading of environment variables](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### @@index([...], where: ...) / @@unique([...], where: ...)

**Added in prisma 7.4.0** (2026-02-11)

Prisma can express a partial (filtered) index in the schema since 7.4.0. Put `partialIndexes` in `previewFeatures` and pass `where:` to `@@index` or `@@unique`. Two predicate forms are accepted: a type-safe object literal, which supports only field equality and `not` (`{ published: true }`, `{ deletedAt: { not: null } }` — no `gt`/`lt`/`in`, no `AND`/`OR`), and `raw("...")` for any connector-specific SQL predicate. Supported on PostgreSQL, SQLite, SQL Server and CockroachDB; the schema validator rejects a `where:` index on MySQL with "Partial indexes (with a `where` clause) are not supported by the current connector".

*The stale belief:* That Prisma's schema language cannot express a partial or filtered index at all, so the only route is a hand-written `CREATE INDEX ... WHERE ...` inside a migration file (or `prisma db execute`), leaving the index invisible to `schema.prisma`.

```prisma
// Stale
// stale: the schema cannot express it, so hand-write it in the migration
model User {
  id        Int       @id @default(autoincrement())
  email     String
  deletedAt DateTime?

  @@index([email])
}
// then, in migrations/xxxx/migration.sql, by hand:
// CREATE INDEX "User_email_live_idx" ON "User"("email") WHERE "deletedAt" IS NULL;

// Current
generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["partialIndexes"]
}

model User {
  id        Int       @id @default(autoincrement())
  email     String
  deletedAt DateTime?
  active    Boolean   @default(true)

  @@index([email], where: { deletedAt: null })
  @@unique([email], where: { active: true })
  // richer predicates go through raw():
  // @@index([email], where: raw("\"deletedAt\" IS NULL AND active"))
}
```

> VERIFIED BY EXECUTION 2026-09-05, both halves of the standing rule. Introducing evidence by bisection against the shipped CLI, not from the release note alone: at prisma@7.3.0 the validator answers `The preview feature "partialIndexes" is not known. Expected one of: fullTextSearchPostgres, nativeDistinct, postgresqlExtensions, relationJoins, schemaEngineDriverAdapters, shardKeys, strictUndefinedChecks, views` — the name is absent from its own enumeration. At prisma@7.4.0 the same enumeration contains `partialIndexes` and the schema above validates. There are no 7.3.x patch releases, so the boundary is exactly 7.3.0 (2026-01-21) -> 7.4.0 (2026-02-11). Current behaviour re-verified at prisma@7.10.0, the newest stable: the same schema is valid, on `@@index` and `@@unique`. Poison controls confirm the validator can fail rather than accepting anything: `previewFeatures = ["partialIndexesXYZ"]` is rejected as unknown, `where: { nosuchfield: null }` is rejected as `Field 'nosuchfield' does not exist in model 'User'`, and dropping the preview feature is rejected with `Partial indexes are a preview feature`. The object form's limits were found the same way — `where: { score: { gt: 10 } }` is rejected with `Unknown key 'gt' in nested where clause object. Only 'not' is supported`, and `where: { AND: [...] }` with `Field 'AND' does not exist in model 'User'`. Connector gating checked directly: valid on `postgresql` and `sqlite`, rejected on `mysql`. Still a preview feature at 7.10.0 — the generator block opt-in is required and is the part a model that half-remembers this will omit.

*Reproduced against: **Claude Opus 5** (S2) — prisma/v2-a, 2026-09-05.*

Source: [Prisma 7.4.0 release notes — Partial Indexes (Filtered Indexes) Support](https://github.com/prisma/prisma/releases/tag/7.4.0) · 2026-02-11 · [prisma 7.4.0, shipped package — build/prisma_schema_build_bg.wasm](https://registry.npmjs.org/prisma/-/prisma-7.4.0.tgz) · [prisma 7.10.0, shipped package — `prisma validate` on the correct_code schema above](https://registry.npmjs.org/prisma/-/prisma-7.10.0.tgz)

#### `compilerBuild`

**Added in prisma 7.3.0** (2026-01-21)

The `prisma-client` generator takes a `compilerBuild` option with two values, `"fast"` (the default) and `"small"`. It selects which build of the query compiler is embedded in the generated client, and it is the size/speed dial for size-constrained runtimes. A model that denies it exists sends you to bundler-side workarounds — trimming `binaryTargets`, marking the client external, pruning models — none of which is the option that was built for this.

*The stale belief:* That the generator has no size/speed dial at all, and that the only real lever on generated-client size is dropping the Rust query engine via `queryCompiler` plus `driverAdapters` — which is a different change, was already the default in 7.0.0, and is not a trade of speed against size.

```prisma
// Stale
generator client {
  provider        = "prisma-client"
  output          = "../src/generated/prisma"
  previewFeatures = ["queryCompiler", "driverAdapters"]
}

// Current
generator client {
  provider      = "prisma-client"
  output        = "../src/generated/prisma"
  compilerBuild = "small" // "fast" | "small"
}
```

> Bisected against the shipped package: the string `compilerBuild` does not occur anywhere in `prisma@7.2.0`’s `build/index.js` and does occur in `prisma@7.3.0`’s.

*Reproduced against: **Claude Opus 5** (S2) — prisma/v5-c, 2026-09-06.*

Source: [Prisma ORM 7.3.0 release notes — new `compilerBuild` generator option](https://github.com/prisma/prisma/releases/tag/7.3.0) · 2026-01-21 · [prisma@7.3.0 shipped CLI — `compilerBuild` present in build/index.js; absent from prisma@7.2.0](https://registry.npmjs.org/prisma/-/prisma-7.3.0.tgz) · 2026-01-21

#### postinstall prisma generate

**Removed in prisma 7.0.0** (2025-11-19)

Prisma 7 runs nothing implicitly. The postinstall hook no longer runs `prisma generate`, and `prisma migrate` no longer runs `generate` or the seed script. Any Dockerfile or CI pipeline that relied on install-time generation produces an image with no client.

*The stale belief:* That `npm install` generates the client through Prisma's postinstall hook, so a Dockerfile needs no explicit generate step.

```bash
# Stale
RUN npm ci        # generated the client via postinstall, through v6
RUN npm run build

# Current
RUN npm ci
RUN npx prisma generate
RUN npm run build
```

> This is the failure that passes locally and fails in CI: a developer who ran `prisma generate` by hand still has the output on disk.

*Reproduced against: **Claude Sonnet 5** (S2) — prisma/v1, 2026-08-31.*

Source: [Prisma 7.0.0 release notes — Removal of implicit Prisma commands](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### enum member @map

**Behaviour changed in prisma 7.3.0** (2026-01-21)

Prisma **reverted** the 7.0.0 mapped-enum change in **7.3.0**. From 7.3.0 onward the generated enum object maps each member name to itself again — `PaymentProvider.MixplatSMS` is the string `'MixplatSMS'` — and the `@map` value is the database value, which the generated client does not expose. The mapped values appear in the generated object for 7.0.0, 7.1.0 and 7.2.0 only. If you need the database string in application code on 7.3.0+, keep your own map; there is no generated export that carries it.

*The stale belief:* That `@map` on an enum member changes what the generated client hands your code, so `PaymentProvider.MixplatSMS === 'mixplat/sms'`. That was true of 7.0.0, 7.1.0 and 7.2.0, and it is what the 7.0.0 release notes still say. It is false at every release from 7.3.0 on, and it was false before 7.0.0.

```ts
// Stale
export const PaymentProvider = {
  MixplatSMS: 'mixplat/sms',
  InternalToken: 'internal/token',
  Offline: 'offline'
} as const

// Current
export const PaymentProvider = {
  MixplatSMS: 'MixplatSMS',
  InternalToken: 'InternalToken',
  Offline: 'Offline'
} as const
```

> CORRECTED 2026-09-03 (JOURNAL/048), and this fact was wrong in the direction that matters: it stated the 7.0.0 behaviour as current and was verified from the 7.0.0 release note alone, never from a generated client. Prisma reverted at 7.3.0. Verified by generating a client from one schema at four releases with prisma 7.0.0, 7.2.0, 7.3.0 and 7.10.0 installed: 7.0.0 and 7.2.0 emit the mapped values, 7.3.0 and 7.10.0 emit the member names. Three charged S2 findings rested on the old wording and are RETRACTED — opus-5 F5, sonnet-5 F12, fable-5 F11 — because all three subjects wrote the member-name form, which is correct for the release that was current when they were scored. The earlier note on this fact stands as history: AUDIT 2026-09-02 (JOURNAL/038) corrected `code_lang` from `ts` to `prisma`; both code blocks are generated TypeScript again now, so it is `ts`.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Prisma 7.3.0 release notes — Revert @map enums to v6.19.0 behavior (PR #29002)](https://github.com/prisma/prisma/releases/tag/7.3.0) · 2026-01-21 · [prisma 7.10.0 — client generated from a schema with @map on every enum member](https://registry.npmjs.org/prisma/-/prisma-7.10.0.tgz) · [prisma 7.2.0 — the same schema, the last release before the revert](https://registry.npmjs.org/prisma/-/prisma-7.2.0.tgz) · [Prisma 7.0.0 release notes — Mapped enums, the change that was later reverted](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

#### connection pool defaults

**Default changed in prisma 7.0.0** (2025-11-19)

Pooling is the driver's, not Prisma's. Driver adapters use the underlying Node driver's pool settings, which differ from Prisma 6's: `pg` has no connection timeout by default (0) where Prisma 6 used five seconds. Connection-string parameters like `connection_limit` are not what tunes this any more.

*The stale belief:* That `?connection_limit=5&pool_timeout=10` on the datasource URL controls the pool, and that Prisma's own five-second connection timeout applies.

```ts
const adapter = new PrismaPg({
  connectionString: process.env.DATABASE_URL,
  max: 5,
  connectionTimeoutMillis: 5000,
})
```

> The adapter option names are the underlying driver's; the example above is `pg`'s.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Upgrade to Prisma ORM 7 — Driver adapters](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7)

### Deprecated, or a better API now exists

Works today. It is the older idiom, and some of it is scheduled for removal.

#### provider = "prisma-client-js"

**Deprecated in prisma 7.0.0** (2025-11-19)

`prisma-client` is the default generator provider in Prisma 7 — the Rust-free ESM client. `prisma-client-js` still works but is stated to be removed in a future release, and using it together with the now-required `output` needs an extra package, `@prisma/client-runtime-utils`.

*The stale belief:* That `prisma-client-js` is the only generator provider, which was true until the `prisma-client` preview landed in 6.16.0.

```prisma
// Stale
generator client {
  provider = "prisma-client-js"
}

// Current
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}
```

*Reproduced against: **Claude Fable 5** (S3), **Claude Sonnet 5** (S3) — prisma/v1, 2026-08-31.*

Source: [Upgrade to Prisma ORM 7 — Schema changes](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7) · [Prisma 7.0.0 release notes — ESM Prisma Client as the default](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19

### Wrong facts about the library

Not code — versions, minimums and metadata that models state confidently and get wrong.

#### MongoDB support

**Removed in prisma 7.0.0** (2025-11-19)

Prisma 7 does not support MongoDB. The vendor's instruction is to stay on Prisma 6 until support returns in a future v7 release. Advising a MongoDB user to install the latest version is advice that does not work.

*The stale belief:* That MongoDB is a first-class Prisma provider on every current version, as it was from 3.12 through 6.x.

> This is the one case where the correct answer is to pin to the previous major. Prisma 6 is still receiving releases (6.19.3 shipped 2026-04-01). SCOPE, checked 2026-09-03 against an installed prisma 7.10.0: the toolchain does not refuse the provider. A schema with `provider = "mongodb"` passes `prisma validate` ("the schema is valid") and `prisma generate` emits a client. What is missing is the runtime: Prisma 7 connects through driver adapters and no MongoDB adapter is published — `@prisma/adapter-mongodb` is a 404 on the npm registry. So the failure arrives at connect time, not at generate time, and a reader who takes "does not support" to mean "the CLI will tell you" is wrong about where it breaks.

*Reproduced against: **Claude Fable 5** (S4), **Claude Opus 5** (S4), **Claude Sonnet 5** (S4) — prisma/v1, 2026-08-31.*

Source: [Prisma 7.0.0 release notes — MongoDB support in Prisma 7](https://github.com/prisma/prisma/releases/tag/7.0.0) · 2025-11-19 · [Upgrade to Prisma ORM 7](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7)

## Not corrections — recorded for honesty

Claims seen in a run but not yet verified against a primary source. Never treated as findings:

- This draw and `v1r-b` were given a byte-identical prompt, the same model alias, on the same day, running concurrently, and placed the boundary 204 days apart (7.0.0 / 2025-11-19 here; 6.7.0 / 2025-04-29 there). Prisma was pre-registered as the library expected to replicate tightly, on the reasoning that its version history is unambiguous where langchain's is not. That reasoning is now falsified. *(open since 2026-09-01)*
- This draw hedged its own answer in a way the scoring rule does not capture: it called 7.0 describable "at headline level only" and volunteered that "for genuinely detailed release-note knowledge, the honest boundary is ~6.16, September 2025". Scored on its stated first-unknown-release it reads 7.0.0; scored on its stated confidence floor it reads 6.16.0. The battery has no rule for a subject that offers two boundaries in one answer. *(open since 2026-09-01)*
- This draw and `v1r-a` were given a byte-identical prompt, the same model alias, on the same day, running concurrently, and placed the boundary 204 days apart. Prisma was pre-registered as the library expected to replicate tightly; it did not. *(open since 2026-09-01)*
- This draw stated 6.7.0 as its boundary while producing a correct, complete, and explicitly disclaimed description of 7.0.0's contents. That is a third mode beyond the two `langchain/v1r` found: not a correct attribution and not a bare version string, but correct content the subject refuses to attribute. Whether the boundary instrument should score the statement or the production is now an open method question, and it is not answered by either battery. *(open since 2026-09-01)*
- 6.8.0 (2025-05-15) is unresolved for this draw: it said it could describe "roughly 6.7-6.8", named 6.7 as the newest it could genuinely describe, and put "6.9-and-later" in the version-number-only bucket. The bracket recorded here uses the subject's two explicit statements (6.7.0 describable, 6.9.0 not) and leaves 6.8.0 unclassified rather than guessing. *(open since 2026-09-01)*
- Both Opus 5 draws in this battery placed query-plan caching at the `queryCompiler` preview (6.7.0 / 7.0.0) rather than at 7.4.0, and both described the mechanism roughly correctly while dating it wrong. Is that a general shape — a feature whose PUBLIC name arrives in one release and whose CAPABILITY is the completion of work named in an earlier one gets attributed to the earlier one? next.js and better-auth both have candidate surfaces with that structure. Worth a battery designed around it rather than a note. *(open since 2026-09-05)*
- This draw's self-report about where its content knowledge stops (6.9/6.10) is four releases below where it demonstrably stops (7.0.0, described correctly in the same answer). Every boundary number the Index publishes for every subject comes from the self-report. How often is the self-report an UNDER-estimate of demonstrated knowledge, and does it bias the published boundaries downward? This is the first draw where both readings are available in one transcript and they disagree. It would take a battery that asks for content and for the self-placement about the same releases, deliberately, to answer. *(open since 2026-09-05)*
- Does the `prisma-client` generator accept a `runtime` key with values such as "vercel-edge" and "workerd", as the serverless answer claims? *(open since 2026-08-31)*

---

*Findings, code and citations: `data/prisma/` — one JSON file and one write-up per model, each finding carrying the release that broke the belief, its publication date and a verbatim quote from the primary source. Corrections: `data/prisma/facts.json`. This file is generated by `tools/build-corrections.mjs`; if the prose and the data ever disagree, that is a bug in the generator, not a stale pack.*

==============================================================================
CORRECTION PACK: tailwindcss (https://stalepriors.com/corrections/tailwindcss.md)

# tailwindcss correction pack · for projects on tailwindcss@^4


## What we actually measured

4 Claude models were asked for idiomatic tailwindcss code with no tools, purely from training knowledge. 7 reproduced failures across 11 runs, each verified against the release that broke the belief.

| Model | Stated cutoff | tailwindcss version attribution stops | Lag inside the window |
|---|---|---|---|
| Claude Fable 5.1 | 2026-06 | 4.1.0 · 2025-04-01 | ~14 months |
| Claude Opus 5 | 2026-05 | 4.1.0 · 2025-04-01 | ~13 months |
| Claude Fable 5 | 2026-01 | 4.1.0 · 2025-04-01 | ~9 months |
| Claude Sonnet 5 | 2026-01 | 4.1.0 · 2025-04-01 | ~9 months |

A recent cutoff is not a defence. Every model here loses track of this library's release history well before the date it states as its own cutoff, and the stopping points cluster far tighter than the cutoffs do.

Read that column precisely. It is the newest tailwindcss release whose contents the model can correctly **attribute to that release** — not the newest tailwindcss feature it knows. Past that point a model will often write working code with a newer API while naming the wrong release for it, and that guess runs *early* — it names a release older than the one that shipped the feature. So the question this pack answers is not "does the model know this API" but "can it be trusted about which version the API arrived in" — which is the question that matters when you are pinned to a version.

Latest tailwindcss is **4.3.3** (verified 2026-09-06). Separately from the corrections below, 1 of 11 runs recorded a version fact — the model named a current tailwindcss version from memory and was behind. If a model states a version without checking, assume it is behind and check the registry.

## How to read an entry

Every entry ends with a *Reproduced against* line. Where it names models, we have the generated code that got it wrong, dated, with the model's own words in the run write-up. Where it says no model yet, the correction is verified from the release notes but nothing has been probed for it — it is a fix, not a measurement, and the pack says so rather than blurring the two.

The section an entry sits in is the worst case if you act on the stale belief. The severity in brackets after a model's name is what that particular model's output actually did, which can be milder — a model can hold the wrong belief and still, on the day, write code that runs.

## The corrections

### Breaks the build, or throws at runtime

Act on the stale belief here and the code does not run. Fix these first.

#### @apply inside Vue/Svelte/Astro <style> blocks and CSS modules

**New requirement in tailwindcss 4.0.0** (2025-01-21)

Stylesheets bundled separately from the main CSS file — single-file-component `<style>` blocks, CSS module files — have no access to your theme variables, custom utilities or custom variants, so `@apply` fails there. Pull the definitions in first with `@reference`, pointing at your CSS entry file so custom `@theme` tokens resolve. `@reference` adds no CSS to the bundle.

*The stale belief:* That `@apply` works in any stylesheet the build touches, as it did in v3.

```html

<style scoped>
h1 { @apply text-2xl font-bold text-brand; }
</style>


<style scoped>
@reference "../assets/main.css";   /* your entry file, so @theme tokens resolve */

h1 { @apply text-2xl font-bold text-brand; }
</style>
```

> `@reference "tailwindcss";` is sufficient only if you use no custom theme tokens. Using the generated CSS variables directly (`color: var(--color-brand)`) avoids the problem and is faster.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Using @apply with Vue, Svelte, or CSS modules"](https://tailwindcss.com/docs/upgrade-guide)

#### @layer utilities / @layer components (for defining custom classes)

**Removed in tailwindcss 4.0.0** (2025-01-21)

v4 uses native CSS cascade layers and no longer hijacks the `@layer` at-rule, so a class defined inside `@layer utilities` is no longer registered as a utility and gets no variant support (`hover:`, `md:`). Custom utilities are declared with the `@utility` API, which also accepts functional forms.

*The stale belief:* That wrapping a class in `@layer utilities` is how you add a custom utility that works with variants.

```css
/* Stale */
@layer utilities {
  .tab-4 { tab-size: 4; }
}

/* Current */
@utility tab-4 {
  tab-size: 4;
}

/* functional form, matching tab-2, tab-4, tab-[13] */
@utility tab-* {
  tab-size: --value(integer);
}
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Adding custom utilities"](https://tailwindcss.com/docs/upgrade-guide) · [Tailwind CSS docs — Adding custom styles, functional utilities](https://tailwindcss.com/docs/adding-custom-styles)

#### @tailwind base / @tailwind components / @tailwind utilities

**Removed in tailwindcss 4.0.0** (2025-01-21)

The three `@tailwind` directives were removed. A v4 CSS entry file pulls the framework in with a plain CSS import: `@import "tailwindcss";`.

*The stale belief:* That a Tailwind entry stylesheet starts with `@tailwind base; @tailwind components; @tailwind utilities;`.

```css
/* Stale */
@tailwind base;
@tailwind components;
@tailwind utilities;

/* Current */
@import "tailwindcss";
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Removed @tailwind directives"](https://tailwindcss.com/docs/upgrade-guide)

#### bg-[--var] (CSS variable shorthand in arbitrary values)

**Renamed in tailwindcss 4.0.0** (2025-01-21)

The bare-variable shorthand inside arbitrary values moved from square brackets to parentheses: `bg-[--brand]` becomes `bg-(--brand)`. The explicit longhand `bg-[var(--brand)]` is unaffected and still works.

*The stale belief:* That `bg-[--brand]` resolves the custom property.

```html

<div class="bg-[--brand]"></div>


<div class="bg-(--brand)"></div>
<div class="bg-[var(--brand)]"></div>   
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Variables in arbitrary values"](https://tailwindcss.com/docs/upgrade-guide)

#### `bg-opacity-* / text-opacity-* / border-opacity-* / ring-opacity-* / placeholder-opacity-* / divide-opacity-*`

**Removed in tailwindcss 4.0.0** (2025-01-21)

The separate opacity utilities were removed. Use the slash opacity modifier on the colour utility itself.

*The stale belief:* That translucency is expressed as a second class, `bg-black bg-opacity-50`.

```html

<div class="bg-black bg-opacity-50"></div>


<div class="bg-black/50"></div>
```

> No CSS is emitted for the removed class, so the element is simply opaque. Nothing errors — the failure is visual.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Removed deprecated utilities"](https://tailwindcss.com/docs/upgrade-guide)

#### commas in grid-cols-[…] / grid-rows-[…] / object-[…] arbitrary values

**Stricter in tailwindcss 4.0.0** (2025-01-21)

v3 replaced commas with spaces inside these particular arbitrary values, a compatibility hack carried over from v2. That is gone: use underscores for spaces, as everywhere else in arbitrary values.

*The stale belief:* That `grid-cols-[max-content,auto]` means two columns.

```html

<div class="grid-cols-[max-content,auto]"></div>


<div class="grid-cols-[max-content_auto]"></div>
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Arbitrary values in grid and object-position utilities"](https://tailwindcss.com/docs/upgrade-guide)

#### container (center / padding configuration)

**Removed in tailwindcss 4.0.0** (2025-01-21)

The `container` utility's `center` and `padding` configuration options no longer exist. Extend the utility itself instead.

*The stale belief:* That container centring and padding are set under `theme.container` in the JS config.

```css
/* Stale */
// tailwind.config.js
theme: { container: { center: true, padding: '2rem' } }

/* Current */
@utility container {
  margin-inline: auto;
  padding-inline: 2rem;
}
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Container configuration"](https://tailwindcss.com/docs/upgrade-guide)

#### `prefix`

**Renamed in tailwindcss 4.0.0** (2025-01-21)

Prefixes now look like variants and sit at the front of the whole class: `tw:flex`, `tw:hover:bg-red-600`. The prefix is declared on the import, and theme variables are still authored unprefixed.

*The stale belief:* That the prefix is glued to the utility name after any variants, `hover:tw-bg-red-600`.

```html

<div class="tw-flex tw-bg-red-500 hover:tw-bg-red-600"></div>


/* CSS */
@import "tailwindcss" prefix(tw);


<div class="tw:flex tw:bg-red-500 tw:hover:bg-red-600"></div>
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Using a prefix"](https://tailwindcss.com/docs/upgrade-guide)

#### `resolveConfig`

**Removed in tailwindcss 4.0.0** (2025-01-21)

The `resolveConfig` export was removed. Theme values are real CSS custom properties at runtime, so reference them directly (`var(--color-blue-500)`), or read one in JS with `getComputedStyle(document.documentElement).getPropertyValue("--shadow-xl")`.

*The stale belief:* That you import `resolveConfig` from `tailwindcss/resolveConfig` to get theme values into JavaScript.

```js
// Stale
import resolveConfig from 'tailwindcss/resolveConfig';
import config from './tailwind.config.js';
const { theme } = resolveConfig(config);

// Current
const styles = getComputedStyle(document.documentElement);
const shadow = styles.getPropertyValue("--shadow-xl");

// or just use the variable in CSS/JS values:
<motion.div animate={{ backgroundColor: "var(--color-blue-500)" }} />
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Theme values in JavaScript"](https://tailwindcss.com/docs/upgrade-guide)

#### `safelist / corePlugins / separator`

**Removed in tailwindcss 4.0.0** (2025-01-21)

The `safelist`, `corePlugins` and `separator` options are not supported in v4, from a JS config or anywhere else. Their replacement did **not** ship with the removal: `@source inline(...)` — whose argument is brace-expanded — arrived in **4.1.0 (2025-04-01)**, ten weeks after 4.0.0 removed `safelist`. On 4.0.x there is no safelisting mechanism at all, and `@source inline("...")` is a build error there: the 4.0 parser accepts a quoted path only and throws ``@source` paths must be quoted.`

*The stale belief:* That runtime-assembled class names are rescued by a `safelist` array in `tailwind.config.js`.

**The code below needs tailwindcss 4.1.0 or later.** Between 4.0.0 and 4.1.0 this correction does not apply — see the note.

```css
/* Stale */
// tailwind.config.js
module.exports = {
  safelist: ['bg-red-500', { pattern: /bg-(red|green)-(100|500)/, variants: ['hover'] }],
};

/* Current */
@import "tailwindcss";

@source inline("{hover:,}bg-{red,green}-{100,500}");
@source inline("{hover:,}bg-red-{50,{100..900..100},950}");   /* ranges work too */

/* on 4.0.x there is no replacement: write the complete class names
   into a lookup map so the scanner sees them literally. */
```

> Bisected in the published packages 2026-09-02: the `@source` parser handles `inline(` (and `not `) from **4.1.0**; the string is absent from the dist of 4.0.0, 4.0.9, 4.0.12, 4.0.15 and 4.0.17 — the last 4.0.x — where the parser takes a quoted path only. The upgrade-guide sentence quoted below is on the current docs page and describes 4.1+, not the 4.0.0 release it appears under; this fact repeated that gap until it was re-verified. The better fix where you control the code is still to write complete class names into a lookup map so the scanner sees them; `@source inline()` is for strings that genuinely cannot be static.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Using a JavaScript config file"](https://tailwindcss.com/docs/upgrade-guide) · [Tailwind CSS docs — Detecting classes in source files, "Safelisting specific utilities"](https://tailwindcss.com/docs/detecting-classes-in-source-files) · [tailwindcss 4.1.0 — shipped package (dist), @source inline( parser present; absent through 4.0.17](https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.1.0) · 2025-04-01

#### `Sass / Less / Stylus`

**New requirement in tailwindcss 4.0.0** (2025-01-21)

v4 is not designed to be used with a CSS preprocessor. Tailwind is the preprocessor: you cannot use Sass, Less or Stylus for your stylesheets or for `<style lang="scss">` blocks in Vue, Svelte or Astro.

*The stale belief:* That Tailwind composes with Sass the way v3 tolerated.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Using Sass, Less, and Stylus"](https://tailwindcss.com/docs/upgrade-guide)

#### `tailwind.config.js`

**Removed in tailwindcss 4.0.0** (2025-01-21)

JavaScript config files are still supported but are **no longer detected automatically**. A `tailwind.config.js` sitting in the project root is simply ignored, so every utility derived from it (`bg-brand`, `font-display`) silently emits nothing. Configure the theme in CSS with `@theme`, or load the legacy file explicitly with `@config`.

*The stale belief:* That dropping a `tailwind.config.js` in the project root configures the build, and that `theme.extend` is where custom colours and fonts go.

```css
/* Stale */
// tailwind.config.js — not detected in v4
module.exports = {
  content: ['./src/**/*.{js,jsx,ts,tsx}'],
  theme: { extend: { colors: { brand: '#4f46e5' } } },
};

/* Current */
/* src/index.css */
@import "tailwindcss";

@theme {
  --color-brand: #4f46e5;      /* generates bg-brand, text-brand, border-brand, ... */
  --font-display: "Satoshi", sans-serif;   /* generates font-display */
}

/* or, to keep a legacy JS config: */
@config "../../tailwind.config.js";
```

> `corePlugins`, `safelist` and `separator` are not supported from a JS config in v4 at all — see LF12.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Using a JavaScript config file"](https://tailwindcss.com/docs/upgrade-guide)

#### tailwindcss as a PostCSS plugin / npx tailwindcss

**Removed in tailwindcss 4.0.0** (2025-01-21)

The `tailwindcss` package is no longer itself the PostCSS plugin or the CLI. The PostCSS plugin moved to `@tailwindcss/postcss`, the CLI to `@tailwindcss/cli`, and Vite projects have a dedicated `@tailwindcss/vite` plugin, which is the documented install path. Import handling and vendor prefixing are built in, so `postcss-import` and `autoprefixer` can be removed.

*The stale belief:* That you install `tailwindcss postcss autoprefixer`, run `npx tailwindcss init -p`, and list `tailwindcss: {}` among your PostCSS plugins.

```js
// Stale
// postcss.config.mjs (v3)
export default { plugins: { "postcss-import": {}, tailwindcss: {}, autoprefixer: {} } };

// Current
// vite.config.ts — the documented v4 path for Vite
import tailwindcss from "@tailwindcss/vite";
export default defineConfig({ plugins: [tailwindcss()] });

// or PostCSS, for non-Vite toolchains:
// postcss.config.mjs
export default { plugins: { "@tailwindcss/postcss": {} } };
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Using PostCSS" / "Using Tailwind CLI"](https://tailwindcss.com/docs/upgrade-guide) · [Tailwind CSS docs — Installation, Using Vite](https://tailwindcss.com/docs/installation/using-vite)

### Runs, but is silently wrong

Nothing errors. The behaviour is simply not what a model trained earlier will tell you.

#### node_modules scanning

**Default changed in tailwindcss 4.1.0** (2025-04-01)

As of 4.1.0 `node_modules` is ignored by default when detecting classes. A component library shipping Tailwind classes in its published files needs an explicit `@source` pointing into it.

*The stale belief:* That classes inside an installed package are picked up automatically.

```css
@import "tailwindcss";
@source "../node_modules/@acmecorp/ui-lib";
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [tailwindcss CHANGELOG — 4.1.0 (2025-04-01), Changed](https://raw.githubusercontent.com/tailwindlabs/tailwindcss/main/CHANGELOG.md) · 2025-04-01 · [Tailwind CSS docs — Detecting classes in source files](https://tailwindcss.com/docs/detecting-classes-in-source-files)

#### border / divide (default colour)

**Default changed in tailwindcss 4.0.0** (2025-01-21)

The default colour of `border-*` and `divide-*` changed from the configured `gray-200` to `currentColor`, matching browser defaults. An uncoloured `border` now renders in the element's text colour — usually near-black — where v3 rendered a light grey.

*The stale belief:* That `class="border"` draws a subtle grey hairline.

```html

<div class="border rounded-lg p-4">…</div>


<div class="border border-gray-200 rounded-lg p-4">…</div>


<style>
@layer base {
  *, ::after, ::before, ::backdrop, ::file-selector-button {
    border-color: var(--color-gray-200, currentColor);
  }
}
</style>
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Default border color"](https://tailwindcss.com/docs/upgrade-guide)

#### hover variant

**Behaviour changed in tailwindcss 4.0.0** (2025-01-21)

`hover:` is now wrapped in `@media (hover: hover)`, so it does not fire on touch devices that previously triggered hover on tap. Treat hover as an enhancement; if you genuinely depend on the old behaviour, override the variant.

*The stale belief:* That `hover:` styles apply on touch devices when the user taps.

```css
/* Stale */
/* v3 */ .hover\:underline:hover { text-decoration: underline; }

/* Current */
/* v4 */ @media (hover: hover) { .hover\:underline:hover { text-decoration: underline; } }

/* to opt out: */
@custom-variant hover (&:hover);
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Hover styles on mobile"](https://tailwindcss.com/docs/upgrade-guide)

#### `outline-none`

**Renamed in tailwindcss 4.0.0** (2025-01-21)

In v3, `outline-none` did not set `outline-style: none` — it set an invisible outline that still appeared in forced-colors mode for accessibility. That behaviour is now called `outline-hidden`. The v4 `outline-none` really does remove the outline. Code carrying `focus:outline-none` from v3 therefore loses its forced-colors-mode focus indicator.

*The stale belief:* That `focus:outline-none` is the safe way to suppress the browser's focus ring before drawing your own.

```html

<input class="focus:outline-none" />


<input class="focus:outline-hidden" />
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Renamed outline utility"](https://tailwindcss.com/docs/upgrade-guide)

#### Preflight base styles

**Default changed in tailwindcss 4.0.0** (2025-01-21)

Three Preflight defaults changed: placeholder text uses the current text colour at 50% opacity rather than `gray-400`; buttons use `cursor: default` rather than `cursor: pointer`; and margins are reset on `<dialog>`, so dialogs are no longer centred by default. Each is restorable with a small `@layer base` block.

*The stale belief:* That buttons get a pointer cursor and dialogs are centred out of the box.

```css
@layer base {
  button:not(:disabled), [role="button"]:not(:disabled) { cursor: pointer; }
  input::placeholder, textarea::placeholder { color: var(--color-gray-400); }
  dialog { margin: auto; }
}
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Preflight changes"](https://tailwindcss.com/docs/upgrade-guide)

#### `ring`

**Default changed in tailwindcss 4.0.0** (2025-01-21)

The bare `ring` utility changed from a 3px `blue-500` ring to a 1px `currentColor` ring. A v3 focus style written as `focus:ring` is therefore now a thin ring in the element's own text colour — on a coloured button with white text, effectively invisible. Use `ring-3` plus an explicit `ring-<color>` to restore the v3 appearance.

*The stale belief:* That `focus:ring` alone produces the familiar 3px blue focus ring.

```html

<button class="focus:ring">Save</button>


<button class="focus-visible:ring-3 focus-visible:ring-blue-500">Save</button>
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Default ring width and color"](https://tailwindcss.com/docs/upgrade-guide)

#### `shadow-sm / shadow / rounded-sm / rounded / blur-sm / blur`

**Renamed in tailwindcss 4.0.0** (2025-01-21)

The shadow, radius and blur scales were shifted one step so every utility has a named value. What v3 called `shadow` is now `shadow-sm`, and v3's `shadow-sm` is now `shadow-xs`. The same applies to `rounded`/`rounded-sm`, `blur`/`blur-sm` and `drop-shadow`/`backdrop-blur`. The old bare names still resolve, so nothing errors — they just render one step larger than the author intended.

*The stale belief:* That `shadow-sm` is the subtlest shadow in the scale.

```html

<div class="shadow-sm rounded-sm blur-sm"></div>   


<div class="shadow-xs rounded-xs blur-xs"></div>   
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Updated shadow, radius, and blur scales"](https://tailwindcss.com/docs/upgrade-guide)

#### space-x-* / space-y-* / divide-x-* / divide-y-* (selector)

**Behaviour changed in tailwindcss 4.0.0** (2025-01-21)

The selector behind these utilities changed from `> :not([hidden]) ~ :not([hidden])` to `> :not(:last-child)`, for performance, and the spacing now hangs off the *bottom* of each child rather than the top of each sibling. Layouts using these with inline elements, or with per-child margin tweaks, can shift. Prefer `flex`/`grid` with `gap`.

*The stale belief:* That `space-y-4` adds top margin to every child after the first.

```css
/* Stale */
/* v3 */ .space-y-4 > :not([hidden]) ~ :not([hidden]) { margin-top: 1rem; }

/* Current */
/* v4 */ .space-y-4 > :not(:last-child) { margin-bottom: 1rem; }

/* recommended instead: */
/* <div class="flex flex-col gap-4"> */
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Space-between selector"](https://tailwindcss.com/docs/upgrade-guide)

#### stacked variant order

**Behaviour changed in tailwindcss 4.0.0** (2025-01-21)

Stacked variants now apply left to right instead of right to left, to read more like CSS. Order-sensitive stacks must be reversed: v3's `first:*:pt-0` is v4's `*:first:pt-0`. In practice this bites the direct-child variant `*` and plugin variants like `prose-headings`.

*The stale belief:* That `first:*:pt-0` targets the first child.

```html

<ul class="py-4 first:*:pt-0 last:*:pb-0">…</ul>


<ul class="py-4 *:first:pt-0 *:last:pb-0">…</ul>
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Variant stacking order"](https://tailwindcss.com/docs/upgrade-guide)

#### `transform-none / rotate-* / scale-* / translate-*`

**Behaviour changed in tailwindcss 4.0.0** (2025-01-21)

These utilities are now built on the individual `rotate`, `scale` and `translate` CSS properties rather than the `transform` shorthand. Two consequences: `transform-none` no longer resets them (reset the individual property, e.g. `scale-none`), and a custom transition list containing `transform` no longer transitions them — list the individual properties, `transition-[opacity,scale]`.

*The stale belief:* That `transform-none` clears a scale or rotation, and that `transition-[opacity,transform]` animates `scale-*`.

```html

<button class="scale-150 focus:transform-none"></button>
<button class="transition-[opacity,transform] hover:scale-150"></button>


<button class="scale-150 focus:scale-none"></button>
<button class="transition-[opacity,scale] hover:scale-150"></button>
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Individual transform properties"](https://tailwindcss.com/docs/upgrade-guide)

### Deprecated, or a better API now exists

Works today. It is the older idiom, and some of it is scheduled for removal.

#### `@container-size`

**Added in tailwindcss 4.3.0** (2026-05-08)

Since 4.3.0 the `@container-size` utility sets `container-type: size`, alongside the long-standing `@container` utility which sets `container-type: inline-size`. Use `@container-size` where a container query needs to read the container's block size as well as its inline size; `@container` is unchanged and is still the right default.

*The stale belief:* That `@container` is the only container-type utility, so `container-type: size` needs `[container-type:size]` or a hand-written rule.

```html

<div class="[container-type:size]"></div>


<div class="@container-size">
  <div class="@md:flex @lg:gap-4">…</div>
</div>
```

> S3 under the workaround rule: `[container-type:size]` compiles at 4.2.4 and at 4.3.0 and emits the same declaration.
VERIFIED BY COMPILATION 2026-09-06 against installed 4.2.4, 4.3.0 and 4.3.3. `@container-size` emits nothing at 4.2.4 and `container-type: size` at 4.3.0 and 4.3.3; `@container` emits `container-type: inline-size` at all three, so the older utility did not change.

*Reproduced against: **Claude Fable 5.1** (S2) — tailwindcss/v3-a, 2026-09-06.*

Source: [tailwindcss v4.3.0 release notes — Added](https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.3.0) · 2026-05-08 · [tailwindcss 4.3.0, shipped package — `@container-size` compiles to `container-type: size`; `@container` still compiles to `container-type: inline-size`.](https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.3.0.tgz) · [tailwindcss 4.2.4, shipped package — `@container-size` compiles to nothing; `@container` is already present.](https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.2.4.tgz)

#### @variant (stacked and compound variants)

**Added in tailwindcss 4.3.0** (2026-05-08)

Since 4.3.0 the `@variant` at-rule accepts a stacked variant (`@variant hover:focus { … }`, applying when both conditions hold) and a comma-separated compound list (`@variant hover, focus { … }`, applying when any of them holds). Both spellings work with modifier-carrying variants too, so `@variant group-hover:focus { … }` is legal. Before 4.3.0 `@variant` took exactly one variant name and anything else was a BUILD ERROR: `Cannot use @variant with unknown variant: hover:focus`.

*The stale belief:* That `@variant` takes a single variant only, so combining two conditions means nesting one `@variant` block inside another, and a comma-separated list has no equivalent at all — a model holding this belief will tell the author of a working `@variant hover:focus { … }` block that Tailwind cannot parse it.

```css
/* Stale */
@import "tailwindcss";

.btn {
  @variant hover {
    @variant focus {
      outline: 2px solid magenta;
    }
  }
}

/* Current */
@import "tailwindcss";

.btn {
  @variant hover:focus {
    outline: 2px solid magenta;
  }

  /* and the compound form, which nesting cannot express at all */
  @variant hover, focus, active {
    outline-offset: 2px;
  }
}
```

> SEVERITY IS ASYMMETRIC ACROSS THE TWO HALVES AND THE FACT DOES NOT AVERAGE THEM. The stacked half is S3: the nested workaround compiles at 4.2.4 and at 4.3.0 and, verified by compilation, produces BYTE-IDENTICAL output to the stacked form at 4.3.0, so a reader who nests loses nothing. The compound half has no nested equivalent — nesting means AND, the comma means OR — so a reader who believes the comma is illegal writes the block out once per variant instead. That is still working CSS, which is why the fact as a whole stays S3 rather than S2; the S2 direction is review, where a draw tells the author of a working `@variant hover:focus` block that it is a build error.
VERIFIED BY COMPILATION 2026-09-06 with the real engine. At 4.2.4 `@variant hover:focus`, `@variant group-hover:focus` and `@variant hover, focus, active` each THROW `Cannot use @variant with unknown variant: …` — a hard build failure, not a silent no-op — while `@variant hover` and the nested form compile. At 4.3.0 and 4.3.3 all five compile.

*Reproduced against: **Claude Fable 5.1** (S3) — tailwindcss/v3-a, 2026-09-06.*

Source: [tailwindcss v4.3.0 release notes — Added](https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.3.0) · 2026-05-08 · [tailwindcss v4.3.0 release notes — Added](https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.3.0) · 2026-05-08 · [tailwindcss 4.3.0, shipped package — `@variant hover:focus { outline: 2px solid magenta }` compiles to `&:hover { @media (hover: hover) { &:focus { outline: 2px solid magenta } } }`, identical to the nested form; `@variant hover, focus { … }` compiles to two separate rules.](https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.3.0.tgz) · [tailwindcss 4.2.4, shipped package — the same stacked and compound sources throw `Cannot use @variant with unknown variant: hover:focus` / `: hover, focus`; the single-variant and nested forms compile.](https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.2.4.tgz)

#### `scrollbar-auto / scrollbar-thin / scrollbar-none / scrollbar-thumb-* / scrollbar-track-* / scrollbar-gutter-*`

**Added in tailwindcss 4.3.0** (2026-05-08)

Since 4.3.0 Tailwind ships first-class scrollbar utilities and no plugin is needed. `scrollbar-auto`, `scrollbar-thin` and `scrollbar-none` set `scrollbar-width`. `scrollbar-thumb-*` and `scrollbar-track-*` set `scrollbar-color` — each writes one half into a CSS variable (`--tw-scrollbar-thumb` / `--tw-scrollbar-track`) and both emit the same `scrollbar-color` declaration, so use them as a pair or the unset half falls back to the variable's default. `scrollbar-gutter-auto` and `scrollbar-gutter-stable` set `scrollbar-gutter`. Colour utilities take the theme palette and arbitrary values alike: `scrollbar-thumb-slate-500` and `scrollbar-thumb-[#123456]` both compile. Do not install `tailwind-scrollbar` and do not hand-write a `::-webkit-scrollbar` block for the standard properties.

*The stale belief:* That Tailwind has no scrollbar utilities, so styling a scrollbar means installing the third-party `tailwind-scrollbar` plugin, writing `::-webkit-scrollbar` rules in your own CSS, or reaching for arbitrary properties. A model holding this belief will also reject working `scrollbar-thin scrollbar-thumb-slate-500` markup in review as classes that generate nothing.

```html



<div class="overflow-y-auto scrollbar-thin"></div>


<style>
  .panel::-webkit-scrollbar { width: 8px }
  .panel::-webkit-scrollbar-thumb { background: #64748b }
</style>


<div class="overflow-y-auto scrollbar-thin scrollbar-thumb-slate-500 scrollbar-track-slate-100 scrollbar-gutter-stable">
  …
</div>
```

> SEVERITY IS S3 AND THE REASON MATTERS, exactly as on LF30. The arbitrary-property workaround a stale model offers (`[scrollbar-width:thin]`, `[scrollbar-color:red_blue]`) compiles at 4.2.4 AND at 4.3.0 and emits the identical declaration, so acting on the stale belief costs verbosity, not correctness, and the workaround rule (HARNESS.md, JOURNAL/030) forbids charging it as a defect. Two directions are worse and are S2 where a run shows them: telling the author of working `scrollbar-thin` markup that it generates nothing, and sending the reader to a third-party plugin or to `::-webkit-scrollbar` — the latter is not equivalent, because `::-webkit-scrollbar` is unimplemented in Firefox while `scrollbar-width` and `scrollbar-color` are the standard properties this family emits.
VERIFIED BY COMPILATION 2026-09-06: every class in `correct_code` built one at a time with the real engine against installed 4.1.0, 4.2.4, 4.3.0 and 4.3.3. All of them emit nothing at 4.1.0 and 4.2.4 and the expected declaration at 4.3.0 and 4.3.3 — a clean bisection onto the target release, with the whole 4.2.x line ruled out rather than just 4.2.0.
THE SCHEME DOES NOT GENERALISE, and this is the family's guessing trap: `scrollbar-corner-*`, `scrollbar-hidden`, `scrollbar-width-thin` and `scrollbar-thumb-rounded` are absent from 4.2.4, 4.3.0 and 4.3.3 alike and compile to nothing at all three. There is no corner utility; CSS `scrollbar-color` takes exactly two colours and the utilities cover exactly those two.

*Reproduced against: **Claude Fable 5.1** (S2) — tailwindcss/v3-a, 2026-09-06.*

Source: [tailwindcss v4.3.0 release notes — Added](https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.3.0) · 2026-05-08 · [tailwindcss v4.3.0 release notes — Added](https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.3.0) · 2026-05-08 · [tailwindcss 4.3.0, shipped package — the engine compiles `scrollbar-thin` to `scrollbar-width: thin`, `scrollbar-thumb-red-500` to `--tw-scrollbar-thumb: var(--color-red-500); scrollbar-color: var(--tw-scrollbar-thumb) var(--tw-scrollbar-track)`, and `scrollbar-gutter-stable` to `scrollbar-gutter: stable`.](https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.3.0.tgz) · [tailwindcss 4.2.4, shipped package — every one of those class names compiles to nothing, at the last release of the 4.2 line. The family begins at 4.3.0, not earlier in 4.2.x.](https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.2.4.tgz) · [tailwindcss 4.3.3, shipped package — `scrollbar-corner-red-500`, `scrollbar-hidden`, `scrollbar-width-thin` and `scrollbar-thumb-rounded` are absent and compile to nothing at the newest release that exists.](https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.3.3.tgz) · [Tailwind CSS docs — scrollbar-width (Interactivity), documented at v4.3](https://tailwindcss.com/docs/scrollbar-width)

#### `zoom-* / tab-*`

**Added in tailwindcss 4.3.0** (2026-05-08)

Since 4.3.0 Tailwind ships `zoom-*` utilities for the CSS `zoom` property and `tab-*` utilities for `tab-size`. `zoom-*` takes a percentage-style number — `zoom-50` emits `zoom: 50%`, `zoom-150` emits `zoom: 150%` — and `tab-*` takes a plain integer, so `tab-4` emits `tab-size: 4`. Both accept arbitrary values: `zoom-[1.5]` emits `zoom: 1.5` (a bare ratio, not a percentage) and `tab-[3]` emits `tab-size: 3`.

*The stale belief:* That neither CSS `zoom` nor `tab-size` has a Tailwind utility, so both need arbitrary properties or hand-written CSS.

```html

<pre class="[tab-size:4]"></pre>
<div class="[zoom:0.5]"></div>


<pre class="tab-4"></pre>
<div class="zoom-50"></div>
```

> S3 for the same reason as LF31: `[tab-size:4]` and `[zoom:1.5]` compile at 4.2.4 and at 4.3.0 and emit the identical declaration, so the stale belief costs verbosity rather than correctness and cannot be charged as a defect under the workaround rule. Note the unit asymmetry, which is the one place a reader can go wrong translating between the two spellings: the named scale is a percentage (`zoom-50` -> `zoom: 50%`) while the arbitrary form is passed through untouched (`zoom-[1.5]` -> `zoom: 1.5`, which is 150%, not 1.5%). `zoom-normal` and `zoom-reset` do not exist.
VERIFIED BY COMPILATION 2026-09-06 against installed 4.1.0, 4.2.4, 4.3.0 and 4.3.3: `zoom-50`, `zoom-25`, `zoom-150`, `tab-1`, `tab-4` and `tab-8` emit nothing at 4.1.0 and 4.2.4 and the expected declaration at 4.3.0 and 4.3.3.

*Reproduced against: **Claude Fable 5.1** (S2) — tailwindcss/v3-a, 2026-09-06.*

Source: [tailwindcss v4.3.0 release notes — Added](https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.3.0) · 2026-05-08 · [tailwindcss v4.3.0 release notes — Added](https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.3.0) · 2026-05-08 · [tailwindcss 4.3.0, shipped package — `zoom-50` compiles to `zoom: 50%`, `zoom-[1.5]` to `zoom: 1.5`, `tab-4` to `tab-size: 4`.](https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.3.0.tgz) · [tailwindcss 4.2.4, shipped package — `zoom-50`, `zoom-[1.5]`, `tab-4` all compile to nothing, while `[zoom:1.5]` and `[tab-size:4]` compile there and at 4.3.0 alike.](https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.2.4.tgz) · [Tailwind CSS docs — zoom, documented at v4.3](https://tailwindcss.com/docs/zoom) · [Tailwind CSS docs — tab-size, documented at v4.3](https://tailwindcss.com/docs/tab-size)

#### `pbs-* / pbe-* / mbs-* / mbe-* / border-bs-* / inline-* / block-* / min-inline-* / max-block-* / inset-bs-*`

**Added in tailwindcss 4.2.0** (2026-02-18)

Since 4.2.0 Tailwind ships first-class utilities for the CSS block axis and for logical sizing. Spacing: `pbs-*`, `pbe-*`, `mbs-*`, `mbe-*`, and the scroll variants `scroll-pbs-*`, `scroll-pbe-*`, `scroll-mbs-*`, `scroll-mbe-*`. Borders: `border-bs-*`, `border-be-*`. Sizing: `inline-*`, `min-inline-*`, `max-inline-*` for `inline-size` and its bounds, and `block-*`, `min-block-*`, `max-block-*` for `block-size`. Insets: `inset-s-*`, `inset-e-*`, `inset-bs-*`, `inset-be-*`. Do not reach for `[padding-block-start:...]` arbitrary values and do not substitute the physical `pt-*` / `mb-*` / `h-*` utilities, which are not equivalent in a vertical writing mode. The INLINE axis is the older half of the family and keeps its v3 spelling: `ps-*`, `pe-*`, `ms-*`, `me-*`. There is no `pis-*`, `pie-*`, `mis-*`, `mie-*` or `border-is-*` at any release, 4.3.3 included.

*The stale belief:* That Tailwind covers the inline axis only (`ps-*`, `ms-*`, `start-*`, `end-*`) and offers nothing for `padding-block-start`, `border-block-start`, `inline-size` or `block-size`, so a writing-mode-agnostic component needs arbitrary values or hand-written CSS. A model holding this belief will also reject working `pbs-6` / `inline-full` markup in review as classes that generate nothing.

```html

<article class="pt-6 pb-6 mb-4 border-t-2 w-full max-h-96">
  
  <article class="[padding-block-start:1.5rem] [inline-size:100%]">


<article class="pbs-6 pbe-6 mbe-4 border-bs-2 inline-full max-block-96">
  
  <div class="ps-4 me-4"></div>
</article>
```

> SEVERITY IS S3 AND THE REASON MATTERS. The arbitrary-value workaround a stale model offers (`[padding-block-start:1.5rem]`) compiles and emits the same declaration, so acting on the stale belief costs verbosity, not correctness - the workaround rule (HARNESS.md, JOURNAL/030) forbids charging that as a defect. The S2 direction is REVIEW: a model that tells the author of working `pbs-6` markup that the class does not exist and emits nothing is asserting something the compiler contradicts, and a finding charged in that direction states S2 on the run. Substituting `pt-*` for `pbs-*` is also S2, but only in a non-horizontal writing mode - in `writing-mode: horizontal-tb` the two are identical, which is why this fact does not claim the substitution is broken in general.
VERIFIED BY COMPILATION 2026-09-03, every class in `correct_code` built one at a time against installed 4.1.0, 4.2.0 and 4.3.3 with the real engine. Every 4.2.0 name emits nothing at 4.1.0 and the expected declaration at 4.2.0; `ps-4` and `me-4` emit at both; `pis-4`, `pie-4`, `mis-4`, `mie-4` and `border-is-2` emit at none of the three. That last check is the point of the `pis-*` sentence in the statement: the family has a naming scheme a reader (or a model) will over-generalise, and four of the names it suggests do not exist.
Not to be confused with the display utilities. `inline`, `block`, `inline-block` and `inline-flex` are unchanged and still set `display`; `inline-4` and `block-full` are the new sizing utilities and do not collide with them.

*Reproduced against: **Claude Opus 5** (S2) — tailwindcss/v2-a, 2026-09-03.*

Source: [tailwindcss CHANGELOG - 4.2.0 (2026-02-18), Added](https://raw.githubusercontent.com/tailwindlabs/tailwindcss/main/CHANGELOG.md) · 2026-02-18 · [tailwindcss CHANGELOG - 4.2.0 (2026-02-18), Added](https://raw.githubusercontent.com/tailwindlabs/tailwindcss/main/CHANGELOG.md) · 2026-02-18 · [tailwindcss CHANGELOG - 4.2.0 (2026-02-18), Added](https://raw.githubusercontent.com/tailwindlabs/tailwindcss/main/CHANGELOG.md) · 2026-02-18 · [tailwindcss 4.2.0, shipped package - dist/ registers pbs, pbe, mbs, mbe, border-bs, border-be, inset-s, inset-e, inset-bs, inset-be, scroll-pbs and scroll-mbe, and the engine compiles `pbs-6` to `padding-block-start: calc(var(--spacing) * 6)` and `inline-full` to `inline-size: 100%`.](https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.2.0.tgz) · [tailwindcss 4.1.0, shipped package - none of those names is registered and every one of them compiles to nothing, while `ps-4` and `me-4` compile normally. The family begins at 4.2.0 and the inline axis predates it.](https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.1.0.tgz) · [tailwindcss 4.3.3, shipped package - `pis-*`, `pie-*`, `mis-*`, `mie-*` and `border-is-*` are absent from dist/ and compile to nothing at the newest release that exists. The scheme does not generalise to the inline axis.](https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.3.3.tgz)

#### `start-* / end-*`

**Deprecated in tailwindcss 4.2.0** (2026-02-18)

As of 4.2.0 the logical inset utilities `start-*` and `end-*` are deprecated in favour of `inset-s-*` and `inset-e-*`, alongside a new family of logical-property utilities (`pbs-*`, `mbe-*`, `border-bs-*`, `inline-*`, `block-*`).

*The stale belief:* That `start-0` / `end-0` are the current logical inset utilities.

```html

<div class="absolute start-0 end-0"></div>


<div class="absolute inset-s-0 inset-e-0"></div>
```

> Published 2026-02-18, after the stated cutoff of two of the three models in this Index. Not chargeable against them - a scheduled retest, not a pass. VERIFIED AGAINST THE COMPILER 2026-09-03, because JOURNAL/041 had just found two tailwindcss facts that read a status word out of a release note and were wrong about the artifact. This one is right, and deprecated really does mean deprecated: at 4.2.0 `start-0` and `inset-s-0` compile to the SAME declaration (`inset-inline-start: calc(var(--spacing) * 0)`), so nobody's working markup broke. Do not restate this fact as `removed`. The only difference the compiler shows is cosmetic and appears later: at 4.3.3 `inset-s-0` emits the constant-folded `inset-inline-start: 0px` while `start-0` still emits the `calc()` form. Same computed value.

*Reproduced against: **Claude Opus 5** (S3) — tailwindcss/v2-a, 2026-09-03.*

Source: [tailwindcss CHANGELOG — 4.2.0 (2026-02-18), Deprecated](https://raw.githubusercontent.com/tailwindlabs/tailwindcss/main/CHANGELOG.md) · 2026-02-18 · [tailwindcss 4.2.0, shipped package - both spellings compile, and to the same declaration. `start-0` -> `inset-inline-start: calc(var(--spacing) * 0)`; `inset-s-0` -> the same string.](https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.2.0.tgz) · [tailwindcss 4.1.0, shipped package - `inset-s-0` and `inset-e-0` generate no CSS at all, and dist/ registers only the `start` and `end` utility names. The deprecation and its replacement both begin at 4.2.0.](https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.1.0.tgz)

#### `bg-gradient-*`

**Deprecated in tailwindcss 4.0.0** (2025-01-21)

Linear gradient utilities were renamed from `bg-gradient-*` to `bg-linear-*`, making room for the new `bg-radial-*` and `bg-conic-*` families and for angle values like `bg-linear-45`. The old spelling was kept as an alias, not removed: 4.x rewrites a `bg-gradient-to-*` candidate to `bg-linear-to-*` before compiling it, so v3 markup still renders a gradient. Adopt the new name for the angle and radial/conic families, not because the old one stops working. Gradients also keep their other stops when a variant overrides one — use `via-none` to drop back to a two-stop gradient in a given state.

*The stale belief:* That `bg-gradient-to-r` is the current spelling of the linear gradient utility. It is the v3 spelling, retained as an alias.

```html

<div class="bg-gradient-to-r from-indigo-500 to-pink-500"></div>


<div class="bg-linear-to-r from-indigo-500 to-pink-500"></div>
<div class="bg-linear-45 from-indigo-500 via-purple-500 to-pink-500"></div>
```

> VERIFIED 2026-09-03 (JOURNAL/041), against the shipped packages, and the statement was sharpened as a result. It previously said only that the utilities were "renamed", which reads as the old name being gone; the note under it hedged that the old name had not been verified to stop working. It has now been verified to keep working. `tools/audit/css-audit.mjs` built `bg-gradient-to-r` against tailwindcss 4.0.0 and 4.3.3: it generates at both, and at 4.0.0 its declarations are identical to `bg-linear-to-r`'s. The alias is explicit in the shipped bundle — the candidate parser rewrites a root beginning `bg-gradient-to-` to `bg-linear-to-` — which is why the two directional families cannot diverge. Only `bg-linear-45` and the `bg-radial-*` / `bg-conic-*` families are genuinely new surface.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS v4.0 announcement — Expanded gradient APIs](https://tailwindcss.com/blog/tailwindcss-v4) · 2025-01-22 · [tailwindcss CHANGELOG — bg-linear-* alias](https://raw.githubusercontent.com/tailwindlabs/tailwindcss/main/CHANGELOG.md) · [tailwindcss 4.3.3, shipped package — dist/lib.mjs rewrites a bg-gradient-to-* root to bg-linear-to-*](https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.3.3.tgz)

#### `flex-shrink-* / flex-grow-* / overflow-ellipsis / decoration-slice / decoration-clone`

**Deprecated in tailwindcss 4.0.0** (2025-01-21)

These v3 aliases were dropped from the documentation, not from the compiler. `flex-shrink-*`, `flex-grow-*`, `overflow-ellipsis`, `decoration-slice` and `decoration-clone` are still registered utilities in every 4.x release and emit exactly the same declarations as `shrink-*`, `grow-*`, `text-ellipsis`, `box-decoration-slice` and `box-decoration-clone`. Markup carrying the old names keeps working and renders identically. Adopt the new spellings because the old ones are undocumented and no longer suggested by tooling — not because anything breaks.

*The stale belief:* That `flex-shrink-0` is the current, documented spelling. It is the v3 spelling: it still compiles to `flex-shrink: 0`, and it is no longer in the docs.

```html

<img class="flex-shrink-0" /> <div class="flex-grow">…</div>


<img class="shrink-0" /> <div class="grow">…</div>
```

> CORRECTED 2026-09-03 (JOURNAL/041), against the shipped packages. This entry previously filed the five aliases as `removed` at S1 breaks-build, on the upgrade guide's line "We've removed any utilities that were deprecated in v3". That line is about the documentation. The compiler never dropped them: `tools/audit/css-audit.mjs` built each stale class against tailwindcss 4.0.0, 4.1.0, 4.2.0 and 4.3.3 and every one generated CSS byte-identical to the replacement this fact prescribes — `.flex-shrink-0 { flex-shrink: 0; }` beside `.shrink-0 { flex-shrink: 0; }`, and the same for the other four. The mechanism is visible in the shipped bundle: each name is registered with `utilities.functional(...)` or `utilities.static(...)` and paired with `utilities.suggest(<name>, () => [])`, an empty suggestion list — registered, and hidden from tooling. A reader following the old entry was told their working markup broke the build. It does not. Same defect class as valibot LF3 (JOURNAL/040): a release note that is accurate about the intent and wrong about the artifact.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Removed deprecated utilities" (accurate about the docs, not about the compiler)](https://tailwindcss.com/docs/upgrade-guide) · [tailwindcss 4.0.0, shipped package — dist/lib.mjs still registers flex-shrink, flex-grow, overflow-ellipsis, decoration-slice and decoration-clone](https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.0.0.tgz) · [tailwindcss 4.3.3, shipped package — the same five, each beside an empty utilities.suggest() list](https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.3.3.tgz)

#### the important modifier (!flex)

**Deprecated in tailwindcss 4.0.0** (2025-01-21)

The `!` that marks a utility important moved from the start of the class name to the end: `!flex` becomes `flex!`, `hover:!bg-red-600` becomes `hover:bg-red-600!`. The leading form is still supported for compatibility but is deprecated.

*The stale belief:* That the important marker goes after the variants and before the utility.

```html

<div class="!flex hover:!bg-red-600"></div>


<div class="flex! hover:bg-red-600!"></div>
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "The important modifier"](https://tailwindcss.com/docs/upgrade-guide)

#### theme() function

**Deprecated in tailwindcss 4.0.0** (2025-01-21)

Prefer the generated CSS variables over `theme()`. The dot path is **deprecated, not removed**: `theme(colors.red.500)` and `theme(screens.xl)` still resolve in v4 and compile to exactly the same declarations as `theme(--color-red-500)` and `theme(--breakpoint-xl)`. Write the CSS-variable form in new code — `var(--color-red-500)` outside media queries, `theme(--breakpoint-xl)` inside them, where CSS variables are not supported — but existing dot-path stylesheets are not broken and do not need an urgent migration.

*The stale belief:* That theme values are addressed with dot notation, `theme(colors.red.500)`, and that this is the current idiom rather than a deprecated one.

```css
/* Stale */
.my-class { background-color: theme(colors.red.500); }
@media (width >= theme(screens.xl)) { }

/* Current */
.my-class { background-color: var(--color-red-500); }
@media (width >= theme(--breakpoint-xl)) { }
```

> Do not tell readers the dot path stopped working. Verified by compiling the four forms with the installed Tailwind engine at both 4.0.0 and 4.3.3: `theme(colors.red.500)` and `theme(--color-red-500)` both emit `color: oklch(0.637 0.237 25.331)`, and `theme(screens.xl)` and `theme(--breakpoint-xl)` both emit `@media (min-width: 80rem)`. The upgrade guide says you *should* use the variable name; it does not say the dot path is rejected, and the v4 line has gone on fixing dot-path resolution in JS plugins and config files (4.3.3 fixes `theme('colors.foo')` lookups). Fourth fact in this pack found asserting a break that the shipped artifact does not perform — see LF5 and LF27.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Using the theme() function" (advice, not a removal)](https://tailwindcss.com/docs/upgrade-guide) · [tailwindcss CHANGELOG — 4.3.3 still fixing dot-path theme() resolution](https://github.com/tailwindlabs/tailwindcss/blob/main/CHANGELOG.md) · 2026-07-16

### Wrong facts about the library

Not code — versions, minimums and metadata that models state confidently and get wrong.

#### browser support baseline

**New requirement in tailwindcss 4.0.0** (2025-01-21)

v4 targets Safari 16.4+, Chrome 111+ and Firefox 128+, because it depends on `@property` and `color-mix()` for core features. It will not work in older browsers; projects that must support them should stay on v3.4.

*The stale belief:* That upgrading to the current major is browser-support-neutral.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Tailwind CSS docs — Upgrade guide, "Browser requirements"](https://tailwindcss.com/docs/upgrade-guide)

## Not corrections — recorded for honesty

Claims seen in a run but not yet verified against a primary source. Never treated as findings:

- The battery's two most derivable-looking probes were derived by the subject furthest below the floor, not the nearest. Claude Sonnet 5 (2026-01) produced the correct `@variant` stacked and compound syntax and the correct `tab-*` scale; Claude Opus 5 (2026-05, three weeks nearer the release) got both wrong and derived only `@container-size`. Nothing in the Index predicts which control derives what, and distance below the floor evidently does not. *(open since 2026-09-06)*
- Does the block-axis denial survive a probe that does not mention writing modes? Every task in this battery framed the need through vertical-rl, which is a rare enough layout that a subject may be reasoning "Tailwind would not bother" rather than recalling. A probe that asks for the same utilities in a plain horizontal document would separate the two, and it bounds how far F1 generalises: a belief held only under an exotic framing is a weaker prior than one held in ordinary markup. *(open since 2026-09-03)*
- The model gave the v4 shadow-sm value as `0 1px 3px 0 rgb(0 0 0 / 0.1), 0 1px 2px -1px rgb(0 0 0 / 0.1)` and shadow-xs as `0 1px 2px 0 rgb(0 0 0 / 0.05)`. The direction of the rename is verified against the upgrade guide; the exact pixel values were not checked against the shipped theme.css. *(open since 2026-08-31)*
- The model gave shadow-sm as `0 1px 3px 0 rgb(0 0 0 / 0.1), 0 1px 2px -1px rgb(0 0 0 / 0.1)`. The direction of the scale rename is verified against the upgrade guide, but the exact pixel values of the v4 shadow scale were not independently checked against the shipped theme.css. *(open since 2026-08-31)*

---

*Findings, code and citations: `data/tailwindcss/` — one JSON file and one write-up per model, each finding carrying the release that broke the belief, its publication date and a verbatim quote from the primary source. Corrections: `data/tailwindcss/facts.json`. This file is generated by `tools/build-corrections.mjs`; if the prose and the data ever disagree, that is a bug in the generator, not a stale pack.*

==============================================================================
CORRECTION PACK: valibot (https://stalepriors.com/corrections/valibot.md)

# valibot correction pack · for projects on valibot@^1.2


## What we actually measured

5 Claude models were asked for idiomatic valibot code with no tools, purely from training knowledge. 13 reproduced failures across 20 runs, each verified against the release that broke the belief.

| Model | Stated cutoff | valibot version attribution stops | Lag inside the window |
|---|---|---|---|
| Claude Fable 5.1 | 2026-06 | 1.1.0 · 2025-05-06 | ~13 months |
| Claude Opus 5 | 2026-05 | 1.1.0 · 2025-05-06 | ~12 months |
| Claude Sonnet 5 | 2026-01 | 1.0.0 · 2025-03-19 | ~10 months |
| Claude Fable 5 | 2026-01 | 1.1.0 · 2025-05-06 | ~8 months |

A recent cutoff is not a defence. Every model here loses track of this library's release history well before the date it states as its own cutoff, and the stopping points cluster far tighter than the cutoffs do.

Read that column precisely. It is the newest valibot release whose contents the model can correctly **attribute to that release** — not the newest valibot feature it knows. Past that point a model will often write working code with a newer API while naming the wrong release for it, and that guess runs *early* — it names a release older than the one that shipped the feature. So the question this pack answers is not "does the model know this API" but "can it be trusted about which version the API arrived in" — which is the question that matters when you are pinned to a version.

## How to read an entry

Every entry ends with a *Reproduced against* line. Where it names models, we have the generated code that got it wrong, dated, with the model's own words in the run write-up. Where it says no model yet, the correction is verified from the release notes but nothing has been probed for it — it is a fix, not a measurement, and the pack says so rather than blurring the two.

The section an entry sits in is the worst case if you act on the stale belief. The severity in brackets after a model's name is what that particular model's output actually did, which can be milder — a model can hold the wrong belief and still, on the day, write code that runs.

## The corrections

### Breaks the build, or throws at runtime

Act on the stale belief here and the code does not run. Fix these first.

#### `NanoIDAction / NanoIDIssue`

**Renamed in valibot 1.1.0** (2025-05-06)

The `NanoIDAction` and `NanoIDIssue` interfaces were renamed to `NanoIdAction` and `NanoIdIssue` in 1.1.0. The old casing is not exported and a type import of it fails to compile.

*The stale belief:* That the nano-ID action's types spell the acronym in full caps, as they did up to 1.0.0.

```ts
// Stale
import type { NanoIDAction } from 'valibot'

function describe(action: NanoIDAction<string, undefined>) {
  return action.type
}

// Current
import type { NanoIdAction } from 'valibot'

function describe(action: NanoIdAction<string, undefined>) {
  return action.type
}
```

> A type-level break only: the runtime `nanoid()` action itself was not renamed. It surfaces at compile time, not at runtime.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [valibot v1.1.0 release notes](https://github.com/open-circle/valibot/releases/tag/v1.1.0) · 2025-05-06

### Runs, but is silently wrong

Nothing errors. The behaviour is simply not what a model trained earlier will tell you.

#### `toNumber / toBoolean / toDate / toBigint / toString`

**Added in valibot 1.2.0** (2025-11-24)

valibot ships dedicated string-to-primitive transformation actions since 1.2.0: `toBigint`, `toBoolean`, `toDate`, `toNumber` and `toString`. Use `toNumber` instead of a bare `transform(Number)`: `toNumber` adds a validation issue when the conversion yields `NaN`, whereas `pipe(string(), transform(Number))` returns `NaN` with `success: true` and hands silently-wrong data downstream. **`toBoolean` is the exception and is not a string parser** — it applies JavaScript `Boolean()`, so the string `"false"` converts to `true`. For the common case of a `"true"`/`"false"` query parameter use `parseBoolean` (1.3.0) or validate the literals with `picklist` before transforming.

*The stale belief:* That valibot has no built-in string-to-primitive conversion at all and every such conversion must go through a hand-written `transform(Number)` or `transform((s) => s === "true")`.

**The code below needs valibot 1.3.0 or later.** Between 1.2.0 and 1.3.0 this correction does not apply — see the note.

```ts
// Stale
import * as v from 'valibot'

const Query = v.object({
  // Number("abc") is NaN, and this pipe returns it with success: true
  page: v.pipe(v.string(), v.transform(Number)),
})

// Current
import * as v from 'valibot'

const Query = v.object({
  // toNumber raises a validation issue instead of yielding NaN
  page: v.pipe(v.string(), v.toNumber()),

  // NOT v.toBoolean() — that is Boolean(), and Boolean("false") is true.
  // parseBoolean (1.3.0) reads the literal words:
  active: v.pipe(v.string(), v.parseBoolean()),

  // on valibot < 1.3.0, validate the literals first:
  // active: v.pipe(v.picklist(["true", "false"]), v.transform((s) => s === "true")),
})
```

> CORRECTED 2026-09-02 (JOURNAL/035), against the shipped package. This entry previously told readers to write `v.pipe(v.string(), v.toBoolean())` for a `"true"`/`"false"` query parameter, and justified the whole fact on the claim that the built-in avoids the `Boolean("false") === true` trap that `transform(Boolean)` falls into. **That justification was false and the recommended code was a bug.** valibot 1.4.2's `toBoolean` is `dataset.value = Boolean(dataset.value)` — literally the same call — so it maps `"false"`, `"0"`, `"no"` and every other non-empty string to `true`. Executed and confirmed: `parse(pipe(string(), toBoolean()), "false")` returns `true`. The word-reading action is `parseBoolean`, which arrived in 1.3.0 (see LF11) and returns `false` for `"false"`. The fact survives on the `toNumber` half, where the built-in genuinely is safer than the hand-roll, and that is now the stated mechanism. The error was caught by the battery `valibot/v2` pre-registration, which required every scored claim to be re-executed against the installed package — and by six test draws that denied these actions exist while independently warning that `Boolean("false")` is `true`. They were right about that and the Index was wrong. ARCHAEOLOGY, 2026-09-02: a subject asserted, inside a run, that valibot USED to have a `coerce` action and that it was deliberately removed. That history is correct. The v0.31.0 migration guide states that `coerce` was removed and why, and maps it onto `pipe` + `unknown` + `transform`. So the belief that produced the wrong answer was not a false memory of the removal but the assumption that nothing replaced it: the generic `coerce` is gone, and the dedicated actions above arrived in 1.2.0, six releases later.

*Reproduced against: **Claude Fable 5** (S2), **Claude Opus 5** (S2), **Claude Sonnet 5** (S2) — valibot/v2-a, 2026-09-02; valibot/v2-c, 2026-09-02; valibot/v2-e, 2026-09-02.*

Source: [valibot v1.2.0 release notes](https://github.com/open-circle/valibot/releases/tag/v1.2.0) · 2025-11-24 · [valibot 1.4.2, shipped package — the toBoolean implementation](https://registry.npmjs.org/valibot/-/valibot-1.4.2.tgz) · 2026-06-28 · [valibot — Migrate to v0.31.0, Coerce method](https://valibot.dev/guides/migrate-to-v0.31.0/)

#### `emoji`

**Behaviour changed in valibot 1.2.0** (2025-11-24)

The regular expression behind the `emoji` validation action carried a ReDoS vulnerability that was fixed in 1.2.0. If you validate user-supplied text with the `emoji` action, require valibot >= 1.2.0. Advice that recommends the action without that version floor exposes the caller to a denial-of-service on attacker-controlled input.

*The stale belief:* That the `emoji` action is safe to run on untrusted, high-volume input at any 1.x version.

```ts
// package.json
// "valibot": "^1.2.0"   <- 1.2.0 fixed the ReDoS in EMOJI_REGEX

import * as v from 'valibot'

const Reaction = v.pipe(v.string(), v.emoji())
```

> Verified only to the extent the vendor's own release notes state it: the notes list the fix. This entry claims the fix landed in 1.2.0 and that earlier 1.x is affected; it does not characterise the exploit, which was not published in the release notes.

*Reproduced against: **Claude Fable 5** (S2) — valibot/v1, 2026-09-01.*

Source: [valibot v1.2.0 release notes](https://github.com/open-circle/valibot/releases/tag/v1.2.0) · 2025-11-24

### Deprecated, or a better API now exists

Works today. It is the older idiom, and some of it is scheduled for removal.

#### `guard / parseBoolean / isrc / domain / jwsCompact / cache`

**Added in valibot 1.3.0** (2026-03-17)

valibot 1.3.0 added the `guard` transformation action (narrow types with a type predicate), `parseBoolean`, the `isrc`, `domain` and `jwsCompact` validation actions, and a `cache` method that caches schema output by input. It also fixed `creditCard` to accept 13-digit Visa numbers.

*The stale belief:* That domain-name, ISRC and JWS-compact validation, and schema-level output caching, have no built-in support in valibot.

```ts
import * as v from 'valibot'

const Host = v.pipe(v.string(), v.domain())
const Token = v.pipe(v.string(), v.jwsCompact())
```

> PROBED 2026-09-05 by battery valibot/v3 (JOURNAL/055) on the guard and cache halves: all five arms denied both capabilities. Charged twice against Claude Opus 5 on v3-c (F1 guard S3, F2 cache S3). 1.3.0 is admissible against Claude Opus 5 (stated 2026-05) and against Claude Fable 5.1 (stated 2026-06), and below the floor for Claude Sonnet 5 and Claude Fable 5. Both Fable 5.1 arms failed it and neither could be charged: see JOURNAL/055 on the direct-question wording that barred them. The isrc, domain and jwsCompact surfaces were deliberately NOT probed - each is named for the standard it validates, so the probe would measure naming rather than knowledge. CROSS-REFERENCE 2026-09-02 (JOURNAL/035): `parseBoolean` is the action that reads the literal words `"true"`/`"false"` (and `1`/`0`, `yes`/`no`, `on`/`off`, `enabled`/`disabled`, case-insensitively, rejecting anything else). It is **not** interchangeable with 1.2.0's `toBoolean`, which is plain `Boolean()` and maps `"false"` to `true` — see the correction on LF1. A project on valibot < 1.3.0 that needs to read a boolean query parameter has no built-in for it and must validate the literals with `picklist` first. Executed against valibot 1.4.2: `parse(pipe(string(), parseBoolean()), "false")` returns `false`; the empty string is rejected with an issue rather than coerced.

*Reproduced against: **Claude Fable 5.1** (S3), **Claude Opus 5** (S3) — valibot/v3-c, 2026-09-05; valibot/v4-a, 2026-09-06.*

Source: [valibot v1.3.0 release notes](https://github.com/open-circle/valibot/releases/tag/v1.3.0) · 2026-03-17 · [valibot v1.3.0 release notes — creditCard fix](https://github.com/open-circle/valibot/releases/tag/v1.3.0) · 2026-03-17 · [valibot 1.4.2, shipped package — parseBoolean truthy/falsy word lists](https://registry.npmjs.org/valibot/-/valibot-1.4.2.tgz) · 2026-06-28

#### `toCamelCase / toKebabCase / toPascalCase / toSnakeCase`

**Added in valibot 1.4.0** (2026-05-05)

valibot 1.4.0 added case-conversion transformation actions (`toCamelCase`, `toKebabCase`, `toPascalCase`, `toSnakeCase`) and the `isoDateTimeSecond` validation action. It also made `intersect` stop mutating its input, so frozen objects and arrays can be merged.

*The stale belief:* That valibot has no built-in naming-convention conversions, and that `intersect` cannot be used with frozen inputs.

```ts
import * as v from 'valibot'

const Slug = v.pipe(v.string(), v.toKebabCase())
```

> PROBED 2026-09-05 by battery valibot/v3 (JOURNAL/055) on the case-conversion half, in both directions. All five arms denied the capability in the offer direction, and all five rejected a pull request using toKebabCase in the recognition direction - calling a real action an invention. NOTHING CHARGED: 1.4.0 published 2026-05-05, the same month as Claude Opus 5s stated cutoff, so the Index parks it against that subject; Claude Fable 5.1 (stated 2026-06) is the one subject it is admissible against, and both of its arms declined their stated cutoff. Five reproduced failures, zero charged, every one flagged chargeable_miss. Verified this session by installing 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0 and 1.4.2 and diffing their exports: toUpperCase and toLowerCase are present at 1.0.0, so a draw that says valibot has upper/lower and nothing for camel/kebab/snake states the precise pre-1.4.0 truth. toTitleCase, used as this batterys poison rung, has never shipped in any release and is absent from all six export tables.

*Reproduced against: **Claude Fable 5.1** (S2) — valibot/v4-a, 2026-09-06.*

Source: [valibot v1.4.0 release notes](https://github.com/open-circle/valibot/releases/tag/v1.4.0) · 2026-05-05 · [valibot v1.4.0 release notes — intersect](https://github.com/open-circle/valibot/releases/tag/v1.4.0) · 2026-05-05

#### `isbn`

**Added in valibot 1.3.0** (2026-03-17)

valibot ships an `isbn` validation action covering ISBN-10 and ISBN-13, and it is usable from **1.3.0**, not from 1.2.0. The v1.2.0 release notes announce it — the implementation was merged the day before that release — but 1.2.0's `library/src/actions/index.ts` never re-exports it, so the published 1.2.0 package contains no trace of `isbn` in its runtime, its types or its bundle. The export line appears at 1.3.0, and 1.3.0's own release notes do not mention `isbn` at all. On valibot 1.2.x the hand-written check digit is still the only option.

*The stale belief:* That valibot has no ISBN validator at any version and the check digit must be implemented by hand in a custom `check`. (Correct for every release up to and including 1.2.x; wrong from 1.3.0.)

```ts
// Stale
import * as v from 'valibot'

const Book = v.object({
  id: v.pipe(v.string(), v.check((s) => /^(?:\d{9}[\dX]|\d{13})$/.test(s), 'Invalid ISBN')),
})

// Current
import * as v from 'valibot'

const Book = v.object({
  id: v.pipe(v.string(), v.isbn()),
})
```

> CORRECTED 2026-09-02 (JOURNAL/040), by the Node auditor. This entry was filed at **1.2.0 / 2025-11-24** on the strength of the v1.2.0 release note quoted below, and the audit at 1.2.0 failed with TS2339: `Property 'isbn' does not exist`. The shipped 1.2.0 package has **zero occurrences of the string `isbn`** in `index.mjs`, `index.cjs`, `index.d.mts`, `index.d.cts` or either minified bundle. Cause, from the tagged source: PR #1097 (`feat: ISBN validation`) merged 2025-11-23, one day before the tag, and `library/src/actions/isbn/isbn.ts` is present at tag `v1.2.0` — but `library/src/actions/index.ts` at that tag goes straight from `ipv6` to `isoDate`, so the module was never wired into the public entry point and was dropped from the bundle. The barrel line `export * from './isbn/index.ts';` first appears at tag `v1.3.0`. **Neither release's notes are true about which release made this usable**: 1.2.0 announces an action its own package does not contain, and 1.3.0 ships it without a word. This is the second instance in the Index of a release note that is wrong about its own release (JOURNAL/027 is the first) and the first that was caught by the auditor rather than by hand. **One published finding was withdrawn as a result**: `valibot--claude-fable-5--v1--2026-09-01` F2 charged Fable 5 (stated cutoff 2026-01) for denying that `isbn` exists — an answer that was true of every valibot release that existed at that cutoff. It is now recorded as a correct answer in that run's non-findings. The Opus 5 charge (stated cutoff 2026-05) survives the date move and is re-cited here.

*Reproduced against: **Claude Opus 5** (S3) — valibot/v1, 2026-09-01.*

Source: [valibot v1.2.0 release notes — the announcement the package does not honour](https://github.com/open-circle/valibot/releases/tag/v1.2.0) · 2025-11-24 · [valibot source at tag v1.2.0 — the action barrel, with no isbn line between ipv6 and isoDate](https://raw.githubusercontent.com/open-circle/valibot/v1.2.0/library/src/actions/index.ts) · 2025-11-24 · [valibot 1.2.0, shipped package — the export list in dist/index.d.mts skips isbn](https://registry.npmjs.org/valibot/-/valibot-1.2.0.tgz) · 2025-11-24 · [valibot source at tag v1.3.0 — the barrel line that first publishes the action](https://raw.githubusercontent.com/open-circle/valibot/v1.3.0/library/src/actions/index.ts) · 2026-03-17 · [valibot 1.3.0, shipped package — the same export list, now carrying isbn](https://registry.npmjs.org/valibot/-/valibot-1.3.0.tgz) · 2026-03-17

#### `examples / getExamples`

**Added in valibot 1.2.0** (2025-11-24)

valibot has first-class example values since 1.2.0: the `examples` action attaches them to a schema and the `getExamples` method reads them back. Do not overload `description` or a custom metadata action to carry examples.

*The stale belief:* That valibot's metadata surface is limited to title/description and examples must be stored outside the schema.

```ts
// Stale
import * as v from 'valibot'

const Email = v.pipe(
  v.string(),
  v.email(),
  v.description('An email address, e.g. a@b.com')
)

// Current
import * as v from 'valibot'

const Email = v.pipe(
  v.string(),
  v.email(),
  v.examples(['a@b.com', 'c@d.org'])
)

const examples = v.getExamples(Email)
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [valibot v1.2.0 release notes](https://github.com/open-circle/valibot/releases/tag/v1.2.0) · 2025-11-24 · [valibot v1.2.0 release notes — getExamples](https://github.com/open-circle/valibot/releases/tag/v1.2.0) · 2025-11-24

#### `message`

**Added in valibot 1.1.0** (2025-05-06)

valibot ships a `message` method since 1.1.0 that overrides the error message configuration for one schema locally, without touching global config.

*The stale belief:* That per-schema message overrides must be passed argument-by-argument to each action, or set globally with `setGlobalMessage`.

```ts
// Stale
import * as v from 'valibot'

v.setGlobalMessage('Invalid input')  // global — affects everything

// Current
import * as v from 'valibot'

const Port = v.message(
  v.pipe(v.number(), v.minValue(1), v.maxValue(65535)),
  'Port must be between 1 and 65535'
)
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [valibot v1.1.0 release notes](https://github.com/open-circle/valibot/releases/tag/v1.1.0) · 2025-05-06

#### `parseJson / stringifyJson`

**Added in valibot 1.1.0** (2025-05-06)

valibot ships `parseJson` and `stringifyJson` transformation actions since 1.1.0. Parsing JSON inside the pipeline makes a malformed string surface as a valibot issue like any other, instead of as a thrown `SyntaxError` you have to catch separately.

*The stale belief:* That JSON must be parsed outside the schema, with its own try/catch, before validation can begin.

```ts
// Stale
import * as v from 'valibot'

let data
try {
  data = JSON.parse(raw)
} catch {
  throw new Error('malformed JSON')
}
const config = v.parse(Config, data)

// Current
import * as v from 'valibot'

const Config = v.pipe(
  v.string(),
  v.parseJson(),
  v.object({ port: v.number() })
)

const result = v.safeParse(Config, raw)
// a malformed string and a schema violation are both issues now
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [valibot v1.1.0 release notes](https://github.com/open-circle/valibot/releases/tag/v1.1.0) · 2025-05-06

#### `summarize`

**Added in valibot 1.1.0** (2025-05-06)

valibot ships a `summarize` method since 1.1.0 that turns an issue list into a pretty-printable multi-line string. Use it instead of looping over issues to build a human-readable error report.

*The stale belief:* That rendering issues for a human requires a hand-written loop over `result.issues` or a `flatten` call.

```ts
// Stale
import * as v from 'valibot'

const result = v.safeParse(Schema, input)
if (!result.success) {
  console.error(result.issues.map((i) => `- ${i.message}`).join('\n'))
}

// Current
import * as v from 'valibot'

const result = v.safeParse(Schema, input)
if (!result.success) {
  console.error(v.summarize(result.issues))
}
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [valibot v1.1.0 release notes](https://github.com/open-circle/valibot/releases/tag/v1.1.0) · 2025-05-06

#### `exactOptional`

**Added in valibot 1.0.0** (2025-03-19)

valibot has `exactOptional` and `exactOptionalAsync` since 1.0.0, for a key that may be absent entirely but must not be present and set to `undefined`. `optional` allows both.

*The stale belief:* That valibot cannot express the difference between a missing key and a key explicitly set to undefined.

```ts
// Stale
import * as v from 'valibot'

// allows { name: undefined } as well as {}
const User = v.object({ name: v.optional(v.string()) })

// Current
import * as v from 'valibot'

// allows {} but rejects { name: undefined }
const User = v.object({ name: v.exactOptional(v.string()) })
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [valibot v1.0.0 release notes](https://github.com/open-circle/valibot/releases/tag/v1.0.0) · 2025-03-19

### Wrong facts about the library

Not code — versions, minimums and metadata that models state confidently and get wrong.

#### `github.com/fabian-hiller/valibot`

**Renamed in valibot 1.2.0** (2025-11-24)

valibot's repository is `github.com/open-circle/valibot`. It moved out of the `fabian-hiller` personal namespace into the `open-circle` organisation, and the npm `repository` field flipped with the 1.2.0 release. The old URL still 301-redirects, so a link to it works — but attributing the project to a personal account is wrong about who maintains it.

*The stale belief:* That valibot is a personal project living at `github.com/fabian-hiller/valibot`.

```text
# Stale
https://github.com/fabian-hiller/valibot

# Current
https://github.com/open-circle/valibot
```

> Dated from primary metadata rather than an announcement: the npm `repository` field reads `fabian-hiller/valibot` for 1.0.0 and 1.1.0 and `open-circle/valibot` from 1.2.0 onward. The docs site remains valibot.dev.

*Reproduced against: **Claude Fable 5** (S4), **Claude Opus 5** (S4), **Claude Sonnet 5** (S4) — valibot/v1, 2026-09-01.*

Source: [npm registry metadata for valibot — repository field per version](https://registry.npmjs.org/valibot) · 2025-11-24

## Not corrections — recorded for honesty

Claims seen in a run but not yet verified against a primary source. Never treated as findings:

- Direct question (b) in this battery asked the subject which cutoff it would trust — the context value or its own sense — and both Claude Fable 5.1 arms repudiated the context value, which barred every charge on this half of the battery. `valibot/v2`, which asked the plain "What is your training cutoff?", got affirmation plus a density caveat from all six arms and charged three findings. Is the repudiation a property of this subject or of the question? *(open since 2026-09-05)*
- The subject asserts valibot's `EMOJI_REGEX` was rewritten to `\p{RGI_Emoji}` with the ES2024 regex `v` flag, and that on older runtimes this is a load-time syntax error rather than a graceful failure. Not verified against a primary source in this run. If true it is a second, independent fact about the same action and belongs in the facts file. *(open since 2026-09-01)*
- Both valibot draws landed one release below `valibot/v1` while agreeing exactly with each other. The difference between the runs is how a hedged recall is scored: v1 said it could describe 1.1.0 "with moderate confidence" and was scored at 1.1.0; these draws called 1.1.0 a version number with no content and were scored at 1.0.0. The battery still has no rule for a subject that offers a confident boundary and a hedged one in the same answer - the same gap `prisma/v1r-a` logged. Two libraries have now hit it. *(open since 2026-09-01)*
- This draw asserted that valibot removed a `coerce` action in the 0.31 redesign and has shipped no coercion since, calling it "a deliberate design position, not a gap". The first half is a claim about pre-1.0 history the Index has never verified; the second half is false as of 1.2.0. Worth pinning from the 0.31.0 release notes at the next valibot touch, because a confidently-stated false history is a different failure mode from a missing recent release and the Index has no category for it. *(open since 2026-09-01)*
- Whether the `emoji` action's regex was rewritten to use `\p{RGI_Emoji}` with the ES2024 regex `v` flag, as the Fable 5 run asserts, and if so in which release. Relevant because it would mean the action carries a runtime floor (Node 20+) in addition to the 1.2.0 ReDoS fix. *(open since 2026-09-01)*

---

*Findings, code and citations: `data/valibot/` — one JSON file and one write-up per model, each finding carrying the release that broke the belief, its publication date and a verbatim quote from the primary source. Corrections: `data/valibot/facts.json`. This file is generated by `tools/build-corrections.mjs`; if the prose and the data ever disagree, that is a bug in the generator, not a stale pack.*

==============================================================================
CORRECTION PACK: zod (https://stalepriors.com/corrections/zod.md)

# zod correction pack · for projects on zod@^4


## What we actually measured

4 Claude models were asked for idiomatic zod code with no tools, purely from training knowledge. 38 reproduced failures across 18 runs, each verified against the release that broke the belief.

| Model | Stated cutoff | zod version attribution stops | Lag inside the window |
|---|---|---|---|
| Claude Opus 5 | 2026-05 | 4.1.0 · 2025-08-23 | ~9 months |
| Claude Sonnet 5 | 2026-01 | 4.0.0 · 2025-07-10 | ~6 months |
| Claude Fable 5 | 2026-01 | 4.1.0 · 2025-08-23 | ~5 months |

A recent cutoff is not a defence. Every model here loses track of this library's release history well before the date it states as its own cutoff, and the stopping points cluster far tighter than the cutoffs do.

Read that column precisely. It is the newest zod release whose contents the model can correctly **attribute to that release** — not the newest zod feature it knows. Past that point a model will often write working code with a newer API while naming the wrong release for it, and that guess runs *early* — it names a release older than the one that shipped the feature. So the question this pack answers is not "does the model know this API" but "can it be trusted about which version the API arrived in" — which is the question that matters when you are pinned to a version.

Latest zod is **4.5.4** (verified 2026-08-31). Separately from the corrections below, 4 of 18 runs recorded a version fact — the model named a current zod version from memory and was behind. If a model states a version without checking, assume it is behind and check the registry.

## How to read an entry

Every entry ends with a *Reproduced against* line. Where it names models, we have the generated code that got it wrong, dated, with the model's own words in the run write-up. Where it says no model yet, the correction is verified from the release notes but nothing has been probed for it — it is a fix, not a measurement, and the pack says so rather than blurring the two.

The section an entry sits in is the worst case if you act on the stale belief. The severity in brackets after a model's name is what that particular model's output actually did, which can be milder — a model can hold the wrong belief and still, on the day, write code that runs.

## The corrections

### Breaks the build, or throws at runtime

Act on the stale belief here and the code does not run. Fix these first.

#### .pick() / .omit() on a schema with refinements

**Now throws in zod 4.3.0** (2025-12-31)

`.pick()` and `.omit()` throw when called on an object schema that carries a refinement. They no longer silently drop the refinement. Rebuild from the shape instead: `z.object(schema.shape).pick({ ... })`.

*The stale belief:* That `.pick()`/`.omit()` on a refined schema succeeds and quietly discards the refinement — true up to 4.2.

```ts
// Stale
const Signup = z.object({
  password: z.string(),
  confirmPassword: z.string(),
}).refine((d) => d.password === d.confirmPassword);

Signup.pick({ password: true });   // 4.3+: throws

// Current
const shape = { password: z.string(), confirmPassword: z.string() };
const Signup = z.object(shape).refine((d) => d.password === d.confirmPassword);

z.object(shape).pick({ password: true });   // derive from the unrefined base
```

> The durable rule for this whole cluster: keep an unrefined `z.object({...})` base, derive every variant from that, and apply `.refine()` last.

*Reproduced against: **Claude Fable 5** (S1), **Claude Opus 5** (S1), **Claude Sonnet 5** (S1) — zod/v2, 2026-08-29; zod/v3-a, 2026-09-02; zod/v4-a, 2026-09-02.*

Source: [Zod 4.3.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.3.0) · 2025-12-31

#### .extend() overwriting a property on a refined schema

**Now throws in zod 4.3.0** (2025-12-31)

`.extend()` throws when it overwrites an existing property on a schema that has refinements. Use `.safeExtend()`, which preserves the refinement and statically prevents you from changing a property's type signature.

*The stale belief:* That `.extend()` may freely overwrite properties on any object schema.

```ts
// Stale
const A = z.object({ a: z.string() }).refine(/* ... */);
A.extend({ a: z.number() });        // 4.3+: throws

// Current
A.safeExtend({ a: z.string().min(5).max(10) });   // allowed, refinement preserved
```

> `.safeExtend()` has existed since 4.1.0, so it is safe to use on any 4.1+ project.

*Reproduced against: **Claude Opus 5** (S1), **Claude Sonnet 5** (S1) — zod/v2, 2026-08-29.*

Source: [Zod 4.3.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.3.0) · 2025-12-31 · [Zod 4.1.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.1.0) · 2025-08-23

#### `z.record()`

**Removed in zod 4.0.0** (2025-07-10)

Write `z.record(keySchema, valueSchema)`. It is the only form that works across the whole v4 line. Zod 4.0 removed the v3 single-argument form; 4.4.0 restored it **at runtime only** — the type declaration was never given a one-argument overload, so `z.record(z.number())` still fails to compile on every v4 release including 4.5.4 (`TS2554: Expected 2-3 arguments, but got 1`). In JavaScript, or with the type error suppressed, the single-argument call behaves differently either side of 4.4.0: on 4.0.0–4.3.6 it constructs and then rejects every key with `invalid_key`, and from 4.4.0 it validates values as the v3 form did.

*The stale belief:* That `z.record(z.number())` — the Zod 3 single-argument form — is current. Or, after reading the 4.4.0 release note, that it is current again.

```ts
// Stale
z.record(z.number());   // TS2554 on every v4 release; also rejects every key before 4.4.0

// Current
z.record(z.string(), z.number());
```

> Re-verified 2026-09-02 against the shipped packages rather than the release note, and the release note is the trap. `tsc --strict` reports TS2554 on 4.3.6, 4.4.0, 4.4.3 and 4.5.4 alike, and `v4/classic/schemas.d.ts` declares the same single two-argument `record` overload byte-identically from 4.0.0 through 4.5.4. The runtime half is true and was executed: at 4.0.0 and 4.3.6 `z.record(z.number()).safeParse({a:1})` fails `invalid_key`; at 4.4.0 and 4.5.4 it passes, and `{a:"nope"}` fails `invalid_type` — so the single argument really is the value schema again. This entry is the reason the pack is generated. The hand-written version said the form was removed in v4 and will not compile; the 2026-08-31 replacement then read the 4.4.0 note as restoring the form outright, which is wrong for every TypeScript reader. Both errors came from a release note, and neither survived running the code.

*Reproduced against: **Claude Haiku 4.5** (S1) — zod/v1, 2026-08-28.*

Source: [Zod 4 changelog — Record Schema Changes](https://zod.dev/v4/changelog) · [Zod 4.4.0 release notes — accurate for the runtime, silent about the unchanged type signature](https://github.com/colinhacks/zod/releases/tag/v4.4.0) · 2026-04-29 · [zod 4.5.4 shipped package — v4/classic/schemas.d.ts declares one two-argument record overload; tsc --strict reports TS2554 for the single-argument call](https://www.npmjs.com/package/zod/v/4.5.4)

#### .merge() on a schema with refinements

**Now throws in zod 4.4.0** (2026-04-29)

`.merge()` throws when the receiver has refinements. Prefer `.extend()` / `.safeExtend()` for object composition; `.merge()` is discouraged for new code regardless.

*The stale belief:* That `.merge()` is the normal way to combine two object schemas.

```ts
// Stale
const a = z.object({ a: z.string() }).refine((val) => val.a.length > 0);
a.merge(z.object({ b: z.string() }));   // 4.4+: throws

// Current
z.object({ a: z.string(), b: z.string() }).refine((val) => val.a.length > 0);
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Zod 4.4.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.4.0) · 2026-04-29

#### .pick() / .omit() with a key that does not exist

**Now throws in zod 4.3.0** (2025-12-31)

Object masking methods now validate that the keys you pass actually exist on the schema, and throw on an unrecognized key.

*The stale belief:* That an unknown key in a `.pick()`/`.omit()` mask is ignored.

```ts
// Stale
z.object({ a: z.string() }).pick({ nonexistent: true });   // 4.3+: throws
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Zod 4.3.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.3.0) · 2025-12-31

### Runs, but is silently wrong

Nothing errors. The behaviour is simply not what a model trained earlier will tell you.

#### `z.fromJSONSchema()`

**Added in zod 4.2.0** (2025-12-15)

Zod converts JSON Schema to Zod at runtime. Do not add Ajv or `json-schema-to-zod` for this. Supports draft-2020-12, draft-7, draft-4 and OpenAPI 3.0. `z.toJSONSchema()` is the other direction.

*The stale belief:* That Zod's JSON Schema support is one-way (Zod to JSON Schema only).

```ts
const schema = z.fromJSONSchema({
  type: "object",
  properties: { name: { type: "string", minLength: 1 } },
  required: ["name"],
});
```

> Upstream calls the API experimental and makes no round-trip soundness guarantee.

*Reproduced against: **Claude Fable 5** (S2), **Claude Opus 5** (S2), **Claude Sonnet 5** (S2) — zod/v2, 2026-08-29; zod/v4-a, 2026-09-02.*

Source: [Zod 4.2.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.2.0) · 2025-12-15 · [Zod 4.3.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.3.0) · 2025-12-31 · [zod@4.5.4 published type declarations, v4/classic/from-json-schema.d.ts](https://cdn.jsdelivr.net/npm/zod@4.5.4/v4/classic/from-json-schema.d.ts)

#### `z.xor()`

**Added in zod 4.2.0** (2025-12-15)

Exclusive union: passes only when exactly one option matches, failing on zero matches and on more than one. Do not hand-roll it with double `safeParse` plus `superRefine`.

*The stale belief:* That Zod has only `z.union()` (any match) and cannot express exclusivity.

```ts
const schema = z.xor([z.string(), z.number()]);
schema.parse("hello");   // ok
schema.parse(true);      // fails: zero matches
```

> Converts to `oneOf` rather than `anyOf` in JSON Schema output.

*Reproduced against: **Claude Fable 5** (S2), **Claude Opus 5** (S2), **Claude Sonnet 5** (S2) — zod/v2, 2026-08-29; zod/v4-a, 2026-09-02.*

Source: [Zod 4.2.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.2.0) · 2025-12-15 · [Zod 4.3.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.3.0) · 2025-12-31 · [zod@4.5.4 published type declarations, v4/classic/schemas.d.ts](https://cdn.jsdelivr.net/npm/zod@4.5.4/v4/classic/schemas.d.ts)

#### object properties typed z.undefined()

**Behaviour changed in zod 4.4.0** (2026-04-29)

A property whose schema accepts `undefined` and is not `.optional()` is required: the key must be present, the value may be `undefined`. Zod can therefore distinguish a missing key from an explicit `undefined` — no `z.preprocess` or `in` check needed. Use `.optional()` only when the key itself may be absent.

*The stale belief:* That Zod cannot tell a missing key from a key explicitly set to `undefined`.

```ts
const schema = z.object({ value: z.undefined() });
schema.safeParse({}).success;                     // false
schema.safeParse({ value: undefined }).success;   // true
```

> Also changes `.catch()`, `.partial()`, `.default()` and `.prefault()` combinations that relied on missing keys being treated as optional.

*Reproduced against: **Claude Fable 5** (S2, not chargeable), **Claude Opus 5** (S4), **Claude Sonnet 5** (S2, not chargeable) — zod/v2, 2026-08-29.*

Source: [Zod 4.4.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.4.0) · 2026-04-29

#### `z.httpUrl()`

**Stricter in zod 4.4.0** (2026-04-29)

`z.httpUrl()` is the validator for http/https URLs — it checks the protocol and that the hostname is a domain — and since 4.4.0 it rejects a missing slash after the protocol instead of accepting the value the `URL` constructor silently repairs. Do not hand-roll a normalization step, and do not reach for `z.url({ protocol: /^https?$/ })`.

*The stale belief:* That URL validation inherits the WHATWG `URL` constructor's leniency, so `"https:/example.com"` has to be normalized by hand.

```ts
// Stale
z.url({ protocol: /^https?$/ });          // plus a manual normalization pass

// Current
z.httpUrl().safeParse("https://example.com").success;   // true
z.httpUrl().safeParse("https:/example.com").success;    // false, since 4.4.0
```

> Matters most where the URL is a webhook target or is later compared as a string.

*Reproduced against: **Claude Opus 5** (S2), **Claude Sonnet 5** (S2) — zod/v2, 2026-08-29; zod/v3-a, 2026-09-02.*

Source: [Zod 4.4.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.4.0) · 2026-04-29

#### `.exactOptional()`

**Added in zod 4.3.0** (2025-12-31)

Makes a property key-optional (may be omitted) while still rejecting an explicit `undefined` value — the missing half of `exactOptionalPropertyTypes`.

```ts
const schema = z.object({
  a: z.string().optional(),        // accepts undefined
  b: z.string().exactOptional(),   // does not accept undefined
});
```

*Reproduced against: **Claude Fable 5** (S2), **Claude Opus 5** (S2), **Claude Sonnet 5** (S2, not chargeable) — zod/v3-a, 2026-09-02; zod/v4-a, 2026-09-02.*

Source: [Zod 4.3.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.3.0) · 2025-12-31 · [zod@4.5.4 published type declarations, v4/classic/schemas.d.ts](https://cdn.jsdelivr.net/npm/zod@4.5.4/v4/classic/schemas.d.ts)

#### intersections involving z.strictObject()

**Behaviour changed in zod 4.3.0** (2025-12-31)

An intersection now rejects only the keys unrecognized by both sides. Previously an unrecognized key from either side errored.

```ts
const C = z.intersection(z.strictObject({ a: z.string() }), z.object({ b: z.string() }));
C.parse({ a: "foo", b: "bar" });   // ok in 4.3+
```

*Reproduced against: **Claude Fable 5** (S2), **Claude Sonnet 5** (S2, not chargeable) — zod/v4-a, 2026-09-02.*

Source: [Zod 4.3.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.3.0) · 2025-12-31

#### z.tuple() defaults

**Behaviour changed in zod 4.4.0** (2026-04-29)

Defaults in tuple positions materialize in parsed output rather than erroring on an under-filled input.

*The stale belief:* That an under-filled tuple is a hard length error regardless of defaults.

```ts
z.tuple([z.string(), z.string().default("fallback")]).parse(["a"]);
// ["a", "fallback"]
```

> Trailing optional elements that are absent stay absent; an explicit `undefined` supplied by the caller is preserved. Because `z.function()` arguments are tuple-shaped, function input errors may also look different.

*Reproduced against: **Claude Sonnet 5** (S2, not chargeable) — zod/v2, 2026-08-29.*

Source: [Zod 4.4.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.4.0) · 2026-04-29

#### `z.compile()`

**Added in zod 4.5.0** (2026-08-28) · published after every cutoff in this dataset — listed for completeness, no model can be faulted for it yet

`z.compile(schema)` pre-compiles a schema and parses roughly 3–9x faster on objects, arrays and unions. A compiled schema is used exactly like an uncompiled one.

```ts
const CompiledPlayer = z.compile(Player);
CompiledPlayer.parse({ /* ... */ });
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Zod 4.5.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.5.0) · 2026-08-28

#### record key transforms

**Behaviour changed in zod 4.4.0** (2026-04-29)

Record schemas now run transforms on record keys, so a key transform changes the parsed output shape.

*The stale belief:* That a transform on the key schema of a record is inert.

```ts
z.record(z.string().transform((k) => k.toUpperCase()), z.number()).parse({ foo: 1 });
// { FOO: 1 }
```

> Key refinement failures now surface as structured `invalid_key` issues.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Zod 4.4.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.4.0) · 2026-04-29

#### `z.base64()`

**Stricter in zod 4.4.0** (2026-04-29)

`z.base64()` rejects whitespace instead of allowing `atob()`-style whitespace stripping.

*The stale belief:* That line-wrapped base64 (PEM, MIME) validates.

```ts
z.base64().safeParse("Zm9v").success;    // true
z.base64().safeParse("Zm 9v").success;   // false, since 4.4.0
```

> Strip whitespace before the check if you need to accept wrapped input.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Zod 4.4.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.4.0) · 2026-04-29

#### `z.slugify()`

**Added in zod 4.3.0** (2025-12-31)

String-to-slug transform. Do not hand-roll a regex chain.

```ts
z.string().slugify().parse("Hello World");   // "hello-world"
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Zod 4.3.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.3.0) · 2025-12-31 · [zod@4.5.4 published type declarations, v4/classic/schemas.d.ts](https://cdn.jsdelivr.net/npm/zod@4.5.4/v4/classic/schemas.d.ts)

#### `z.looseRecord()`

**Added in zod 4.2.0** (2025-12-15)

Validates only the keys matching the key schema and passes non-matching keys through unchanged — the representation of JSON Schema `patternProperties`.

```ts
z.looseRecord(z.string().regex(/^S_/), z.string()).parse({ S_name: "John", other: 123 });
// { S_name: "John", other: 123 }  — only S_name is validated
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Zod 4.2.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.2.0) · 2025-12-15 · [Zod 4.3.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.3.0) · 2025-12-31

#### `z.codec() / z.encode() / z.decode()`

**Added in zod 4.1.0** (2025-08-23)

A codec is a bidirectional transformation and replaces a pair of one-way `.transform()` schemas kept in sync by hand. `z.invertCodec()` (4.4.0) flips one.

*The stale belief:* That a round-trip needs two separate `.transform()` schemas.

**The code below needs zod 4.4.0 or later.** Between 4.1.0 and 4.4.0 this correction does not apply — see the note.

```ts
const stringToDate = z.codec(z.iso.datetime(), z.date(), {
  decode: (isoString) => new Date(isoString),
  encode: (date) => date.toISOString(),
});
const dateToString = z.invertCodec(stringToDate);   // 4.4.0
```

> AUDIT 2026-09-02 (JOURNAL/038). The floor is on the last line only: `z.codec()` is the 4.1.0 arrival this fact is filed under and compiles from 4.1.0, but `z.invertCodec()` arrived at 4.4.0, so the block as printed is TS2339 on 4.1.0, 4.2.0 and 4.3.0 — bisected against the installed packages. The fact stated 4.4.0 in prose and in a trailing comment and still carried no `replacement_available_from`, which is why the sweep of all 168 facts in JOURNAL/037 read past it and the mechanical audit did not.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Zod 4.1.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.1.0) · 2025-08-23 · [Zod 4.4.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.4.0) · 2026-04-29

#### defaults inside optionals

**Behaviour changed in zod 4.0.0** (2025-07-10)

A default applies inside an optional: `z.object({ a: z.string().default("tuna").optional() })` parses `{}` to `{ a: "tuna" }`.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Zod 4 changelog — Defaults](https://zod.dev/v4/changelog)

#### `z.coerce.*`

**Behaviour changed in zod 4.0.0** (2025-07-10)

`z.coerce.*` accepts `unknown` input in v4, and an object with coerced fields errors on a missing key instead of silently defaulting. Declare the fallback with `.default()`.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Zod 4 changelog — Coercion](https://zod.dev/v4/changelog)

### Deprecated, or a better API now exists

Works today. It is the older idiom, and some of it is scheduled for removal.

#### custom error messages

**Deprecated in zod 4.0.0** (2025-07-10)

Custom errors use the `error` parameter: `z.email({ error: "..." })`. Not `message`, `invalid_type_error` or `required_error`.

*The stale belief:* The most common half-migration is a v4 format function carrying the v3 `message` param.

```ts
// Stale
z.email({ message: "Invalid email" });

// Current
z.email({ error: "Invalid email" });
```

*Reproduced against: **Claude Haiku 4.5** (S3), **Claude Sonnet 5** (S3) — zod/v1, 2026-08-28; zod/v1, 2026-08-29.*

Source: [Zod 4 changelog — Error Customization](https://zod.dev/v4/changelog)

#### string format validators

**Deprecated in zod 4.0.0** (2025-07-10)

Format validators are top-level functions in v4: `z.email()`, `z.uuid()`, `z.url()`, `z.ipv4()`. The method-style `z.string().email()` form is the v3 idiom.

```ts
// Stale
z.string().email();

// Current
z.email();
```

*Reproduced against: **Claude Haiku 4.5** (S3) — zod/v1, 2026-08-28.*

Source: [Zod 4 changelog — String Format Validators](https://zod.dev/v4/changelog)

#### ZodError formatting

**Deprecated in zod 4.0.0** (2025-07-10)

Shape errors for a form with `z.treeifyError(result.error)` or `z.flattenError(result.error)`, not the `.flatten()` / `.format()` methods on the error object.

```ts
// Stale
result.error.flatten();

// Current
z.treeifyError(result.error);
```

*Reproduced against: **Claude Haiku 4.5** (S3) — zod/v1, 2026-08-28.*

Source: [Zod 4 changelog — Error Formatting](https://zod.dev/v4/changelog)

#### `z.creditCard() / z.properties() / .deepPartial() / .exactPartial()`

**Added in zod 4.5.0** (2026-08-28) · published after every cutoff in this dataset — listed for completeness, no model can be faulted for it yet

4.5.0 added `z.creditCard()` (12–19 digits plus a Luhn checksum) and `z.properties()` as the multi-property counterpart to `z.property()`, and returned `.deepPartial()` / `.exactPartial()`.

> A model asserting `.deepPartial()` was removed is correct as of its own cutoff, not stale — it came back in 4.5.0.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Zod 4.5.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.5.0) · 2026-08-28

#### `z.validate()`

**Added in zod 4.5.0** (2026-08-28) · published after every cutoff in this dataset — listed for completeness, no model can be faulted for it yet

`z.validate(schema, input)` returns a boolean without a full parse — a fast path when you only need validity.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Zod 4.5.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.5.0) · 2026-08-28

#### .superRefine({ when })

**Added in zod 4.4.0** (2026-04-29)

`.superRefine()` takes a `when` option for conditional refinement, so a guard clause inside the callback is no longer the only way to express it.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Zod 4.4.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.4.0) · 2026-04-29

#### empty z.union([]) / z.xor([])

**Behaviour changed in zod 4.4.0** (2026-04-29)

Empty unions and discriminated unions construct without crashing and fail at parse time instead of construction time.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Zod 4.4.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.4.0) · 2026-04-29

#### `z.cuid()`

**Stricter in zod 4.4.0** (2026-04-29)

CUID validation was tightened and CUID v1 is deprecated.

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Zod 4.4.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.4.0) · 2026-04-29

#### `.with()`

**Added in zod 4.3.0** (2025-12-31)

`.with()` is the readable alias for `.check()`, added because not everything composable is a 'check'.

```ts
z.string().with(z.minLength(5), z.toLowerCase());
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Zod 4.3.0 release notes](https://github.com/colinhacks/zod/releases/tag/v4.3.0) · 2025-12-31 · [zod@4.5.4 published type declarations, v4/classic/schemas.d.ts](https://cdn.jsdelivr.net/npm/zod@4.5.4/v4/classic/schemas.d.ts)

#### `z.function()`

**Behaviour changed in zod 4.0.0** (2025-07-10)

`z.function()` is a factory, not a schema: build it with `{ input, output }` and call `.implement()` / `.implementAsync()`.

```ts
const fn = z.function({ input: [z.string()], output: z.number() })
  .implement((s) => s.length);
```

*Reproduced against: no model yet. Verified from the primary source only — this is a correction, not an Index entry.*

Source: [Zod 4 changelog — z.function()](https://zod.dev/v4/changelog)

### Wrong facts about the library

Not code — versions, minimums and metadata that models state confidently and get wrong.

#### installing and importing zod

**Behaviour changed in zod 4.0.0** (2025-07-10)

`npm install zod` has installed v4 since 4.0.0 and the import path is plain `"zod"`. Generated code does not need a v3/v4 fallback branch, and `zod/v4` is not the subpath to reach for on a new project.

*The stale belief:* That v4 is opt-in behind a subpath, so generated code should hedge with a v3 fallback block.

```ts
import * as z from "zod";
```

*Reproduced against: **Claude Sonnet 5** (S4) — zod/v1, 2026-08-29.*

Source: [Zod 4 changelog](https://zod.dev/v4/changelog)

## Not corrections — recorded for honesty

These are real reproduced failures that we do **not** charge to the model, because the release that made the belief wrong was published after that model's stated cutoff. They are scheduled retests, not passes.

- **Claude Fable 5** · claims Zod cannot enforce key presence with an undefined value — 4.4.0 postdates this subject's stated 2026-01 cutoff. Recorded as context and as a retest target for the next Fable release.
- **Claude Sonnet 5** · claims Zod cannot distinguish a missing key from an explicit undefined — 4.4.0 postdates this subject's stated 2026-01 cutoff, so this is outside the probe fairness window and is recorded as context, not charged. It IS chargeable against Opus 5 (F6 of that run), whose cutoff is 2026-05.
- **Claude Sonnet 5** · wrong runtime prediction for tuple defaults — Same as F5 — 4.4.0 postdates the stated 2026-01 cutoff. Recorded as context and as a retest target.
- **Claude Sonnet 5** · Denies that the library has any way to make an object key omittable while rejecting an explicit undefined value, and argues the gap is structural — NOT chargeable against this draw. 4.3.0 published 2025-12-31; this draw stated its own cutoff as "roughly early-to-mid 2025" and explicitly repudiated the January 2026 its environment reported. Under the probe fairness rule a finding is chargeable only where the release precedes the subject's STATED cutoff, and this one does not. It becomes chargeable against any draw of this subject that states a cutoff after 2025-12-31 - which this battery's own blind twin did, in the arm that charges nothing.
- **Claude Sonnet 5** · Denies that the library can consume a JSON Schema document at runtime and prescribes Ajv as a new dependency — NOT chargeable against this draw, for the same reason as F1: 4.2.0 published 2025-12-15, after the "early-to-mid 2025" this draw states for itself.
- **Claude Sonnet 5** · Denies that the library has an exclusive union primitive — NOT chargeable against this draw's stated cutoff of "roughly early-to-mid 2025".
- **Claude Sonnet 5** · States that an intersection of two strict object schemas cannot parse an object carrying keys from both sides — NOT chargeable against this draw's stated cutoff.

Claims seen in a run but not yet verified against a primary source. Never treated as findings:

- Did a trailing-`?` key-optional object constructor (z.interface()) ever ship in a published Zod 4 beta, as both Fable 5 draws assert - "the Zod 4 betas had this, via z.interface() and its 'nickname?' key syntax, and it was removed before 4.0 stable"? *(open since 2026-09-02)*
- Did a trailing-`?` key-optional object constructor (z.interface()) ever ship in a published Zod 4 beta? *(open since 2026-09-02)*
- Zod 4 coercion accepts unknown input and changed missing-key behaviour for objects with coerced fields. Does this subject know either change? *(open since 2026-08-28)*
- This draw named `.safeExtend()` as a 4.1 addition that "exists precisely because plain `.extend()` handles existing object-level checks unsoundly" while simultaneously asserting that Zod 4 lifted the restriction on `.pick()`/`.extend()` over refined schemas. Those two statements are in tension and the battery has no way to score a subject that holds both. The Index's finding F2 charges the second; the first is closer to right than anything `zod/v2` recorded. *(open since 2026-09-01)*
- This draw raised `z.interface()` and said it could not recall whether it survived into stable Zod 4 - "I have conflicting recollections" - and declined to build task 7 on it. The Index has never verified what became of `z.interface()`. It is cheap archaeology from the 4.0.0 release notes and it would let a future battery score the question rather than watch a subject hedge past it. *(open since 2026-09-01)*
- Did an object-schema constructor using trailing-`?` key syntax ever exist in a published zod build? This draw placed it in "the Zod 4 beta, published as zod@3.25.0 under the zod/v4 subpath, ~late May 2025", and could not say whether it survived to stable. *(open since 2026-09-02)*
- Does z.number().int().min(18, "Must be at least 18") — the bare-string shorthand second argument — remain supported in v4 alongside { error }? *(open since 2026-08-29)*

---

*Findings, code and citations: `data/zod/` — one JSON file and one write-up per model, each finding carrying the release that broke the belief, its publication date and a verbatim quote from the primary source. Corrections: `data/zod/facts.json`. This file is generated by `tools/build-corrections.mjs`; if the prose and the data ever disagree, that is a bug in the generator, not a stale pack.*