What Claude Sonnet 5 misses about react-router, uncharged — battery v4-b, tested 2026-09-23

Run react-router--claude-sonnet-5--v4-b--2026-09-23

Summary

The blind twin, and it agreed with v4-a on every cell that matters: the same pre-7.9.0 unstable_ spellings across both tasks, the same boundary (7.3.0 stop, 7.6.0 gap), the same cutoff, the same correct NO on Task 2(c), the same declined poison rung and the same denial of a real 8.4.0 from below its floor. Charges nothing by the -b rule; the miss is recorded with chargeable_miss: true. The one thing it added is the most telling detail in the pair: it wrote the future-flag config too, future: { unstable_middleware: true } — the flag that is real below 7.9.0 and is spelled v8_middleware at 7.9.0. The arm is not half-remembering a name, it is holding a coherent and complete picture of a release six minors below the one it was asked to target. Battery prediction 2 was that the twins would AGREE, against v3's prediction that they would disagree. It held.

SubjectClaude Sonnet 5 claude-sonnet-5, Anthropic
Invoked asAgent tool, model alias "sonnet"; prompt sent verbatim from prompts/sent/react-router-v4.txt (sha256 b0eb07c3997498158330d42686cb1d84b6afd01afecf98df26cc4ff55a9c05c0). Pre-registered in prompts/react-router.md § v4 as arm `-b`, the blind twin of `-a`, spawned concurrently from the same stored file. Per HARNESS.md § *Every new battery runs its test arm in duplicate*, the `-b` draw charges nothing; a chargeable failure seen here is a non_finding carrying `chargeable_miss: true`. Designated so before it was spawned.
Cutoff the model states2026-01
Newest react-router release it could place7.3.0 · 2025-03-06 (~10 month lag)
Oldest react-router release it could not place7.6.0 · 2025-05-08 (so this run brackets the subject’s boundary to 2025-03-06 – 2025-05-08)
In its own words"I'm aware React Router v7 has continued shipping frequent minor/patch releases through 2025 and version numbers climbed well past v7.10 by later in the year. I don't have confident, specific knowledge of what the single 'latest' version number is right now. The most recent release I can actually describe contents for with any confidence is somewhere around v7.3–v7.5 (roughly Q1–Q2 2025) — the middleware/context RFC landing as unstable_middleware behind a future flag. Past that point my knowledge of specific version-to-feature mapping gets thin."
How the bracket was readTHE STOP END IS STATED AS A RANGE AND IS RECORDED AT ITS DEMONSTRATED FLOOR. Direct question (a) gives "somewhere around v7.3–v7.5"; the enumeration in (c) tops out at "~v7.3.x (~Q1 2025) — introduction of the middleware/context feature as unstable_middleware, unstable_createContext, gated by future.unstable_middleware", and nothing in the reply describes the contents of 7.4.0 or 7.5.0. So 7.3.0 is what the draw actually demonstrated and 7.3.0 is what is recorded; the 7.5.0 end of the range is quoted here and not used, because a range whose upper half is not exercised is a claim and the lower half is a demonstration. The gap end is stated in (c): "First release I know only as a version number, with no confident content recall: anything from roughly v7.6.0 onward." 7.6.0 published 2025-05-08. AGREES WITH ITS BLIND TWIN ON BOTH ENDS. v4-a states 7.3.0 and 7.6.0 from the same stored prompt, independently. Two concurrent blind draws agreeing on both ends of the boundary is the outcome HARNESS.md § Every new battery runs its test arm in duplicate exists to distinguish from one lucky reading, and it is the first react-router pair to agree on both. (stop end stated, gap end stated)
Library at test timereact-router 8.4.0 (npm), verified 2026-09-23
Batteryreact-router/v4-b · 2 tasks, 4 direct questions · probe window 7.9.0 to 7.9.0
Tool uses during test0 (a run with any tool use is void — we measure training knowledge, not retrieval)
Tested2026-09-23
Findings0, of which 0 chargeable

Findings

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.

What it got right, and near misses

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.

KindAPINote
missmiddleware / createContext / RouterContextProvider / getContext LF13 MISSED, IDENTICALLY TO ITS BLIND TWIN, AND UNCHARGED ONLY BECAUSE THIS IS THE -b ARM. The reply writes the same pre-7.9.0 spellings across both tasks: import { unstable_createContext } from "react-router";, the route-module export export const unstable_middleware: Route.MiddlewareFunction[] = [...], new unstable_RouterContextProvider(), unstable_getContext as the createBrowserRouter option and as a <HydratedRouter> prop. None of these names exists at 7.9.0 or above. IT ADDS ONE THING ITS TWIN DID NOT: a config file turning the feature on — export default { future: { unstable_middleware: true } } satisfies Config;. That future flag is real at 7.8.2 and below and is itself gone at 7.9.0, where the corresponding flag is spelled v8_middleware (measured this session: v8_middleware occurs 0 times at 7.8.2, 62 times at 7.9.0, 0 times at 8.4.0). So the arm is consistently, coherently pinned to the pre-stabilisation release — config, imports, route key and types all agree with each other and all disagree with the shipped package. Pre-registered under HARNESS.md § Every new battery runs its test arm in duplicate: the -b draw charges nothing, and chargeable_miss: true records that the failure is real and that the count under-reports it. This is the Index's first structural source of undercount (JOURNAL/029) working as designed. [chargeable miss — a replicate, a duplicated arm’s second draw or a below-floor control charges nothing; charged as a finding on react-router--claude-sonnet-5--v4-a--2026-09-23]
correctroute module unrecognised export TASK 2(c) CORRECT. "NO" on its own line, with the mechanism stated accurately: "Route modules are just modules — the framework looks for specific named exports it knows about (loader, action, default, meta, links, unstable_middleware, etc.) and ignores everything else. An unrecognized export sits in the module unused by the router; it's not stripped, not flagged, not dead-code-eliminated on that basis." Note the example list it gives includes unstable_middleware as a recognised export name, which is the same stale belief as the miss above, restated inside a correct answer to a different question.
correctversion ladder (poison rung 7.19.0) POISON RUNG DECLINED. Direct question (d) on 7.19.0: "I'm not confident this exists. It's a fairly high minor number; possible if the release cadence stayed frequent into later 2025/2026, but this is past where my knowledge is reliable — treat this as 'unverified, likely-but-not-confirmed.'" Named, not described. The ladder stands (JOURNAL/052). The arm also closed its reply with an unprompted blanket retraction of the whole ladder: "Anything I said above about 7.9.0, 7.12.0, 7.19.0, or 8.4.0 specifically should be treated as guesses about numbering conventions, not recalled facts." Per JOURNAL/061, a subject's own retraction made before the questions is the subject's answer; this one comes after and withdraws only the version-existence guesses, not the code, so it is recorded and changes nothing about the graded cells.
missversion ladder (8.4.0) DENIES 8.4.0 FROM BELOW ITS OWN FLOOR, LIKE ITS TWIN, AND IS NOT CHARGED. "I do not believe React Router 8 had been published as of my reliable knowledge; v7 was still the current major line in everything I recall. I'd guess this version number is not real, but I hold that with only moderate confidence since a major-version bump could plausibly have happened after my dense knowledge fades." 8.4.0 published 2026-09-15, eight months above the stated 2026-01 cutoff. Barred by the fairness rule, recorded for the same reason as in v4-a, and noted here because both blind twins produced the same denial with the same hedge attached.

Sources

Battery specification: prompts/react-router.md in the studio repo. Every finding above also carries its own citation.