--- library: valibot library-latest: "1.4.2" library-latest-verified: 2026-09-01 model: claude-opus-5 (spawned via Agent model alias "opus") model-self-reported-cutoff: 2026-05 model-believed-latest: "1.x; 1.0.0 (2025-03-19) is the last release whose contents it attributes" test-date: 2026-09-01 battery: valibot/v1r-a (replicate of valibot/v1, prompt unchanged; 10 tasks + 4 direct questions) replicate-of: valibot--claude-opus-5--v1--2026-09-01 tool-uses-during-test: 0 verified-against: https://registry.npmjs.org/valibot · https://github.com/open-circle/valibot/releases/tag/v1.1.0 · https://github.com/open-circle/valibot/releases/tag/v1.2.0 status: open (no retest yet) json: opus-5-v1r-a.json self-test: true (the operator model is the subject; disclosed, weaker evidence) --- # valibot × Claude Opus 5 — replicate A of battery v1 **The confident draw.** It never claimed to know valibot 1.1.0 at all, so there was nothing for it to hedge about. Its blind twin [`v1r-b`](opus-5-v1r-b.md) arrived at the same boundary by the opposite route — believing 1.1.0 exists, producing a vague impression of it, and then refusing to count that impression as knowledge. ## What this draw said > *"Latest version I believe exists: the Valibot **1.x** line. Basis: I saw v1.0.0 ship and I have > a weak recollection of v1.1.0."* and, asked which release it knows only as a version number: > *"Most recent release whose **contents** I can describe: **v1.0.0**, approximately > February–March 2025. ... First release I know only as a version number: **v1.1.0**. I believe it > exists; I cannot tell you a single thing that changed in it."* Taking the bracket as [last release describable, first release not describable] gives **[2025-03-19, 2025-05-06)**. ## The measurement | Draw | Last describable | First known only as a number | Spread vs twin | |---|---|---|---| | `v1r-a` (this run) | 1.0.0 · 2025-03-19 | 1.1.0 · 2025-05-06 | — | | [`v1r-b`](opus-5-v1r-b.md) | 1.0.0 · 2025-03-19 | 1.1.0 · 2025-05-06 | **0 days** | | [`v1`](opus-5.md) | 1.1.0 · 2025-05-06 | 1.2.0 · 2025-11-24 | 48 days | The pre-registration in `prompts/valibot.md` § v1r fixed the reading before either subagent was spawned: **the primary criterion is a-vs-b**, because those two share one prompt file byte for byte, and a case where both replicates agree with each other but differ from the original counts as **agreement**. That is the case here, and 48 days is one release step — the smallest non-zero spread this library's timeline permits, against prisma's 204. What separates `v1` from these two is not a different answer so much as a different way of scoring the same hedge. `v1` said it could describe 1.0.0 "confidently and v1.1.0 with moderate confidence" and was scored at 1.1.0. Both replicates put 1.1.0 on the other side of the line. The battery still has no rule for a subject that offers a confident boundary and a hedged one in the same breath — the gap [`prisma/v1r-a`](../prisma/opus-5-v1r-a.md) logged first, now hit by a second library. ## Findings: none, by design `valibot/v1` carries this subject's two valibot findings and a replicate does not re-charge them. Both reproduced here: - **F1** — task 2: *"Valibot does not ship an `isbn` action"*. Usable from **1.3.0** (re-dated 2026-09-02, JOURNAL/040 — the v1.2.0 notes announce it, the 1.2.0 package does not contain it). - **F2** — task 5: the repository attributed to `github.com/fabian-hiller/valibot` and to a personal account, where it moved to the `open-circle` organisation with 1.2.0. Also reproduced without charge: task 3 said nothing about the ReDoS fix in the 1.2.0 emoji regex (the battery's designed S2), task 4 routed around the 1.2.0 `examples` action via `metadata`, and task 7 hand-rolled the 1.1.0 `parseJson` pipeline out of `rawTransform`. ## One chargeable miss, flagged not charged Task 1 asked for query parameters coerced to numbers and a boolean. This draw stated the negative **inside a code task**: > *"Valibot has **no `coerce` helper**."* and again under question (d): *"**None.** Valibot ships **no coercion helpers at all** ... This is a deliberate design position, not an omission."* valibot 1.2.0 (2025-11-24) shipped `toNumber`, `toBoolean`, `toDate`, `toBigint` and `toString`, and 1.2.0 precedes this subject's stated 2026-05 cutoff. `valibot/v1` recorded the same wrong belief under question (d) — where the battery scores it as a belief datum, not a finding — and scored its task-1 *code* as an imprecision, because that draw hand-rolled the coercion without claiming the built-ins were absent. This draw claims it in the code task, which the additive-API rule makes chargeable. So it is a real scoring gap rather than a double-count, and it is **not charged here**: a replicate does not charge findings, and a gap is not fixed by smuggling it into the run that exposed it. It is queued in `BACKLOG.md` against a battery aimed at the 1.2.0 coercion surface. ## What it got right Task 10, the floor probe, passed cleanly — `exactOptional` distinguished from `optional` and `undefinedable`, with the inferred types spelled out. Task 9, the one designed S1, passed in substance: rather than writing the pre-1.1.0 `NanoIDAction` spelling, the draw flagged its own uncertainty about the casing and offered `ReturnType` as a rename-proof alternative. Task 6 is where it differs from its twin — it hand-rolled the CLI error printer with `getDotPath` where `v1r-b` reached for the 1.1.0 `summarize` built-in.