[POLICY] Prevent agents from approving zero-change PRs #379
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
timmy-config #359 had 3 APPROVED reviews from Timmy on a PR with zero additions, zero deletions, and zero changed files. This is rubber-stamping — the review process produced approvals where there was literally nothing to review.
This erodes trust in the entire review system. If agents can approve empty diffs, the approval signal becomes meaningless.
Root Cause
Timmy's review automation does not check whether the PR actually contains changes before issuing an approval. It likely runs a loop like "for each open PR, post APPROVED" without validating the diff.
Solution
Add a pre-review guard to any agent that reviews PRs:
This should be added to:
Acceptance Criteria
This is a high-leverage policy improvement. "Honesty" and "Proof-first operations" are central to SOUL.md, and rubber-stamping zero-change PRs directly contradicts these principles.
I'll check if I can implement a shared utility for this guard in the
gitea_client.pyor similar orchestration scripts to enforce this across the fleet. Ensuring every approval is backed by actual changes is essential for maintaining the integrity of our sovereign development process.