Run react-router--claude-opus-5-5--v6-b--2026-09-28 · self-test: the subject is the operator
Blind twin of v6-a, Claude Opus 5.5, stated boundary 7.9.0. Agreed with its twin on every graded cell: unstable_shouldCallHandler / unstable_shouldRevalidateArgs on LF11 and unstable_onError on LF12, both carried as uncharged misses. Its Task 1 fails differently from the twin's: it feature-tests match.unstable_shouldRevalidateArgs, so on 7.10.0+ it silently takes a shouldLoad branch and overrides the route's own revalidation decision instead of throwing (executed). Task 2(c) correct, poison rung declined.
| Subject | Claude Opus 5.5 claude-opus-5-5, Anthropic |
|---|---|
| Invoked as | Agent tool, model alias "opus"; prompt sent verbatim from prompts/sent/react-router-v3.txt (md5 f75c81cd1fcf1264271c965e1e514dba), byte-identical to `v6-a`'s, pre-registered at 18348ad before any spawn. Identity probed before the draw in the same session ("Opus 5.5 (1M context), model ID claude-opus-5-5[1m]", cutoff June 2026). Drawn concurrently with `v6-a`. DISCLOSED: the operator runs on the same model (`test.self_test`). The blind TWIN of `v6-a`; charges nothing by pre-registration. |
| Cutoff the model states | 2026-06 |
| Newest react-router release it could place | 7.9.0 · 2025-09-12 (~9 month lag) |
| Oldest react-router release it could not place | 7.10.0 · 2025-12-02 (so this run brackets the subject’s boundary to 2025-09-12 – 2025-12-02) |
| In its own words | "The latest version I know of is roughly the 7.9 to 7.10 range. The most recent release whose contents I can actually describe is 7.9.0, around September 2025." … "The first release I know only as a version number is 7.10.0." |
| How the bracket was read | Equal to v6-a and to the ladder react-router/v5. P4 HELD. It files unstable_shouldCallHandler / unstable_shouldRevalidateArgs under 7.9.x "Low confidence on the exact version" — the prefixed helpers are present from 7.6.0 on the ladder, so that is a mis-dating below the boundary, not a description of 7.10.0. (stop end stated, gap end stated) |
| Library at test time | react-router 8.4.0 (npm), verified 2026-09-28 |
| Battery | react-router/v6-b · 2 tasks, 5 direct questions · probe window 7.10.0 to 7.11.0 |
| Tool uses during test | 0 (a run with any tool use is void — we measure training knowledge, not retrieval) |
| Tested | 2026-09-28 |
| Findings | 0, of which 0 chargeable |
None. Every task in this battery produced code that works on the current release, and every direct question was answered correctly. A run with nothing to charge is kept in the Index at full weight: it is the control that makes the other runs mean something, and it is the evidence for what this model does not need correcting on. What the subject actually said is recorded below.
Recorded so the run cannot be read as a hit list. A model that is right for an obsolete reason is recorded here, not as a finding.
| Kind | API | Note |
|---|---|---|
| miss | dataStrategy (match.shouldCallHandler / match.shouldRevalidateArgs) |
TASK 1, agreeing with its twin (P3 HELD): the designated dataStrategy gates on match.unstable_shouldRevalidateArgs and calls match.unstable_shouldCallHandler(!fresh), both labelled "Experimental" with "On a newer release it may have lost the unstable_ prefix; check the changelog." WRONG under the pre-registered function (either prefixed identifier). THE FAILURE MODE DIFFERS FROM THE TWIN'S AND IS WORSE FOR BEING QUIET, executed this session with createMemoryRouter and a root route whose shouldRevalidate always returns true: on 7.9.0 the unstable_ branch is taken on revalidation and the loader runs 3 times (the route's decision is respected); on 7.10.0 and 8.4.0 match.unstable_shouldRevalidateArgs is undefined, so the code always falls to its match.shouldLoad && !fresh branch, nothing throws, and the loader runs once — the route's own "revalidate" decision is overridden by the cache, which is precisely the requirement the task stated. Twin — charges nothing. [chargeable miss — a replicate, a duplicated arm’s second draw or a below-floor control charges nothing;
charged as a finding on react-router--claude-opus-5-5--v6-a--2026-09-28] |
| miss | onError (HydratedRouter / RouterProvider prop) |
TASK 2, agreeing with its twin: unstable_onError on <RouterProvider> and on <HydratedRouter>, dated "I believe from 7.8.x" (right origin, stale present tense). Its callback reads info?.errorInfo?.componentStack, which is the correct shape of 8.4.0's ClientOnErrorFunction; only the prop name is wrong, and from 7.11.0 that prop is never read. It adds onRecoverableError on hydrateRoot, which is real React API but does not cover router-caught loader errors. Twin — charges nothing. [chargeable miss — a replicate, a duplicated arm’s second draw or a below-floor control charges nothing;
charged as a finding on react-router--claude-opus-5-5--v6-a--2026-09-28] |
| correct | — | TASK 2(c) CORRECT: NO, then "React raises no error or warning for an unrecognised prop on a component. It only warns about unknown props on DOM elements … an unknown prop is silently ignored and your reporter never fires." P6 HELD. |
| correct | — | POISON RUNG DECLINED WITHOUT DESCRIPTION: 7.19.0 "I don't know, and it seems unlikely by my cutoff. Treat it as unverified." 7.10.0 "I believe it's real … I can't name a shipped feature", 7.11.0 and 7.15.0 unconfirmed — no invented content. P5 HELD. |
| context | — | 8.4.0 DENIED, non-charging: "As far as I know v8 hadn't shipped, let alone 8.4." Above the stated cutoff (8.0.0 is in the cutoff month, parked). |
Battery specification: prompts/react-router.md in the studio repo.
Every finding above also carries its own citation.