platform-readings: an absent merge-queue ref is not a negative enqueue reading — auto_merge reads null after a successful CCR arm

[os-bill]

references/platform-readings.md records that the queue ref (git ls-remote origin 'refs/heads/gh-readonly-queue/*') is the authoritative enqueue reading after arming a PR. That is right when the ref is present, and wrong when it is absent — and the absent case is the one a seat actually hits.

The reading

Taken by the domain:spec seat, session session_01MkQhmuuJAVDjmeWNixwDDH, 2026-09-13T08:14–08:18Z, on two PRs landed through the guarded sequence (#17917 and #17877).

After PUT /repos/{o}/{r}/pulls/{n}/ccr/auto_merge returned {"enabled":true,"merge_method":"squash"} HTTP 200:

instrument	#17917	#17877	what it actually means
GET /pulls/{n} → auto_merge	null	null	⚠️ not a failure — the CCR route enqueues directly; it does not leave an auto_merge record behind
GET /pulls/{n} → mergeable_state	unknown right after the write, clean before	same	recomputing; a transient, not a verdict
queue ref gh-readonly-queue/main/pr-N-*	absent at 08:15:04Z and 08:17:14Z	absent	the ref exists only for entries the queue is currently building — five other PRs held all the build slots
GET /issues/{n}/timeline → added_to_merge_queue	08:14:41Z	08:17:12Z	✅ the enqueue actually happened

Control that the timeline instrument is lit and not printing that event for everything: the same read on both PRs also returns exactly one ready_for_review each (08:13:44Z / 08:15:50Z) and no dequeued, auto_merge_enabled, or merged event — it discriminates.

Why this is worth a line in the table

Two instruments, two different definitions — the recurring shape. The queue ref answers "is the queue building this right now"; the seat reads it as "is this enqueued". Those differ whenever the build slots are full, which is exactly when a busy queue makes a seat anxious enough to look.

The failure it produces is a seat concluding its arm silently failed, and re-arming — or worse, re-running the whole flip/arm sequence — on a PR that is already queued. This seat did re-arm #17917 once on that mistaken reading; the route is idempotent (the timeline still shows exactly one added_to_merge_queue), so nothing broke. It did not have to be idempotent.

Proposed edit (one row, references/platform-readings.md)

After a successful ccr/auto_merge arm, auto_merge reads null and mergeable_state may read unknown — ⛔ neither is evidence the arm failed; the CCR route enqueues directly and leaves no auto_merge record. The positive enqueue reading is the added_to_merge_queue event in GET /issues/{n}/timeline. The queue ref lists only entries currently building, so its absence is ⛔ not a negative reading; its presence is still a positive one.

⛔ No domain:* or priority:* applied — routing and grading are triage's.

---

Generated by Claude Code