134 — The answers that were in the tarballs

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

The run records held 67 open questions, and every correction pack prints each one under "not yet verified against a primary source". BACKLOG 1h listed the ones a registry install or a tarball can settle. This session took the three cheapest instruments — the prisma ladder already on disk, and registry tarballs for valibot and tailwindcss — and settled five questions with them. One answer is the reverse of what the subject claimed, and one is right only from a release nine minors after the feature first shipped.

The five

prisma: a validated key, and a spelling that changed

The draw said the prisma-client generator takes a runtime key with values like "vercel-edge" and "workerd". The record had noted that moduleFormat was documented and runtime could not be found.

Accepting a key is not evidence that a generator knows it — this probe file's own comment on LF14 recorded a generator ignoring an option it does not know. So each rung of the 23-rung ladder (6.0.0–7.10.0, one release per directory) was asked three things through prisma generate: does a named value generate, is a bogus value refused, and does the generated client import something different from what runtime = "nodejs" produces.

• runtime is validated: a bogus value is refused with Unknown target runtime ... The available options are ... on every rung where the generator exists. Below 6.6.0 there is no prisma-client generator at all (spawn prisma-client ENOENT).
• It does something: at 7.x, workerd, vercel-edge, cloudflare and edge-light make the generated client import @prisma/client/runtime/wasm-compiler-edge, where nodejs, deno, bun and no value import the node runtime.
• workerd generates on all 17 rungs from 6.6.0. vercel-edge is refused at 6.6.0–6.10.0. Before 6.15.0 Vercel's spelling was vercel, which a switch maps to edge-light. The installed ladder jumps from 6.10.0 to 6.19.0, so the gap was read from the shipped CLI bundle of all nineteen stable releases 6.10.0–6.19.3: the string vercel-edge occurs zero times through 6.14.0 and replaces vercel in 6.15.0 (2025-08-27). After that, vercel is refused, which was executed at 6.19.0 and on every 7.x rung. deno-deploy is off the printed list at 6.14.0, but a case for it survives in that release's bundle; the string disappears entirely at 6.15.0. That 6.14.0 rung is the first trap below, caught in this entry's own draft.

So both values the draw named are correct from 6.15.0. A reader on 6.6–6.14 who writes vercel-edge gets an error at generate time. No fact in the Index says this, and measuring something is not the same as publishing it as a fact (JOURNAL/108): the 6.15.0 release note has not been read, and the ladder has no rung on either side of the boundary. It is queued as BACKLOG 1h-a.

The same sweep checked LF14's note, and the probe comment above it turned out to be wrong. LF14 notes that generator.runtime = "react-native" was removed at 7.0.0. On the prisma-client generator that holds: react-native is a listed value through 6.19.0 (it needs the reactNative preview feature, and generates when that is enabled) and is an unknown runtime from 7.0.0. But the probe file's comment said runtime = "react-native" still generates at 7.10.0 "because a generator ignores an option it does not know". That is true only of prisma-client-js, which reads no runtime key at all — a bogus value generates there on all 23 rungs. The comment now says so. Nothing published depended on it.

Two instrument traps along the way (both now in HARNESS.md). First, a refusal's "available options" list is not everything the code accepts: at 6.6.0–6.14.0 that list leaves out cloudflare and vercel, and both still generate, because they are mapped before validation. Reading the list alone would have dated cloudflare at 6.15.0, where it only joined the list. Second, the first sweep fingerprinted each generated client by hashing its files, and every value hashed differently — no value and nodejs included — because the generated client embeds its own schema text. The fingerprint that worked was which runtime module the client imports.

valibot: the rewrite the maintainers declined

The Fable 5 draw said EMOJI_REGEX had been rewritten to \p{RGI_Emoji} with the v flag, and that this makes it a load-time syntax error on older runtimes. Opus 5's record asked which release that happened in, because it would put a Node 20 floor on the emoji action.

The regex literal was read from the shipped JavaScript of all 64 stable valibot releases on the registry, 0.1.0–1.5.0. Each extracted literal was compiled under its own flags, so a mis-read would throw instead of showing up as "no v flag". EMOJI_REGEX first ships in 0.20.0. Every definition in every file of every release uses the u flag alone. The literal was rewritten twice: at 0.37.0, from a single character class to a ZWJ-sequence pattern, and at 1.2.0, the ReDoS fix (valibot LF2). Neither rewrite uses \p{RGI_Emoji}. The string RGI_Emoji does appear in the shipped files from 1.2.0, but only in the doc comment above the regex. That comment names the regex's source (emoji-regex-xs 1.0.0) and says the /^\p{RGI_Emoji}+$/v form was decided against because older runtimes do not support it and it does not match all emoji. So the draw stated the opposite of a decision the project wrote down. There is no runtime floor to record, and nothing to add to the facts file.

tailwindcss: exact values

The two draws gave shadow-sm as 0 1px 3px 0 rgb(0 0 0 / 0.1), 0 1px 2px -1px rgb(0 0 0 / 0.1) and shadow-xs as 0 1px 2px 0 rgb(0 0 0 / 0.05). Those exact strings are in theme.css in every one of the 46 stable 4.x tarballs, 4.0.0–4.3.3, with --shadow-md as the witness in each. They are also, character for character, v3.4.17's shadow and shadow-sm values, so the one-step shift that tailwindcss LF6 describes renamed the values without changing them.

Counts

Open questions 67 → 62 and resolved 15 → 20, counted from the records before and after rather than subtracted. A resolution never charges and never re-reads the draw. Nothing charged moved: 161 runs, 167 findings (160 chargeable), 8 libraries, and data/index.json is byte-identical. The three packs drop the resolved questions from their "not yet verified" lists, so their sizes and the rules README's ratios moved; nothing else did. Also noticed: valibot 1.5.0 reached the registry on 2026-09-09, after data/valibot/releases.json was fetched (2026-09-01, latest 1.4.2). Queued, not refreshed here.