Run react-router--claude-sonnet-5--v2-c--2026-09-10
The second charging subject, and it passes both facts — pre-registered as the expected outcome and delivered without a charge. It installs react-router alone, explains the 7.0.0 package collapse and names react-router-dom as the compatibility re-export it now is; it answers "No" to the React 17 / Node 18 question where both Haiku arms answered "yes", and recommends the 6.x line correctly to within a patch. Its value to the Index is the other half: it resolves the last unmeasured (subject x library) cell in the charging sweep — Claude Sonnet 5's react-router boundary is 7.0.0, 2024-11-22 — and in doing so FALSIFIES the battery's second pre-registered prediction by four months and nine releases. The loudest library in the Index is among this subject's stalest, not its freshest.
| Subject | Claude Sonnet 5 claude-sonnet-5, Anthropic |
|---|---|
| Invoked as | Agent tool, model alias "sonnet"; prompt sent verbatim from prompts/sent/react-router-v2.txt, the same stored file as both Haiku arms. Pre-registered in prompts/react-router.md § v2 as a SECOND CHARGING SUBJECT, single rather than duplicated, and designated so before it was spawned — not a control, and expected to pass. It carries the single-arm insurance JOURNAL/110 made a rule after both Fable 5.1 arms repudiated their cutoff and took `react-router/v1`'s designed output with them. It is also the ruler probe for the LAST unmeasured (subject x library) cell in `charge-windows.mjs`: every react-router row for this subject printed `?` before this run. |
| Cutoff the model states | 2026-01 |
| Newest react-router release it could place | 7.0.0 · 2024-11-22 (~13 month lag) |
| Oldest react-router release it could not place | 7.1.0 · 2024-12-20 (so this run brackets the subject’s boundary to 2024-11-22 – 2024-12-20) |
| In its own words | "(a) Latest version I know of: React Router v7 (the 7.x line, which absorbed Remix). Most recent release I can actually describe in real detail is v7.0.0, shipped around November 2024 — the rebrand/merge with Remix, three modes (framework/data/declarative), single react-router package, Vite-based framework tooling, generated route types."
BRACKET PROVENANCE — BOTH ENDS ARE STATED AND THE STOP END IS DESCRIBED IN DETAIL, which makes this the strongest bracket in the battery. The stop end is 7.0.0 (2024-11-22) and the arm's description of it is accurate on every clause. The gap end is direct question (c): "I believe there have been 7.1.x/7.2.x releases continuing to refine framework mode (and I have a hazy, low-confidence memory of 'middleware' being added as an experimental feature somewhere in the 7.x line) but I can't describe the actual contents of any specific one of those with confidence. That's roughly where my real knowledge stops and turns into 'I believe this version number exists'." The first release above 7.0.0 is 7.1.0, published 2024-12-20.
ITS DATE FOR ITS OWN STOP IS RIGHT: "around November 2024" against 7.0.0's actual 2024-11-22 — the only arm in this battery whose self-dating is accurate, and the two Haiku arms were each about a year out. |
| Library at test time | react-router 8.3.1 (npm), verified 2026-09-10 |
| Battery | react-router/v2-c · 4 tasks, 4 direct questions · probe window 7.0.0 to 7.0.0 |
| Tool uses during test | 0 (a run with any tool use is void — we measure training knowledge, not retrieval) |
| Tested | 2026-09-10 |
| 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 |
|---|---|---|
| correct | react-router (package exports) |
LF8 PASSES, AND THE ARM EXPLAINS THE FACT RATHER THAN MERELY LANDING ON IT. Task 1(a) verbatim: "npm install react-router", with the reason unprompted — "In the current major (v7), react-router itself ships both the routing core and the DOM bindings (RouterProvider, createBrowserRouter, Link, useSearchParams, etc.) ... react-router-dom still exists only as a thin compatibility re-export, so for a fresh project you don't need it." Every import in Tasks 1, 2 and 4 names react-router. This is the pre-registered expected outcome on this arm and it charges nothing. IT IS ALSO WHY THE HAIKU ARMS' FAILURE IS READABLE: the spec pre-registered that a PASS on Task 1 is not evidence of knowing 7.0.0, because "import it from the package named after the library" is the naive guess — but a pass that arrives with the collapse described, the re-export named and the reason given is not the naive guess, and it demonstrates the task elicits the surface it was built to elicit. |
| correct | react-router@7 engine and peer requirements |
LF9 PASSES, AND ON THE FORCED ONE-WORD ANSWER. Task 3(a) verbatim: "No" — where both Haiku arms answered "yes". Task 3(c): "The blocker is React itself, not Node: the current major (v7) requires React 18+ ... so it can't sit on React 17 regardless of Node version." It then recommends "react-router-dom": "^6.30.0" for the React 17 project, which is the correct advice and correct to within a patch — the last 6.x release is 6.30.6, published 2026-08-18, and the arm flags its own uncertainty about the last digit rather than asserting it. Charges nothing, by pre-registration and by being right. |
| miss | — | IT BELIEVES v7 IS THE CURRENT MAJOR AND v8 IS THE ONE IT CANNOT PLACE — AND THAT IS NOT CHARGEABLE, WHICH IS THE FAIRNESS RULE WORKING RATHER THAN A GAP. react-router 8.0.0 published 2026-06-17, five months ABOVE this subject's stated 2026-01 cutoff, so "the current major (v7)" is a correct belief about the world at its cutoff and the Index charges nothing for it. Its direct-question (d) answer is the honest form of the same state: "8.0.0 — I have no confident knowledge of a React Router v8. I'm not aware of one having shipped; given my stated cutoff is later than my confident recall, I can't rule it out, but I'm not going to claim knowledge I don't have." Recorded because the run's whole surface reads as v7-centric and a later reader should not mistake that for an uncharged miss. (8.0.0 published 2026-06-17, above this subject's stated 2026-01 cutoff. Not a pass and not a charge — a scheduled retest.) |
| miss | — | THE POISON RUNG WORKED, ON THE SUBJECT IT WAS DESIGNED FOR, AND WHAT IT MEASURED IS AN INABILITY TO DISCRIMINATE RATHER THAN AN INVENTION. 6.31.0 has never been published — the 6.x line stops at minor 6.30, verified against the registry this session — and this arm answered "6.31.0 — Plausible as a real late-6.x patch release, same caveat as 6.29.0 — I can't name specific contents." It gave 6.29.0, which IS real, the same answer in the same words and said so itself. So the rung does not show a subject inventing a release; it shows a subject that cannot separate a real late-6.x release from a fabricated one and correctly reports that it cannot. THE SPEC PRE-REGISTERED THIS RUNG AS INFORMATIVE FOR THIS SUBJECT AND UNREADABLE FOR HAIKU 4.5 — 6.30.0 published 2025-02-27, eleven months inside this cutoff and inside Haiku's own cutoff month — and that is how it came out. Belief data, never a finding, per the spec. Its other three rungs are right: 7.0.0 real and described accurately, 7.2.0 "plausible as a real early-2025 7.x release" (2025-02-18), 6.20.0 plausible and placed in "late 2023/early 2024" against an actual 2023-11-22. |
| context | — | PREDICTION 2 IS FALSIFIED, DECISIVELY, AND IT IS THE THIRD FALSIFICATION OF THE LOUD-LIBRARY MECHANISM ON THIS LIBRARY. The spec predicted, before this arm was spawned, that Claude Sonnet 5's last describable react-router release would be published LATER than 2025-03-17 — its own median lag of 9.5 months applied to its stated cutoff — and named the falsifier: stopping at 7.3.0 (2025-03-06) or below. IT STOPS AT 7.0.0, 2024-11-22, FOUR MONTHS BELOW THE FALSIFICATION THRESHOLD AND NINE RELEASES SHORT OF IT, with nine chances inside its own cutoff (7.4.0 through 7.12.0) taken and missed. Its react-router lag is 13.4 months against a 9.5-month median across seven libraries: react-router is not this subject's freshest library, it is among its stalest, joining the high cluster (next.js 14.4, better-auth 13.3, prisma 13.1) rather than the low one (langchain 2.5, zod 5.7). THE MECHANISM'S RECORD ON THIS LIBRARY IS NOW ONE WEAK CONFIRMATION AND THREE FALSIFICATIONS: v1-c (Opus 5) confirmed by twenty days across an 81-day publishing gap and was reported as weak at the time, both v1 Fable 5.1 arms falsified, and this arm falsifies. No cause is claimed — one library cannot refute a mechanism, and JOURNAL/110 already established that react-router's release calendar explains its boundaries better than anything about the subjects. What is now measured is that the loudest library in the Index is not the one its subjects know best. |
| context | — | THE LAST ? CELL IS RESOLVED. charge-windows.mjs printed every react-router row for Claude Sonnet 5 as ? — boundary never measured on this library — and listed it under "Boundary never measured (one probe each would resolve every ? above)" as the only subject-library pair of its kind besides Haiku 4.5 on prisma and tailwindcss. This run measures it at 7.0.0 (2024-11-22). The consequence for future design is immediate and is the reason a charging arm was worth spending here rather than a control: every react-router release from 7.1.0 (2024-12-20) up to this subject's cutoff month is now a LIVE chargeable window for Claude Sonnet 5, where before it was an unmeasured ? that no battery could be designed against. |
| imprecision | — | Three hedged inaccuracies, none charged, all of them flagged by the arm itself before it wrote them — which is the code-vs-claim rule's other side. (1) It gives v7's react peer as "^18.0.0 || ^19.0.0", prefixed "I recall its peer dependency as"; the shipped manifest says >=18, which is the same set for every published React and a different string. (2) On Node it says it has "a vague, low-confidence recollection that the v7/Vite tooling chain trends toward requiring newer Node LTS (20+)" — which is exactly right (7.0.0 raised engines.node to >=20.0.0) and is offered as a thing it will not assert. (3) On Task 2 it writes the correct imports — createStaticHandler, createStaticRouter, StaticRouterProvider, and Meta/Links/Scripts/ScrollRestoration from react-router, all of which the installed 8.3.1 package does export — and then says "I'm genuinely unsure whether Meta/Links/Scripts are exported directly from react-router in the current release or from a separate entry point." A correct artifact under a disclaimed claim. None of these is a finding: the code runs and the prose names its own uncertainty rather than asserting something the artifact contradicts. |
data/index.json.knowledge_boundary, which now has eight libraries for four subjects. — openBattery specification: prompts/react-router.md in the studio repo.
Every finding above also carries its own citation.