{
 "$schema": "../../schema/run.schema.json",
 "run_id": "react-router--claude-sonnet-5--v2-c--2026-09-10",
 "supersedes": null,
 "replicate_of": null,
 "library": {
  "name": "react-router",
  "ecosystem": "npm",
  "latest_version_at_test": "8.3.1",
  "latest_version_verified_on": "2026-09-10",
  "latest_version_note": "Same verification as the two Haiku arms, run once for the battery: registry `dist-tags` (`latest` 8.3.1, `version-7` 7.18.3, `version-6` 6.30.6, the last published 2026-08-18), `react-router-dom` `latest` 7.18.3 with no 8.x release of any kind, and both charged surfaces re-read off the 51-rung ladder JOURNAL/116 and /118 left installed."
 },
 "model": {
  "id": "claude-sonnet-5",
  "label": "Claude Sonnet 5",
  "vendor": "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.",
  "self_reported_cutoff": "2026-01",
  "cutoff_basis": "Self-reported to the plainest form of the question, and it sits ON the line JOURNAL/035 drew and JOURNAL/055 said would not be re-argued, so the reading is recorded in full. Verbatim: \"My stated training cutoff, per this environment, is **January 2026**. I want to flag a gap though: that's the cutoff I've been told applies to me, but my *confident, specific* recall of this particular library's changelog thins out well before that — solidly through the v7.0 launch, fuzzier for anything after roughly early-to-mid 2025.\"\n\nREAD AS AN AFFIRMATION WITH A DENSITY CAVEAT, NOT A REPUDIATION — CHARGEABLE. The distinguishing test HARNESS.md states for exactly this case is: does the answer QUALIFY the subject's recall, or does it CHOOSE between two dates? This draw names one date as its cutoff and offers no second date in that role. \"early-to-mid 2025\" is explicitly where its *recall of this library's changelog* thins, not a cutoff it would substitute, and the draw never says which of two dates it would trust — the verb JOURNAL/055 made decisive. Compare the repudiations that rule was written for, which named the environment value, said they would trust their own sense over it, and then offered \"mid-2025\" AS the effective cutoff.\n\nWHAT IS NEW HERE AND IS AN INSTRUMENT OBSERVATION RATHER THAN A DATUM ABOUT THE SUBJECT: this draw attributes the date's PROVENANCE to the session (\"per this environment\", \"the cutoff I've been told applies to me\") without disputing it. No previous run in this corpus has done that. It qualifies where the number came from, not what the number is, and under the same test it changes nothing about chargeability. Recorded so the next draw that does it is not read fresh.",
  "believed_latest_version": "7.0.0",
  "believed_latest_quote": "\"(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.\"\n\nBRACKET 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.\n\nITS 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.",
  "knowledge_stops_at_version": "7.0.0",
  "knowledge_stops_on": "2024-11-22",
  "knowledge_gap_starts_at_version": "7.1.0",
  "knowledge_gap_starts_on": "2024-12-20",
  "cutoff_lag_months": 13
 },
 "test": {
  "date": "2026-09-10",
  "battery": "react-router/v2-c",
  "battery_spec": "prompts/react-router.md",
  "prompt_file": "prompts/sent/react-router-v2.txt",
  "tasks": 4,
  "direct_questions": 4,
  "elicits_code": true,
  "tool_uses_during_test": 0,
  "probe_window": {
   "from": "7.0.0",
   "to": "7.0.0"
  },
  "self_test": false,
  "saturated": false,
  "status": "open",
  "retested_on": null
 },
 "sources": [
  "https://registry.npmjs.org/react-router",
  "https://registry.npmjs.org/react-router-dom",
  "https://github.com/remix-run/react-router/blob/main/packages/react-router/CHANGELOG.md"
 ],
 "findings": [],
 "non_findings": [
  {
   "kind": "correct",
   "summary": "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.",
   "api": "react-router (package exports)",
   "introduced_in": "7.0.0"
  },
  {
   "kind": "correct",
   "summary": "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.",
   "api": "react-router@7 engine and peer requirements",
   "introduced_in": "7.0.0"
  },
  {
   "kind": "miss",
   "summary": "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.",
   "api": null,
   "introduced_in": "8.0.0",
   "chargeable_miss": false,
   "why_not_a_finding": "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."
  },
  {
   "kind": "miss",
   "summary": "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.",
   "api": null,
   "introduced_in": null,
   "chargeable_miss": false
  },
  {
   "kind": "context",
   "summary": "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.",
   "api": null,
   "introduced_in": null
  },
  {
   "kind": "context",
   "summary": "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.",
   "api": null,
   "introduced_in": null
  },
  {
   "kind": "imprecision",
   "summary": "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.",
   "api": null,
   "introduced_in": null
  }
 ],
 "open_questions": [
  {
   "question": "Sonnet 5's react-router lag is 13.4 months against its own 9.5-month median, and its per-library lags are bimodal — {2.5, 5.7, 9.0, 9.5} against {13.1, 13.3, 13.4, 14.4}. Is the split a property of the libraries or of this subject? — Four of the eight sit within a month of each other at ~13-14 months, which is close enough to the subject's own release date to look like a floor rather than a library effect, and the other four are spread across seven months. If the high cluster is a floor, the quantity the Index calls a boundary is measuring two different things depending on which side a library falls, and the loud-library mechanism cannot be tested on a library in the high cluster at all. The test is cheap and needs no new battery: the same split can be computed for every subject out of `data/index.json.knowledge_boundary`, which now has eight libraries for four subjects.",
   "status": "open",
   "resolved_in_run": null
  }
 ],
 "summary": "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."
}