check-platform-checklist's self-test D4 uses a strict <, so draining two more bad citations reds the gate for doing what #18104 asks — and the drain's end state reds it permanently #19233

Path: none | instrument (checklist gate self-test) | 北极星「仪器为车队服务」

check-platform-checklist's own self-test D4 asserts the accept-set rows are a strict minority of the bad-citation rows — so draining two more bad citations turns the gate red for doing exactly what #18104 asks, and the drain's terminal state makes it red forever.

Filed by the domain:devx execution PM seat (session session_017ef78bLdybu3AffehKkhfk) out of cut 3's out_of_scope_findings on #18104 / PR #19232. ⛔ Not graded, no domain:* — that is triage's. Expected landing point: scripts/check-platform-checklist.mjs ⇒ domain:devx by SUBJECT.

The assertion, verbatim

scripts/check-platform-checklist.mjs:2248-2250:

t('D4 the `accept-set` rows are the minority and are named as a DIFFERENT card — ⛔ nothing here widens the shared core',
  SHARED_RESOLVER_RESIDUAL.filter((r) => r.verdict === 'accept-set').length
    < SHARED_RESOLVER_RESIDUAL.filter((r) => r.verdict === 'bad-citation').length);

⭐ The comparison is a strict <. That is the whole defect: it fails at equality, not only when accept-set exceeds bad-citation.

⚠️ The arithmetic, measured on PR #19232's head 76e8df900

Ledger after cut 3: 18 rows = 10 bad-citation + 8 accept-set (ceiling 18, rows == ceiling).

⚠️ Correction to the reading this was handed over with: cut 3's report says the break comes at "3 or more". Measured against the real ledger it comes at 2 — the strict < fails on equality. A cut sized at two rows would look safe under the looser reading and would red the gate.

⇒ Reproducible today, cheaply: delete any 2 bad-citation rows from the ledger and run node scripts/check-platform-checklist.mjs --self-test.

⭐ Why this is worth a card and not a note

The 8 accept-set rows cannot leave without a maintainer letter on #18101. So D4 now couples two cards that neither of them names:

• Drain the 47 bad-citation rows on SHARED_RESOLVER_RESIDUAL — a closed ledger with no owner is how it turns back into an allow-list #18104 cannot finish its drain without turning D4 red;
• [finding] the shared symbol-anchor resolver refuses 8 anchors that name real declaration sites — an INLINE object-literal key, and a DATA identifier that heads a dotted string token #18101's letter is the only thing that can remove the other side of the comparison.

⇒ A gate's self-test is quietly holding one card hostage to another's pending decision. Nobody reading either card can see that — it is visible only in the assertion.

⛔ What the repair must NOT be

⛔ Do not delete D4, and ⛔ do not relax it to <=. Its subject is real and worth keeping: it exists so the accept-set bucket cannot quietly become the main population, which is how «nothing here widens the shared core» is enforced. <= merely moves the cliff by one row and leaves the terminal state red.

What the repair plausibly is (⛔ not prescribed)

The invariant D4 wants is about the residual's composition while a drain is in progress — not about a terminal state where bad-citation is legitimately zero because the work finished. Any repair should keep D4 able to catch the thing it was built for (an accept-set bucket growing into the main population) while letting a completed drain be green. ⛔ This card does not choose the spelling, and the reading that the drain's end state is legitimate is the load-bearing judgement — put it to whoever owns this gate.

⚠️ Whoever takes it: the gate's --self-test is 221 assertions and runs from source (no build), so reproduction is cheap; node scripts/check-platform-checklist.mjs (census) is the other half.

Refs: #18104 (the drain) · #18101 (the letter that frees the accept-set rows) · PR #19232 (cut 3, the state above)

Generated by Claude Code