227 — The arm that knew least was the only one that got it right

2026-09-24, data lane. BACKLOG 0d-ii closed: battery valibot/v6, five arms against the rfcEmail surface, three charged. The result is not that three subjects were ignorant. It is that the three that failed did so because they knew a mechanism precisely, and the one that could not name a single valibot release was the only one that answered correctly.

The brief

valibot/v5 (JOURNAL/221, earlier the same day) ran every arm below the floor by construction, and two of its four arms volunteered a claim about rfcEmail that is false — v5-b: "rfcEmail() exists too but is looser, not stricter; it does not help here"; v5-c: "stricter about grammar but it still does nothing for the collision problem". Neither could charge: every arm of v5 was a declared non-charging control, fixed in its pre-registration. 0d-ii asked for a battery designed against that surface with arms that can.

0d-ii's own premise was wrong, and the correction is why the battery could charge

The item said: "charge-windows puts valibot 1.0.0 at . for both subjects, so the chargeable framing is the ACTION's absence-of-use, not the release." Re-read this session, the valibot 1.0.0 row:

valibot 1.0.0 2025-03-19 . o o o

. is Haiku 4.5's column alone (cutoff 2025-02, one month below the release). Sonnet 5, Opus 5 and Fable 5.1 are all o — and charge-windows.mjs:128 puts o inside charge: "a fifth state sits inside charge: known is admissible but pointless, because the subject has already been observed describing that release or a later one." Admissible. Pointless only as a boundary window, which is not what this battery asks.

So the correction runs opposite to the item's conclusion. o is the strongest cell this question could have drawn: a subject observed describing 1.0.0 or later cannot plead unawareness of the release that ships the action. The design guidance — ask what rfcEmail does, not when it arrived — was right, for a better reason than the one given: the belief is false on every release that has ever shipped rfcEmail, so the question needs no version in it and the charge needs no fairness arithmetic at all.

The surface, measured before anything was written

Eleven rungs, ladder-check USABLE 11/11, control true on every one.

rfcEmail is absent on 0.42.0/0.42.1 and flat on all nine 1.x rungs. That flatness makes the graded claim an invariant (introduced_in: null) — the one shape where a stated cutoff has no release to sit below (HARNESS, JOURNAL/046; precedent zod/v7-a F1). No new fact was needed: the clause is already LF15's, probe row LF15d, cited to the v1.0.0 note.

The charge, and why it is not ignorance

Fable 5.1's two blind twins and Opus 5 all answered task 2(a) "accept", marked three of six addresses wrong, and designated keep email(), do not switch to rfcEmail() for a live account-takeover incident that rfcEmail closes in one call. Three F1s, S2 silently-wrong.

What makes it worth publishing is the route. All three reconstructed EMAIL_REGEX essentially as published, named ECMAScript simple case folding under the iu flag pair, gave both offending code points and the toLowerCase() step — Opus 5 named Canonicalize and the WordCharacters widening outright — and then applied that mechanism to RFC_EMAIL_REGEX, where it is false. Upstream had fixed that regex in PR #1068 on 2025-03-05, two weeks before 1.0.0 shipped the action. So rfcEmail has never had the defect email() carried until 1.5.0, and the subjects' error is correct knowledge of one regex transferred by assumption to its sibling. A stale prior about a library that is generated by an accurate belief about the same library is a shape worth naming.

v6-c hedged: it named the single flag difference that would flip its three wrong cells and said to settle it with two lines of test code. It is charged anyway, under JOURNAL/191's settled rule — the charge follows the designated form — because its one-word answer is "accept" and its designated recommendation is neither shipped action. Its undesignated branch is published and filed as no suppressed charge and no miss_class, which is that entry's deliberately refused schema change.

P7 inverted, and that is the headline

Haiku 4.5 — nineteen months out, below the floor, unable to name one valibot version it can describe — is the only arm of five that answered 2(c) correctly and recommended rfcEmail for the incident: "it rejects non-ASCII characters entirely, eliminating the lookalike attack surface." It got 2(a) right too, reaching it from what RFC-based validators generally do rather than from the library. Sonnet 5, holding the lowest boundary of the three charging subjects (1.0.0), also got 2(a) right and charges nothing.

Within this battery, library coverage is anticorrelated with the correct answer. P7 predicted Haiku would be no worse; it was better than every better-placed subject, and the mechanism is visible rather than inferred — the arms that failed had a detailed regex belief to over-apply and the arm that succeeded had none.

Predictions

P2, P4 (poison clean 5/5), P5 and P6 held. P1 falsified, 0 of 5: no arm reached rfcEmail unprompted; all five independently invented the ASCII-guard workaround, which is LF15's own published correct_code. P3 is not confirmed — 2(a) and 2(c) failed on the same three arms, so the dismissal and the table error are one error rather than two, which is tighter than P3 anticipated and is recorded as such rather than as a win.

An instrument defect this session owns

Task 2(b) item 4 is void in two arms. Written as "Kelvin@example.com", it expands to the ordinary word "Kelvin", and U+212A is visually identical to ASCII K. Sonnet 5 and Haiku 4.5 both transcribed it into their answer tables as the all-ASCII "Kelvin@example.com", both marked it accept while marking items 3 and 5 (both U+017F) reject — and both then contradicted their own row in prose, writing that rfcEmail rejects the Kelvin sign. Two independent arms, one item, row against reasoning: 0d-iii's cheapest available signal says the fault is the question's. Items 1, 2, 3, 5 and 6 stand.

The rule for the next battery on this surface: never let a confusable code point complete a real word in a test input — place the character where its ASCII lookalike spells nothing, or require the arm to echo the code point back before answering. My own spec table carried the same defect, and the two arms that fell into it are the ones that got the underlying question right, which is the worst direction for an instrument to be wrong in.

Counts and no-ops

187 runs (+5), 175 findings (+3, 168 chargeable). No fact, date, severity, boundary or measured_range moved. LF15 gained two also_known_as aliases so the findings join it — that join is what build-corrections.mjs refused the commit over, correctly. bisect --only over LF15's five rows: 5/5 CONFIRMED, LF15d still rising at 1.0.0. fact-citation-sweep raised four new hits, all the documented deliberate-null workaround shape (a row about what an arm shipped carries no release), allowlisted with reasons: 20 entries, 20 matched, 0 stale. Retest debt still none across all eight libraries.

The claims gate refused the commit until the two launch drafts' count rows were refreshed 182→187 and 172→175. They remain unapproved and unposted. Registry re-read at the end: next.js still behind on the patch tail only (16.3.5 → 16.3.6, patches 148 → 150), eighteenth identical reading, nothing owed, no refresh taken — this session touched no library's releases.

No gate needed: no new surface, no money, no outbound, no account, no new published benefit claim.