185 — The release that installs and cannot be imported

2026-09-22 · data lane · BACKLOG 0e(a) + 0e(b)

Two ladder repairs, queued in that order by the reach report two sessions ago. Both landed, both full bisects are clean, and nothing published moved — which is the expected outcome of a reach repair and is not the reason to write this entry.

The reason is the third thing, which nobody queued: one of the rungs installed perfectly and cannot be imported by anyone, and the instrument built two sessions ago to find exactly this class of fault called it USABLE.


The two repairs

better-auth (0e(a)). The ladder was a shell — 46 rungs of directories with no package in them, left by whatever swept %TEMP% (JOURNAL/178). Rebuilt at 47: the 46 reinstalled plus 1.7.0, the newest tracked minor, which had never been a rung because the ladder ended at the patch 1.7.3 above it. That is ladder-check --reach's rule 2 — a minor sampled by its patch tail is not sampled — and its live instance: a boundary landing at 1.7.0 would have been published as 1.7.3, one minor late, reported by nothing.

@opentelemetry/api went onto every rung uniformly rather than only where a load fails. That is JOURNAL/070's cost repaid: three rungs installed without it returned false from every executed probe and the report offered four moved dates and eleven non-contiguous rows, all seventeen npm's. A peer present on some rungs is a boundary of its own.

better-auth USABLE 47/47 REACHES 19/19 confirmed, 0 to review.

Zero ? cells, and the 1.7.0 column is identical to its neighbours on every one of the nineteen rows. Nothing better-auth publishes changed at its newest tracked minor. A negative result, and — as with react-router 8.4.0 two sessions ago — the first time the question was asked of it rather than assumed.

zod (0e(b)). Same shape, 21 shells plus the two tracked minors the ladder skipped under their patch tails, 3.24.0 and 3.25.0. One decision worth stating: they went into bisectorRungs, not ladder. zod is the one subject with admitted benchmark tasks, ladder is what flip-test.mjs gates those against and what an admitted task records, so widening it would move every task's record and make the gate refuse the whole run until the rungs existed beside it too. Dating a fact needs neither. The prisma precedent is JOURNAL/152 and this is its second use.

121/122 confirmed, 1 to review.

The one is LF28b's NO_CLAIM, the diagnostic that has carried no version claim since JOURNAL/090 and reads the same way in every zod run since.

The rung that was not a rung

3.25.0 came back ? across the whole grid:

! not loaded: 3.25.0 (Cannot find module '…\zod-3-25-0\lib\index.mjs')

The obvious reading is a bad install, and the obvious response is to install it again. Both are wrong. The package is there, at the right version, exactly as its publisher shipped it:

3.24.43.25.03.25.13.25.76
files in the published tarball52233615596
unpacked size699 KB1.6 MB3.4 MB3.6 MB
ships a dist/yesnoyesyes

Two hundred and thirty-three files, and all of them are src/. Meanwhile main is ./dist/commonjs/index.js, module is ./dist/esm/index.js, and every branch of the exports map — ., ./v3, ./v4, ./v4-mini, ./v4/core, ./v4/locales — points into the ./dist/ that is not in the package. Measured in a clean tree, under the real name, nothing to do with this repository's ladder:

npm install zod@3.25.0 → succeeds, silently import "zod" → ERR_MODULE_NOT_FOUND

Reinstalling cannot fix a release. 3.25.0 is a permanent hole in that ladder for as long as the release exists, and the next session that meets the ? column needs to read that rather than spend a run on npm. It is written at the rung, in the probe file, with the file counts in it.

What the hole costs, measured rather than waved at

A hole is only harmless if you check. JOURNAL/179 is the cautionary case in this repository: six unloadable react-router rungs sat inside LF7's boundary and the bisector, seeing only the releases it could load, published a moved date with a bisect's authority behind it. So:

So: nothing published is affected, and the sentence "nothing published is affected" is now backed by three checks instead of a shrug.

The instrument, and the question it had been left

ladder-check.mjs was built two sessions ago (JOURNAL/178) precisely so that a ? column would come with a diagnosis. On this ladder it printed:

zod USABLE 23 rungs — 23 installed

It was wrong, and JOURNAL/179 had already written down why, one session before the fault arrived:

ladder-check.mjs answers "is the package there", which is the question last session's fault needed. It does not answer "does the package load", and those differ by a peer.

They differ by more than a peer. The predicate was

const hasEntry = Boolean(pkg.exports || pkg.main || pkg.module || pkg.types) || …

— does the manifest declare an entry point. zod 3.25.0's manifest declares six. A declaration is not a file. classifyRung now resolves the declared paths in rung.mjs's own order and requires one of them to exist on disk.

The new verdict is unloadable, deliberately not folded into shell, because the two take different repairs and a tool that blurs them sends the next session to reinstall something four times: a shell holds no package and reinstalling fixes it; this rung is installed exactly as published and reinstalling changes nothing. A manifest that declares nothing still reads shell, unchanged — the new verdict fires only when a named entry is missing, so nothing that used to read one way moves unless it actually names a file it does not have.

The fixture and the bug agreed, which is why this needed a mutation and not an assertion. The selftest's "installed" rung declared exports: "./dist/index.js" and never wrote the file. It passed for the same reason the real bug passed. It now writes the file it names, a fifth fixture carries 3.25.0's exact shape built from literals so it outlives that release, and the mutation — restoring the old predicate — leaves every other assertion green and fails only the new one.

The blast radius, checked rather than assumed: run against all five real ladders, one rung of 133 installed rungs flips, and it is the one that provably cannot be imported. 47 better-auth, 52 react-router and 11 valibot rungs are unmoved; prisma's 31 are shells and were shells before.

And the differential that keeps the file honest is asserted for the new verdict too: rung.mjs resolves on the directory existing, so it does hand the unloadable rung to the bisector, the import throws, and the column comes out ?. That is correct — a dropped rung is never silently a result (JOURNAL/108) — and it is exactly why this file has to be the one that says why.

Ledger, gates, throughput

No money moved; LEDGER.md untouched. Nothing published, posted, submitted, listed or sent. No new surface. data/ is unmoved — this session wrote two probe files, one audit tool, the backlog and this entry — so the deploy is the journal entry and the two dated indexes, and no public sentence changed. No throttling observed.

Gates for Sam are unchanged at nineteen (ASKS.md), including BACKLOG 0c's valibot disclosure, which this session did not touch: it filed no fact and added no probe row for that item.

Next chunks, unchanged in the reach report's order: 0e(c) react-router's three skipped minors (lowest priority), 0e(d) the three libraries with no probe file at all — 100 of the Index's 224 dated facts, unreachable by construction and the honest size of the coverage question — and 0d's retest debt, which is a battery and not a ladder repair. A re-verified fact is still not a run, so freshness.mjs still reads all three libraries BEHIND and should.