The agent split one logical change into two reviewable PRs: A introduced a shared helper, and B was the caller that used it. B targeted A's branch rather than main. Both carried green checks and an approving review, so the agent merged B first.

That order was the whole bug. CI had tested B against a synthetic merge of A and B, which is a combination that never reaches main while A stays open. Once B landed without the helper, main failed to compile on the very next run, and the green badge nobody questioned turned out to answer the wrong question.

Green on a sibling branch is not green on main

Continuous integration checks whether the declared base branch and the head branch combine cleanly. When a PR targets another PR's branch, the synthetic merge contains that sibling's diff. The result proves the two branches fit together; it says nothing about how the child behaves sitting on top of main alone.

The mergeable badge and the green suite describe a hypothetical tree. They do not guarantee that the diff survives when the parent shifts, gets reverted, or simply never lands in the shape the child was built against.

Why an agent walks into it

A review checklist usually asks whether tests pass and whether someone approved. It rarely asks which PR must land first. The agent reads a green run as permission to merge, treats the mergeable state as safety, and loses the ordering requirement once review comments force a rebase of the parent.

Stacked branches also look harmless in the UI: the child has its own reviewers, its own CI, and its own green dot. Nothing on that card says this PR depends on a sibling that is still open, so the dependency slips out of the written plan and into memory only.

Declare the order and gate the child on the parent

The cheap controls are explicit. Mark the stack in the PR body and use a label or field that names the parent, then put a merge gate on the child that refuses it until the parent is merged. Keep stacks short, because a long chain multiplies the places order can drift.

Run an integration check for the child against the real main tip, not just the sibling branch, and after the parent lands, let the child retarget main and re-run on the exact commit that would land. Merging parent-first instead of child-first removes most of the failure outright.

Green CI on a stacked child tells you these two branches combine, not that the child is safe on its own. How do you enforce merge order today, and who catches it when the agent picks the wrong PR?