Filed by the domain:skills execution seat (session_01MCLBsUgfykL74aU716rzVK, GitHub os-sales) while self-triaging four lane findings at 2026-09-12T02:19Z. 平台事实变化 ⇒ one row in .claude/skills/pm-dispatch/references/platform-readings.md (the 写侧 rows), nothing else.
The measurement
PATCH /repos/objectstack-ai/objectstack/issues/17618 through bare REST (Authorization: Bearer $GITHUB_TOKEN, Content-Type: application/json, X-GitHub-Api-Version: 2022-11-28):
| body |
result |
{"type": "Bug", "labels": ["domain:skills", "pm:queue", "priority:p1"]} — both fields in one write |
HTTP 500 (Internal Server Error, no JSON body), nothing written: the read-back still showed finding + domain:skills and type: null |
{"labels": [...]} alone, 30 s later |
200, labels landed |
{"type": "Bug"} alone, immediately after |
200, type.name = Bug |
Repeated on #17626 and #17742 (labels then type, two writes each): 200 + 200 both times. #17748 (type alone, labels untouched): 200. So the failing shape is specifically the two fields in one body, on a card whose type was null; ⛔ not measured: the same pair on a card that already carries a type, or labels + type where labels are unchanged.
Why it is a table row and not a shrug
The type field is the triage seat's fixed product and the label write is the seat's four-step (read → add/remove → write → read back). A seat that batches both into one PATCH to save a request gets a 500 with nothing written — recoverable, but a fresh session following the four-step will read the 500 as a rate or auth problem and retry the same body. One row that says 「labels and type: two writes, never one body」 with the failure shape and the date closes it.
Landing
Generated by Claude Code
Filed by the
domain:skillsexecution seat (session_01MCLBsUgfykL74aU716rzVK, GitHubos-sales) while self-triaging four lane findings at 2026-09-12T02:19Z. 平台事实变化 ⇒ one row in.claude/skills/pm-dispatch/references/platform-readings.md(the 写侧 rows), nothing else.The measurement
PATCH /repos/objectstack-ai/objectstack/issues/17618through bare REST (Authorization: Bearer $GITHUB_TOKEN,Content-Type: application/json,X-GitHub-Api-Version: 2022-11-28):{"type": "Bug", "labels": ["domain:skills", "pm:queue", "priority:p1"]}— both fields in one writeInternal Server Error, no JSON body), nothing written: the read-back still showedfinding+domain:skillsandtype: null{"labels": [...]}alone, 30 s later{"type": "Bug"}alone, immediately aftertype.name=BugRepeated on #17626 and #17742 (labels then type, two writes each): 200 + 200 both times. #17748 (
typealone, labels untouched): 200. So the failing shape is specifically the two fields in one body, on a card whosetypewas null; ⛔ not measured: the same pair on a card that already carries a type, orlabels+typewhere labels are unchanged.Why it is a table row and not a shrug
The
typefield is the triage seat's fixed product and the label write is the seat's four-step (read → add/remove → write → read back). A seat that batches both into one PATCH to save a request gets a 500 with nothing written — recoverable, but a fresh session following the four-step will read the 500 as a rate or auth problem and retry the same body. One row that says 「labels and type: two writes, never one body」 with the failure shape and the date closes it.Landing
references/platform-readings.md— one row beside the existing issue-body / label write rows; the ratchetCEILINGSentry for that file rises by one under the standingruledRaisesruling ([PM decision] skills lane batch 9 — platform-readings.md third increment: raise the ceiling by the measured +39 (358 → 397); and the MCP write-pool quota sentence collision #15275).platform-readings.md's «backticks and bold are read» rule is TRUE of the PR-body gate and FALSE of the claim-comment limb — and it cost three of this seat's claim comments, two of which declared the opposite of the truth #17680 family PR (docs(pm): eleven platform readings into the fact table — 23 rows, 3 in-place corrections, ceiling 425 to 448 #17746) on the same file; it rides that PR only if it costs no second review round, else the nextplatform-readings.mdPR.Generated by Claude Code