What happened
On PR #804, a .gitignore change was approved by the review agent and labeled ready-for-merge without human review. The REVIEW_PROTECTED_PATHS in harness/review.yaml includes .gitattributes but not .gitignore, despite .gitignore having equal or greater blast radius — it controls which files git tracks across the entire repository. The human reviewer caught that the .gitignore change would break documented workflows, but this was discovered only because a human happened to review the PR.
What could go better
.gitignore changes are infrequent and high-impact — they control what files are tracked in version control, affecting all contributors and CI pipelines. The existing REVIEW_PROTECTED_PATHS list protects .gitattributes (git attribute configuration) but not .gitignore (git tracking configuration). This asymmetry means .gitignore changes can be auto-approved and labeled ready-for-merge without human oversight. In PR #804, this resulted in a premature ready-for-merge label on a PR that would have broken documented workflows. Confidence is high: the .gitattributes precedent establishes that git configuration files are considered governance-worthy, and .gitignore fits the same pattern.
Proposed change
Add .gitignore to the REVIEW_PROTECTED_PATHS value in harness/review.yaml (both env.runner and env.sandbox blocks). The current value includes .gitattributes — .gitignore should follow it for consistency. This is a static default per AGENTS.md section 8 and does not require ${VAR} passthrough. The change ensures that any PR modifying .gitignore triggers the protected-path finding and requires human approval before merging.
Validation criteria
After the change, the next review of a PR that modifies .gitignore should produce a protected-path finding (either medium or high depending on context) and the verdict should not be approve. Verify by checking that .gitignore appears in the REVIEW_PROTECTED_PATHS value in both env.runner and env.sandbox blocks.
Generated by retro agent from #804
What happened
On PR #804, a
.gitignorechange was approved by the review agent and labeledready-for-mergewithout human review. TheREVIEW_PROTECTED_PATHSinharness/review.yamlincludes.gitattributesbut not.gitignore, despite.gitignorehaving equal or greater blast radius — it controls which files git tracks across the entire repository. The human reviewer caught that the.gitignorechange would break documented workflows, but this was discovered only because a human happened to review the PR.What could go better
.gitignorechanges are infrequent and high-impact — they control what files are tracked in version control, affecting all contributors and CI pipelines. The existingREVIEW_PROTECTED_PATHSlist protects.gitattributes(git attribute configuration) but not.gitignore(git tracking configuration). This asymmetry means.gitignorechanges can be auto-approved and labeledready-for-mergewithout human oversight. In PR #804, this resulted in a prematureready-for-mergelabel on a PR that would have broken documented workflows. Confidence is high: the.gitattributesprecedent establishes that git configuration files are considered governance-worthy, and.gitignorefits the same pattern.Proposed change
Add
.gitignoreto theREVIEW_PROTECTED_PATHSvalue inharness/review.yaml(bothenv.runnerandenv.sandboxblocks). The current value includes.gitattributes—.gitignoreshould follow it for consistency. This is a static default per AGENTS.md section 8 and does not require${VAR}passthrough. The change ensures that any PR modifying.gitignoretriggers the protected-path finding and requires human approval before merging.Validation criteria
After the change, the next review of a PR that modifies
.gitignoreshould produce a protected-path finding (either medium or high depending on context) and the verdict should not be approve. Verify by checking that.gitignoreappears in theREVIEW_PROTECTED_PATHSvalue in bothenv.runnerandenv.sandboxblocks.Generated by retro agent from #804