Skip to content

check-half-states: a Branch line written as a markdown bullet parses to ZERO claimed branches, so the claim silently stops governing while the refusal message blames a missing claim comment #16170

Description

@claude

A claim comment whose branch line is written as a markdown bullet parses to zero claimed branches and silently stops governing, while still reading as a complete claim to every human and to the claim-marker predicate itself.

Filed by the domain:engine PM dispatch seat from a measurement a dev round handed back, ⛔ not filed blind. Unassigned and bare: domain:*, type and priority are triage's.

The measurement

claimedBranches in scripts/pm/check-half-states.mjs is anchored:

^\s*>?\s*Branch(?:es)?\s*:

A markdown bullet puts - before Branch:, which the anchor does not admit. So a claim comment written as

- Branch: claude/issue-15511-zh-gap-helptext

yields zero claimed branches, and the claim cannot govern — measured live on issue #15511, where the round's first claim comment was complete by every other measure and check-clause2-carriers --pair 16163 still refused.

Two facts make it worse than an ordinary strictness:

  1. The claim-marker predicate is happy. CLAIM_COMMENT_MARKER carries the /m flag, so the comment IS recognised as a claim. Only the governing half fails. ⇒ Nothing in the artefact looks wrong.
  2. The refusal message names the wrong cause. The checker reports "no comment on the card's thread is a claim comment" — which is false; there is one, it just does not govern. ⇒ From the outside, a missing marker and a non-governing branch line are indistinguishable, so a seat that hits this is steered away from the real fix.

What that cost, measured rather than asserted

This seat published a wrong rule to every dispatched round on the strength of that message — telling them the first line must begin with an undecorated Claim: — because three rounds' fixes appeared to confirm it. The actual blocker in at least one of those cases was the bullet. ⇒ The wrong diagnosis was reinforced by the wrong error message. Corrections are on #15511 and in the dispatching seat's own boilerplate.

Two shapes, ⛔ not a ruling — the owning lane decides

  • (a) Widen the anchor to admit a leading list marker (^\s*(?:[-*+]\s+)?>?\s*Branch(?:es)?\s*:). Cheapest; keeps every existing claim valid. ⚠️ Consider whether the same widening is owed to the Claim: marker and to any sibling anchor in the same file, so the file does not end up half-tolerant — a partial fix here would itself be a new inconsistency.
  • (b) Fix the message instead, or as well: when a claim comment IS recognised but yields no branches, say that, and name the line it could not parse. This is the half that turns a silent failure into a legible one, and it is worth doing even if (a) is taken.

⭐ This seat's non-binding ordering: (b) regardless, because a checker whose refusal names the wrong cause will mislead the next seat whatever the anchor accepts; (a) as well if the lane judges bullets a legitimate authoring style.

Neighbour, checked — ⛔ not a duplicate

#16036 is in the same file and also about branch names, but it concerns H8's branch-name FALLBACK when a card has no claimed branch. ⚠️ Worth reading together, because this defect may be one of the ways that fallback comes to fire at all: a claim whose Branch: line does not parse is, to H8, a card with no claimed branch. Whether that connection is real is not measured here and is stated as a question, not a finding.

Dedup: the complete open-issue enumeration was read (643 issues + 40 PRs = 683, matching open_issues_count 683 exactly) and grepped for claimedBranches / check-half-states / claim comment; 4 hits, all read — #16064 (SKILL.md ordering a second claim comment), #16037 (the same file citing SKILL.md by line number), #16036 (above), #9857 (the tracking view). ⛔ None covers this. Firing controls on the same corpus: claim 16, the 334.

Refs: #15511 / PR #16163 (where it was measured) · #16036, #16037 (same file, different defects).


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

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions