What Claude Haiku 4.5 gets wrong about react-router — battery v2-a, tested 2026-09-10

Run react-router--claude-haiku-4-5--v2-a--2026-09-10

Summary

The first charging test arm on Claude Haiku 4.5 since the 2026-08-28 zod pilot, and both facts it was designed against are charged. The subject installs and imports the entire router from react-router-dom (F1, S1) — every identifier correct, every one of them dragged down by one module specifier that has no release on the current major — and answers "yes" to whether the current release installs on React 17 and Node 18, adding that no version changes are needed (F2, S1), when the current release asks for Node >=22.22.0 and React >=19.2.7. The anchor task, dated 6.4.0, is answered correctly and idiomatically, so the 6.20.0 boundary is this subject's knowledge ending rather than the battery failing to reach it. Prediction 1 is confirmed — no 7.x release is described — but the confirmation does not look like v1-d's flat denial of the v7 line: this draw knows a major was coming and cannot say whether it landed.

SubjectClaude Haiku 4.5 claude-haiku-4-5, Anthropic
Invoked asAgent tool, model alias "haiku"; prompt sent verbatim from prompts/sent/react-router-v2.txt. Pre-registered in prompts/react-router.md § v2 as the TEST ARM, blind twin `-a`, charging LF8 and LF9, and designated so before it was spawned. THIS IS THE FIRST CHARGING TEST ARM RUN ON THIS SUBJECT SINCE THE 2026-08-28 ZOD PILOT: Claude Haiku 4.5 has eleven prior runs in this corpus, ten of them below-floor derivability controls, because every fact the Index held was dated above its 2025-02 cutoff until LF8 and LF9.
Cutoff the model states2025-02
Newest react-router release it could place6.20.0 · 2023-11-22 (~14 month lag)
Oldest react-router release it could not place7.0.0 · 2024-11-22 (so this run brackets the subject’s boundary to 2023-11-22 – 2024-11-22)
In its own words"Latest version: I believe React Router is in the v6.2x range as of my training cutoff (February 2025). I have some awareness of v7 being in development but am not certain of its release status. The most recent version whose contents I can confidently describe is probably v6.20.x or thereabouts, shipped approximately mid-2024 or earlier in 2024." BRACKET PROVENANCE — Both ends are stated by the arm rather than derived. The stop end is the arm's own answer to the describable-contents half of direct question (a), v6.20.x, read at 6.20.0 (2023-11-22). The gap end is direct question (c): "The first release I know only as a version number: probably 7.0.0 — I'm aware it may exist or be imminent, but I cannot describe its contents." 7.0.0 published 2024-11-22. THE ARM'S DATE FOR ITS OWN STOP IS WRONG BY ABOUT A YEAR AND THE VERSION IS NOT: 6.20.0 shipped 2023-11-22, not "mid-2024 or earlier in 2024". The Index's boundary is a release, not the subject's estimate of when it shipped, so the version governs; the date error is recorded as belief data and charged nowhere. CONTRAST WITH v1-d, DELIBERATELY NOT RECONCILED: that arm answered the same half of the same question with no version at all ("v6.x releases throughout 2024") and its record therefore reached for the latest 6.x minor consistent with the range it did name, 6.28.0. This arm names 6.20.x, so no reaching is needed and none is done. The two readings are different because the two answers are different, not because the rule changed — but the tension is real and is queued rather than resolved here (BACKLOG), because resolving it would mean re-reading v1-d's draw, which is the line JOURNAL/098 drew.
Library at test timereact-router 8.3.1 (npm), verified 2026-09-10
Batteryreact-router/v2-a · 4 tasks, 4 direct questions · probe window 7.0.0 to 7.0.0
Tool uses during test0 (a run with any tool use is void — we measure training knowledge, not retrieval)
Tested2026-09-10
Findings2, of which 2 chargeable
this run as JSON all react-router findings Does Claude Haiku 4.5 know react-router 8? method

Findings

F1 · Installs and imports the whole router from react-router-dom, the package the 7.0.0 collapse folded away — which has no release on the current major at all

S1breaks-build · react-router (package exports) · added · changed in react-router 7.0.0 (2024-11-22) · chargeable

react-router 7.0.0 published 2024-11-22; this subject states a 2025-02 cutoff, so the release precedes it by three months and the miss is inside the fairness window. Pre-registered as chargeable on this arm in prompts/react-router.md § v2 before the arm was spawned.

What the model believes

That react-router is the routing core and react-router-dom the package an application installs, so every DOM binding — the link component, the query-parameter hook, the data-router factory — is imported from react-router-dom. Task 1(a) verbatim: "npm install react react-dom react-router-dom". Task 1(b) imports createBrowserRouter, RouterProvider, Outlet, Link, useSearchParams and useLoaderData from 'react-router-dom' in one statement. CORROBORATED ON TWO FURTHER TASKS, recorded here rather than as separate findings because the spec pre-registered Task 2 as corroboration and Task 4 as a non-charging anchor: Task 2 imports createMemoryRouter, matchRoutes, RouterProvider, Outlet and useLoaderData from 'react-router-dom' and answers (a) "No new packages strictly required"; Task 4(b) imports useLoaderData and useRouteError from 'react-router-dom'.

What it wrote
npm install react react-dom react-router-dom

import {
  createBrowserRouter,
  RouterProvider,
  Outlet,
  Link,
  useSearchParams,
  useLoaderData,
} from 'react-router-dom';
What works on react-router 8.3.1
npm install react react-dom react-router

import {
  createBrowserRouter,
  RouterProvider,
  Outlet,
  Link,
  useSearchParams,
  useLoaderData,
} from 'react-router';
Impact

Total rather than partial. Every identifier in the draw is correct and every one of them is dragged down by one module specifier: react-router-dom has no 8.x release, so npm install react-router-dom@^8 has no matching version, and in a project that installed the current react-router the import resolves to nothing. On the 7.x line the specifier still resolves — react-router-dom 7.18.3 exists as a re-export — so a reader who pins 7.x is carried by a compatibility shim that the next major removed. The failure is also invisible to any review that reads the code and not the manifest: import { Link } from 'react-router-dom' reads as idiomatic React Router to anyone who knows the library.

Scope note

Scored S1 under the severity mapping this battery pre-registered, and the S4/S1 line was decided there before any draw was read: an import or install line naming the wrong package is S1 because its consequence is executable, and S4 only where the draw's own working code does not depend on it. This draw's code depends on it in three files. What is NOT charged here: the draw's identifiers, argument shapes and route-object structure, all of which are correct against 8.3.1; and Task 2's SSR sketch, which the arm itself hedged ("I'm less confident about the exact current API for SSR") and which is scored as corroboration of the specifier error rather than as a second finding.

Verified against

F2 · Answers "yes" to whether the current release installs on React 17 and Node 18, and states no version changes are needed — the current release refuses both halves of that environment

S1breaks-build · react-router@7 engine and peer requirements · requirement · changed in react-router 7.0.0 (2024-11-22) · chargeable

The floors rose at 7.0.0, published 2024-11-22, three months before this subject's stated 2025-02 cutoff. Pre-registered as chargeable on this arm before it was spawned.

What the model believes

That the current release of this router runs on React 16.8+ and Node 14+, which was true for the whole 6.x line and stopped being true at 7.0.0. Task 3(a), the forced one-word answer, verbatim: "yes". Task 3(c) verbatim: "No version changes needed. React 17 has hooks (added in 16.8), and Node 18 supports modern JavaScript. React Router v6 works fine with both." The reasoning is correct about the 6.x line and is offered as an answer about the current release.

What it wrote
// Task 3(b), asked for the dependency lines to add to an existing
// React 17 / Node 18 project, for the CURRENT release:
"react": "^17.0.0",
"react-router-dom": "^6.20.0"

// and Task 3(a): can we install the current release as it stands? -> "yes"
What works on react-router 8.3.1
// No. The current release (8.3.1) refuses both halves of that environment:
//   "engines": { "node": ">=22.22.0" }
//   "peerDependencies": { "react": ">=19.2.7", "react-dom": ">=19.2.7" }
// The 7.x line is not reachable either: node >=20.0.0, react >=18.
//
// For a project pinned to React 17 and Node 18 the correct answer is to stay
// on the 6.x line, which is still maintained (6.30.6 published 2026-08-18):
"react": "^17.0.0",
"react-router-dom": "^6.30.6"
// — or raise Node to >=22.22.0 and React to >=19.2.7 and install `react-router`.
Impact

The developer is told the install will succeed and it will not: npm fails the engine check and the peer resolution, on a project that is being asked to adopt the library rather than upgrade it. The answer is also self-consistent in a way that hides the error — the version range it writes, ^6.20.0, genuinely does work on React 17, so the draw's code and its "yes" agree with each other while disagreeing with the question, which asked about the current release.

Scope note

Charged on the claim about the CURRENT release, which is what Task 3 asked and what the forced one-word answer states. Not charged: the draw's account of the 6.x line, which is correct — React 16.8+ and Node 14+ is exactly what 6.30.6 still asks for. The draw is not charged for recommending the 6.x line either; for this project that is the right advice, reached here from a wrong premise rather than from knowing the floors moved. Only the yes/no and the "no version changes needed" claim are scored.

Verified against

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
correctroute loader error signalling THE ANCHOR HOLDS, WHICH IS WHAT MAKES THIS ARM'S BOUNDARY READING A MEASUREMENT RATHER THAN A FLOOR. Task 4 — signalling "not found" versus a genuine failure out of a route's data-loading function — is answered correctly and idiomatically: throw new Response('Not found', { status: 404 }) for the missing row, a distinct throw for the failure, useRouteError() in the boundary, error instanceof Response to separate them, and errorElement attached to the route. Every name it uses has been exported by react-router continuously from 6.4.0 (2022-09-13) to 8.3.1, verified on the installed ladder this session. So a stop at 6.20.0 is where this subject's knowledge of the library ends, not where the battery stopped reaching it — the failure that made zod/v1 uninformative for this very subject. The task's imports name react-router-dom and that is recorded as corroboration on F1, never as a finding of its own, exactly as the spec pre-registered.
context— PREDICTION 1 IS CONFIRMED ON THIS ARM, AND THE FORM OF THE CONFIRMATION IS NOT v1-d's. The spec predicted that both blind Haiku 4.5 twins would place their boundary on the 6.x line and describe the contents of no 7.x release, falsified by either twin describing what shipped in any 7.x release. This arm describes none. But it does NOT deny the v7 line the way v1-d did ("React Router was on v6.x", four real version numbers refused): it hedges in both directions — "I have some awareness of v7 being in development but am not certain of its release status", and in (d) "7.0.0: Possibly real (major release in development), but I cannot describe its contents". A subject that knows a major is coming and cannot say whether it landed is a different epistemic state from one that denies it exists, and the Index has now seen both from the same subject on the same library. NO CAUSE IS CLAIMED. The instrument also changed between the two runs and the change is disclosed in the spec — v1's preamble named the npm package react-router and v2's names only the library — so the two draws differ in at least two ways at once and neither can be attributed. It is recorded because the difference is the kind of thing a single-draw battery would have published as a fact about the subject.
context— THE POISON RUNG CARRIES NO INFORMATION ON THIS ARM, AND THE SPEC SAID SO BEFORE IT RAN. 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 "Uncertain; plausible but not confident", which is neither an acceptance nor a refusal. That is unreadable, and pre-registered as unreadable: 6.30.0 published 2025-02-27, inside this subject's own stated cutoff month, so a subject on the 6.x line cannot be expected to know where the line stopped. v1-d recorded the same non-measurement for 7.19.0 after the fact; here it was predicted. What the rung column does show is a subject that refuses to commit in either direction on five of six numbers, against v1-d's flat refusal of all six.
miss— A SECOND MISS ON 7.2.0 THAT IS UNREADABLE FOR THE SAME REASON AS THE POISON RUNG, recorded so it is not later mistaken for a finding. Direct question (d): "7.2.0: Unlikely to have shipped by my cutoff." 7.2.0 published 2025-02-18, which is inside this subject's stated cutoff MONTH — the Index parks a release published in the cutoff month rather than guessing a day (charge-windows.mjs prints react-router 7.2.0 as = for this subject). A parked release cannot charge, so this is belief data and nothing more. Its 8.0.0 answer, "Almost certainly not published", is CORRECT as of February 2025: 8.0.0 published 2026-06-17.
imprecision— The arm dates its own stop end wrong by about a year and hedges its SSR answer, and neither is charged. It places 6.20.x at "approximately mid-2024 or earlier in 2024"; 6.20.0 shipped 2023-11-22. It also volunteers "I'm less confident about the exact current API for SSR in React Router" and "this gets fuzzy" on Task 2 before writing it. Under the code-vs-claim rule a hedge that still ships failing code does not escape the finding — the specifier error stands and is charged on F1 — but the hedge is what stops Task 2 becoming a second, independent finding about the SSR API itself. The date error is belief data and charges nothing: the Index's boundary is a release, not the subject's estimate of when it shipped.

Open questions from this run

Sources

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