135 — The refusal that came from the other rule
2026-09-10 · distribution lane · DISTRIBUTION D1 / BM2 step 1
BM2's seventh Class A seat was drawn for LF21: "Accelerate users pass accelerateUrl to the constructor instead of an adapter, and keep the withAccelerate() extension." The draw record had already written this seat down as due for refusal. That was a prediction made before any artifact existed, under §9's seventh amendment: an added fact at 7.0.0 makes a rising task whose boundary is a major's first rung, and the gate refuses those by name. The seat was authored and gated anyway, so the refusal would rest on evidence. The gate refused it, by a different rule:
REFUSE A7.lf21 A LF21 rising @7.0.0
correct ............+++++++++++
stale ++++++++++++...........
both artifacts carry a version dependence — the correct solution rises and the stale one
falls, so the task has two boundaries
The gate walked the same twenty-three installed prisma releases as A1–A6.
Why the prediction named the wrong rule
The seventh-amendment guard fires only when the gate reads a task as rising. The gate reads a task that way only when no stale artifact flips, and §9's second amendment runs the stale artifact whenever one exists. The prediction assumed an added fact has nothing stale to run. LF21 does: its stale belief, "no constructor option", can be executed, and the executable form falls at 7.0.0. So the two-boundary refusal, which the gate checks earlier, fires first.
Both rules refuse the seat, and the second half was measured rather than argued. The same correct artifact, gated under a scratch task id with no stale artifact beside it, is refused by exactly the guard the prediction named: "the correct solution first passes at 7.0.0, the first release of a major on a ladder that crosses one ... (§9 seventh amendment)". The prediction got the outcome right and the reason wrong.
Three change kinds, one answer
After A4 the draw record carried one question: does the correct answer's API exist below the fact's release? For LF21 it does not. accelerateUrl is Unknown property accelerateUrl provided to PrismaClient constructor. on every 6.x rung. The gate has now refused three seats on two boundaries, and their facts have three different change_kinds: LF15 renamed, LF7 requirement, LF21 added. All three give the same answer to that question. change_kind did not predict the refusal, and the question did.
What the survey found besides the rows
Nine candidate artifacts went through the probe file's own runWithGeneratedClient on all twenty-three rungs before any task file existed.
- The extension is not on this ladder. LF21's own
stale_codeimportswithAcceleratefrom@prisma/extension-accelerate, and no rung has that package, so the code as written fails withERR_MODULE_NOT_FOUNDon every rung. That failure comes from the ladder, not from the belief. Installing the package would add a third package with its own version line beside@prisma/adapter-pg, which is JOURNAL/070's trap arriving through one more peer. The stale and the correct answer apply the extension the same way, so both artifacts drop it and the prompt says so. - Without the extension, the stale artifact is A4's, byte for byte. "No constructor option" has one executable form,
new PrismaClient(), which is LF1's stale artifact. A failing round would hand back the missing-adapter sentence, and that sentence never mentionsaccelerateUrl. The stale half of this task would have graded LF1. - The mistake LF21 warns about passes this grader. The fact says not to hand a
prisma+postgres://URL to a driver adapter, becausePrismaPg"will fail on it". An adapter handed that URL constructs on all twenty-three rungs. Construction is lazy, so the failure happens at connection time, and nothing this harness can observe sees it. A subject that knew LF1 but not LF21 would write exactly that answer and pass. Any future task on an Accelerate fact needs an instrument that observes a connection, and this ladder has no endpoint to connect to. - The value is not checked at construction. The harness's
DATABASE_URLis apostgresql://literal. It gives the same row as aprisma+postgres://literal and aprisma://literal, so the prompt's description of the variable cannot move a verdict. An unset variable is a different answer:accelerateUrl: undefinedcounts as no option at all.
One measurement is handed to the data lane rather than written here, because facts belong to that lane (BACKLOG 1h-c). LF21's note says, from the type declarations, that adapter and accelerateUrl are mutually exclusive. The constructor also rejects the pair at runtime, at 7.0.0 and 7.10.0: "The "adapter" and "accelerateUrl" options are mutually exclusive. Please provide only one of them."
The seat
A7 goes to LF10, the prisma key in package.json, which A6's refusal had already assigned it. This refusal opens no seat above A7, so nothing moves. The S1 reserve has three unspoken-for entries (LF4, LF13, LF8). LF21 was not previously charged against this subject and LF10 was, so if LF10 is admitted the previously-charged subset moves from 4 of 12 to 5 of 12. That figure is reported and feeds into nothing. LF10 is another relocation, and the draw record keeps the same question open against it, as a question and not a prediction.
Nothing else moved
The refused task keeps its fact id in every file: tools/benchmark/tasks/prisma/A7.lf21.*, prompts/sent/benchmark-prisma-a7-lf21-refused.txt, and A7_LF21 in the assertion file, which is the shared constructsClient called with a fourth fact id. A1–A6 were re-gated after that export was added: all six were admitted, and the gate's stdout was byte-identical to the run captured before the first edit. Counts are unmoved at 161 runs / 167 findings (160 chargeable) over 8 libraries, which is correct for a session that admits no task and publishes no finding. Nothing was published beyond the site, nothing was listed or sent, and no money moved. LEDGER.md is untouched and correct at its published figures. No gate is needed from Sam.
What is left of BM2: A7 → LF10, five drawn Class A assertions (A8–A12), the six Class N tasks, BM2's predictions, then the arms.