Development record
A pull request that goes BEHIND main under the strict ruleset never enqueues: the merge queue requires an up-to-date branch, and auto-merge armed on a PR that then falls behind waits forever without a word. The only recovery is scripts/pr-keep-current.sh, a forge update-branch that lives outside abcd; the pilot run hit it on its first lane (PR 647, update-branch at 23:37Z after a sibling merged) and every later lane was sequenced around it by hand. Nothing abcd prints at push or PR time names the condition, the remedy or the sequencing rule (one lane in the queue at a time when they share a file). Wanted: the launch or capture surface that opens a PR says the rule, and a verb or the keep-current script is reachable from the plugin surface, so an orchestrating agent does not learn it from a stalled queue.
A pull request that goes BEHIND main under the strict ruleset never enqueues: the merge queue requires an up-to-date branch, and auto-merge armed on a PR that then falls behind waits forever without a word. The only recovery is scripts/pr-keep-current.sh, a forge update-branch that lives outside abcd; the pilot run hit it on its first lane (PR 647, update-branch at 23:37Z after a sibling merged) and every later lane was sequenced around it by hand. Nothing abcd prints at push or PR time names the condition, the remedy or the sequencing rule (one lane in the queue at a time when they share a file). Wanted: the launch or capture surface that opens a PR says the rule, and a verb or the keep-current script is reachable from the plugin surface, so an orchestrating agent does not learn it from a stalled queue.
Evidence
- 2026-09-21, PR 652: the keep-current remedy has a second half. The forge's update-branch that brings a BEHIND pull request current DISARMS its auto-merge, so after the update the pull request sat CLEAN with every check green and no queue entry for fifteen minutes; nothing said so.
scripts/pr-keep-current.shnow re-arms after a successful update and prints what it did; the want above stands, since the sequencing rule and the condition are still learned from a stalled queue. - 2026-09-23, autonomous run A (second session): the forge clears a pull request's
autoMergeRequestwhen the pull request enters the merge queue, so a watcher keyed on that field reads a queue entry as a disarm.scripts/pr-keep-current.shselects the pull requests it watches by that field, so a queued pull request drops out of its watch and the loop can end on "no open pull request has auto-merge armed" while pull requests still sit in the queue. The signals that hold areisInMergeQueueand the RemovedFromMergeQueueEvent on the timeline.
Grounds
- declined: the finding is carried whole by iss-172; this would be wrong if iss-172 were closed without answering it
Frontmatter
| id | iss-2609211105011322 |
|---|---|
| type | issue |
| lifecycle | wontfix |
| severity | minor |
.abcd/work/issues/wontfix/iss-2609211105011322-a-pull-request-that-goes-behind-under.md
open on GitHub ↗ · commit history ↗
mentions1
- iss-172abcd-managed repos need PR-queue hygiene when branch protection requires up-to-date branches: a queued auto-merge PR whose base moved sits BEHIND forever because GitHub auto-merge never updates branches. Two delivery rungs per basics-built-in/SOTA-delegated: (1) protocol-level now — after arming auto-merge, poll mergeStateStatus and run gh pr update-branch on BEHIND (works with the agent's own token, CI triggers normally); (2) scaffolded CI later — abcd scaffolds an update-branch workflow into managed repos, which requires a PAT/GitHub-App secret because the default GITHUB_TOKEN's pushes do not trigger workflows (the recursion suppression trap), or points at a merge queue where the plan allows. Same scaffolding family as itd-93's release gate; same merged-work-hygiene family as itd-95.