{
 "$schema": "../../schema/run.schema.json",
 "run_id": "react-router--claude-haiku-4-5--v2-a--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": "`https://registry.npmjs.org/react-router` read this session before the prompt was written: `dist-tags.latest` is 8.3.1, `version-7` is 7.18.3, `version-6` is 6.30.6 — and the 6.x line is still alive, 6.30.6 having published 2026-08-18, three weeks before this battery. `https://registry.npmjs.org/react-router-dom` the same session: `latest` is 7.18.3 and there is NO 8.x release of any kind. Both surfaces this battery charges were then re-read off the 51-rung ladder JOURNAL/116 and /118 left installed (one release per directory, resolved alone): `react-router` exports 59 names at 6.28.0 and 111 at 7.0.0, none of LF8's fifteen names present at any 6.x rung and all fifteen present from 7.0.0 up; `engines.node` `>=14.0.0` -> `>=20.0.0` -> `>=22.22.0` and the react peer `>=16.8` -> `>=18` -> `>=19.2.7` across 6.x / 7.x / 8.x."
 },
 "model": {
  "id": "claude-haiku-4-5",
  "label": "Claude Haiku 4.5",
  "vendor": "Anthropic",
  "invoked_as": "Agent 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.",
  "self_reported_cutoff": "2025-02",
  "cutoff_basis": "Self-reported, plain and unqualified, to the plainest form of the question (\"What is your training cutoff?\", no trust clause): \"**Training cutoff:** February 2025.\" No hedge, no substitute date, no library-scoped qualifier, and none volunteered elsewhere in the reply — the arm also opened with \"I'll work through these without tools, from training knowledge only\" and stated February 2025 unprompted in direct question (a). NOT back-filled from any other run of this subject (JOURNAL/031); it agrees with `v1-d`'s datum but is this draw's own.",
  "believed_latest_version": "6.20.0",
  "believed_latest_quote": "\"**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.\"\n\nBRACKET 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.\n\nTHE 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.\n\nCONTRAST 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.",
  "knowledge_stops_at_version": "6.20.0",
  "knowledge_stops_on": "2023-11-22",
  "knowledge_gap_starts_at_version": "7.0.0",
  "knowledge_gap_starts_on": "2024-11-22",
  "cutoff_lag_months": 14
 },
 "test": {
  "date": "2026-09-10",
  "battery": "react-router/v2-a",
  "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": [
  {
   "id": "F1",
   "severity": "S1",
   "severity_label": "breaks-build",
   "title": "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",
   "api": "react-router (package exports)",
   "change_kind": "added",
   "introduced_in": "7.0.0",
   "introduced_on": "2024-11-22",
   "chargeable": true,
   "chargeable_note": "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.",
   "model_belief": "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'`.",
   "wrong_code": "npm install react react-dom react-router-dom\n\nimport {\n  createBrowserRouter,\n  RouterProvider,\n  Outlet,\n  Link,\n  useSearchParams,\n  useLoaderData,\n} from 'react-router-dom';",
   "correct_code": "npm install react react-dom react-router\n\nimport {\n  createBrowserRouter,\n  RouterProvider,\n  Outlet,\n  Link,\n  useSearchParams,\n  useLoaderData,\n} 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.",
   "citations": [
    {
     "url": "https://github.com/remix-run/react-router/blob/main/packages/react-router/CHANGELOG.md",
     "title": "react-router CHANGELOG.md — 7.0.0, Major Changes",
     "published_on": "2024-11-22",
     "quote": "Collapse `@remix-run/router` into `react-router`\n  - Collapse `react-router-dom` into `react-router`\n  - Collapse `@remix-run/server-runtime` into `react-router`\n  - Collapse `@remix-run/testing` into `react-router`"
    },
    {
     "url": "https://registry.npmjs.org/react-router-dom",
     "title": "npm registry metadata for react-router-dom, read 2026-09-10",
     "published_on": "2026-09-10",
     "quote": "dist-tags.latest is 7.18.3 and no 8.x version of any kind is published."
    },
    {
     "url": "https://registry.npmjs.org/react-router",
     "title": "Bisected against the published packages (tools/audit/bisect-facts.mjs, 2026-09-10, JOURNAL/116)",
     "published_on": "2026-09-10",
     "quote": "`react-router` exports 59 names at 6.28.0 and 111 at 7.0.0. BrowserRouter, HashRouter, Link, NavLink, Form, useSubmit, useSearchParams and createBrowserRouter are absent at every rung from 6.4.0 to 6.30.6 and present at every rung from 7.0.0 to 8.3.1."
    }
   ],
   "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."
  },
  {
   "id": "F2",
   "severity": "S1",
   "severity_label": "breaks-build",
   "title": "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",
   "api": "react-router@7 engine and peer requirements",
   "change_kind": "requirement",
   "introduced_in": "7.0.0",
   "introduced_on": "2024-11-22",
   "chargeable": true,
   "chargeable_note": "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.",
   "model_belief": "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.",
   "wrong_code": "// Task 3(b), asked for the dependency lines to add to an existing\n// React 17 / Node 18 project, for the CURRENT release:\n\"react\": \"^17.0.0\",\n\"react-router-dom\": \"^6.20.0\"\n\n// and Task 3(a): can we install the current release as it stands? -> \"yes\"",
   "correct_code": "// No. The current release (8.3.1) refuses both halves of that environment:\n//   \"engines\": { \"node\": \">=22.22.0\" }\n//   \"peerDependencies\": { \"react\": \">=19.2.7\", \"react-dom\": \">=19.2.7\" }\n// The 7.x line is not reachable either: node >=20.0.0, react >=18.\n//\n// For a project pinned to React 17 and Node 18 the correct answer is to stay\n// on the 6.x line, which is still maintained (6.30.6 published 2026-08-18):\n\"react\": \"^17.0.0\",\n\"react-router-dom\": \"^6.30.6\"\n// — 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.",
   "citations": [
    {
     "url": "https://github.com/remix-run/react-router/blob/main/packages/react-router/CHANGELOG.md",
     "title": "react-router CHANGELOG.md — 7.0.0 major changes",
     "published_on": "2024-11-22",
     "quote": "Drop support for Node 18, update minimum Node vestion to 20"
    },
    {
     "url": "https://registry.npmjs.org/react-router",
     "title": "Installed manifests across the 51-rung ladder (tools/audit/bisect-facts.mjs, 2026-09-10, JOURNAL/118)",
     "published_on": "2026-09-10",
     "quote": "engines.node is \">=14\" through 6.15.x and \">=14.0.0\" from 6.16.0 to 6.30.6, \">=20.0.0\" from 7.0.0, \">=22.22.0\" from 8.0.0; the react peer is \">=16.8\" on the whole 6.x line, \">=18\" from 7.0.0, \">=19.2.7\" from 8.0.0."
    }
   ],
   "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."
  }
 ],
 "non_findings": [
  {
   "kind": "correct",
   "summary": "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.",
   "api": "route loader error signalling",
   "introduced_in": "6.4.0"
  },
  {
   "kind": "context",
   "summary": "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.",
   "api": null,
   "introduced_in": "7.0.0"
  },
  {
   "kind": "context",
   "summary": "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.",
   "api": null,
   "introduced_in": null
  },
  {
   "kind": "miss",
   "summary": "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.",
   "api": null,
   "introduced_in": "7.2.0",
   "chargeable_miss": false
  },
  {
   "kind": "imprecision",
   "summary": "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.",
   "api": null,
   "introduced_in": null
  }
 ],
 "open_questions": [
  {
   "question": "Does `defer`'s removal at 7.0.0 belong in the Index as a fact, and does this battery's silence about it mean anything? — A sweep run this session over all 61 installed rungs found `defer` exported at every 6.x rung including 6.30.6 (published 2026-08-18) and absent at every rung from 7.0.0 up — contiguous, witness never absent, zero unreadable rungs, which is bisect-quality evidence of a removal at exactly the release this battery probes. The Index holds no fact for it. It was measured BEFORE these draws were read and recorded in the spec as queued rather than written, so that a draw using `defer` could not be charged against a fact retrofitted to it. Neither Haiku twin used `defer`, so nothing turns on it here — but a v6-era subject writing a deferred loader is a live S1 that this corpus currently cannot charge, which is the same gap `v1-d` opened and LF8 closed.",
   "status": "open",
   "resolved_in_run": null
  }
 ],
 "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."
}