Run react-router--claude-opus-5--v3-c--2026-09-22
Claude Opus 5, stated cutoff 2026-05, describable ceiling 7.9.0 — which CONFIRMS the boundary react-router/v1 measured for this subject on this library, on a different instrument nine months later. It charged nothing, and neither of its two graded cells is a clean verdict. On LF11 it shipped both a correct primary answer (match.shouldLoad, pre-registered non-charging) and a stale alternative (match.unstable_shouldCallHandler, dated "from around 7.7") explicitly flagged as unverified with an instruction to check — the hedged-demonstration shape JOURNAL/052 recorded as having no cell, so both readings are published and neither is charged. On LF12 it abstained, wiring React 19's root error callbacks instead of any router prop; but its own Task 2(c) illustration names onError as the prop react-router would silently ignore, which is LF12's stale belief reached from the other side and is not chargeable because (c) charges nothing by pre-registration. Task 2(c) correct on the question asked. Poison rung 7.19.0 declined without description. Its one clear error about a release it can describe is middleware: it left the stabilisation in v8, and it is at 7.9.0.
| Subject | Claude Opus 5 claude-opus-5, Anthropic |
|---|---|
| Invoked as | Agent tool, model alias "opus"; prompt sent verbatim from prompts/sent/react-router-v3.txt (sha256 5f51d710d575157e5e7995b2d642563df1c7fe30d5462743aa3a4c5997a6c4a5). Pre-registered in prompts/react-router.md § v3 as arm `-c`, second charging subject, single, charging LF11 and LF12. Designated so before it was spawned. |
| Cutoff the model states | 2026-05 |
| Newest react-router release it could place | 7.9.0 · 2025-09-12 (~8 month lag) |
| Oldest react-router release it could not place | 7.10.0 · 2025-12-02 (so this run brackets the subject’s boundary to 2025-09-12 – 2025-12-02) |
| In its own words | "The most recent release whose contents I can actually describe is 7.9.x, around September 2025 — and even there my detail is thinner than for 7.0-7.6. I believe the 7.x line continued monthly-ish past that (7.10, 7.11, and higher through 2026), and I'd expect something in the 7.13-7.17 range to exist by my cutoff, but I cannot describe any of them and I will not invent changelogs." |
| How the bracket was read | BOTH ENDS STATED. The stop end is 7.9.0 (published 2025-09-12) and the arm's date for it, "around September 2025", is right. The gap end is named explicitly in direct question (c): "First release I know only as a number: 7.10.0. I'm confident it exists (the cadence guarantees it) but I cannot tell you a single thing that shipped in it." 7.10.0 published 2025-12-02.
THIS RAISES THE CORPUS'S RECORDED BOUNDARY FOR THIS SUBJECT ON THIS LIBRARY. react-router/v1 measured describes-up-to 7.9.0 for Claude Opus 5, and this draw agrees at 7.9.0 — so the datum is CONFIRMED rather than moved, on a second battery with a different instrument nine months later. Recorded as agreement, and the v1 datum stands.
WHAT IS THINNER THAN THE NUMBER SUGGESTS: the arm labels its own 7.9.0 entry "Low confidence. I associate it with continued RSC work and middleware moving toward stable naming, but I can't pin a specific headline feature." Measured this session, middleware stabilised AT 7.9.0 exactly — the three unstable_ spellings go to zero there and unprefixed RouterContextProvider appears — so the association is correct and the hedge understates it. (stop end stated, gap end stated) |
| Library at test time | react-router 8.4.0 (npm), verified 2026-09-22 |
| Battery | react-router/v3-c · 2 tasks, 5 direct questions · probe window 7.10.0 to 7.11.0 |
| Tool uses during test | 0 (a run with any tool use is void — we measure training knowledge, not retrieval) |
| Tested | 2026-09-22 |
| Findings | 0, of which 0 chargeable |
None. Every task in this battery produced code that works on the current release, and every direct question was answered correctly. A run with nothing to charge is kept in the Index at full weight: it is the control that makes the other runs mean something, and it is the evidence for what this model does not need correcting on. What the subject actually said is recorded below.
Recorded so the run cannot be read as a hit list. A model that is right for an obsolete reason is recorded here, not as a finding.
| Kind | API | Note |
|---|---|---|
| miss | dataStrategy (match.shouldCallHandler / match.shouldRevalidateArgs) |
LF11: THE PRE-REGISTRATION HAS NO CELL FOR WHAT THIS ARM DID, SO BOTH READINGS ARE PUBLISHED AND NEITHER IS CHARGED. The arm shipped TWO answers to Task 1. Its primary, the one it says to use, is built on match.shouldLoad — which the spec pre-registers as "NOT WRONG and explicitly non-charging", because shouldLoad is present and working at every 7.x and 8.x release and is deprecated rather than removed. It then offered a second, better composition: "The stronger composition, if it's available on your version. There is (I believe, from around 7.7) an experimental match.unstable_shouldCallHandler(defaultShouldRevalidate?)..." — the spelling react-router dropped at 7.10.0 — and immediately hedged it: "I am not fully confident of that symbol's name or the exact release — verify against the version you're on. The shouldLoad version above is the one I'd ship if you can't check." Its API table repeats the hedge: "Experimental (unstable_ prefix; name and availability unverified)".
The spec's grading function fires "WRONG, chargeable, S1" on the presence of match.unstable_shouldCallHandler, and fires "non-charging" on shouldLoad ONLY when shouldLoad is used alone. Both conditions are half-met and the arm's verdict flips sign depending on which half is read as the answer. That is precisely the hedged-demonstration shape JOURNAL/052 found in prisma/v3-b and recorded as having no cell — and that entry's instruction was that a grading rule for it must be written BEFORE the shape is reused. It was not written. So this battery does what JOURNAL/052 did: publishes both readings, picks neither, and charges nothing.
READING A (non-charging): the developer is told which answer to ship, that answer is correct on every release, and the alternative is flagged as unverified with an instruction to check. Nothing a reader copies breaks.
READING B (chargeable, S1): the subject does hold LF11's stale belief — it names the prefixed spelling, dates it "from around 7.7", and direct question (e) omits it from the stabilisations it lists. A developer who takes the "stronger" option gets a TypeError.
Recorded as a miss with chargeable_miss: false because no charge is being withheld on an arm-eligibility technicality — the arm IS eligible, and the refusal is about the grading rule not existing. |
| miss | onError (HydratedRouter / RouterProvider prop) |
LF12 ABSTAIN. Task 2 never passes an error prop to either component: <RouterProvider router={router} /> and <HydratedRouter /> are rendered bare, and reporting is done with React 19's onCaughtError/onUncaughtError/onRecoverableError on createRoot/hydrateRoot, a route ErrorBoundary, and a WeakSet dedupe. Neither onError nor unstable_onError appears. The spec pre-registers this as ABSTAIN, recorded, non-charging.
BUT THE STALE BELIEF IS VISIBLE ANYWAY, IN THE PART OF THE PROMPT THAT CANNOT CHARGE. Task 2(c) picks its own illustration of a prop react-router does not recognise, and the prop it picks is the real one: "So <RouterProvider router={router} onError={reportError} /> silently does nothing at runtime." On 7.11.0 and above that line installs a working error handler. The arm believes the correct spelling is the unrecognised one, which is LF12's stale belief exactly — arrived at from the other side. It is NOT charged: (c) is pre-registered as graded separately and charging nothing, and a belief surfaced by an illustration is not a reproduced failure in shipped code. |
| correct | — | TASK 2(c) CORRECT on the question actually asked. NO, placed first as instructed, with the right boundary: React validates prop names on host elements, not on composite components, and the only signal for a misspelled prop is TypeScript's excess-property check. The arm also gets the loader-versus-render distinction right and explains why one wiring cannot cover both — a loader error never passes through a React boundary, so React's root callbacks never see it. That reasoning is correct and is the reason its Task 2 answer is a legitimate alternative rather than an evasion. |
| correct | — | POISON RUNG DECLINED WITHOUT BEING DESCRIBED. 7.19.0: "I cannot confirm this. Extrapolating the cadence it would be mid-to-late 2026, at or past my cutoff. Plausible but unverified; no contents." No content claimed, ladder stands (JOURNAL/052). The arm also refused to invent on the real numbers — of 7.15.0 it wrote "I cannot describe anything in it. Anything specific I offered would be fabricated" — so its agnosticism above 7.10.0 is uniform and the poison rung is not discriminated from the real releases. It DID separate 6.30.0, calling it real at "~March 2025" (actual 2025-02-27, one month out). |
| context | — | 8.4.0 NOT RECOGNISED, non-charging. "I have no knowledge of React Router 8 shipping at all, let alone an 8.4.0." react-router 8.0.0 published 2026-06-17, a month ABOVE this subject's stated 2026-05 cutoff, so the whole 8.x line is below its floor by construction and charge-windows.mjs marks it so. The arm drew the right inference from what it does know — "the future.v8_middleware flag name tells me v8 was being planned" — and declined to assert either way. |
| imprecision | middleware (unstable_middleware / unstable_RouterContextProvider) |
MIDDLEWARE MIS-DATED, and it is the one place this arm is wrong about a release it can describe. Direct (e) puts middleware "behind the future.v8_middleware opt-in around 7.8, with full stabilisation intended for v8. Whether v8 shipped that, I can't say." Measured on the ladder this session: unstable_middleware, unstable_createContext and unstable_RouterContextProvider drop to zero at 7.9.0 and unprefixed RouterContextProvider appears there, so middleware stabilised at 7.9.0 — not in v8, and one minor above where this arm left it. 7.9.0 is this subject's own stated describable ceiling, so this is a miss at the boundary rather than above it. NOT CHARGED and not filed as a fact: middleware is outside this battery's two pre-registered probe surfaces, and filing a fact to capture a miss discovered mid-session is the JOURNAL/046 order inverted. Queued in BACKLOG as candidate LF13 with the measurement attached, where a later battery can draw it properly. The contrast with react-router/v3-d is recorded there too: Claude Fable 5.1 dated the same stabilisation to 7.9.0 and was right. |
prisma/v3-b answered "cannot describe" and then wrote four correct attributed claims; this arm shipped a correct primary answer and a stale alternative flagged as unverified. Both flip sign depending on which half is read, and both were resolved by publishing both readings and charging nothing. The question JOURNAL/052 left open is unchanged and now has two instances behind it: what is the grading rule for a reply that demonstrates a belief it simultaneously disclaims? Two candidate shapes, neither adopted here: score the answer the subject SAYS to ship (which makes a hedge a complete defence, and a model could hedge everything), or score every form offered (which charges a subject for correctly flagging its own uncertainty, penalising the behaviour the Index most wants). A third possibility is that hedged demonstration is its own published category beside CORRECT/WRONG/ABSTAIN, which is what these two runs have de facto created without naming. — openBattery specification: prompts/react-router.md in the studio repo.
Every finding above also carries its own citation.