Automatically reject clear contribution-policy violations

[dcartertwo]

The contribution policy has both objective requirements and a subjective final judgment. This automates only the objective rejection cases: incomplete author confirmations and patches over 30 changed lines. It deliberately does not decide whether a remaining PR is obviously correct or trivially verifiable; that stays with maintainers.

Because closing fork PRs requires a write-capable workflow, it executes only repository-owned code and never checks out the contributor’s branch.

Depends on #144.

[ask-bonk]

Good — the root test script runs node --test scripts/*.test.js, so the new test is wired into CI. Let me verify the earlier git log — the commit 23a932a shows the pull_request_template.md is a separate commit (26a5d0b Add pull request template) that's a dependency (#144). The PR body says "Depends on #144", and the template file is in this diff — likely because #144 is not yet merged to main.

I have enough to complete the review. Let me confirm there are no genuine bugs in the exemption logic order (e.g., a fixed PR that becomes compliant between the two fetches).

The logic is sound. Let me finalize my assessment. The code is well-structured, tested, and the security posture around pull_request_target is correct. I found no actionable defects that materially affect correctness or security.

Let me reconsider two things carefully before concluding:

1. findAutomationComment pagination + the double-fetch order. The existingComment lookup happens before the second PR fetch. If the second fetch shows compliance, the function returns early (line 86) without commenting — correct, no wasted write. Fine.

2. Reopen-loop / notification spam. On every qualifying event (edited, synchronize, labeled, etc.) for a violating PR, it will comment/close. But it updates the existing comment rather than creating new ones, and closing an already-closed PR is idempotent. concurrency with cancel-in-progress limits churn. Acceptable.

No actionable issues found.

LGTM!

github run

[ask-bonk]

pulls.get always returns additions/deletions as numbers, so NaN is not a real concern here (the event payload might not have them, but the code re-fetches via pulls.get which does).

Let me consider the concurrency/cancel-in-progress interaction with the close operation, and whether closing then commenting order matters. The code comments first (line 91-105), then closes (line 107-112). Correct order — the explanation is posted before the close.

One more consideration: the converted_to_draft event triggers the workflow, but the job if requires draft == false, so a PR converted to draft is skipped. And getContributionPolicyViolations also exempts drafts. Consistent.

Let me double check whether there's a concern with the reopen loop that the prior bonk comment raised — the override label requires a maintainer, and the comment tells users to fix and reopen. That's a reasonable design.

I've completed a thorough review. Let me summarize my findings.

Review

I reviewed all four files. The change is well-constructed and I found no actionable defects.

Key points I verified:

• pull_request_target security posture is correct. The workflow checks out github.workflow_sha with persist-credentials: false and executes only repo-owned scripts/contribution-policy.js; it never checks out the contributor's head. This is the safe pattern for a write-capable fork-PR workflow, and it matches the PR's stated intent.
• The state == 'open' gate is present both in the workflow if (contribution-policy.yml:15) and in getContributionPolicyViolations (contribution-policy.js:32), addressing the GPT-sourced review concern about edited/labeled/unlabeled firing on merged/closed PRs. The final commit be20d7d and tests at lines 122-133/231-245 confirm this.
• TOCTOU double-fetch (contribution-policy.js:84-87) correctly re-evaluates before commenting/closing, so a PR corrected during evaluation isn't closed. Covered by tests.
• Comment-then-close ordering, override-label escape hatch, trusted-author/Dependabot exemptions, and single-line confirmation-marker matching are all sound and well-tested.

Non-blocking observations (not requesting changes):

• CONTRIBUTING.md:7 says "more than a dozen or so lines" while the automation's MAX_CHANGED_LINES is 30. This is an intentional-looking leniency gap (automation is stricter-bounded than prose, maintainers judge the middle), so it's fine — but if you want the docs and automation to agree, one of the two numbers could be aligned.
• As the prior automated comment noted, qualifying events on a persistently-violating PR will re-run; this is bounded by idempotent updates/closes and cancel-in-progress, so it's acceptable.

LGTM!

github run

[ask-bonk]

UnknownError: Your AI Gateway has authentication active, but you didn't provide a valid apiKey

github run

[ask-bonk]

@dcartertwo Bonk workflow failed. Check the logs for details.

View workflow run · To retry, trigger Bonk again.