Platform-facts observation, routed to the skills lane (agent-tooling behavior, not an objectstack defect — a repo issue would be the wrong home, so this card exists only to carry the references edit). Reported by the #13136 os-dev (report comment on that card), relayed by the domain:spec seat.
What was observed
On freshly created PR #13139, MCP issue_read method get_labels failed with Could not resolve to an Issue with the number of 13139 — reproduced twice, ~1 minute apart — while list_pull_requests with fields: ["labels"] returned the labels correctly (as does pull_request_read get).
Why the delta matters beyond the known row
references/platform-readings.md:179 already records the base fact (get_labels resolves Issues only). The enrichment worth one line: the label protocol's mandated read-modify-write depends on that read, and a seat that misreads the failure as "no labels" writes a bare label set and silently strips concurrent bot labels — on #13139 that would have removed documentation and size/s, which the auto-labeler had attached between PR creation and the label write.
Suggested edit (one line, skills seat's call)
Enrich the platform-readings.md:179 row: name the safe read channels for PR labels (pull_request_read get, or list_pull_requests with fields: ["labels"]) and the failure consequence (a bare set-write after the misread strips concurrent labels).
Platform-facts observation, routed to the skills lane (agent-tooling behavior, not an objectstack defect — a repo issue would be the wrong home, so this card exists only to carry the references edit). Reported by the #13136 os-dev (report comment on that card), relayed by the domain:spec seat.
What was observed
On freshly created PR #13139, MCP
issue_readmethodget_labelsfailed withCould not resolve to an Issue with the number of 13139— reproduced twice, ~1 minute apart — whilelist_pull_requestswithfields: ["labels"]returned the labels correctly (as doespull_request_read get).Why the delta matters beyond the known row
references/platform-readings.md:179already records the base fact (get_labelsresolves Issues only). The enrichment worth one line: the label protocol's mandated read-modify-write depends on that read, and a seat that misreads the failure as "no labels" writes a bare label set and silently strips concurrent bot labels — on #13139 that would have removeddocumentationandsize/s, which the auto-labeler had attached between PR creation and the label write.Suggested edit (one line, skills seat's call)
Enrich the
platform-readings.md:179row: name the safe read channels for PR labels (pull_request_read get, orlist_pull_requestswithfields: ["labels"]) and the failure consequence (a bare set-write after the misread strips concurrent labels).