| miss | error.tsx retry prop |
Task 1(a): hand-rolled router.refresh() + reset() inside startTransition, which is exactly what the retry prop passed to every error.tsx since 16.2.0 does (as unstable_retry; stable as retry at 16.3.0). It volunteered "a faint memory of a newer unstable_retry-style prop on error boundaries in a later 16.x, but I can't confirm it" — the right name, undesignated. Working code; the scale has no level for 'superseded by a first-class API' (next.js/v2 precedent). Not charged. (The hand-rolled code works on 16.3.6.) [chargeable miss — working code the library now supersedes — no severity level fits it;
absent from the finding count] |
| context | error.tsx retry prop |
DERIVABLE — task 1(b): reset() re-renders from the payload already held, nothing is requested, the query does not re-run and the error returns. Correct, and answered correctly by both below-floor controls in next.js/v2 (sonnet-5-v2-c, fable-5-v2-d), so not reported as knowledge of anything in the band. |
| miss | catchError (next/error) |
Task 2(a): "Next.js has no public component-level error boundary" — then parallel routes with a per-slot error.tsx, and a React class boundary as the alternative. next/error has exported one since 16.2.0 (unstable_catchError; catchError from 16.3.0). The denial is explicit, but the code it designates works, so under the next.js/v2 precedent it is a miss with no severity level. Not charged. (Parallel routes with slot-level error.tsx isolate the widget on 16.3.6.) [chargeable miss — working code the library now supersedes — no severity level fits it;
absent from the finding count] |
| context | catchError (next/error) |
DERIVABLE — task 2(b): Next's own boundaries rethrow NEXT_REDIRECT; a hand-rolled class boundary would swallow it unless it checks the digest. Correct; the hazard predates the band and both v2 controls answered it. |
| correct | Link transitionTypes |
Task 4, ALL FOUR PARTS RIGHT under an explicit non-recognition: "I don't recognise transitionTypes as a Link prop. It must be newer than my reliable knowledge. These are guesses" — then (a) addTransitionType('slide') in the navigation Transition; (b) Pages Router ignores it; (c) no warning in either router, "assuming Link pulls the prop out"; (d) a dev-time prop error demanding an array. Every v2 draw (Opus 5 ×2, Sonnet 5, Fable 5) denied the prop and predicted the warning. Recorded as correct and NOT as recall of 16.2.0: the draw says it reasoned from the obvious design, and the prompt's (d) names the array. P2 FALSIFIED on this arm. |
| imprecision | images.maximumDiskCacheSize |
Task 5(a), the scored half: "As far as I know, the image cache in .next/cache/images has no size limit by default ... The question implies a newer rule, perhaps a default based on a fraction of disk space calculated when the server starts. I can't describe that rule. Confidence: low that this is still current." The designated statement is LF25's stale belief (unbounded); the hedge names the right shape and timing, and 5(b)/(c) write the RIGHT key — maximumDiskCacheSize: 1_000_000_000 and maximumDiskCacheSize: 0 ("a guess at the option name"), both accepted by 16.3.6's configSchema (executed). Under the code-vs-claim rule a hedged prose claim beside a correct fix is an imprecision. P4 FALSIFIED on this arm: the right key was written. |
| context | images.maximumResponseBody |
VOID PROBE — task 6, scored for nobody as pre-registered (the 'default image configuration' wording beside a remote src). This draw read it as the allowlist being satisfied, designated 'optimized normally, slow first request', and then volunteered: "I believe a later release added a cap on how large an upstream image can be (possibly images.maximumResponseBody, default around 50 MB) ... I lean towards the cap existing" — the right key and figure for LF26 (16.1.5), hedged. |
| correct | images.qualities |
Task 7, the internal control (LF8, 16.0.0): "It's encoded at 75. From Next 16, images.qualities defaults to [75], and the quality prop is snapped to the nearest allowed value"; dated to 16.0, October 2025. Right on the behaviour (executed on 16.3.6: q=90 becomes q=75) and on the release, so this arm's attribution answers are readable. |
| correct | experimental.prefetchInlining |
Task 8: "I don't know of a stable option to switch back to one request per link. If there is one, it's probably an experimental flag, something like experimental: { prefetchInlining: true } (I'm unsure of the name), which would bundle a route's segments into one response." The right key, the right namespace and the right mechanism (16.2.0; configSchema accepts it at 16.3.6, executed). No dead clientSegmentCache offered. P3 FALSIFIED — the prediction said no draw of four would name it. Its twin did not (below). |
| context | — |
Task 9, attribution: both behaviours guessed at "16.1.0, around December 2025". True: the font default 16.2.0 (a minor), the disk-cache rule 16.1.7 (a patch, two days earlier). Neither reached; no patch named. P5 HELD. None of the eight draws on these bytes (four in next.js/v2, four here) named a patch release. |
| context | — |
Task 10: recency not charged. The v1 S4 rule would reach it (knowledge stops at 16.0.0, below 16.2.0, the last minor before the stated cutoff), but no Claude Opus 5.5 or Claude Fable 5.1 run in the corpus carries an S4 recency finding and this battery did not pre-register one; the stated boundary is recorded above. |