Found by the domain:devx dev seat while implementing #13975 (PR #13990). ⛔ Unassigned. Nothing is broken by this today — it is a ledger/board drift with one measured consequence already on the record.
The drift
scripts/pm/ensure-pm-labels.sh — the label ledger — creates exactly three repo:* labels, each with the same description:
gh label create repo:objectui -R … -d "Seam card: cross-repo ordering with objectui is the substance (pure objectui fixes live in objectui)"
gh label create repo:cloud -R … -d "Seam card: cross-repo ordering with cloud is the substance (pure cloud fixes live in cloud)"
gh label create repo:hotcrm -R … -d "Seam card: cross-repo ordering with hotcrm is the substance (pure hotcrm fixes live in hotcrm)"
The board carries a fourth: repo:objectstack, on 4 open cards (#12237, #12238, #12243, #12311 — all docs-site work). It has no description, and no line of the ledger creates it, so --reconcile never sees it.
⇒ The repo:* family means two different things depending on the member: three declare "the ordering is cross-repo, the audience is elsewhere", and the fourth declares "this repo" — the exact opposite reading.
Why it is worth a card rather than a shrug
Measured while implementing #13975: the H14 seam predicate ruled for that card is "carries any repo:* label", and it is correct for exactly the three ledger members. On repo:objectstack it over-covers — a label naming the swept repo cannot make this sweep's Blocked-by: index blind, so declining there is conservative rather than structural. The patrol ships that literal predicate (the ruling's), and says in the row when the decline is conservative; today 0 of 5 live H14 strip rows carry the label, so the cost is 0. That is a fact about this week's board, not a property.
Two directions to consider, ⛔ neither decided here:
- Declare it — add
repo:objectstack to the ledger with a description that says what it means (a docs-site/main-repo lane, not a seam), and let readers of the family stop having to know the exception.
- Retire it — the 4 carriers are all docs-site cards, and if
domain:docs-style routing already covers them the label is a lane spelling the family does not need.
Whichever is taken, the predicate in h14BlockingCacheIncoherent can then be narrowed (or left literal) on a ruling rather than on an author's judgement — that is the reason this is filed rather than fixed in the #13975 PR, which is scoped to the H14 row.
Also measured, same round (context, not part of this card)
The repo:* family is a poor proxy for "has an off-repo audience" in general: of the 67 open cards naming a sibling-repo issue (objectui#N / cloud#N / hotcrm#N) in title, body or gathered comments, 58 carry no repo:* label. That under-coverage is disclosed in the H14 row text by PR #13990 and is the PM's to rule on separately.
Dedup
REST search_issues is not available to this container (repo-scoped endpoints only), so dedup was run over the full open-issue listing this session already held (402 open cards, fetched 2026-08-31) with repo:objectstack / ensure-pm-labels / label ledger / undeclared label: 0 matches. Controls over the same corpus in the same pass: pm:blocking 4, check-half-states 6, seam card 9 — so the zero is a reading, ⛔ not a broken query. Closed cards were not covered by this method.
Generated by Claude Code
Found by the
domain:devxdev seat while implementing #13975 (PR #13990). ⛔ Unassigned. Nothing is broken by this today — it is a ledger/board drift with one measured consequence already on the record.The drift
scripts/pm/ensure-pm-labels.sh— the label ledger — creates exactly threerepo:*labels, each with the same description:The board carries a fourth:
repo:objectstack, on 4 open cards (#12237, #12238, #12243, #12311 — all docs-site work). It has no description, and no line of the ledger creates it, so--reconcilenever sees it.⇒ The
repo:*family means two different things depending on the member: three declare "the ordering is cross-repo, the audience is elsewhere", and the fourth declares "this repo" — the exact opposite reading.Why it is worth a card rather than a shrug
Measured while implementing #13975: the H14 seam predicate ruled for that card is "carries any
repo:*label", and it is correct for exactly the three ledger members. Onrepo:objectstackit over-covers — a label naming the swept repo cannot make this sweep'sBlocked-by:index blind, so declining there is conservative rather than structural. The patrol ships that literal predicate (the ruling's), and says in the row when the decline is conservative; today 0 of 5 live H14 strip rows carry the label, so the cost is 0. That is a fact about this week's board, not a property.Two directions to consider, ⛔ neither decided here:
repo:objectstackto the ledger with a description that says what it means (a docs-site/main-repo lane, not a seam), and let readers of the family stop having to know the exception.domain:docs-style routing already covers them the label is a lane spelling the family does not need.Whichever is taken, the predicate in
h14BlockingCacheIncoherentcan then be narrowed (or left literal) on a ruling rather than on an author's judgement — that is the reason this is filed rather than fixed in the #13975 PR, which is scoped to the H14 row.Also measured, same round (context, not part of this card)
The
repo:*family is a poor proxy for "has an off-repo audience" in general: of the 67 open cards naming a sibling-repo issue (objectui#N/cloud#N/hotcrm#N) in title, body or gathered comments, 58 carry norepo:*label. That under-coverage is disclosed in the H14 row text by PR #13990 and is the PM's to rule on separately.Dedup
REST
search_issuesis not available to this container (repo-scoped endpoints only), so dedup was run over the full open-issue listing this session already held (402 open cards, fetched 2026-08-31) withrepo:objectstack/ensure-pm-labels/label ledger/undeclared label: 0 matches. Controls over the same corpus in the same pass:pm:blocking4,check-half-states6,seam card9 — so the zero is a reading, ⛔ not a broken query. Closed cards were not covered by this method.Generated by Claude Code