Opt-in, conditional auto-approval (off by default)

[IsmaelMartinez]

The FAQ lists "won't approve PRs" as a safeguard, and #3780 was closed on that basis. I'd like to test whether an approval gate can keep the intent of that safeguard (the developer stays in the driver's seat) while being useful to teams that want it.

Proposal. auto_approval.enabled = false by default. When a team turns it on, /review approves only if every condition holds, all evaluated in code:

• estimated effort ≤ max_effort (default 1)
• no security concerns, and a single PR theme
• CI green on the head commit
• no changed file matches a deny list (default: CI config, IaC, dependency manifests and lockfiles, migrations, deploy config)
• changed lines ≤ max_changed_lines

It approves only and never merges. Each run posts which conditions passed or failed. Approval is withdrawn on a new push. merge_recommendation is never used on its own.

Why these conditions. Our organisation measured about 8,000 merged PRs and 1.5% needed a later fix or revert. Within an effort-1 lane, 0.8% did, all affecting test environments only. Every one of those changed dependency or deploy files, which is why the deny list defaults include them. The model's own verdict carried almost no signal, so it is not used on its own.

Scope. Start with GitLab (mr.approve()). GitHub already implements auto_approve(). FAQ item 3 would become "won't approve PRs unless you explicitly opt in to a conditional gate".

Question for the other maintainers and the community: is an opt-in gate like this acceptable for the project, or should approval stay out of scope? If it's acceptable, I'll write it up as an issue for contributors.

@naorpeled @ofir-frd @DanaFineTLV

[IsmaelMartinez]

@naorpeled, a TL;DR with the numbers: https://claude.ai/artifact/KmZHwEYumEENuX9D78wXkm

• merge_recommendation becomes a verdict computed in code: hard checks on facts (green CI, not stale, human authors, no sensitive path, no risky change shape such as a signature, cache or migration change, a size cap) decide, and the model can only veto. Opt-in auto-approval acts on no_concerns_found, approves that commit, never merges, and is removed on push.
• On all 1,307 PRs merged here June to October, 32 later needed a fix. With every check on, none of the 32 would have been approved, and about 13% of merges would have been.

Is this acceptable here, and should approval live upstream or only the status?

[IsmaelMartinez]

Filed the pieces as separate issues so they can be picked up independently, in roughly this order:

• Harden the auto-approval path before it is re-enabled #4693 Harden the auto-approval path before it is re-enabled (pin the reviewed commit, make the flag host-only)
• Expose head CI status and staleness through the provider interface #4694 Expose head CI status and staleness through the provider interface
• Deterministic risk checks: default sensitive paths and risky-change shapes #4695 Deterministic risk checks: default sensitive paths and risky-change shapes
• Compute merge_recommendation from deterministic checks; the model can only veto #4696 Compute merge_recommendation from deterministic checks; the model can only veto
• Publish the review verdict as a status on the reviewed commit #4697 Publish the review verdict as a status on the reviewed commit
• Opt-in approval of the reviewed commit when the computed verdict is clean #4698 Opt-in approval of the reviewed commit when the computed verdict is clean
• Document the approval verdict, its checks and the opt-in approval #4699 Document the approval verdict, its checks and the opt-in approval

Nothing approves until #4698, and that stays off by default and host-only. The reasoning and numbers are here:
https://claude.ai/artifact/KmZHwEYumEENuX9D78wXkm