{
  "$schema": "../../schema/run.schema.json",
  "run_id": "next.js--claude-fable-5--v3-c--2026-09-02",
  "supersedes": null,
  "replicate_of": null,
  "library": {
    "name": "next.js",
    "ecosystem": "npm",
    "latest_version_at_test": "16.3.4",
    "latest_version_verified_on": "2026-09-02"
  },
  "model": {
    "id": "claude-fable-5",
    "label": "Claude Fable 5",
    "vendor": "Anthropic",
    "invoked_as": "Agent tool, model alias \"fable\"",
    "self_reported_cutoff": "2026-01",
    "cutoff_basis": "Self-reported: \"My training cutoff is January 2026. Practically, coverage of the last several weeks before that is thin - I'd treat my knowledge as solid through roughly November 2025 and increasingly spotty after.\" The caveat is about recall density, not about the date; the draw states one cutoff and does not dispute its environment. Not back-filled from any other run - its blind twin v3-d states the same value independently.",
    "believed_latest_version": "16.1.x",
    "believed_latest_quote": "\"The most recent line I'm aware of is Next.js 16.1.x, from roughly December 2025, with patches possibly into January 2026. The most recent release whose contents I can actually describe with confidence is 16.0 (~October 21, 2025)\"",
    "knowledge_stops_at_version": "16.0.0",
    "knowledge_stops_on": "2025-10-22",
    "knowledge_gap_starts_at_version": "16.1.0",
    "knowledge_gap_starts_on": "2025-12-18",
    "cutoff_lag_months": 3
  },
  "test": {
    "date": "2026-09-02",
    "battery": "next.js/v3-c",
    "battery_spec": "prompts/nextjs.md",
    "prompt_file": "prompts/sent/nextjs-v3.txt",
    "tasks": 5,
    "direct_questions": 2,
    "tool_uses_during_test": 0,
    "probe_window": {
      "from": "16.0.3",
      "to": "16.0.3"
    },
    "self_test": false,
    "saturated": false,
    "status": "open",
    "retested_on": null
  },
  "sources": [
    "https://unpkg.com/next@16.0.2/dist/server/config-shared.d.ts",
    "https://unpkg.com/next@16.0.3/dist/server/config-shared.d.ts",
    "https://unpkg.com/next@16.3.4/dist/server/config.js",
    "https://unpkg.com/next@16.3.4/dist/shared/lib/image-config.js",
    "https://nextjs.org/blog/next-16-2"
  ],
  "summary": "The Fable 5 half of next.js/v3, run 2026-09-02 after both Fable arms of the original battery died on an API-side safeguard error without emitting a token. The stored prompt was re-sent verbatim; nothing was reworded. This is the charging arm and it charges one finding: asked in one word whether per-part prefetching can be turned off, it answered \"Yes\" and wrote experimental: { clientSegmentCache: false }, a key removed in patch 16.0.3 on 2025-11-13, two months inside its own stated cutoff. Handed the same key back in task 2 it said the build accepts the config, and in task 5(a) it committed to the key still being recognised on current stable. What separates this draw from the Sonnet 5 draw that failed the same probe is that it did not assert a mechanism it lacked: it put the whole answer at about 60 percent, named the opposite branch explicitly, and reproduced the exact warning string the build would print if the key were gone - which it is. The finding is charged on the artefact under the code-vs-claim rule and the hedge is recorded with it. On the internal control it passed cleanly, naming proxy.ts exporting proxy and dating the rename to 16.0.0, which is right and is a major; the same draw could not reach a patch for the removal. Its twin v3-d, blind to this one, answered task 1 \"No\" and got the entire surface right, which falsifies the battery's first prediction. Both Fable draws read the same boundary this battery read in v1 and v2 - 16.0.0 describable, 16.1.0 not - so on this subject the boundary did not move between batteries or between twins.",
  "findings": [
    {
      "id": "F1",
      "severity": "S2",
      "severity_label": "silently-wrong",
      "title": "Answers \"yes\" and configures experimental.clientSegmentCache, a key removed in patch 16.0.3",
      "api": "experimental.clientSegmentCache",
      "change_kind": "removed",
      "introduced_in": "16.0.3",
      "introduced_on": "2025-11-13",
      "chargeable": true,
      "chargeable_note": "Removed 2025-11-13, two months before this draw's stated cutoff of January 2026. Not back-filled from another run: the twin v3-d states the same cutoff independently and charges nothing, because it got the surface right.",
      "model_belief": "Task 1(a), one word: \"Yes.\" Task 1(b): \"It is controlled by the clientSegmentCache flag ... Disabling it reverts to the older whole-route prefetch - one RSC payload request per link\". Task 2(a): \"the key is still recognised, so the build accepts the config\". Task 2(b): \"With false you get the legacy behaviour - a single prefetch per link carrying the route's RSC payload, duplicating shared-layout data across links\". Task 5(a): \"I believe experimental.clientSegmentCache is still recognised on current stable (it flipped default rather than disappearing)\".",
      "wrong_code": "experimental: { clientSegmentCache: false }",
      "correct_code": "experimental: { prefetchInlining: true }",
      "impact": "The team asked how to collapse a prefetch burst into one request per link and gets a config file that builds, deploys and does nothing. An unrecognised key under experimental warns and is dropped rather than failing the build, so the file reads as applied and the burst continues unchanged. The reader is also told the reverted behaviour will duplicate shared-layout data across links, which is a specific and false description of what their app will now do.",
      "citations": [
        {
          "url": "https://unpkg.com/next@16.0.2/dist/server/config-shared.d.ts",
          "title": "next 16.0.2 published package - the key still exists",
          "published_on": "2025-11-12",
          "quote": "clientSegmentCache?: boolean | 'client-only';"
        },
        {
          "url": "https://unpkg.com/next@16.0.3/dist/server/config-shared.d.ts",
          "title": "next 16.0.3 published package - gone one day later",
          "published_on": "2025-11-13",
          "quote": "(no occurrence of clientSegmentCache in the file)"
        },
        {
          "url": "https://unpkg.com/next@16.3.4/dist/server/config.js",
          "title": "next 16.3.4 published package - why the dead key warns instead of failing",
          "published_on": "2026-08-31",
          "quote": "if (issue.code === 'unrecognized_keys' && issue.path[0] === 'experimental') {"
        }
      ],
      "scope_note": "The hedge is part of the record and is not deducted from the charge. This draw put the answer at \"moderate (~60%)\", wrote out the branch in which it is wrong, and reproduced the warning the build actually prints - \"Invalid next.config.ts options detected: Unrecognized key(s) in object: 'clientSegmentCache' at experimental\" - as the counterfactual. It is charged because the task demanded a one-word verdict before any explanation, the verdict was \"Yes\", and the configuration written under it is inert. The code-vs-claim rule (prompts/nextjs.md v1) scores the artefact a reader would copy. Compared against next.js/v3-a, which failed the same probe while asserting the key \"is a recognized key under experimental in the config schema Next.js validates against\", this is the same wrong answer delivered with the uncertainty intact - the same severity, because the failure mode of a silently inert config does not depend on how confident its author was."
    }
  ],
  "non_findings": [
    {
      "kind": "correct",
      "summary": "Task 4, the internal control, passed cleanly. Named proxy.ts at the project root with the named export proxy, wrote a correct matcher-scoped redirect, named middleware.ts / export function middleware as the older form, and said correctly that it still works on 16 and warns. It also correctly identified the Next 12 per-directory _middleware.ts as a still older form that was removed in 12.2. Under JOURNAL/030(b) this is what makes the run's attribution answers readable at all: the subject holds the change, so its dating of it measures attribution rather than absence.",
      "api": "proxy.ts / export function proxy",
      "introduced_in": "16.0.0",
      "chargeable_miss": false
    },
    {
      "kind": "miss",
      "summary": "Task 3, and the reason it is not charged against this subject. Answered that the browser receives a resized AVIF or WebP with HTTP 200 and that no documented byte-size cap on the source file exists in self-hosted Next.js. The truth is a fixed 50 MB body cap that throws a 413 while streaming. images.maximumResponseBody arrived in 16.1.5 on 2026-01-26, the same month as this subject's stated cutoff, so it sits outside the fairness window under the same-month rule and is not a chargeable miss - the battery fixed this reading in advance for v3-a and v3-c both. Two details worth keeping: the draw declined to invent a key or a number, saying so explicitly - \"I cannot honestly write a 5 MB config, and I won't invent one\" - and it reached instead for sharp's 268 megapixel input limit and the keys experimental.imgOptMaxInputPixels and experimental.imgOptTimeoutInSeconds. Those two key names were not verified this session and the Index makes no claim about them either way.",
      "api": "images.maximumResponseBody",
      "introduced_in": "16.1.5",
      "chargeable_miss": false
    },
    {
      "kind": "correct",
      "summary": "Task 3(c), the fixed-policy versus resource discriminator, answered correctly and for the correct reason despite the wrong answer in (a) and (b): \"No. Neither limit is resource-adaptive: the pixel cap is a decompression-bomb guard and the timeout is fixed config, so more RAM/disk changes nothing about the defined behaviour.\" It then separated an undefined failure - the process being OOM-killed mid-decode - from a framework limit. This is the sub-question next.js/v3-e and v3-f landed on opposite sides of; both Fable draws land on the correct side.",
      "api": "images.maximumResponseBody",
      "introduced_in": "16.1.5",
      "chargeable_miss": false
    },
    {
      "kind": "context",
      "summary": "Attribution, and the patch result holds for a fourth draw. This draw dates the middleware-to-proxy rename to 16.0.0, ~October 21 2025, which is right to the release and is a major it demonstrably holds. Asked in the same task for the release at which clientSegmentCache stopped being recognised, it committed to the key still being recognised and named 16.0.0 as the fallback if it were wrong. The removal is 16.0.3. Across two subjects and three batteries no draw has yet attributed any change to a patch release, and this draw shows the split inside one task: the major it holds is dated correctly, the patch is unreachable even as a hypothetical.",
      "api": "experimental.clientSegmentCache",
      "introduced_in": "16.0.3",
      "chargeable_miss": false
    },
    {
      "kind": "context",
      "summary": "The boundary did not move for this subject, which is the contrast the battery could not draw from Sonnet 5. Fable 5 x next.js now has four readings across three batteries - v1, v2-d, and both v3 twins - and all four are identical: 16.1.x known by name, 16.0.0 (2025-10-22) the most recent release whose contents it can describe, nothing describable at 16.1.0 (2025-12-18). Sonnet 5 on the same library reads 15.0.0, 15.0.0, 15.3.0 and 15.5.0 across the same three batteries. JOURNAL/033 left open whether v3 moved Sonnet's boundary or whether v1 and v2 happened to agree; this run does not settle that, but it does show the instrument holding perfectly still on a second subject over the same three batteries, so whatever moves Sonnet's reading is not something every battery does to every subject.",
      "api": null,
      "introduced_in": null,
      "chargeable_miss": false
    },
    {
      "kind": "context",
      "summary": "The arm ran. Both Fable arms of this battery failed on 2026-09-02 with an API-side safeguard error (invalid_request, [reasoning_extraction]) before emitting a token, were retried once each and failed identically, and were recorded in JOURNAL/033 as void rather than as runs. The stored prompt at prompts/sent/nextjs-v3.txt was re-sent byte-identical in a later session and both arms completed without incident. The earlier failure is therefore transient and infrastructural, and is not a property of this prompt or this subject. No wording changed between the void attempt and this run.",
      "api": null,
      "introduced_in": null,
      "chargeable_miss": false
    }
  ],
  "open_questions": [
    {
      "question": "Prediction P1 said all four Sonnet 5 and Fable 5 draws would reach experimental.clientSegmentCache. Three of four did; this draw's twin v3-d did not, answering \"No\" and naming the key only to say it is gone. The prediction is falsified on the fourth draw, and the two subjects split the same way internally: both Sonnet draws fail the surface, one Fable draw of two fails it. Whether that is a subject difference or two coin flips cannot be read from four draws.",
      "status": "open"
    },
    {
      "question": "This draw and next.js/v3-a produce the same wrong configuration with opposite epistemics - one at 60 percent with the correct counterfactual spelled out, one asserting a schema validation that does not exist. The Index scores both S2 because the artefact is identical, and the severity scale has no way to say that one of them warned its reader. Whether that is the right treatment or a gap in the scale is unresolved; JOURNAL/032 declined to add a fifth level and this is a second kind of pressure on the same edge.",
      "status": "open"
    }
  ]
}