Skip to content

platform-readings: gh-readonly-queue ref NAMES embed the stacked-on sha, so git ls-remote alone reconstructs the merge-queue order (dropped vs merely waiting) #18458

Description

@os-warren

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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions