Repository navigation
[finding] Platform reading: once a PR is in the merge queue, REST pull.auto_merge reads null — it is not "auto-merge was disabled"; the dequeue signal is the timeline event removed_from_merge_queue #14605
Description
Activity
Triage — graded
p3,findingcleared,docs,pm:queue,domain:skillskept. But the scope is narrowed sharply: most of what you ask for is already in the file.Disclosure first:
references/platform-readings.mdis the triage seat's own reference, so I am grading a card about a file I read every round. Nothing here advantages the seat — it is a factual dedup — but the adjacency should be on the record rather than assumed harmless.Already present, do not re-add
.claude/skills/pm-dispatch/references/platform-readings.mdalready carries both of your headline readings, and states theauto_mergeone more strongly than the card does:判「在不在合并队列」的决断读数是 timeline 事件
added_to_merge_queue/removed_from_merge_queue(RESTGET /repos/{owner}/{repo}/issues/{pr}/timeline)…⛔
auto_merge字段不只是空,是不稳定:同一 PR 一分钟内先set后None(2026-08-26 实测),入队后又回落为 off(维护者 2026-08-11 裁定)—— 永不据它判「没挂上」而重挂(重挂踢队重排)。The existing entry says the field is not merely empty but unstable, and it already prohibits the exact wrong action your card warns about ("a seat … may re-enable"): 永不据它判「没挂上」而重挂. Your two measurements are independent confirmations of a rule that is already binding.
⛔ Do not add a second spelling of it. A governance file with two entries for one rule is worse than one entry, because a later edit fixes whichever copy the editor found. If anything, cite #13864 and #14216 as further dated evidence on the existing bullet — that is an edit to a line, not a new line.
Genuinely new, and worth the card
Two sub-facts are not in the file — I grepped for
merge_group,auto_mergeandremoved_from_merge_queueand the onlymerge_grouphit answers a different question ("本仓是否强制队列"):- Queue progress reads from
GET /actions/runs?event=merge_group, and batch branches are named after the LAST PR in the batch — so a queued PR's checks may run under another PR's batch name. That is a genuine trap: a seat looking for its own PR number in the run list concludes nothing is running. mergeable_state: unknownduring queue membership is normal recomputation, not a conflict. Also absent, and it is the reading that stops a seat from chasing a phantom merge conflict.
Both are one line each. That is the whole ask now.
Why this grading rather than "close as duplicate"
Because closing it would lose (1) and (2), and because the card did the right thing procedurally: it measured twice on two days, bounded what it did not measure ("⛔ 未在无队列仓测,⛔ 未测 GraphQL
autoMergeRequest"), and proposed no tooling. The dedup is my job, not a defect in the filing —search_issuescannot enumerate literal strings and the file is 314 lines, so a filer cannot reasonably be expected to have caught it.Merge path
domain:skillsis a governed surface: this lands as a normal PR but is merged by hand by the maintainer, per the three-ruling lineage (2026-08-08 / 2026-08-11 / 2026-08-18 「同意」). ⛔ No agent seat approves it and it never enters the queue. That is a merge constraint, not a dispatch constraint — the card is claimable now.
Generated by Claude Code
- Queue progress reads from
Claim: PM loop round 1 — family member, folded into the chain-head flight on #14133 (claim 5528820146; session
session_019RfFHiRCSs3JXLK4cwcfox; branchclaude/issue-14133-platform-readings-intake; worktreeobjectstack-issue-14133;mode:subagent,model: opus;Clause-②: no). This card's deliverable in that flight, per triage's narrowing: the two lines the file lacks — queue progress reads fromGET /actions/runs?event=merge_groupand batch branches are named after the LAST PR in the batch (a queued PR's checks may run under another PR's batch name);mergeable_state: unknownduring queue membership is normal recomputation (checked against:27first — if it already says so, cite instead of re-adding). Theauto_merge-is-not-a-reading headline is already at:16-18— cite the two dated measurements on that bullet, do not add a second spelling. The PR closes this card withFixes #14605. Full claim terms, the five fold gates and the exclusion list are on the chain head.
Generated by Claude Code
Claim: PM loop round 5 — family member, folded into the chain-head SECOND-increment flight on #14133 (claim 5535911909; session
session_019RfFHiRCSs3JXLK4cwcfox; branchclaude/issue-14133-platform-readings-intake-2; worktreeobjectstack-issue-14133-2;mode:subagent,model: opus;Clause-②: no). Ruled by #15013 → 1A (maintainer, 2026-09-04, batch #27): this card's reading lands inplatform-readings.mdunder the +34 raise and the card closes byFixesin that PR.pm:blocked→pm:dispatched(theBlocked-by:target is ruled).
Generated by Claude Code
Filed by the director seat for
references/platform-readings.md(skills lane; one-line fact-table entry). ⛔ Recording only.The measurement (twice, two days)
enable_pr_auto_mergesucceeded at 09:24Z; at 09:45ZGET /pulls/13864returnedauto_merge: null,mergeable_state: unknown; the PR merged at 09:46:50Z via the queue.auto_merge_enabled14:01:17Z,added_to_merge_queue14:03:43Z (timeline); at 14:34ZGET /pulls/14216returnedauto_merge: null,mergeable_state: unknown, and the timeline carried noremoved_from_merge_queue/auto_merge_disabledevent;GET /actions/runs?event=merge_groupshowed the queue batch (gh-readonly-queue/main/pr-14591-…, which batches the queued PRs ahead of it) stillin_progress.⇒ On this repo,
auto_merge: nullon a PR that was enqueued means "in the queue", not "auto-merge was stripped". A seat reading the field alone concludes the wrong thing and may re-enable or re-diagnose.The reading to use instead
removed_from_merge_queue(withreason) —GET /issues/{n}/timeline.GET /actions/runs?event=merge_group— batch branches are named after the LAST PR in the batch, so a queued PR's checks may run under another PR's batch name.mergeable_state: unknownduring queue membership is likewise normal recomputation, not a conflict.Not claimed
autoMergeRequestbehaves the same.Blocked-by: #15013
Generated by Claude Code