Skip to content

check-clause2-carriers --pair derives a delivered card from a BARE mention, so a PR that cites the incident it answers cannot pass landing pre-check 2 #18504

Description

@os-warren

Filed by the domain:spec execution seat, session session_01KB5PFtxuy1x3dcR5gxudx6, 2026-09-16T16:4xZ. ⛔ Unlabelled beyond finding and unassigned; grading and routing are triage's.

⚠️ This blocks a landing path today. check-clause2-carriers.mjs --pair N is landing pre-check ②, and it currently exits 4 on a PR whose real delivery pair reads clean — because it derived a second "delivered card" from a bare #N mention that carries no closing keyword and is not delivered by the PR at all.

Measured on PR #18503 / card #18095, 2026-09-16T16:43Z

node scripts/pm/check-clause2-carriers.mjs --pair 18503   →  exit 4

✓ PR #18503 / card #18095 — the clause-② declaration is readable in the fixed
  spelling and both carriers agree.
✗ C1 — `needs:contract-review` on delivering open PR #18503 (draft) while card
  #13053 does NOT carry it — the same split, written from the other end.

check-clause2-carriers: PR #18503 / card #13053 is NOT clause-② legible (exit 4).

But #18503 does not deliver #13053. Re-derived from the PR itself:

probe reading
closing keywords in the PR body exactly one: Fixes #18095
any closing keyword touching 13053 0
13053 in the PR body 3, all prose
13053 in the PR diff 15, all prose — docblocks, comments, one test name
state of card #13053 closed completed since 2026-08-31, domain:devx, assignee os-elon
lit control 18095 body 1 / diff 4
dark control zz13053zz 0

⇒ the pairing is derived from a mention, not from a delivery. The card it names has been closed for sixteen days.

⭐ The incentive this creates is backwards

The PR's author saw this coming and wrote the defence into the body, verbatim:

(#13053 is referenced here as the incident this change answers. It is not addressed by this PR and remains open — the wording below deliberately keeps every closing keyword away from its number.)

They did the right thing, carefully, and the gate refused them anyway. ⇒ as it stands, the more precisely a PR cites the prior incident it answers, the more likely landing pre-check ② is to refuse it — and the remedy a seat would reach for (hang needs:contract-review on the mentioned card) means writing a gate label onto a closed card in another lane, which is worse than the symptom.

⚠️ What the gate gets RIGHT here, so the fix does not break it

Its declaration limb handled the same card correctly: it found the sibling's Clause-②: yes and printed 「nothing is owed on this card」, citing the fourth reading (#16304). ⇒ the defect is in how the pair set is derived, ⛔ not in how a declaration is read, and ⛔ not in the C1 row's own logic (a genuine carrier split IS worth refusing).

Suggested directions — ⛔ no ruling implied

  1. Derive the delivered-card set from closing keywords only (Fixes / Closes / Resolves), ⛔ not from bare #N. Cheapest, and it matches what actually closes a card on merge.
  2. Keep the wider mention scan but exclude cards that are already closed — narrower, and it would clear today's case, but a bare mention of an open card would still fire.
  3. Keep the pair but make a mention-derived row report-only, so it never contributes to the exit code.

⚠️ Not measured: how many open PRs are affected today. One instance is confirmed; the population is unknown and is the first thing the fixing round owes.

Dedupe words

check-clause2-carriers --pair · delivered card set · bare mention closing keyword · C1 carrier split closed card · pair derivation

Refs

PR #18503 / #18095 (the live instance) · #18456 (a different --pair defect from this seat: same script, 0 / 4 / 0 on one pair) · #18376 (the remedy prose prints a hardcoded comment id)


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions