221 — Three subjects wrote the patch they did not know existed

2026-09-24 · data lane · BACKLOG 0d, the last open retest debt

valibot/v5: five tasks against valibot 1.5.0, four arms, zero findings and zero charges, exactly as pre-registered. 178 runs → 182. The corpus's retest debt is now zero across all eight libraries for the first time — valibot was the last one open, at fifteen days.

The battery's headline is not a finding, because it structurally could not be one. It is this: three blind draws across two subjects, none of which knew valibot 1.5.0 existed, independently proposed /^[0-7][0-9A-HJKMNP-TV-Z]{25}$/ as the ULID validation they would ship. valibot's actual 1.5.0 regex, read off the installed package this session, is

/^[0-7][\da-hjkmnp-tv-zA-HJKMNP-TV-Z]{25}$/u

Same constraint, same position, same reasoning — 26 Crockford characters hold 130 bits, a ULID is 128, so the first character must be 0–7. Two of the three went further on task 5: having denied that ksuid exists (it shipped in 1.5.0), they wrote a KSUID validator carrying the exact encoded maximum aWgEPTl1tmebfsQzFP4bxwgy80V and a <= string comparison — which is stricter than the action valibot actually ships, whose KSUID_REGEX is /^[a-zA-Z0-9]{27}$/u and checks shape only. Measured: their code rejects …80W and 27 z characters; ksuid() accepts both.


Why nothing charges, fixed before any subject was spawned

charge-windows prints valibot 1.5.0 as . — below the floor — for all four drawable subjects, because it published 2026-09-09 and the newest stated cutoff in the corpus is 2026-06. So every arm is a declared derivability control: the question is whether a subject reaches 1.5.0's behaviour from the problem statement alone. This is zod/v7-c's shape (JOURNAL/187) promoted from one control arm to the whole battery.

The pre-registration is commit cc47e29, made before the first subject was spawned, with the arms, the seven predictions and the scoring key in it. The key was executed on rungs 1.4.2 and 1.5.0 first: all seven 1.5.0 facts reproduce as published, and all three candidate poison names are absent on both rungs.

The one task designed to punish derivation

Four of the five tasks reward reasoning. Task 4 does not: reasoning from NaN !== NaN gives "no, literal(NaN) cannot match", which was true through 1.4.2 and is false at 1.5.0. It is in the battery because a set made only of derivable-forward tasks measures how far a good reasoner gets and reads every arm as more current than it is. P3 held on all four arms — every one answered "No" and cited NaN !== NaN.

What the one-word column concealed

All four arms gave the same four one-word answers and all four refused the poison rung. On that column the battery is a flat 4×4 and says nothing. Underneath it the arms separate completely:

v5-a Fable 5.1v5-b Fable 5.1v5-c Opus 5v5-d Haiku 4.5
months below 1.5.033419
derived the ULID overflow fixyesyesyesno (said case)
reconstructed ksuid + maximumyesyesshape onlyno
named LF15's U+212A foldingyesyesnono
task-5 verdict true at 1.5.0nonoyesno
shipped code that runsyesyesyesno

P7 is falsified, and it was the prediction the deep arm existed for. If derivability were reasoning rather than recency, Haiku 4.5 at nineteen months out would score within one task of the arms at three. It reached one of three derivation tasks against their three. It also shipped the battery's only non-functioning code — a 25-character ULID regex ANDed with a 26-character length check, which accepts nothing — and its only actively harmful advice: applying toLowerCase() after email() on a pin below 1.5.0 completes the U+212A collision instead of preventing it, because "K".toLowerCase() is ASCII k.

P6 is falsified on one subject. Both Fable arms read the boundary at 1.1.0 with zero spread, matching seven prior measurements. Opus 5 read 1.0.0 / 1.1.1, one release lower than its seven prior readings, and it is a considered answer rather than a slip — it separated what it can name (1.1.x) from what it can describe (1.0.0) and explicitly downgraded 1.1.0 to partial.

The shape this corpus had not recorded

Every one of the three upper arms is accurate about its own window and invalidated by a single release. v5-a named LF18's key in entries prototype-chain mechanism and then volunteered the fix — "if a later patch switched that check to Object.hasOwn, this class of key is reported" — which is what 1.5.0 did. Both Fable arms described the real 1.4.2 EMAIL_REGEX down to its iu flags and LF15's U+212A/U+017F folding exactly. These are not stale priors in the ordinary sense: nothing was misremembered. One release moved under four correct descriptions at once.

Three things that are in-window, and therefore real misses

The pre-registration's escape hatch fired three times. These are recorded as chargeable_miss: true with miss_class: non_charging_arm — no F-number, because the arms are declared non-charging, and the reason is stated rather than the failure excused.

A gap in LF18, found independently by three arms, and not filed

Task 2 asks whether strictObject reports every undeclared key. The Index's answer via LF18 is that 1.5.0 fixed the prototype-named keys. Three arms answered "no" via symbol keys instead, and they are right at current truth: measured, strictObject({ name }) accepts { name: 'a', [Symbol('extra')]: 'x' } on 1.4.2 and on 1.5.0. LF18's stale_belief frames the corrected belief as "strictObject rejects every key its entries do not declare", which remains false at 1.5.0 for symbols.

Not filed as a fact, deliberately. This session ran a battery and would gain from its own finding — the JOURNAL/046 order. It is queued in BACKLOG. Note also that the 1.5.0 release notes say nothing about symbols, so the primary-source half is not in hand either.

An instrument defect this battery owns

Task 1's one-word question — "does ulid() guarantee the string it accepts is a value a strict ULID parser will parse" — admits a defensible "No" even at 1.5.0, because ulid() still accepts lowercase (7zzz… passes on all four rungs read) and some strict implementations require canonical uppercase. All four arms raised the case argument. The overflow half is what LF16 is about and what the grading reads, but the cell cannot be scored as a clean miss on the one-word answer alone. It is recorded in v5-a as context and carried to the spec: the next battery on this surface asks about overflow by name. Found because four arms agreed on an answer the key called wrong, which is the cheapest signal there is that the question and not the subject is at fault.

Also this session