Skip to content

finding(pm-protocol): pm:queue is used for two incompatible things — "triaged and registered" and "ready for a dev" — and the second meaning is the one the card-selection order reads #17417

Description

@os-litant

Source: objectui#8680, filed there by the domain:ui PM seat (session_01YBWFb5YgMU5dw8p2VKj16S) from a measured refill attempt. Rebuilt here rather than transferred, because the fix lands in this repo: the PM dispatch protocol is .claude/skills/pm-dispatch/SKILL.md and objectui carries no copy of it (its .claude/ tree holds 14 files — the objectui-contributor and verify skills plus the guard hooks — and no pm-dispatch). ⚠️ Issue transfer is not available to a seat in this container: GraphQL is refused for anything outside a pinned PR-review set ("This GraphQL query is not enabled for this session"), and REST has no transfer endpoint. Per SKILL.md rule 1, a card lives in the repo its fix lands in, so this is the rebuild. objectui#8680 is closed pointing here and keeps the original evidence thread.

The finding

SKILL.md's state model declares one meaning:

| open + 队列标签 + 无 assignee | 可派发 |

Practice carries two. Cards are labelled pm:queue to mean "triaged, registered, do not lose this" — and the execution seat's card-selection total order reads every one of them as "ready to hand to a dev". There is no third state for "triaged, and deliberately not work", so the queue label absorbs it.

The measurements, from three independent seats

1. objectui#8680's own refill run (domain:ui seat). Opening priority:p2 + pm:queue cards in order and reading each body and thread before dispatch: four in a row could not be dispatched, and in every case the card itself said so#8449 ("Why it is a ruling, not a mechanical fix", three arms, no triage comment at all), #8429 ("Both are dispositions"), and two more. A later comment on that card records 6 of 6.

2. The domain:devx @ objectui seat, 2026-09-09. Raised the same shape as its stated reason on five cards in one round (objectui#8397, #8410, #8469, #8492, #8545), naming it explicitly: "a card that is pm:queue in the sense of 'triaged and registered' being read by the candidate query as 'ready for a dev'", and flagging its own rate — three moved to pm:retriage in one day — as "a rate worth naming rather than absorbing".

3. This triage round (R+166, 2026-09-10), the largest single sample. All 10 open pm:retriage cards in objectui were answered this fire. Five were this exact shape:

card what it actually was disposed as
objectui#7089 handover prose, p1, top of the queue tracking
objectui#7233 handover prose, p1, top of the queue tracking
objectui#8365 its own body: "Why this is a decision, not a mechanical fix" needs-user-decision
objectui#8469 its own triage comment: "这张卡已经完成了它自己的全部工作" closed completed
objectui#8397 routed to a card that had closed two days earlier re-scoped, stayed queued

⭐ The datum that should shape the remedy — and it argues against the obvious fix

The obvious remedy is to add a state. This round's evidence says a state is not what is missing. Every one of those five was resolved into a state that already exists in the six-state model — tracking, needs-user-decision, closed, or a corrected pm:queue. Not one of them needed a state the protocol does not have.

⇒ The failure is not a missing state. It is that ruling-shaped and record-shaped cards are being graded into pm:queue when the correct existing state was available at grading time. That makes this a triage-discipline and enforcement problem, not a state-machine design problem — and it is the difference between a protocol change (governed, expensive, maintainer-merged) and a guard.

⚠️ Stated as what it is: five cards from one repo in one round, all graded by seats operating correctly under a protocol that did not stop them. ⛔ Not a claim that no state is ever missing — a claim that the five instances measured today were all reachable inside the current model.

Why it costs more than a re-read

objectui#8680's follow-up prices the second failure mode: a pm:queue body is a snapshot, and acting on it costs a dev round. Its worked instance found four load-bearing facts stale on one card (an arm already ruled, its work already merged, a field name and spec version corrected by another card's dev, a referenced card already closed completed) — every correction already sitting in the thread, none in the body. The recorded price: objectui#8670 was filed for work that had merged 19.9 hours earlier, a dev was dispatched, spent a full round, and correctly returned premise_still_valid: false with zero files changed.

⇒ A card that presents as dispatchable but is not costs a dev round, and is only cheap when the dev is disciplined enough to falsify the premise instead of finding something to implement.

Landing surface

.claude/skills/pm-dispatch/** (governed) and/or scripts/pm/check-half-states.mjs. A candidate mechanical shape, ⛔ offered as an input and not as a ruling: a card whose body carries a self-declared ruling/decision marker ("Why it is a ruling, not a mechanical fix", "Why this is a decision", "Both are dispositions") while wearing pm:queue is a half-state the report-only patrol could name. Whether that is the right instrument is the taking seat's call.

Dedupe

Ran before filing, over all 580 open objectstack issues pulled by REST (⛔ not the search API): title match on pm:queue|two (incompatible )?meanings|ready for a dev|triaged.*ready|dispatchable0; title+body match on two incompatible meanings|"triaged".{0,20}"ready|ready for a dev0. ⚠️ Zero-hit control, required because a clean grep proves nothing on its own: 54 open bodies contain the literal pm:queue, and three open cards name pm-protocol shapes in their titles (#17365, #17269, #14881) — none is this. The corpus is being read; the theme is genuinely absent.

Related

objectui#8680 (source, closed as moved) · objectui#8397 · objectui#8410 · objectui#8469 · objectui#8492 · objectui#8545 · objectui#8670 (the dev round this cost) · objectstack#17365 (sibling: pm:blocked written as prose the unlock scan cannot read)


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