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

[Maximo-Guk]

Is it intentional that we won't enforce this for draft PR's?

[dcartertwo]

yes

[Maximo-Guk]

From GPT:

.github/workflows/contribution-policy.yml:5: edited, labeled, and unlabeled also fire for closed or merged PRs. Without checking state === "open", the bot can post a false rejection comment on an already merged PR.