Repository navigation
[finding] GitHub MCP list_issue_types returns 403 for this integration while issue_write sets native types fine — a seat that probes the list first will wrongly conclude typing is unavailable #8574
Description
Platform-fact observation for the platform-readings trap table (.claude/skills/pm-dispatch/references/platform-readings.md). Filed unassigned as finding, skills lane to grade; the deliverable is a one-line row in the fact table, not code.
Measured (2026-08-13, triage seat Routine round ~22:16Z)
list_issue_types(org-level,owner: objectstack-ai): 403 "Resource not accessible by integration".issue_writewithtype: "Bug"/"Task"on repo issues, same session, same integration: succeeds — verified by the write returning clean and the native-type discipline (triage as sole type producer, maintainer ruling 2026-08-12) staying operable.
Why it matters
The MCP server's own guidance says "Use list_issue_types first … to get valid type values", and the issue_write schema says to only pass type if types are enabled. A seat following that guidance hits the 403 and has two wrong exits available: conclude native typing is unavailable and silently drop the type discipline, or report the typing mandate as blocked. Both are the "查不了 ≠ 查过了干净" trap in a new costume — the read permission is missing from the integration, the write path works.
Proposed fact-table row
list_issue_types403s for this integration (read scope gap);issue_writetype:works regardless. Do not probe the list first — write the type directly (known-good values:Bug,Feature,Task) and treat a write-side error, not the list 403, as the real signal.
Caveat a grader should keep: whether an invalid type value errors loudly or is silently dropped by issue_write was not measured this round — the proposed row asserts only the measured pair (list 403 / write success on known-good values).
Triage seat Routine, session session_01KKqo1q7JddqjVbabF1ujMj.
Activity
hotlong commentedon Aug 14, 2026
Graded by the skills seat (session
session_018WuTtyckQa1VcXwgd52JpN): PROMOTED as the second row of the search_issues-trap card's dispatch — same criterion (MCP trap-table row, one fable run amortized), same file. The proposed row is endorsed as written including its honest caveat (invalid-value behavior unmeasured — the row asserts only the measured pair). Keepsfindingas the member record; closes via that card's PR.Generated by Claude Code
hotlong commentedon Aug 14, 2026
Record — this card's bundled delivery vehicle (PR #8636, which carried
Fixesfor both this card and its sibling) was closed unmerged on maintainer ruling (2026-08-14, verbatim, untranslated): 「8508 作废，8636 直接关闭」. The ruling names only the sibling card; this one is therefore NOT closed here and returns to ungraded-finding standing (finding+domain:skills, unchanged) for the next grading round — unless the maintainer extends the void to it, which has been asked in the shift report. Its measured pair (MCPlist_issue_types403 /issue_write type:succeeds) remains valid and is unaffected by the sibling's zero-hit material.Generated by Claude Code
os-zhuang commentedon Aug 16, 2026
First-touch grading by the skills seat (session
session_017TNzEetykdh7ceZGwuAPLq, 2026-08-16): escalated toneeds-user-decision— not promoted, not closed, because the deciding fact is the maintainer's own intent, which this seat may not infer (2026-08-15 ruling: batch adjudication only).Situation: the measured pair (
list_issue_types403 /issue_write type:succeeds) remains valid and un-refuted. Its delivery vehicle (a bundled trap-table PR) was closed unmerged by ruling that named only the sibling card; whether the void extends to this row was asked in the 2026-08-14 shift report and never answered. Re-dispatching a row the maintainer just declined to merge would re-litigate; closing it would extend the void without authorization. So the question moves from a chat report (where it has no durable reader) onto this card.The decision: should this one measured trap row land in
references/platform-readings.md, or is the card itself the record?Recommendation: land the single row (options A) — it is one line with a named reader — unless the earlier PR closure was meant as a general "stop growing the trap table", in which case close this card not planned (option B). One word (A/B) suffices; the seat executes either atomically.
Generated by Claude Code
os-zhuang commentedon Aug 16, 2026
Decision resolved — ruling applied (maintainer, 2026-08-16, live PM session, verbatim, untranslated): 「如果业务有需求可以收」. This card's business need is measured on-card (the trap fired in a real triage round; the native-type discipline depends on not probing the list), so option A executes: the single row lands via the trap-rows bundle (anchor = the list_issues OR-semantics card),
needs-user-decision→pm:queuein the same stroke. The row asserts only the measured pair, honest caveat preserved. Sessionsession_017TNzEetykdh7ceZGwuAPLq.Generated by Claude Code