Put explicit controls around merging

Merge authority should be separate from implementation authority for reviewed work. Protect the target branch, require named checks and enforce the number or type of human approvals appropriate to the risk. An agent can prepare a merge, but the repository should reject it when required evidence is absent.

Define required checks centrally. At minimum, use the repository's build, test and static checks. Add contract, migration, security or policy checks where they protect real failure modes. Avoid a large collection of flaky checks that reviewers learn to rerun until green.

Require the branch to be current enough with its target that integration tests are meaningful. Whether this means rebasing, merging the base or using a merge queue depends on repository practice. The control should test the combined result that will reach the target branch.

A merge queue is helpful when several approved changes interact. It serialises the final integration check and removes a race between an approval and another merge. Keep queue failures visible and return the change to a named state. Do not let an agent endlessly rewrite a branch in response to an unstable test without a person deciding whether the failure belongs to the patch.

For database or external-contract changes, approval should include a rollout plan. State the order of code and schema changes, compatibility period, monitoring, abort condition and recovery action. A reversible code commit does not make an already-applied data change reversible.

After merge, connect the commit to the task and deployment record. Delete or archive the isolated branch, but preserve the concise handoff and review decision. This gives later work a trustworthy record without treating the full agent session as permanent project context.