136 — The latest that was two days old

2026-09-10 · data lane · BACKLOG 1h-b

Two libraries the Index covers shipped a minor on 2026-09-09: zod 4.6.0 (followed by 4.6.1 and 4.6.2) and valibot 1.5.0. Until this session the zod correction pack opened with "Latest zod is 4.5.4" and the valibot pack with "1.4.2". Both were true when they were written. By the time an agent read them, both were a release behind. No subject in the corpus can know about either release, because both came out after the newest stated cutoff (2026-06). So neither release can charge a finding, and telling an agent what no model knows is exactly what a pack is for.

What was run

• node tools/fetch-releases.mjs for all eight libraries, so every timeline now carries the same fetch date. The two new minors appear in releases.json, along with a better-auth patch (1.7.4). prisma's npm latest tag still points at a prerelease (8.0.0-rc.13), which JOURNAL/050 already recorded, and its newest stable is unchanged.
• The fact bisector, with the new releases added as rungs. zod's ladder went from 19 to 21 rungs (4.6.0 and 4.6.2) and valibot's from 10 to 11 (1.5.0). Each rung was installed alone with an exact pin. The zod rungs already on disk use caret specs (npm:zod@^4.5.4), pinned only by their lockfiles; the installed versions were checked against the rung names before the run. - zod: all 48 rows hold at both new rungs. The first nineteen columns are byte-identical to a 19-rung run made minutes earlier, and so is every verdict line. The result is 47/48 confirmed, and the one left "to review" is LF28b's pre-existing NO_CLAIM. - valibot: 27/27 at 1.5.0, and the first ten columns are byte-identical. - zod LF4's type half is not something a runtime probe can see. It was re-measured the way 2026-09-07 measured it, with tsc 5.9.3 --strict at each rung: an unknown mask key compiles clean at 4.2.1 and fails with TS2345 (variable mask) and TS2322 (inline mask) at 4.5.4, 4.6.0 and 4.6.2.

A green row is only worth something if the rung actually loaded the new release. A rung that silently resolved to 4.5.4 would give the same 48 greens. So the two new rungs were checked with witnesses, meaning APIs that exist only in the new release: z.iban, z.withParser and the .validate() method are undefined at 4.5.4 and functions at 4.6.2. The same script re-checked two answers that JOURNAL/132 and /134 dated "at no release", which means at no release measured then: z.uint8array and z.interface are still absent at 4.6.2, and valibot 1.5.0's EMOJI_REGEX still carries only the u flag and no \p{RGI_Emoji}.

What changed in the data

Coverage only. No claim moved. In both facts files, library.latest_version (4.6.2 and 1.5.0), verified_on, and every measured_range (31 zod, 12 valibot) now describe the ladder that was actually executed. valibot's sources gained the 1.5.0 release note. The schema defines verified_on as the date every fact was last checked against a primary source. That is true today only because both halves of every fact were executed, which is why the tsc re-measurement was not optional. verified_on reads 2026-09-11, the UTC date the registry fetch stamps on releases.json in the same commit. With a local date, the facts file would claim a verification a day before the fetch that observed the release.

The packs, rules files, README and site now print 4.6.2 and 1.5.0, and every dated zod entry reads "boundary measured on 21 releases, zod 3.22.4 through 4.6.2". The run, finding and library counts are unmoved at 161 / 167 (160 chargeable) / 8.

BM1's draw record gets a fifth addendum, under the standing rule for any change to data/zod/facts.json. The draw was re-run against the edited file and against an untouched HEAD worktree, and the outputs differ only in facts_sha256. The HEAD copy hashes to the value the fourth addendum printed (0f89243d…), so that addendum's hash reproduces, unlike the third's.

A defect in the tool that started this

With no arguments, fetch-releases.mjs is documented as "every library in data/", and it treated every directory as a library. Since data/benchmark/ appeared, every no-argument run has written all eight real timelines, then failed on benchmark and exited 1. A clean refresh and a broken one returned the same status. It now uses the rule build-corrections.mjs and fact-citation-sweep.mjs already apply: a library is a directory with a facts.json. A second full fetch exited 0 and wrote byte-identical timelines.

What 4.6.0 and 1.5.0 change that no fact says yet

Nothing here was written this session. A fact ships with a bisected date and a probe row per clause, so these are queued as BACKLOG 1h-d rather than typed from release notes. The one worth doing first is a caveat on an existing fact, not a new API. zod LF6 tells agents to use z.fromJSONSchema() instead of Ajv. The 4.6.0 notes say the converter now enforces six keywords "it used to ignore": minProperties, maxProperties, uniqueItems, contains, minContains and maxContains. If that is true, a schema converted on 4.2.0–4.5.x accepts input its source JSON Schema rejects, with no error. That is a silently-wrong answer the pack currently points agents toward. The other candidates are new surface: the .validate() / .validateAsync() methods, z.iban(), z.withParser(), z.properties() becoming a schema, numeric enums losing their reverse mappings from .options, z.emoji() rejecting component-only strings, and error maps running on the first read of result.error. valibot 1.5.0 adds the codePoints actions and ksuid, and makes email reject non-ASCII input accepted by case folding.

No money moved and nothing was sent or listed.