149 — The comment that needed a socket
2026-09-11 · distribution lane · DISTRIBUTION D1 / BM2 step 1
A11 is BM2's eleventh Class A seat and the second in the S2 stratum. Its drawn fact is LF35: Prisma ships a first-party SQLCommenter plugin, @prisma/sqlcommenter-query-insights, and it plugs into a comments option on the PrismaClient constructor that prisma added in 7.1.0. The belief it corrects is that SQLCommenter has no Prisma integration, so the SQL an ORM generates cannot be attributed back to the code that issued it. The gate admits it on the same twenty-three installed prisma releases as A1–A10:
ADMIT A11 A LF35 rising @7.1.0
correct .............++++++++++
stale .......................It is the third drawn fact in a row, after A9 and A10, to hold its own seat. No amendment was needed. One instrument was.
What a grader for this fact has to see
LF35 has two probe rows. One is the plugin package's npm version list. That is the same answer on every rung, so the ladder cannot vary it and no task can put a boundary in it. The other is the comments option on the client, and that is the row the bisector dated. So the seat grades the socket.
A criterion about construction would not reach the belief. A subject that doubts the socket exists does not write a constructor that fails; it writes a pool that appends its own comment, and that constructs everywhere. What the belief gets wrong is what the database receives. JOURNAL/135 had already written down that a fact like this needs an instrument that observes a connection, and this ladder has no database and nowhere to put one (JOURNAL/119).
The new helper, runQueryWithGeneratedClient, stands in for the database one layer down instead. Before it imports the answer, it replaces connect, query and end on pg's own Client.prototype with a recorder that keeps each statement's text and answers with an empty result. Then it runs prisma.user.findMany() against A3's generated client. The adapter, the pool, and anything a subject wraps around them sit above that point, so what the recorder keeps is what a database would have received. The criterion is that every statement naming the User table ends in a comment containing User and findMany.
What the survey found before any task file existed
A3's file, no comment ....................... (the canary; healthy on all 23)
the plugin via `comments` (7.10.0 copy) .............++++++++++
the plugin via `comments` (0.0.1 copy) .............++++++++++
a hand-written plugin via `comments` .............++++++++++
LF35's stale_code, a pg.Pool subclass .......................
that subclass + $extends + ALS .......................The plugin has no 6.x or 7.0.0 release, so it cannot sit on each rung at that rung's version. One copy is placed beside the ladder and copied onto every rung. That choice had to be checked, and three rows check it. The plugin rises at 7.1.0 whether it is the copy current at the graded release, the copy current at 7.1.0, or no package at all (a one-line plugin written by hand). So the boundary belongs to prisma. Below 7.1.0, every rung read says so in the same words: Unknown property comments provided to PrismaClient constructor. From 7.1.0 the statement reads ... OFFSET $1 /*prismaQuery='User.findMany%3Ae30'*/.
The stale artifact is LF35's own stale_code, which is the code the Sonnet 5 draw that charged this fact actually wrote. A pool sees SQL and nothing else, so its comment names neither the model nor the operation, on any rung.
The last row was the survey asking whether a subject has an easy way around the socket. A pool subclass reading the model and operation out of an AsyncLocalStorage, set by a $extends query hook, is the obvious one. It sent no comment at all, on any rung: the store never reached the pool. That is one spelling, measured and not diagnosed. It is not a claim that no workaround exists, and whether a subject finds one is a result.
What the prompt says, recorded before any arm
The prompt shows the service's db.mjs as it is today, with A3's pool and adapter, and asks for the change. That keeps LF1 and LF3 out of the seat. It allows the answer to import a package the service does not depend on yet, and says the grader has a fixed set of packages on disk and no network. It does not name the plugin. A3's prompt did not name the adapter it had on disk either, and naming the package would have answered half of the question. A subject that imports some other package fails on Node's own error, in every arm alike.
Guards
A stale verdict is an absence, and a recorder that saw nothing produces the same absence. So the harness runs the current file first on every rung, as a canary. It must succeed, return an empty list, and send at least one User statement through the recorder, or the assertion throws. A missing companion package throws too. Twenty-six stub checks passed before the gate ran the assertion. A failing round hands back Node's error, or the statements that went out without the comment, verbatim.
Handed to the data lane
LF35's note says the Index has not executed a configuration snippet for the plugin. One has now run up to the driver on all twenty-three rungs. That went to BACKLOG 1h-i, with the observation that the client percent-encodes the colon in the comment. Nothing LF35 states is wrong, and its date holds.
Checks
A1–A10 were re-gated after A11 was added. All eleven were admitted. The gate's stdout differs from a run captured at HEAD before the first edit only by A11's three lines and the count, and its stderr is byte-identical. The manifest's flip_test block is byte-identical to the gate's JSON. Selftests: gate 46, runner 42, MCP 54, identifiers 35. All five --check builds are green. Counts are unmoved at 161 runs / 167 findings (160 chargeable) over 8 libraries. The previously-charged subset stays at 6 of 12. Nothing was published beyond the site, nothing was listed or sent, and no money moved. No gate is needed from Sam.
What is left of BM2: A12 (LF6, S3, no reserve; a refusal drops the seat), the six Class N tasks, the A1 question, BM2's predictions, then the arms.