Measured from the domain:cli execution PM seat while re-deriving its own lane, 2026-09-17, on objectstack-ai/objectstack. ⛔ Filed unlabelled by domain — routing and grading are triage's.
The defect
references/rest-channel.md states, about the read channel a PM seat uses to size its lane:
✓ 按标签/状态列卡 GET /repos/{o}/{r}/issues?state=open&labels=a,b&per_page=N，labels= 是真 AND。
That is correct for REST. The MCP tool list_issues treats the same list as OR, and nothing anywhere says so. The two answers to the identical question differ by an order of magnitude.
Measured, both channels, same minute, same repo
| channel |
query |
result |
MCP list_issues |
labels: ["domain:cli", "pm:queue"] |
totalCount: 271, hasNextPage: true, rows spanning domain:skills, domain:spec, domain:engine, domain:devx, domain:services, repo:objectui, repo:hotcrm |
| REST, paged to a short page |
labels=domain:cli,pm:queue |
12 |
And the union, derived separately over REST so the arithmetic is checkable rather than asserted:
domain:cli 28
pm:queue 256
UNION(domain:cli, pm:queue) 272 ⇐ what an OR reading returns
domain:cli AND pm:queue 12 ⇐ what the seat asked for
⇒ the MCP figure is the union, not the intersection. (271 vs 272 is one card whose label moved between the two reads — this seat dispatched it in that window.)
⛔ Control that can fail
REST, AND of two mutually exclusive lane labels — `labels=domain:cli,repo:objectui` → 0
A real AND must answer zero there, and REST does. ⇒ the AND is not an artefact of a small population, and the OR reading is not an artefact of my pagination.
Why it is worth a card rather than a note
⭐ The wrong answer does not look wrong. It is a well-formed list of open issues, correctly labelled, in the right repo, sorted sensibly. A seat that reads it as "my lane's queue" gets a cross-lane union — 272 cards where 12 are its own — and every downstream count derived from it (how much work is queued, how many p1s, whether the lane is empty) is wrong in the same direction.
⚠️ It is the exact query the lane-derivation duty prescribes. The PM patrol's standing duty is 「Re-derive the lane single-label… Read totalCount AGAINST returned」 — and totalCount vs returned does not catch this: both figures are internally consistent for the union. The one check the discipline provides is blind to this particular wrongness.
⚠️ This seat hit it live. It had already stated to its maintainer that the lane's queue was empty, on a remembered list; re-deriving through MCP would have replaced one wrong answer with a differently wrong one. Only going back to the REST spelling produced the 12.
What is NOT claimed
- ⛔ Not claimed that the MCP server is wrong. OR may be its documented or intended semantics; this card does not assert which. What is measured is that the two channels answer the same query differently and that the repo's own channel reference describes only one of them.
- ⛔ Not measured: whether other MCP list/search tools carry the same divergence (
list_pull_requests, search_issues filters). One tool was measured; the rest were not, and ⛔ absence of a reading is not a reading of absence.
- ⛔ No remedy prescribed. Whether the fix is a line in
rest-channel.md, a wrapper, or a seat-side lint is the owning lane's call. The cheapest honest version is one sentence in the channel table saying the MCP equivalent is OR.
Dedupe: a semantic search for this shape returned 0 results; the same tool returned 139 on an adjacent query in the same session, so the zero is a reading and not a dead search.
Dedupe words: list_issues labels OR not AND · MCP lane derivation cross-lane union · labels= 真 AND · totalCount consistent for the wrong set · rest-channel MCP divergence.
Generated by Claude Code
Measured from the
domain:cliexecution PM seat while re-deriving its own lane, 2026-09-17, onobjectstack-ai/objectstack. ⛔ Filed unlabelled by domain — routing and grading are triage's.The defect
references/rest-channel.mdstates, about the read channel a PM seat uses to size its lane:That is correct for REST. The MCP tool
list_issuestreats the same list as OR, and nothing anywhere says so. The two answers to the identical question differ by an order of magnitude.Measured, both channels, same minute, same repo
list_issueslabels: ["domain:cli", "pm:queue"]totalCount: 271,hasNextPage: true, rows spanningdomain:skills,domain:spec,domain:engine,domain:devx,domain:services,repo:objectui,repo:hotcrmlabels=domain:cli,pm:queueAnd the union, derived separately over REST so the arithmetic is checkable rather than asserted:
⇒ the MCP figure is the union, not the intersection. (271 vs 272 is one card whose label moved between the two reads — this seat dispatched it in that window.)
⛔ Control that can fail
A real AND must answer zero there, and REST does. ⇒ the AND is not an artefact of a small population, and the OR reading is not an artefact of my pagination.
Why it is worth a card rather than a note
⭐ The wrong answer does not look wrong. It is a well-formed list of open issues, correctly labelled, in the right repo, sorted sensibly. A seat that reads it as "my lane's queue" gets a cross-lane union — 272 cards where 12 are its own — and every downstream count derived from it (how much work is queued, how many p1s, whether the lane is empty) is wrong in the same direction.
totalCountAGAINSTreturned」 — andtotalCountvsreturneddoes not catch this: both figures are internally consistent for the union. The one check the discipline provides is blind to this particular wrongness.What is NOT claimed
list_pull_requests,search_issuesfilters). One tool was measured; the rest were not, and ⛔ absence of a reading is not a reading of absence.rest-channel.md, a wrapper, or a seat-side lint is the owning lane's call. The cheapest honest version is one sentence in the channel table saying the MCP equivalent is OR.Dedupe: a semantic search for this shape returned 0 results; the same tool returned 139 on an adjacent query in the same session, so the zero is a reading and not a dead search.
Dedupe words:
list_issues labels OR not AND·MCP lane derivation cross-lane union·labels= 真 AND·totalCount consistent for the wrong set·rest-channel MCP divergence.Generated by Claude Code