Handover item from a domain:cli execution seat standing down. Filed under the platform fact change category of the離任 report contract (the other two being principle gaps and mechanizable items); this is not a "lessons learned" essay and asks for no prose in any skill file — the requested change is one row in the references/platform-readings.md reading-trap table.
The measured fact
The GitHub MCP list_issues tool's fields enum is:
number · title · body · state · user · labels · comments · created_at · updated_at · field_values
There is no assignee / assignees member, and assignees are absent from the response whether or not fields is passed. issue_read (method get) does return assignees.
Why it is a trap rather than a limitation
The PM loop's candidate rule is "open, unassigned, no needs-user-decision", and the prescribed cheap probe is a single whole-lane list_issues call. Those two do not compose: the query that the loop tells a seat to run cannot answer the question the loop tells it to ask. A claimed card and a free one are byte-identical in that response.
Concretely, this shift: a lane card read as pm:queue + domain:cli with nothing else on it, i.e. the exact shape of a dispatchable candidate. It was assigned. Only the full issue_read before claiming caught it, and it was one of the last cards checked — had the batch been picked in a different order, the seat would have claimed a card another account was already working.
The existing "assignee is not you ⇒ never touch it" rule is what saved it, but that rule is only reachable after a per-card read, and nothing in the listing step signals that the read is load-bearing rather than a formality.
Suggested row for the fact table
list_issues never returns assignees (no such fields member; absent from the response either way). A lane listing therefore cannot distinguish a claimed card from a free one — assignee status is only visible via issue_read. ⛔ Never treat a list_issues result as a candidate set; it is a shortlist, and every entry needs a full read before it can be claimed.
The wording is deliberately a reading rule, not advice: the failure is silent and looks exactly like success.
Related but deliberately not bundled
The same shift also found a lane card carrying pm:queuewhile assigned — a half-state that makes it simultaneously invisible to the dispatch view and falsely present in dispatchable inventory. That was reported on the card itself and is a state-machine hygiene matter, not a platform fact; it belongs to whoever owns that claim, not to this table row.
Handover item from a
domain:cliexecution seat standing down. Filed under the platform fact change category of the離任 report contract (the other two being principle gaps and mechanizable items); this is not a "lessons learned" essay and asks for no prose in any skill file — the requested change is one row in thereferences/platform-readings.mdreading-trap table.The measured fact
The GitHub MCP
list_issuestool'sfieldsenum is:There is no
assignee/assigneesmember, and assignees are absent from the response whether or notfieldsis passed.issue_read(methodget) does returnassignees.Why it is a trap rather than a limitation
The PM loop's candidate rule is "open, unassigned, no
needs-user-decision", and the prescribed cheap probe is a single whole-lanelist_issuescall. Those two do not compose: the query that the loop tells a seat to run cannot answer the question the loop tells it to ask. A claimed card and a free one are byte-identical in that response.Concretely, this shift: a lane card read as
pm:queue+domain:cliwith nothing else on it, i.e. the exact shape of a dispatchable candidate. It was assigned. Only the fullissue_readbefore claiming caught it, and it was one of the last cards checked — had the batch been picked in a different order, the seat would have claimed a card another account was already working.The existing "assignee is not you ⇒ never touch it" rule is what saved it, but that rule is only reachable after a per-card read, and nothing in the listing step signals that the read is load-bearing rather than a formality.
Suggested row for the fact table
The wording is deliberately a reading rule, not advice: the failure is silent and looks exactly like success.
Related but deliberately not bundled
The same shift also found a lane card carrying
pm:queuewhile assigned — a half-state that makes it simultaneously invisible to the dispatch view and falsely present in dispatchable inventory. That was reported on the card itself and is a state-machine hygiene matter, not a platform fact; it belongs to whoever owns that claim, not to this table row.