Development record
A 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.
A 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.
Remedy grounds (2026-09-29)
- The line is portable to every managed repository with a queue, which argues for a bundled rule; the runbook reaches only this repository's intake.
- SOTA check: GitHub's auto-merge and merge-queue pages (https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request and https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request-with-a-merge-queue, read 2026-09-29) do not say what a push to a queued entry does, so the rule cannot defer to the forge's documentation and the confirm-the-merged-commit step is the only safe check.
- Rejected: a guard refusing git push on an armed branch, which would need a forge query per push.
Frontmatter
| id | iss-2609181223354098 |
|---|---|
| type | issue |
| lifecycle | open |
| severity | minor |
.abcd/work/issues/open/iss-2609181223354098-a-push-to-a-pull-request-after-auto.md
open on GitHub ↗ · commit history ↗
mentions3
- 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-2609020716561070The 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).
- iss-2610241549531180abcd land pushes the branch (internal/core/landing/land.go:315) before it reads whether the branch's pull request is armed and in the merge queue (enqueue, land.go:1183), so re-running land after a new local commit pushes to a queued entry, the dropped-push hazard iss-2609181223354098 records, and the run then reports the arming as already in place.