Run react-router--claude-sonnet-5--v3-b--2026-09-22
Claude Sonnet 5, test arm, blind twin of v3-a, byte-identical prompt. Reproduced its sibling on both graded cells: LF11 abstain (route shouldRevalidate composition, no dataStrategy), LF12 abstain (errorElement plus React root callbacks, <HydratedRouter /> bare). Same stop-end boundary at 7.0.0, gap end one to two minors higher. Task 2(c) correct, with the clearest statement in the battery of the silent-failure mechanism that sets LF12's severity. It identified the missing componentStack that onError's second argument supplies, and still did not find the prop. No charge.
| Subject | Claude Sonnet 5 claude-sonnet-5, Anthropic |
|---|---|
| Invoked as | Agent tool, model alias "sonnet"; prompt sent verbatim from prompts/sent/react-router-v3.txt, BYTE-IDENTICAL to the file `-a` received (sha256 5f51d710d575157e5e7995b2d642563df1c7fe30d5462743aa3a4c5997a6c4a5). Pre-registered in prompts/react-router.md § v3 as arm `-b`, TEST ARM, blind twin, charging LF11 and LF12. Spawned independently of `-a` with no knowledge of it. |
| 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 | "The most recent release whose contents I can actually describe with real confidence is v7.0.0, shipped November 2024 — the release that merged Remix into React Router, introduced the three \"modes\" (Framework, Data, Declarative), unified the package so react-router alone provides both routing and DOM bindings (with react-router/dom for browser-entry helpers like HydratedRouter), and added type-safe route typegen." |
| How the bracket was read | STOP END IDENTICAL TO ITS TWIN, GAP END SLIGHTLY HIGHER. Stop 7.0.0 (2024-11-22), dated "November 2024" — right, and the description is accurate on every clause including the react-router/dom entry point. The gap end differs from -a: this twin puts it at "anything past roughly v7.2-7.3 onward", where -a said "roughly anything from v7.1.0 onward". Recorded as the twins' only disagreement about the boundary, and it is one to two minors wide.
This twin also describes a release -a did not: v6.28.x, "roughly Oct/Nov 2024", with the full set of v7_* future flags named individually. react-router 6.28.0 published 2024-11-06, so the date is right.
BOTH TWINS AGREE WITH react-router/v2-c AT 7.0.0. The corpus datum is unmoved by three independent measurements. (stop end stated, gap end stated) |
| Library at test time | react-router 8.4.0 (npm), verified 2026-09-22 |
| Battery | react-router/v3-b · 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 ABSTAIN, same as its twin and by the same route. Wraps each route's own shouldRevalidate, composes through args.defaultShouldRevalidate, never reaches dataStrategy. None of the four graded identifiers appears. It also volunteers the same unprompted stability claim -a did: "I'm not treating anything here as unstable_-prefixed — the whole shouldRevalidate mechanism has been part of the stable data-router surface since it shipped in v6.4." True of what it wrote. |
| miss | onError (HydratedRouter / RouterProvider prop) |
LF12 ABSTAIN. <HydratedRouter /> rendered bare again; reporting wired through errorElement / a root ErrorBoundary export plus React's onRecoverableError on hydrateRoot. Neither onError nor unstable_onError appears. This twin adds a caveat -a did not: that useRouteError() hands you no real componentStack, "a real limitation of this approach, not something I'm papering over" — which is correct, and is the gap onError's second argument actually fills. It identified the need the prop exists to serve and did not find the prop. |
| correct | — | TASK 2(c) CORRECT, and this twin independently produced the exact sentence LF12's severity rests on: "A prop like a mistyped onErorr passed to RouterProvider... is simply unused — it's a silent no-op, which is exactly the kind of thing that bites people in wiring like this." Five arms, five NOs, and three of them spelled out the harm mechanism unprompted. |
| correct | — | POISON RUNG NOT DESCRIBED. 7.19.0: "plausibly real, no reliable memory of contents." Ladder stands. Same caveat as -a: it gave the identical answer to the real 7.10.0, 7.11.0 and 7.15.0, so this is absence of confabulation and not presence of discrimination. |
| context | — | DIRECT (e), non-charging by pre-registration, and this twin names a surface -a did not: "unstable_dataStrategy → dataStrategy — introduced experimentally for controlling how loaders/actions execute across matched routes, later stabilized (I believe around the v7 line, but I'm not confident of the exact minor version)." That is the dataStrategy OPTION's own stabilisation, not LF11's per-match methods, and it is roughly right — react-router/v3-c dates the same event to 7.0.0. Neither twin named shouldCallHandler or onError. |
| context | — | 8.4.0 CALLED VERY LIKELY FAKE, non-charging for -a's reason: the 8.x line is five months above this subject's stated cutoff and below its floor by construction. |
zod/v7 FOUND. Prediction 2 registered that they would disagree on at least one graded cell, on the reasoning that the gap between surface and cutoff was narrower here than in zod/v7, where byte-identical twins believed opposite things about one library's failure mode. Here they produced the same verdict on both facts, by the same route, with the same unprompted stability claim — and differed only on ungraded choices (React root callback: onCaughtError/onUncaughtError versus onRecoverableError) and on their gap-end self-report (v7.1.0 versus v7.2-7.3). Is duplication informative mainly where the subject REACHES the probed surface, and near-redundant where both twins abstain? If so the duplication rule could be spent where it pays, but the corpus has two data points and that is not enough to change a standing rule. — openBattery specification: prompts/react-router.md in the studio repo.
Every finding above also carries its own citation.