Development record
The main ruleset requires a pull request to be up to date with its base before its checks count, and the merge queue already provides that guarantee by building each entry on top of the queue ahead of it; keeping both means every merge invalidates every open branch, so an autonomous run had to run scripts/pr-keep-current.sh after each of eleven merges and a peer session's overnight merges churned every branch this run held. GitHub's own guidance says the queue removes the need for the up-to-date requirement. Worth deciding whether the strict requirement still earns its place (iss-172 argued it gates a duplicate record id, which the timestamp mint since made moot).
The main ruleset requires a pull request to be up to date with its base before its checks count, and the merge queue already provides that guarantee by building each entry on top of the queue ahead of it; keeping both means every merge invalidates every open branch, so an autonomous run had to run scripts/pr-keep-current.sh after each of eleven merges and a peer session's overnight merges churned every branch this run held. GitHub's own guidance says the queue removes the need for the up-to-date requirement. Worth deciding whether the strict requirement still earns its place (iss-172 argued it gates a duplicate record id, which the timestamp mint since made moot).
Grounds
- declined: the strict rule stays and the branch update is automated instead; this would be wrong if that 2026-09-01 ruling were reversed
Frontmatter
| id | iss-2609020716561070 |
|---|---|
| type | issue |
| lifecycle | wontfix |
| severity | minor |
.abcd/work/issues/wontfix/iss-2609020716561070-the-main-ruleset-requires-a-pull-request.md
open on GitHub ↗ · commit history ↗
mentions2
- 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.
- iss-2609181223354098A push to a pull request after auto-merge is armed on a merge queue can be dropped silently, and the bundled COMMITTING rules do not say so. Reported from the Gropius managed repository on 2026-09-18 (its own ledger carries it under its own id): with auto-merge armed and the entry already queued, a later push to the branch was not what the queue merged; the repository lost two commits and re-landed them in a second pull request. The failure is the forge's, not abcd's: a queue builds its entry from the head it took at enqueue time, and a push after that either removes the entry (to be re-armed) or, when the entry is already merging, lands nothing, and the pull request's merged state looks the same either way. The lesson is portable to every managed repository whose ruleset routes through a queue, which is why the session asked for a line in the bundled COMMITTING domain: after arming auto-merge on a queue, do not push again; if a push is needed, disarm first, push, re-arm, and confirm the merged sha contains the last local commit before deleting the branch. Sibling of iss-172 (queued entries left BEHIND) and iss-2609020716561070 (the up-to-date requirement beside a queue); this one is the dropped push, which neither covers. Recorded as a process observation; the routing (a COMMITTING rule, a line in the intake runbook, or both) is the product thinker's.