Surfaced 2026-08-01 by @tobiu after I lost a commit to this, and filed at his direction as the follow-up.
I pushed a spec commit to ticket-16253 and told two peers it was on PR #16255 with CI green. It was neither. The PR had merged three minutes earlier, and a merged PR does not accept further commits — the branch ref advanced, the PR did not follow, and no CI ever ran on that commit. I then repeated the false claim in two A2A messages before catching it.
Everything below is observed; the prescription in The Fix is inference and is marked as such.
Live latest-open sweep: latest 20 open issues at 2026-08-01T11:40:01Z. Search sweep for an existing push-guard ticket returned no equivalent (nearest neighbours are #13652 mechanical-enforcement epic and #12964 deploy automation — neither covers this). No A2A [lane-claim] on push tooling.
The Problem
Pushing to a branch whose PR is already merged succeeds, silently, and reaches nothing.
The failure is quiet in a specific way that defeats the obvious checks. Three instruments all returned true answers to a question I was not asking:
Instrument
Reported
What it actually answered
git push
Everything up-to-date
the ref matches the local commit
git ls-remote origin <branch>
93e6078… refs/heads/ticket-16253
the ref did move, server-side
gh pr checks <n>
all green, watcher exit 0
checks belonging to the previous SHA
The ref genuinely advanced. The PR was simply no longer listening. gh pr checks never names the SHA it inspected, so a green result reads as "green on what I just pushed" when it may be green on something else entirely.
What eventually exposed it was unrelated: git rebase origin/dev printed "skipped previously applied commit ddf522a6fe" — the rebase knew the work was already merged when three direct queries had not said so.
Why this deserves mechanical treatment rather than discipline. The window between "peer approves" and "operator merges" is now routinely under a minute (35 seconds in this case). Any agent that pushes a follow-up commit after requesting review — addressing a nit, adding a spec, fixing a lint — can land inside that window. The result is not a lost commit alone; it is a confidently false claim to peers, because every check the author runs says success. One reviewer was seated on an already-merged PR and spent context on it.
The Architectural Reality
buildScripts/util/agent-push.mjs — the sanctioned agent push wrapper (npm run agent-push), which already parses the refspec surface and already emits advisory warnings at push time. It printed a branch-staleness advisory during this very incident, so the advisory channel exists and is proven to reach the author.
buildScripts/util/branchFreshness.mjs — the existing two-dot staleness check that backs that advisory. The natural sibling for a merged-PR check.
buildScripts/util/check-branch-discipline.mjs — related branch-hygiene enforcement.
The guard needs one fact GitHub already exposes: whether an open PR exists for the branch, and if not, whether a merged one does.
Existing precedent matters here: the wrapper's staleness warning is advisory and non-blocking (This is advisory — the push proceeds). A merged-PR push should follow the same shape unless there is reason to be stricter.
The Fix
(Prescription — inference, not observation.)
Extend the agent-push wrapper: before pushing, resolve the branch's PR state. If the branch's most recent PR is MERGED and the push would advance the ref beyond that PR's merge commit, warn loudly and name the consequence — "PR #N for this branch merged at
Two properties any implementation should keep:
Fail toward pushing. If PR state cannot be resolved — offline, rate-limited, no gh auth, branch never had a PR — proceed with the push. A false block is worse than a false warning, and this mirrors the existing staleness advisory's stance.
Name the SHA and the remedy, not just the condition. The author's next question is always "so where did my commit go?" The warning should answer it in the same breath: the commit is on the branch, it is in no PR, and the fix is a fresh branch off origin/dev.
Worth considering but explicitly not prescribed here: whether gh pr checks should refuse to report green when the PR head differs from the local HEAD. That is a different tool and a separate decision.
warn when the branch's latest PR is MERGED and the push advances past its merge commit
fail toward pushing — unresolvable PR state, no auth, or no PR ever ⇒ silent proceed
in-wrapper message naming SHA + remedy
pushing a commit to a branch with a merged PR prints the warning; pushing to a branch with an open PR does not
Decision Record impact
none. This adds an advisory to existing push tooling; it changes no branch or merge policy.
Acceptance Criteria
Pushing a new commit to a branch whose PR is MERGED emits a warning naming the PR number, its merge time, and that the commit reaches no PR and no CI.
The warning states the remedy — branch fresh from origin/dev under a follow-up ticket.
Pushing to a branch with an open PR emits nothing (no new noise on the common path).
Pushing to a branch that never had a PR emits nothing.
Unresolvable PR state — no network, no gh auth, API error — proceeds silently, with a test that fails if the fallback is ever flipped to blocking.
The push still proceeds in every case; this is advisory, matching the existing staleness warning.
Out of Scope
Blocking the push. The existing advisory precedent is non-blocking and this should not be the first guard to diverge without a reason.
Changing gh pr checks behaviour, or any wrapper that hides which SHA was checked. Real, adjacent, separable.
The container-image staleness problem raised in the same conversation — the running Agent OS containers do not receive merged code. Genuinely serious (14 merged PRs currently absent from the running Brain) but a different subsystem with its own ideation home; see Related.
Auto-creating the follow-up ticket or branch. Warn, do not act.
Avoided Traps
Assuming the push failed. It did not. The ref advanced correctly and every ref-level instrument confirms it. A guard that checks whether the push succeeded will find success and say nothing.
Trusting gh pr checks as evidence about a specific commit. It reports checks without naming their SHA. Green after a push is not evidence that the pushed commit was checked.
Treating this as author carelessness. The merge landed 35 seconds after approval; the author cannot reliably observe that window, which is exactly why it wants a mechanical check rather than a rule.
Blocking by default. A hard block on unresolvable PR state would strand any agent pushing offline or rate-limited.
Related
PR #16255 / #16253 — the incident; merged at ad76ede9bf 11:27:27Z, spec pushed ~11:30
#13652 — mechanical-enforcement epic; this is the same philosophy (replace discipline with a hook) at a much smaller scale
#16193 (Discussion) — Docker-canonical provisioning / IaC, the existing home for the container-staleness half noted in Out of Scope
Context
Surfaced 2026-08-01 by @tobiu after I lost a commit to this, and filed at his direction as the follow-up.
I pushed a spec commit to
ticket-16253and told two peers it was on PR #16255 with CI green. It was neither. The PR had merged three minutes earlier, and a merged PR does not accept further commits — the branch ref advanced, the PR did not follow, and no CI ever ran on that commit. I then repeated the false claim in two A2A messages before catching it.Everything below is observed; the prescription in The Fix is inference and is marked as such.
Live latest-open sweep: latest 20 open issues at 2026-08-01T11:40:01Z. Search sweep for an existing push-guard ticket returned no equivalent (nearest neighbours are
#13652mechanical-enforcement epic and#12964deploy automation — neither covers this). No A2A[lane-claim]on push tooling.The Problem
Pushing to a branch whose PR is already merged succeeds, silently, and reaches nothing.
The failure is quiet in a specific way that defeats the obvious checks. Three instruments all returned true answers to a question I was not asking:
git pushEverything up-to-dategit ls-remote origin <branch>93e6078… refs/heads/ticket-16253gh pr checks <n>0The ref genuinely advanced. The PR was simply no longer listening.
gh pr checksnever names the SHA it inspected, so a green result reads as "green on what I just pushed" when it may be green on something else entirely.What eventually exposed it was unrelated:
git rebase origin/devprinted "skipped previously applied commit ddf522a6fe" — the rebase knew the work was already merged when three direct queries had not said so.Why this deserves mechanical treatment rather than discipline. The window between "peer approves" and "operator merges" is now routinely under a minute (35 seconds in this case). Any agent that pushes a follow-up commit after requesting review — addressing a nit, adding a spec, fixing a lint — can land inside that window. The result is not a lost commit alone; it is a confidently false claim to peers, because every check the author runs says success. One reviewer was seated on an already-merged PR and spent context on it.
The Architectural Reality
buildScripts/util/agent-push.mjs— the sanctioned agent push wrapper (npm run agent-push), which already parses the refspec surface and already emits advisory warnings at push time. It printed a branch-staleness advisory during this very incident, so the advisory channel exists and is proven to reach the author.buildScripts/util/branchFreshness.mjs— the existing two-dot staleness check that backs that advisory. The natural sibling for a merged-PR check.buildScripts/util/check-branch-discipline.mjs— related branch-hygiene enforcement.Existing precedent matters here: the wrapper's staleness warning is advisory and non-blocking (
This is advisory — the push proceeds). A merged-PR push should follow the same shape unless there is reason to be stricter.The Fix
(Prescription — inference, not observation.)
Extend the
agent-pushwrapper: before pushing, resolve the branch's PR state. If the branch's most recent PR is MERGED and the push would advance the ref beyond that PR's merge commit, warn loudly and name the consequence — "PR #N for this branch merged atTwo properties any implementation should keep:
ghauth, branch never had a PR — proceed with the push. A false block is worse than a false warning, and this mirrors the existing staleness advisory's stance.origin/dev.Worth considering but explicitly not prescribed here: whether
gh pr checksshould refuse to report green when the PR head differs from the local HEAD. That is a different tool and a separate decision.Contract Ledger Matrix
agent-pushpre-push advisorybuildScripts/util/agent-push.mjs, existing staleness-advisory precedentDecision Record impact
none. This adds an advisory to existing push tooling; it changes no branch or merge policy.Acceptance Criteria
origin/devunder a follow-up ticket.ghauth, API error — proceeds silently, with a test that fails if the fallback is ever flipped to blocking.Out of Scope
gh pr checksbehaviour, or any wrapper that hides which SHA was checked. Real, adjacent, separable.Avoided Traps
gh pr checksas evidence about a specific commit. It reports checks without naming their SHA. Green after a push is not evidence that the pushed commit was checked.Related
ad76ede9bf11:27:27Z, spec pushed ~11:30#13652— mechanical-enforcement epic; this is the same philosophy (replace discipline with a hook) at a much smaller scale#16193(Discussion) — Docker-canonical provisioning / IaC, the existing home for the container-staleness half noted in Out of ScopeOrigin Session ID:
713db0da-2239-44ea-ba5b-931be90d34fcRetrieval Hint:
query_raw_memories("push to merged branch silently reaches no PR agent-push advisory"), orbuildScripts/util/agent-push.mjs.