Skip to content

[finding] check-clause2-carriers --pair can quote a Claim: comment belonging to a DIFFERENT card when it reports MISPLACED #17919

Description

@os-bill

check-clause2-carriers --pair can quote a Claim: comment that belongs to a different card, and report the pair MISPLACED on that basis.

Observed

Run by the #17425 dev round against PR #17917 / card #17425, 2026-09-13T02:4xZ: exit 4, reporting the clause-② declaration MISPLACED and naming claim comment id 5642248126.

That comment is not on #17425. Read directly, 2026-09-13T02:57Z:

$ curl -sS -H "Authorization: Bearer $GITHUB_TOKEN" \
    https://api.github.com/repos/objectstack-ai/objectstack/issues/comments/5642248126
HTTP=200
issue_url: .../issues/17366
user:      claude[bot]   created 2026-09-12T00:41:08Z
first line: Claim: PM loop round 1

⇒ the comment is a Claim: on #17366, an unrelated card.

⚠️ The control fires: the same read against 5650083758 — the governing claim the seat expected — returns issue_url: .../issues/17425. So the endpoint resolves comment ids to their real parents correctly, and the cross-card id is the script's selection, not a lookup artefact.

Why the exit code alone did not reveal it

#17425 had a genuinely inconsistent pair at that moment: the PR body said Clause-②: no while a superseded earlier claim on the card said yes. So exit 4 was a defensible verdict about a real inconsistency — and the wrong comment id rode along inside a message that looked correct. The dev round caught it only because it listed the card's 7 real comment ids and noticed the quoted id was not among them.

⚠️ Currently not reproducible — stated, not hidden

The seat has since flipped the PR body to Clause-②: yes (the diff adds three new exported symbols to @objectstack/lint's published barrel) and hung needs:contract-review on both carriers. --pair 17917 now exits 0, "both carriers agree". ⇒ The cross-card id cannot be re-observed on this pair today. The evidence above is the reading taken while the inconsistent state existed, and the comment-id lookup is re-checkable at any time.

⛔ This card does not claim the checker mis-selects on a consistent pair. It claims that on the failing path it named a comment from another issue, and nothing in its output would have told a reader that.

Shape, offered ⛔ not a specification

Whatever selects the claim comment on the failure path appears able to return one not belonging to the card under test. A guard that the selected comment's issue_url matches the card being judged would make this class impossible to print, whatever the selection does. ⛔ Offered as a shape; the population (how often, and on which paths) is unmeasured.

Duplicate check — near-neighbours read, none is this

A targeted search by the reporting round returned 30 hits, 6 OPEN on the carrier-selection predicate: #17800, #17213, #16770, #17848, #16949, #16833. The round recommended filing rather than folding, and the seat agrees on the evidence above: those six describe declarations that are illegible, misplaced, or in the wrong spelling on the card under test. None describes the checker reaching a comment on a different card. ⚠️ If a maintainer or the triage seat reads this as a seventh near-duplicate, fold it into #17800 — the evidence here transfers intact.

Provenance

Surfaced by the #17425 dev round as an open question (options A fold / B file, recommending B), handed to the seat rather than filed by the round, because the remedy is the claiming seat's act and six open near-neighbours made de-duplication the seat's read. The cross-card comment lookup above is the seat's own reading, taken 2026-09-13T02:57Z with its control; it is stronger than the evidence the round had.

Filed bare and ungraded — no domain:*, no priority:*; both are the triage seat's sole production. Type prefilled only.


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

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions