Put clear controls around merging

For reviewed work, the authority to merge should sit apart from the authority to implement. Protect the target branch, require named checks and enforce whatever number or type of human approvals the risk calls for. An agent can get a merge ready, but the repository should refuse it if the required evidence isn't there.

Define the required checks in one central place. At a minimum that's the repository's build, test and static checks. Add contract, migration, security or policy checks where they protect against failures that can really happen. Avoid a pile of flaky checks that reviewers learn to rerun until green.

The branch needs to be close enough to its target that integration tests mean something. Whether you get there by rebasing, merging the base in or using a merge queue depends on how the repository already works. Either way, it should test the combined result that will land on the target branch.

A merge queue helps when several approved changes interact. It runs the final integration check one change at a time and gets rid of the race between one approval and someone else's merge. Keep queue failures visible and send the change back to a named state. Don't let an agent keep rewriting a branch to chase an unstable test without a person deciding whether that failure is actually the patch's fault.

For database or external contract changes, approval should come with a rollout plan. It should cover the order of code and schema changes, the compatibility period, monitoring, the abort condition and the recovery action. Being able to revert the code commit doesn't undo a data change that's already been applied.

After the merge, link the commit to the task and the deployment record. Delete or archive the isolated branch but keep the short handoff and the review decision, so later work has a record it can rely on without treating the full agent session as permanent project context.