{
  "$schema": "../../schema/run.schema.json",
  "run_id": "react-router--claude-fable-5-1--v1-a--2026-09-09",
  "supersedes": null,
  "replicate_of": null,
  "library": {
    "name": "react-router",
    "ecosystem": "npm",
    "latest_version_at_test": "8.3.1",
    "latest_version_verified_on": "2026-09-09",
    "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. Three real installs were driven this session, each under the package's real name in its own scratch directory beside `react@19.2.8`: `react-router@7.11.0`, `@7.14.2` and `@8.3.1`."
  },
  "model": {
    "id": "claude-fable-5-1",
    "label": "Claude Fable 5.1",
    "vendor": "Anthropic",
    "invoked_as": "Agent tool, model alias \"fable\"; prompt sent verbatim from prompts/sent/react-router-v1.txt. Pre-registered as the CHARGING half of the test arm, duplicated at birth with `v1-b`. It is the only subject for whom this battery had more than one live fact — and it disqualified itself on direct question (b), so all three of its reproduced failures are chargeable misses.",
    "self_reported_cutoff": null,
    "cutoff_basis": "REPUDIATED, and therefore null. Asked the standing plain wording — \"What is your training cutoff?\", with no trust clause — it answered: \"My training cutoff is June 2026 as I understand it, but my usable knowledge of this library's changelog visibly thins out around late 2025 — **treat that as the effective cutoff for React Router**.\" HARNESS.md § *A library-scoped substitute cutoff is still a repudiation* supplies the distinguishing test: does the answer qualify the subject's recall, or does it choose between two dates? This one names a second date and instructs the reader to use it AS the cutoff for this library. The scope does not save it — \"Choosing is a cutoff claim, whatever scope it is given\" — and the tie-break the same section fixes applies: a rule read one way produces findings and read the other way produces none, so it is read the way that produces none. `self_reported_cutoff: null`, no charge, `chargeable_miss: true` on every failure, `miss_class: stated_cutoff`. THIS IS NEW EVIDENCE ABOUT THE INSTRUMENT AND IT CUTS AGAINST WHAT THE INDEX CONCLUDED IN JOURNAL/056: the repudiation was produced by the STANDING wording, the one that was reverted to precisely because `valibot/v4` measured it as the wording under which this subject affirms. See the journal entry.",
    "believed_latest_version": "7.13.0",
    "believed_latest_quote": "\"The highest version I believe exists is somewhere in the 7.1x line — I am fairly sure 7.13.0 shipped in early 2026, and I would not be surprised by a few more after it. The most recent release whose contents I can actually describe is 7.9.0 (September 2025), with only partial knowledge of 7.10.0 (roughly November 2025). I do not have knowledge of a released React Router 8.0.0 with contents I can describe.\"\n\nBRACKET PROVENANCE — The two direct questions disagree by one release and the disagreement is recorded rather than resolved silently. Question (a) says the most recent release whose contents it can describe is 7.9.0, \"with only partial knowledge of 7.10.0\". Question (c) — the designated ruler, asked last — lists 7.10.0 WITH contents at \"partial confidence\" (`unstable_instrumentations`, `unstable_pattern` on loader/action args) and then names 7.11.0 as \"the first release I know only as a version number\". This is HARNESS.md § *Grade the rungs, disclose the cell you do not have* arriving from the hedged side: an arm that qualifies a rung and then describes it. The bracket is taken from (c), the ruler question, so `stops_at` is 7.10.0 and the gap opens at 7.11.0. NOTHING IN THIS RUN TURNS ON THE CHOICE: the battery's prediction is falsified under both readings (7.10.0 is 2025-12-02 and 7.9.0 is 2025-09-12; the falsification threshold is 2025-12-15), and every charge is barred by the cutoff repudiation regardless. Its content attribution for 7.10.0 is also approximately right and slightly early by the Index's own bisect — `unstable_pattern` is present from 7.9.5 (JOURNAL/108), which under the Index's minor-granularity convention belongs to the 7.9 line.",
    "knowledge_stops_at_version": "7.10.0",
    "knowledge_stops_on": "2025-12-02",
    "knowledge_gap_starts_at_version": "7.11.0",
    "knowledge_gap_starts_on": "2025-12-17",
    "cutoff_lag_months": 6
  },
  "test": {
    "date": "2026-09-09",
    "battery": "react-router/v1-a",
    "battery_spec": "prompts/react-router.md",
    "prompt_file": "prompts/sent/react-router-v1.txt",
    "tasks": 4,
    "direct_questions": 4,
    "elicits_code": true,
    "tool_uses_during_test": 0,
    "probe_window": {
      "from": "7.12.0",
      "to": "7.15.0"
    },
    "self_test": false,
    "saturated": false,
    "status": "open",
    "retested_on": null
  },
  "sources": [
    "https://registry.npmjs.org/react-router",
    "https://github.com/remix-run/react-router/blob/main/packages/react-router/CHANGELOG.md",
    "https://github.com/remix-run/react-router/pull/15121"
  ],
  "findings": [],
  "non_findings": [
    {
      "kind": "miss",
      "summary": "LF1, reproduced and uncharged. Asked for the concrete URL, it wrote `generatePath(BOOK_JSON, { id })` with the comment `// intended: \"/books/7.json\"` and then answered (b) in the present tense: \"The current `generatePath` is segment-based ... `:id.json` is one segment and does not match that regex, so the segment is passed through untouched. As I remember the implementation, the call above returns **`/books/:id.json`** unchanged for `\"7\"` — and it does not throw.\" It said it \"would not ship the above without a test\". Executed this session: `react-router@8.3.1` returns `\"/books/7.json\"`; `@7.11.0`, the release below the boundary, returns `\"/books/:id.json\"`. The belief is 7.11.0's behaviour stated as current, seven months after 7.12.0 fixed it — the same failure `v1-c` is charged S2 for. Barred here by the cutoff repudiation only. Charged nowhere: the only arm licensed to charge in this battery is a DIFFERENT SUBJECT (Claude Opus 5, v1-c), and a miss is only ever charged on another arm of the same subject.",
      "api": "generatePath",
      "introduced_in": "7.12.0",
      "chargeable_miss": true,
      "miss_class": "stated_cutoff",
      "charged_on": null,
      "why_not_a_finding": "Direct question (b) offered a library-scoped substitute date as the effective cutoff, which HARNESS.md reads as a repudiation."
    },
    {
      "kind": "miss",
      "summary": "LF3, reproduced and uncharged, and it is the one failure in this battery whose artifact does NOT compile. Task 2's shipped code is `import type { unstable_Instrumentation } from \"react-router\"`, a handler reading `info.unstable_pattern`, and three wiring sites — `export const unstable_instrumentations = [timing]`, `<HydratedRouter unstable_instrumentations={[timing]} />` and `createBrowserRouter(routes, { unstable_instrumentations: [timing] })`. Counted in the shipped `dist/` this session: `unstable_Instrumentation` appears 24 times at 7.11.0 and 7.14.2 and **0 times at 8.3.1**; `unstable_instrumentations` 156 times and **0**; `unstable_pattern` 164 / 148 and **0**. The names are gone, not aliased (LF3), so the type import fails to resolve, the option is silently ignored and `info.unstable_pattern` is `undefined`. Under the battery's pre-registered mapping this is S1 breaks-build. It is not an invention: every identifier it used is real below 7.15.0, which is what makes it a stale prior rather than a confabulation.",
      "api": "instrumentations",
      "introduced_in": "7.15.0",
      "chargeable_miss": true,
      "miss_class": "stated_cutoff",
      "charged_on": null,
      "why_not_a_finding": "Cutoff repudiated; and no other arm in this battery is above 7.15.0's park line, so this failure is charged nowhere."
    },
    {
      "kind": "imprecision",
      "summary": "Task 3 reads the URL with `new URL(request.url)` and never mentions the normalised `url` loader argument (LF2). Working code and an imprecision under the additive-API rule — it did not claim no such argument exists. Its (b) answer contains a claim the Index CANNOT adjudicate and must not pretend to: \"Client-side navigations hit the server as `/books/7.data?_routes=...`. The router strips the `.data` suffix and the `_routes` param before calling your loader, so you should see the clean URL.\" That is LF2's second clause, in the opposite direction, and it is the exact clause `data/react-router/facts.json` records as never executed — `createStaticHandler` does not produce a client data request, so the bisector has no probe for it and neither does this session. Recorded as an open question, not as a finding in either direction.",
      "api": "url",
      "introduced_in": "7.15.0"
    },
    {
      "kind": "correct",
      "summary": "THE ANSWER THAT WOULD HAVE BEEN THE BATTERY'S BEST FINDING IF IT HAD GONE THE OTHER WAY, AND IT IS RIGHT. Having declared `generatePath` unusable for this pattern, it recommended the typed helper instead — \"use the typed `href()` helper, which does a `/:param` substring replace rather than whole-segment matching\" — and gave `href(\"/books/:id.json\", { id: \"7\" }); // \"/books/7.json\"`. Executed this session at three rungs: `href` returns `\"/books/7.json\"` at 7.11.0, 7.14.2 AND 8.3.1. The recommendation is correct at every release tested, including the ones below LF1's boundary where `generatePath` really did fail. `v1-c` reached the opposite conclusion about the same helper on the same prompt and was wrong.",
      "api": "href",
      "introduced_in": null
    },
    {
      "kind": "correct",
      "summary": "The attribution anchor holds. Task 4 produced a working framework-mode scaffold — the `@react-router/dev/vite` plugin, `react-router.config.ts` typed with `Config`, `app/routes.ts` with `index`/`route`, a route module using `Route.LoaderArgs`/`Route.MetaArgs`/`Route.ComponentProps` from `./+types/`, and the `rootDirs` typegen wiring — and dated 7.0.0 to \"Nov 2024\" (actual 2024-11-22). The arm is well above the floor and its boundary answer is readable.",
      "api": null,
      "introduced_in": "7.0.0"
    },
    {
      "kind": "context",
      "summary": "The poison rung produced no false positive. `7.19.0` has never been published and this arm declined it — \"Unknown. At the ~monthly cadence, 7.19 would fall around mid/late 2026, at or past my effective knowledge; I cannot confirm it was published\" — while asserting 7.9.0, 7.5.0 and 7.13.0 as real. 7.13.0 IS real (2026-01-23) and it dated it \"roughly February 2026\", one month late and above its own stated gap, which it flagged as undescribable content. It abstained on both 8.x rungs. So the rung licenses reading this arm's boundary: nothing in its version answers is confabulated.",
      "api": null,
      "introduced_in": null
    },
    {
      "kind": "context",
      "summary": "THE PREDICTION IS FALSIFIED ON THIS ARM, and under both readings of its bracket. Predicted: a boundary later than this subject's 2025-12-15 median across the seven measured libraries — react-router being the loudest library the Index has probed, and JOURNAL/015's mechanism holding that a loud library looks newer to a model than a quiet one. Measured: 7.10.0 (2025-12-02) on the ruler question, 7.9.0 (2025-09-12) on question (a). Both are below the threshold. This subject's boundary on react-router is EARLIER than its median across seven other libraries, not later.",
      "api": null,
      "introduced_in": null
    }
  ],
  "open_questions": [
    {
      "question": "On the v8 line, does a client data request's `request.url` reach a loader carrying the `.data` suffix and the `index`/`_routes` search params, or does the router still strip them? (Why it matters: It is LF2's second clause, the Index has never executed it, and this arm asserted the stripping confidently while the fact's note leans the other way for v8 (`future.v8_passThroughRequests` was removed). Neither direction can be charged until a framework-mode server producing a real client data request is driven; `createStaticHandler` does not produce one.)",
      "status": "open"
    }
  ],
  "summary": "The charging half of the test arm, and it charged nothing. It reproduced both of the battery's designed failures — `generatePath` stated in the present tense as returning the pattern unsubstituted, and a full instrumentation setup built on three `unstable_`-prefixed names that have zero occurrences in 8.3.1's shipped `dist` — and then disqualified itself on the cutoff question, offering \"late 2025\" as the effective cutoff for this library. That question used the STANDING plain wording, which is the wording JOURNAL/056 measured as the one under which this subject affirms, so the repudiation is new evidence about the instrument rather than a known cost. Boundary 7.10.0 / 7.11.0, which falsifies the battery's loud-library prediction. Its one unhedged recommendation was right and is the correction the Index will ship: `href()` substitutes a suffixed param at every release tested."
}
