132 — The questions that had answers on the registry

2026-09-10, data lane. Every react-router item in the 1g series is closed, so this session went back down the queue to three items that each said the same thing — one grep settles it, do not cite it until then — and had sat unchecked since 2026-09-06: BACKLOG 11k-w (zod .safeExtend()), 11k-j (better-auth session.disableSessionRefresh) and 11k-q (two dated Anthropic identifiers). They turned out to be the visible corner of something larger. The run records carried 78 open questions and 3 resolved ones, and the packs print every open one under "not yet verified against a primary source". Several of them were library claims an install can settle. This session settled eleven, added the one the better-auth record said it had filed and had not, and — measuring the first of them — corrected a published fact and found that fact's probe blind to the clause the question was about.

The eleven, by execution

All zod rows ran against the committed 19-rung ladder (3.22.4–4.5.4, one release per directory), with a witness row that must be true on every rung.

z.interface(): the versions "not published" were on the registry

Three Claude subjects had said the Zod 4 betas carried a trailing-? key constructor that was cut before stable. Two records said the question could not be settled because "the versions that would settle whether it existed earlier are not published" — JOURNAL/027 had checked a CDN range of 3.25.x and stopped. The npm registry holds 35 4.0.0-beta.* and 74 3.25.0-beta.* prereleases. All were installed and z.interface({ name: z.string(), "nickname?": z.string() }) executed on each: it exists and works (the ? key may be omitted; a value present under it is type-checked) in 27 consecutive prereleases, 4.0.0-beta.0 (2025-04-08) to 4.0.0-beta.20250503T014749 (2025-05-03), and is absent from the next one (2025-05-04) onward — every later 4.0.0 beta, every 3.25.0 beta, 3.25.1 and every stable release. The Fable draws were right. Opus 5's v3-a was right that it existed and wrong about where: it placed it in "zod@3.25.0 under the zod/v4 subpath", and it had been cut eleven days before the first 3.25.0 beta.

The first reading of the 3.25.x rows was a blind instrument, and it looked like the answer. 3.25.x ships Zod 4 under zod/v4, whose code imports zod/v4/core by the package's own name. Under an npm alias that does not resolve; the loader fell back to the root, found zod 3, and 73 of 76 rows read "absent" — the correct answer, for a reason that was npm's. Reinstalled under the real name, one per directory, every one loads. Same constraint JOURNAL/131 met from the other side (there the reader's code named the package; here the package names itself). Also on the registry: 3.25.0 was published with no dist/ and cannot load at all; 3.25.1 followed six minutes later.

The 4.0.0 betas were installed in one shared alias tree, which the harness forbids for a reason — a shared tree lets npm satisfy a range with another rung's copy. Thirty-three of them depend on @zod/core, each at an exact pin, so no substitution is possible; that was asserted per alias (33 of 33 resolve exactly their own pin) rather than argued.

The Anthropic identifiers: one real, one langchain's

tool_search_tool_regex_20251119 is a server-tool type in Anthropic's own published SDKs — @anthropic-ai/sdk from 0.71.1 (2025-12-04) through 0.125.0, and PyPI anthropic 1.5.0. advanced-tool-use-2025-11-20 is in neither: zero occurrences in twelve npm SDK releases sampled monthly from 0.70.0 to 0.125.0 and in the PyPI SDK, with the witness beta files-api-2025-04-14 present in every one. It lives in langchain-anthropic 1.7.1, whose chat_models.py maps both tool-search types to exactly that header and adds it by itself. So the draw's betas=[...] line is what the package it was writing against sends anyway — redundant, not invented. Whether Anthropic's API still honours the header is something no package settles; the Index does not claim it.

The fact the .safeExtend() question corrected

The draw claimed .safeExtend() is "the one object derivation that preserves refinements where .pick() / .omit() / .extend() / .partial() drop them". Measured with a refinement that can fail, fourteen derivations on nineteen rungs:

• .safeExtend() keeps it on every release from 4.1.0. So do .strict(), .passthrough() and .catchall() on every 4.x release, .required() from 4.3.0, and an .extend() that only adds keys from 4.3.1.
• .pick(), .omit() and .partial() drop it on 4.0.0–4.2.1 and throw from 4.3.0. .merge() drops it through 4.3.6 and throws from 4.4.0 (LF3).
• .extend() of a refined schema throws on 4.1.0 through 4.3.0 even when it only adds a key (Object schemas containing refinements cannot be extended). From 4.3.1 only an overwrite throws (Cannot overwrite keys on object schemas containing refinements).

That last line is not in the Index. zod LF2 says .extend() "throws when it overwrites an existing property", dated 4.1.0 — true, and silent about the three minors in which the throw was wider. A reader pinned at 4.1–4.3.0 following the pack would reach for .extend() to add a field and get a throw at module load. And LF2's bisect citation said the 4.3.0 note "re-announces behaviour that shipped two minors earlier". The primary sources say otherwise: the 4.1.0 note says refinements "were dropped in the extended result ... It now throws an error" — a blanket throw; the 4.3.0 note describes the narrowed rule ("if you are overwriting"); and the narrowing shipped in 4.3.1, 39 minutes later ("allow non-overwriting extends with refinements"). It is the shape of zod LF20, the intersection fact, whose change was also announced in the 4.3.0 note and shipped in a patch that morning (4.3.2).

LF2's statement now carries the window; its note records the correction; the wrong gloss is gone and three citations were added. introduced_in, severity and every charge are unchanged — each finding on LF2 is an overwrite, which throws from 4.1.0 either way — and 4.3.1 shares 4.3.0's publish date, so no fairness arithmetic moves. Two probe rows make it reproducible: LF2b (window, 4.1.0..4.3.1, WINDOW_HOLDS, false at 4.0.17 and at 4.3.1) and LF2c (the keep, CONFIRMED at 4.3.1, false at 4.3.0). The first draft of LF2b had two defects of its own, caught before it ran: on 3.x a refined schema has no .extend and the try would have scored the TypeError as the rule's throw, and on 4.0.x its drop-guard would have turned two honest F cells into errors. Hence two rows, not one.

The probe that could not fail

LF2's committed row checked "the refinement must survive the safeExtend" with refine(() => true) — a refinement that never rejects anything — and expected { a: "abc" } to fail, which it does because of the new field's own min(5). The clause was true whether the refinement survived or not. Made to fail against the defect it names, per JOURNAL/118: a stub whose .safeExtend() drops the refinement reads T under the old row and F under the new one, whose refinement rejects only "blocked" — a value the new field accepts. Five mutants in all, each caught, including the guard firing as an error rather than a pass. Nothing published was wrong: .safeExtend() does preserve. The row had simply never measured it. Re-run after the change: all 46 pre-existing rows byte-identical, LF2's cells included; 47/48 confirmed with the one pre-existing NO_CLAIM diagnostic (LF28b) as before.

Also found, and queued rather than written

.partial() throws on a refined object from 4.3.0, the same way .pick() / .omit() do, and no fact says so — LF1 names only those two. .required() goes the other way at the same release, from dropping the refinement to keeping it. Measurement that supports a fact is not automatically a fact (JOURNAL/108); BACKLOG 11k-w-a.

Counts

Open questions 78 → 67, resolved 3 → 15, counted from the records at HEAD and after, not subtracted. Nothing charged moved: 161 runs / 167 findings (160 chargeable) / 8 libraries; zod still 31 facts; data/index.json byte-identical. The BM1 draw re-run against HEAD and against the edited file differs on one line, facts_sha256 — and the third addendum's printed hash, it turns out, never matched a committed file; both are in a fourth addendum. Citation sweep: 459 api joins, 8 allowlisted, 8 matched, 0 stale. Three rules in HARNESS.md: a preservation check needs an input only the preserved thing rejects; a self-importing package cannot load under an alias and its failure reads as an absence; a shared-tree install is safe only where every dependency is an exact pin, and that is asserted.