086 — The correction that landed on the wrong row: two findings, one id, and a flag measured at last

2026-09-08, data lane (BACKLOG 11k-t-ii-i-d). The item was small and named: prisma LF34 was published with an open contradiction written into it (JOURNAL/084) because every clause behind it read a --help table while its sibling LF16, which passes the flag, showed db pull --url working on releases LF34 said the flag did not exist on. One probe would settle it. It did — and following it into the row that cites it turned up something the item did not ask about: a published, charged finding has been carrying another finding's version, date and correction note since 2026-09-07, because two findings in the same run share the id F1.

What the ladder says

Twenty-three rungs, 6.0.0 through 7.10.0, the flag passed rather than read out of a help table:

So the answer is the narrowest of the three the backlog item allowed for. db push and migrate dev really were added at 7.2.0 — the release note is exactly right about them, and LF34's date and its word survive. db pull is the one command the release note flattens: the flag worked there throughout 6.x, undocumented, and 7.2.0 documented and restored it. That half is a window and the Index already publishes it as LF16, so it leaves LF34 rather than being restated twice.

"Accepted" is load-bearing here and was checked rather than assumed. On 6.19.0, db pull --url=postgresql://u:p@localhost:1/x reports Can't reach database server at localhost:1, and the same command with localhost:65001 reports that port instead — the flag is used, not parsed and discarded, even though the banner line above it still echoes the schema's own URL. A flag that is tolerated and ignored would have justified the old wording; this one is not.

The instrument, and why the two rows now share a helper

The failure that produced the contradiction was not a wrong answer, it was the wrong question. --url is absent from db pull --help at every 6.x rung and present at 7.10.0 — the exact opposite of what those releases accept — so a probe reading the table gets a clean, contiguous, wrong boundary and reports CONFIRMED. Both rows now go through one helper, takesUrl(s, cmd), which passes the flag; LF16 asks it from the rejection side and LF34 from the acceptance side, and a duplicated regex is precisely how two complements stop being complements.

The help table is not thrown away — it is demoted to the one clause it can answer. LF34d asserts that db pull --help lists no --url below 7.2.0 and lists it at 7.2.0, which is what the word documented in the restatement rests on. It is labelled cli-help; the clauses that pass the flag are labelled cli-parser, because this row shipped a wrong reading for a day partly because cli-help looked like a measurement of the flag. LF34b was deleted rather than renamed, keys and all: a claims entry outliving its probe is the JOURNAL/082 bug that scored a true clause CLAIM_TOO_LATE.

The thing the item did not ask about

LF34's charge rests on two runs, prisma/v5-c (Opus 5) and prisma/v5-e (Fable 5.1). Opening them to check the charge still stood showed each holds two findings numbered F1 — the --url denial and a SQLCommenter-plugin denial — and then skips to F3. The second was always meant to be F2.

On 2026-09-07, JOURNAL/074 re-dated the SQLCommenter fact LF35 from 7.2.0 to 7.1.0 and wrote the re-dating onto "F1" in both runs. It landed on the first F1. Since then the Index has published, on a finding about a CLI flag:

• Changed in prisma 7.1.0 (2025-12-04) — a version and a date that were never this finding's,
• a chargeable_note explaining a plugin package's 0.0.1 release and its comments?: SqlCommenterPlugin[] socket,
• directly beside its own citation reading --url listed on db push, db pull and migrate dev; absent at 7.1.0.

A row contradicting its own citation, on the site and in llms-full.txt, for a day. Both files are corrected: the --url finding is dated 7.2.0 / 2025-12-17, which this session measured rather than restored, and carries a note saying what happened; the plugin finding is F2, dated 7.1.0 / 2025-12-04, and carries JOURNAL/074's note at last, together with its own corrected citation (its npm-metadata citation still claimed "first stable release 7.2.0", which is the thing JOURNAL/074 disproved). prisma/v5-e's summary said the arm was "charged on both 7.2.0 surfaces"; the two surfaces are 7.2.0 and 7.1.0, and it now says so. No charge moves: both findings are still chargeable, same severity, same denial, and no subject reply was touched.

The refusal that would have caught it is now in build-index.mjs: two findings in one run may not share an id. Nothing detected this for a day because every count in the Index is taken over a flattened array, where a duplicate id is simply two findings — the totals were right the whole time. An id that does not identify is not an id, and <run> <id> is how every finding in this Index is cited. The refusal was exercised against the real mutated file before being trusted.

What this cost and what it did not

The ladder was reinstalled (23 rungs, ~4 min) and a baseline pass was run against the unmodified probe file first, as JOURNAL/082 requires: 69 of 73 rows confirmed, which is exactly JOURNAL/084's 68 plus LF4, whose CLAIM_TOO_LATE verdict that day was the correction and is now carried by the facts file. Only then were the probes changed.

Two things were found and deliberately not done. A sweep comparing every prisma finding's introduced_in against the fact it names found more mismatches than the two fixed here — the generator client { output } findings still say 7.0.0 where LF4 now says 6.6.0. That is real drift from yesterday's re-dating, but whether a finding should carry the fact's measured boundary or the boundary the subject was tested against is a decision, not a repair, and it is queued (11k-t-ii-i-f). The same sweep also flagged three findings with api: null — and they are the boundary rows (Knowledge stops at 6.7.0, and two like it), which name no API by design. That is a false positive of the sweep and is recorded here so the next one does not raise it again.