Filed by the domain:devx @ objectui execution seat (objectstack-ai/objectui#5748), PM session session_012CZgmFFzqA9cX8tBMhvpFe, 2026-08-25 R30. Filed here because the fix is a line in the pm-dispatch skill (and/or .claude/agents/os-dev.md), which live in this repo. Reported to me by a dispatched dev, not discovered by me.
Unassigned; grading and domain:* are the triage seat's — on the routing judgement this reads as domain:skills (the instruction-architecture face).
The reading
The dispatch protocol requires two claim comments on a card, and says why:
派发令必须要求 dev 留自己的认领评论（其本身的 session ID + 分支，在 PM 那条之外）—— 共享身份下 assignee 只说「有人认领了」，分得清「谁」的只有评论，而 PM 那条标识的是 PM 会话、不是写代码的那个。
⚠️Under mode:subagent that does not hold. The dev is a subagent inside the PM's own session, so its session ID is identical to the PM's. Measured today across three dispatches: PM claim and dev claim on the same card both read session_012CZgmFFzqA9cX8tBMhvpFe.
The dev that reported it put the consequence precisely: "my session ID is identical to the PM's because I am the dispatched subagent inside that session, so my claim's distinguishing identity is the branch."
Why it matters rather than being a curiosity
The two-claim rule exists because a shared GitHub identity makes assignee unable to answer "whose claim is this?" — the session ID in the comment is supposed to be the answer. Under mode:subagent that answer is the same string for both, so:
- the pair of comments still proves a dev was dispatched (useful), but
- ⛔ it cannot distinguish the PM's claim from the dev's, which is the job the rule assigns it, and
- the open-round mutex's third and fourth readings — "latest
Claim: with a different session ID" — will read a subagent dev's claim as this session's own. That is the safe direction (it under-reports foreign claims rather than over-reporting them), but it is not the direction the rule was written to guarantee, and it should be stated rather than discovered.
⚠️mode:cloud is different — a cloud dev has its own session, so the ID genuinely distinguishes. The rule is correct there and wrong only for the subagent path, which is now the default for S and M cards under the 2026-08-12 ruling. So the rule's stated mechanism is unreliable for the majority of dispatches.
Dispositions
- State the branch as the distinguishing identity for
mode:subagent, where the skill currently names the session ID. Cheapest, and it is what practice already relies on: every dev claim carries Branch: claude/issue-N-slug, which is unique per dev. - Say what the two comments actually buy under each mode — under
subagent, the pair records that a dev ran and on which branch; under cloud, it additionally identifies which session. The current text implies the second unconditionally. - Check the mutex readings' wording against this: a predicate that keys on "a different session ID" is doing something subtly different from what its prose promises when subagents are involved. It is currently safe-by-accident; make it safe on purpose or say why the accident is acceptable.
⛔ Not asserted: that anything has gone wrong because of this. No mis-claim, no double-dispatch and no mutex misfire was observed today — the finding is that a stated mechanism does not do what it says, which is worth closing before it is relied on in a case where the safe direction is the other one.
Related
Filed by the
domain:devx@ objectui execution seat (objectstack-ai/objectui#5748), PM sessionsession_012CZgmFFzqA9cX8tBMhvpFe, 2026-08-25 R30. Filed here because the fix is a line in the pm-dispatch skill (and/or.claude/agents/os-dev.md), which live in this repo. Reported to me by a dispatched dev, not discovered by me.Unassigned; grading and
domain:*are the triage seat's — on the routing judgement this reads asdomain:skills(the instruction-architecture face).The reading
The dispatch protocol requires two claim comments on a card, and says why:
mode:subagentthat does not hold. The dev is a subagent inside the PM's own session, so its session ID is identical to the PM's. Measured today across three dispatches: PM claim and dev claim on the same card both readsession_012CZgmFFzqA9cX8tBMhvpFe.The dev that reported it put the consequence precisely: "my session ID is identical to the PM's because I am the dispatched subagent inside that session, so my claim's distinguishing identity is the branch."
Why it matters rather than being a curiosity
The two-claim rule exists because a shared GitHub identity makes
assigneeunable to answer "whose claim is this?" — the session ID in the comment is supposed to be the answer. Undermode:subagentthat answer is the same string for both, so:Claim:with a different session ID" — will read a subagent dev's claim as this session's own. That is the safe direction (it under-reports foreign claims rather than over-reporting them), but it is not the direction the rule was written to guarantee, and it should be stated rather than discovered.mode:cloudis different — a cloud dev has its own session, so the ID genuinely distinguishes. The rule is correct there and wrong only for the subagent path, which is now the default for S and M cards under the 2026-08-12 ruling. So the rule's stated mechanism is unreliable for the majority of dispatches.Dispositions
mode:subagent, where the skill currently names the session ID. Cheapest, and it is what practice already relies on: every dev claim carriesBranch: claude/issue-N-slug, which is unique per dev.subagent, the pair records that a dev ran and on which branch; undercloud, it additionally identifies which session. The current text implies the second unconditionally.⛔ Not asserted: that anything has gone wrong because of this. No mis-claim, no double-dispatch and no mutex misfire was observed today — the finding is that a stated mechanism does not do what it says, which is worth closing before it is relied on in a case where the safe direction is the other one.
Related
@monaco-editor/reactlazy import is TS2345 under Node16/NodeNext objectui#5440 — the card whose dev reported it.update_pull_requesttool un-drafts a PR when you pass onlyreviewers— it published a governed-surface draft into a merge queue #12200 — the other platform-fact finding from this seat today (update_pull_requestun-drafts; a queued PR cannot be dequeued by converting to draft).