⛔ Filed bare and ungraded by the domain:spec execution seat, session session_01KB5PFtxuy1x3dcR5gxudx6, 2026-09-16T11:5xZ. domain:*, type and priority are triage's. ⛔ Not claimed, ⛔ not dispatched. Routes to whichever lane owns .claude/skills/pm-dispatch/references/platform-readings.md.
Dedupe keywords: gh-readonly-queue, merge queue order, queue ref parent sha, PR sitting in queue, dropped vs queued behind.
The refinement
The existing fact-table row says the gh-readonly-queue/* refs are positive-only — they answer BUILD, not membership, and an absent ref is only corroborating evidence. That stays true. ⭐ What is not recorded is that when the refs ARE present they carry more than presence: each ref name embeds the sha of the commit it is stacked on, so the whole queue ORDER is reconstructable from git ls-remote alone.
Measured 2026-09-16T11:51Z, git ls-remote --heads origin 'gh-readonly-queue/*':
3ab1508160 refs/heads/gh-readonly-queue/main/pr-18433-24646d44bd…
24646d44bd refs/heads/gh-readonly-queue/main/pr-18444-66abef3fde…
c2815a2023 refs/heads/gh-readonly-queue/main/pr-18445-2502b8a101…
2502b8a101 refs/heads/gh-readonly-queue/main/pr-18448-3ab1508160…
Pair each ref's own sha against the sha inside the NEXT ref's name and the stack falls out, with origin/main at 66abef3fde as its root:
main 66abef3fde
└─ pr-18444 -> 24646d44bd
└─ pr-18433 -> 3ab1508160
└─ pr-18448 -> 2502b8a101
└─ pr-18445 -> c2815a2023
Why a seat needs this
Without it, a PR that sits in the queue is ambiguous: dropped, or simply behind others? The pull_request object does not say — measured on #18433 at 11:51Z it reads state=open merged=false mergeable=null mergeable_state=unknown auto_merge=false, which is the same shape a dropped PR would show. auto_merge is false because it clears on enqueue (already in the fact table), so it discriminates nothing here either.
This reading answers it in one command: #18433 had been queued 19 minutes with origin/main unmoved, and the refs show it second of four, behind #18444. ⇒ nothing was wrong, and no re-queue was owed. Guessing the other way — re-enqueueing a PR that is merely waiting — is the expensive mistake this prevents.
⛔ What this does NOT change
Absence still proves nothing (the standing row). The pull_request.enqueued webhook remains the instrument that answers membership affirmatively. This adds one thing only: when the refs are there, read the names, and you get the order for free.
Shape, ⛔ offered not specified
One row beside the existing queue-ref row, with the pairing recipe and the caution that it is still positive-only.
Generated by Claude Code
⛔ Filed bare and ungraded by the
domain:specexecution seat, sessionsession_01KB5PFtxuy1x3dcR5gxudx6, 2026-09-16T11:5xZ.domain:*, type and priority are triage's. ⛔ Not claimed, ⛔ not dispatched. Routes to whichever lane owns.claude/skills/pm-dispatch/references/platform-readings.md.Dedupe keywords:
gh-readonly-queue,merge queue order,queue ref parent sha,PR sitting in queue,dropped vs queued behind.The refinement
The existing fact-table row says the
gh-readonly-queue/*refs are positive-only — they answer BUILD, not membership, and an absent ref is only corroborating evidence. That stays true. ⭐ What is not recorded is that when the refs ARE present they carry more than presence: each ref name embeds the sha of the commit it is stacked on, so the whole queue ORDER is reconstructable fromgit ls-remotealone.Measured 2026-09-16T11:51Z,
git ls-remote --heads origin 'gh-readonly-queue/*':Pair each ref's own sha against the sha inside the NEXT ref's name and the stack falls out, with
origin/mainat66abef3fdeas its root:Why a seat needs this
Without it, a PR that sits in the queue is ambiguous: dropped, or simply behind others? The
pull_requestobject does not say — measured on #18433 at 11:51Z it readsstate=open merged=false mergeable=null mergeable_state=unknown auto_merge=false, which is the same shape a dropped PR would show.auto_mergeis false because it clears on enqueue (already in the fact table), so it discriminates nothing here either.This reading answers it in one command: #18433 had been queued 19 minutes with
origin/mainunmoved, and the refs show it second of four, behind #18444. ⇒ nothing was wrong, and no re-queue was owed. Guessing the other way — re-enqueueing a PR that is merely waiting — is the expensive mistake this prevents.⛔ What this does NOT change
Absence still proves nothing (the standing row). The
pull_request.enqueuedwebhook remains the instrument that answers membership affirmatively. This adds one thing only: when the refs are there, read the names, and you get the order for free.Shape, ⛔ offered not specified
One row beside the existing queue-ref row, with the pairing recipe and the caution that it is still positive-only.
Generated by Claude Code