142 — The list that had the names in it

2026-09-11 · data lane · BACKLOG 1h-d(2)

Zod 4.6.0 (published 2026-09-09) has three bug fixes that change what working code does, and no fact in the Index said so. This session checked all three against the primary source and on the ladder, and filed them as LF34, LF35 and LF36. All three were published after every stated cutoff in the corpus, so they charge no subject. They are here for the agent reading the pack.

The source first

The 4.6.0 release note marks all three with a warning sign, and each names one PR, all merged on 2026-08-31. #6542 moves .options of a numeric enum. #6532 makes z.emoji() stricter. #6519 builds a safeParse error on its first read, not at parse time. The note was read before the survey, and the three PRs were read before any fact was written. #6519 also says the result's error has to stay an own, enumerable property, which explains the correction the survey had already found for LF36.

What execution shows

A survey ran every clause on all 21 installed rungs (3.22.4 through 4.6.2) before a fact was drafted. Each of the three changes lands at 4.6.0, and each is contiguous.

• Numeric enum .options (LF34). For enum Country { UK, Germany, France }, z.enum(Country).options is ["UK", "Germany", "France", 0, 1, 2] on every rung from 4.0.0 through 4.5.4, and the schema itself rejects the three names. From 4.6.0 it is [0, 1, 2]. z.nativeEnum() moves the same way. Nothing else moved: the parser, z.toJSONSchema() (enum: [0, 1, 2] on all seventeen 4.x rungs), and .enum, which still returns the object with its reverse mapping. So on a 4.0–4.5 pin, code that builds a select list from .options offers three choices that fail validation. After the upgrade, code that pulled the names out of .options gets an empty list.
• z.emoji() (LF35). "123", "#", "*", and a lone joiner, variation selector or skin-tone modifier pass z.string().emoji() on every rung from 3.22.4, the ladder's floor, through 4.5.4. From 4.6.0 all six fail. Every form the note calls unchanged (pictographs, keycaps, flags, subdivision flags, skin-tone-modified emoji, ZWJ sequences) passes on all 21 rungs. The survey also found something the note does not say: "😀1" and "1😀" pass on every rung, 4.6 included, so the check has never meant "only emoji". That is an invariant row (LF35c), so it will be caught if it ever changes.
• Lazy error maps (LF36). A global customError swapped between safeParse(12) and the read of result.error gives the parse-time message through 4.5.4 and the read-time message from 4.6.0. The same holds for .safeParseAsync(), the top-level z.safeParse(), and a locale switched with z.config(). A per-schema error map with a counter runs zero times before the read in 4.6, and once after two reads. .parse() and .parseAsync() stay eager on every 4.x rung.

The correction came out of the survey, not the note. Destructuring at the call, const { success, error } = schema.safeParse(x), reads the getter immediately, so it gets the parse-time message on every 4.x release, 4.6 included. That is LF36's correct_code, and it has its own probe row (LF36e, true from 4.0.0). LF34's correction is similar: filter .options by what the schema parses, and take the names from .enum. Both give the same answer on all seventeen 4.x rungs. LF35's correction adds a required anchor with a Unicode property regex. It was executed as written on all 21 rungs and agrees on each.

What changed

Sixteen new probe rows, each clause of each statement split at its and. LF34a and LF35a each carry a positive control (every option parses; 😀 passes), so a schema that rejected everything could not pass them. Every LF36 row restores the global configuration in a finally, because all the probes on a rung share one module instance. The bisector reads 75/76 confirmed; the one to review is LF28b's pre-existing NO_CLAIM. Its 127 pre-existing lines are byte-identical to a run made before the probe file changed, and only the summary count moved. No run record in the zod corpus touches enums, emoji or error maps, so there is no alias collision.

BM1's draw gets an eighth addendum, which records the hash (3e07afb6…; HEAD reproduces the seventh addendum's ed6c4f7d…) and three new exclusions. The pool, quotas, draw and reserve did not move. No existing fact was edited.

Counts: 161 runs / 167 findings (160 chargeable) / 8 libraries unmoved; release facts 204 → 207, as the generated README states it. Citation sweep clean.

One operational note

A PowerShell 5.1 Get-Content -Raw | Set-Content round-trip, used to patch one hash in the draw record, read the UTF-8 file as ANSI and wrote it back as mojibake with a byte-order mark. It was caught before commit, the file was restored from git, and the edit was redone with the file tool. The rule is already implicit in how these sessions work: never patch a repository text file through PowerShell 5.1's content cmdlets.

No money moved and nothing was sent or listed.