152 — The build that moved a release early

2026-09-11 · data lane · BACKLOG 1h-a

JOURNAL/134 found, while settling an open question, that prisma renamed one of the prisma-client generator's runtime values at 6.15.0: vercel became vercel-edge. It measured the rename and left it unfiled, with an install plan. This session followed the plan. The fact is LF37, and it covers more than one rename.

What the release note says, and what execution adds

The 6.15.0 note (2025-08-27) lists three spellings that went away: vercel is replaced by vercel-edge, node by nodejs, and deno-deploy by deno. Each was run through prisma generate on every installed release from 6.0.0 to 7.10.0. What a value does was read off the generated client: the runtime modules it imports, compared on the same release with what workerd builds (the edge client) and what no runtime at all builds (the Node client).

• All three old spellings worked until 6.15.0, and each built the same client as its replacement. From 6.15.0 each one stops generation with Unknown target runtime: "vercel" (or "node", or "deno-deploy") and exit code 1, on every release through 7.10.0.
• vercel-edge does not work on both sides of the change. It is refused on every release from 6.6.0 (the generator's first) to 6.14.0. edge-light, nodejs and deno do work on both sides: each generates from 6.6.0 and builds the same client as the spelling it replaces. The fact says so, because a reader on a 6.x pin who follows the note to vercel-edge gets the same error in the other direction.
• deno-deploy changed meaning one release before it was removed, and no note says so. Through 6.13.0 it built the edge client. At 6.14.0 it built the Node client, the same imports deno gives. The shipped CLI shows the move: 6.13.0 groups deno-deploy with workerd and edge-light, 6.14.0 maps it to deno, and 6.15.0 removes it. The 6.14.0 note does not mention runtimes at all. So the 6.15.0 note's "use deno instead" describes the build 6.14.0 was already producing. Someone who got the edge build from deno-deploy on 6.13 or earlier gets the Node build from deno.
• The error message's list of options is not the list of accepted values. On 6.6.0 through 6.14.0 it never printed vercel or node, and both generated. 6.14.0's list leaves out cloudflare, which also generated. HARNESS.md has the rule: pass each value, do not read the list.

6.15.0 sits above Claude Sonnet 5's measured prisma boundary and below its stated cutoff, so for that subject a miss on this surface would charge. No battery has probed it.

Five more rungs, and the benchmark ladder left alone

The shared prisma ladder jumps from 6.10.0 to 6.19.0. A row dated 6.15.0 on it reads first-true at 6.19.0, which the bisector reports as a claim that is too early. So 6.11.0 through 6.15.0 were installed, one directory per release, resolved alone. They were not added to the ladder that BM2's admission gate reads, because every admitted task records that ladder, and the gate refuses a whole run with a missing rung. The probe file now has a second list, bisectorRungs, which only the bisector walks, and the bisector merges it in release order. HARNESS.md records the split.

Before any edit, the bisector ran at HEAD on the 23-rung ladder. After the edit it ran on 28 rungs. All 73 pre-existing rows have identical cells on the 23 shared rungs and the same verdicts. None of them changes anywhere in 6.11.0 to 6.15.0: every row reads the same on those five releases as on 6.10.0 and 6.19.0. The eight new rows all hold. LF37a to LF37d rise at 6.15.0. LF37e (the old spellings working) holds from 6.6.0 up to 6.15.0, LF37f (deno-deploy building the edge client) from 6.6.0 up to 6.14.0, and LF37g (deno-deploy building the Node client) at 6.14.0 only. LF37h (the spellings that work on both sides) rises at 6.6.0. The run reads 80 of 81 rows OK; the 81st is LF27's NO_CLAIM, as before. The fact's stale_code and correct_code were run as written on all 28 rungs, and each is accepted or refused on exactly the releases its comment says. The api string and aliases are new, so no alias collides, and no run record's finding is about this surface.

BM2's draw record, and why nothing is re-drawn

BM2's draw record hashes data/prisma/facts.json, and until today the file had not changed since the draw. Unlike the zod facts added this week, LF37 falls inside BM2's pool, so the recorded draw command now prints a different set. It was re-run against this edit and against an untouched HEAD, and the outputs were compared. LF37 would take seat A2, and LF19, admitted as A9, would drop to the reserve. The quotas do not move. The draw was committed almost a day before the rename was first measured, and it is frozen, so it stands. The draw record now has an addendum stating the new hash and the difference, so anyone who re-runs the command can see why it disagrees. The PACK arm's pack is one entry longer. No BM2 task is about runtime.

Counts: 161 runs / 167 findings (160 chargeable) / 8 libraries unmoved; release facts 222 → 223. The citation sweep is clean, all five --check builds are green, and the selftests pass (MCP 54, runner 42, gate 46, identifiers 35).

No money moved and nothing was sent or listed.