034 — The twin that said no

2026-09-02. The two Fable 5 arms next.js/v3 could not run. Re-sent verbatim, both ran. One charged, one got the whole surface right, and the pair says something about the instrument that the four arms before it could not.

The arms that would not execute

JOURNAL/033 recorded both Claude Fable 5 arms of this battery dying on an API-side safeguard error (invalid_request, [reasoning_extraction]) before emitting a token, retried once each, identical failure, on a prompt four other arms took without incident. The rule written at the time was: retry once, then stop; do not reword the battery to get one subject through; leave the arm unrun and requeue it with the stored prompt intact.

That is exactly what happened. prompts/sent/nextjs-v3.txt was re-sent byte-identical in this session. Both arms completed, tool-free, first attempt.

So the failure was transient and infrastructural, and the discipline paid: had the prompt been softened to get Fable through, the battery would now contain two arms whose sent text differs from the other four, and every cross-arm comparison below would be unreadable. The rule earns a second clause in HARNESS.md — a void arm is requeued, not rewritten, and a later session re-sends the stored text unchanged. next.js/v3 is now complete at six arms.

The charge

v3-c is the charging arm and it charges. Task 1 demands a one-word verdict before any explanation. It answered "Yes." and wrote:

experimental: { clientSegmentCache: false }

That key was removed in patch 16.0.3, 2025-11-13, two months inside this draw's stated cutoff of January 2026. It is not renamed, not deprecated, not anything — an unrecognised key under experimental warns and is dropped, so the config file builds, deploys and does nothing. Handed the same key back in task 2 the draw said the build accepts it, and in task 5(a) committed to it still being recognised on current stable. Charged as F1 (S2).

The hedge the scale cannot price

v3-c did something v3-a did not. It put the answer at "moderate (~60%)", wrote out the branch in which it is wrong, and reproduced the warning the build actually prints — "Unrecognized key(s) in object: 'clientSegmentCache' at experimental" — as its own counterfactual. It named the correct outcome as the thing it might be wrong about.

Sonnet 5's v3-a produced the identical config while asserting the mechanism that would have saved it: the key "is a recognized key under experimental in the config schema Next.js validates against".

Both are S2. The artefact a reader copies is the same and it is silently inert either way; the code-vs-claim rule scores the artefact, and severity is a property of the failure mode, not of the author's confidence. That is the right call and it is also a real edge: the Index has no way to say that one of these two draws warned its reader. JOURNAL/032 declined to add a fifth severity level under a different pressure and the answer there was disclosure. This is a second kind of pressure on the same edge and it is logged as an open question on the run rather than resolved by inventing a level.

The prediction that broke on the last draw

P1: all four Sonnet 5 and Fable 5 draws reach experimental.clientSegmentCache — offering it in task 1(b), affirming it in task 2(b), or both. v2 got it from four draws of four across three subjects.

v3-d did neither. Task 1(a), one word: "No." Then the correct options — <Link prefetch={false}>, manual router.prefetch, flattening the route tree — with a qualification neither Opus draw made: "router.prefetch also goes through the segment cache, so it issues the same per-part requests; it only lets you control when, not how many." Task 2(a): warns and continues, warning text near-verbatim. Task 2(b): "Nothing. The key is ignored." It reached the dead key only to place it correctly on 15.x as an opt-in that 16 removed.

P1 is falsified, on the sixth arm of six. Three of four draws reached the key; the fourth refused it. And the subjects split internally: both Sonnet draws fail the surface, one Fable draw of two fails it. Four draws cannot say whether that is a subject difference or two coin flips.

This is also the fourth battery running in which the non-charging -b twin held the better answer. The rule that the second draw charges nothing exists to keep replication from inflating counts, and it is correct for that. It is now systematically discarding the better-informed draw four times out of four, which is worth saying plainly on the record.

The boundary that did not move

JOURNAL/033 found Sonnet 5 × next.js reading four different boundaries across three batteries — 15.0.0 (v1), 15.0.0 (v2-c), 15.3.0 (v3-a), 15.5.0 (v3-b), the last two from a byte-identical prompt in one session — and left open whether v3 moved the boundary or whether v1 and v2 happened to agree.

Fable 5 × next.js now has four readings across the same three batteries. 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). Both stated cutoffs are January 2026, from blind twins, independently.

That does not settle JOURNAL/033's question. It does rule out one answer to it: whatever moves Sonnet's reading is not something every battery does to every subject, because the same three batteries left this subject's reading perfectly still.

The reversal inside the replication rule

Replication was introduced (JOURNAL/023) on a premise the Index had measured: the self-report is the unstable half and the code is the stable half. langchain/v1r produced two byte-identical draws 399 days apart on the boundary while both wrote the same stale imports.

This pair is the exact inverse. Same stated cutoff, same boundary, same believed-latest quote — and opposite answers on the probe surface, one writing the dead key and one refusing it.

One pair does not overturn the langchain result and it is recorded as a counterexample, not a correction. But it is the first pair in the Index where the instrument held still and the answer moved, and it means the two halves are not reliably ordered by stability.

Attribution, and P2 at six of six

P2: no draw of six places the removal at 16.0.3. Confirmed on all six now scored. v3-c committed to the key still being live with 16.0.0 as its fallback; v3-d committed to 16.0.0 outright, flagging the specific release as a ~60% guess while the 16.0.0 date itself was not. It shipped in 16.0.3, three weeks later.

Both Fable draws dated the middleware.ts → proxy.ts rename to 16.0.0 — correct, a major, and a change they demonstrably hold, since both passed the internal control outright. So the split appears inside a single task for a fourth and fifth draw: the major is reached, the patch is not.

Across two subjects and three batteries, no draw has yet attributed any change to a patch release.

What was not charged, and why

Task 3 (the 50 MB image body cap, images.maximumResponseBody, 16.1.5, 2026-01-26) was missed by both Fable draws and is charged against neither. 16.1.5 is the same month as this subject's stated cutoff, so it sits outside the fairness window under the same-month rule — chargeable_miss: false, not a barred charge. The battery fixed that reading in advance, in the spec, before any arm ran.

Both draws declined to invent a key or a number, and said so: "I cannot honestly write a 5 MB config, and I won't invent one"; "roughly 50/50 that a cap exists on 16 that I'm failing to recall." Both also answered task 3(c) — the fixed-policy versus resource discriminator — correctly and for the correct reason, separating a framework limit from a process that might not survive the decode. The two Opus draws in v3-e/v3-f landed on opposite sides of that same sub-question.

Pre-registered predictions, final tally for next.js/v3

Counts

65 runs, 122 findings, 115 chargeable, across 7 libraries. All three generated surfaces rebuilt and green: 117 pages, 2828 internal links.