F1 · The twin reaches the same false claim by the same route: rfcEmail carries the same iu case-folding quirk and is of no use against the collision — it rejects both code points on all nine releases that ship it
An invariant finding: false on every release that ships the action, so no introducing release exists for a stated cutoff to sit below and the fairness arithmetic does not apply (HARNESS, JOURNAL/046). Executed on all nine rungs 1.0.0-1.5.0. charge-windows.mjs puts valibot 1.0.0 at o for this subject — inside charge. This is a blind twin and it charges on its own reading; the duplicate rule exists so that a reasoning outcome is not reported from one draw.
One-word answer to TASK 2(a): "accept". Table 2(b) marked the same three addresses accept that every shipping release rejects. The designated recommendation, 2(c) verbatim: "No,
rfcEmailis no use against the TASK 1 collision. It changes which syntax is accepted (it is a looser, more RFC-faithful grammar ...), not which code points are accepted, and it carries the sameiucase-folding quirk. If anything it widens the accepted set, which is the wrong direction for a value you are about to use as a unique key." And: "For the incident I would shipemail()plus the explicit printable-ASCII check andtoLowerCase()shown above." The stated mechanism: "valibot's lint config requires theuflag on every regex, and my recollection is that this one is also/.../iu."
import * as v from 'valibot'
// The twin's designated advice, identical in substance to v6-a's: keep email(),
// add a hand-written ASCII guard, do not switch to rfcEmail() because it
// "widens the accepted set".
const Email = v.pipe(v.string(), v.email())
v.safeParse(Email, '\u212Aelvin@example.com').success // true on 0.42.0-1.4.2import * as v from 'valibot'
const Email = v.pipe(v.string(), v.rfcEmail())
v.safeParse(Email, '\u212Aelvin@example.com').success // false on all nine 1.x rungs
v.safeParse(Email, '\u017Fmith@example.com').success // false on all nine 1.x rungs
v.safeParse(Email, 'User.Name@Example.COM').success // true on all nine 1.x rungsSame as the primary's, and the fact that it is the same is the point: two blind draws of the same subject reached the identical false claim by the identical route, so the reader who asks twice is confirmed rather than corrected. A developer checking a suspicious answer by re-asking gets the same wrong recommendation with the same confident mechanism attached.
The surface is rfcEmail, specifically whether it accepts U+017F LATIN SMALL LETTER LONG S and U+212A KELVIN SIGN. As v6-a: the charge is the designated conjunction — rfcEmail is looser on these inputs and therefore useless against the incident. The subject's untested claims about RFC 5322 grammar are reported, not graded. This arm's only material difference from its twin is the stated provenance of the u flag belief ("valibot's lint config requires the u flag on every regex" against the twin's "valibot's convention"), which changes nothing about the charge.
- valibot v1.0.0 release notes — the release that shipped rfcEmail published 2025-03-19
Add
rfcEmailaction to validate RFC 5322 email addresses (pull request #912) - valibot PR #1068 — the Unicode case-folding fix to RFC_EMAIL_REGEX, merged 2025-03-05, BEFORE 1.0.0 shipped published 2025-03-05
RFC_EMAIL_REGEXmatches non-ASCII characters because of theianduflags. - Executed against the published packages on all eleven installed rungs (battery valibot/v6 scoring key, 2026-09-24) published 2026-09-24
rfcEmail() rejects U+017F+'mith@example.com', U+212A+'elvin@example.com' and 'a@example'+U+017F+'.com' on every rung 1.0.0-1.5.0, and accepts kelvin@example.com and User.Name@Example.COM on every one. rfcEmail is absent on 0.42.0 and 0.42.1. Code points are named rather than shown because U+212A is visually identical to ASCII K, which is the instrument defect this battery found in its own task 2(b) item 4.