Fix contribution policy exemptions

[dcartertwo]

GitHub’s author_association depends on the viewer: the Actions token classified a maintainer as CONTRIBUTOR and auto-closed #167. This uses the author’s effective repository permission instead, which is the authority the exemption is meant to represent.

Drafts are no longer a blanket exemption. External draft PRs are subject to the same checks as ready PRs; maintainers, Dependabot, and policy/override remain exempt.

[ask-bonk]

The change is small, focused, well-tested, and correct. Let me do a final assessment of potential issues:

1. Fail-open on API error — if getCollaboratorPermissionLevel throws, the function throws and no close happens. This is acceptable (safe direction) but undocumented. Not a blocking issue.

2. permission values — GitHub's API returns admin/maintain/write/triage/read/none. The TRUSTED_PERMISSIONS set correctly captures the push-capable levels (admin, maintain, write) and excludes triage/read/none. Correct.

3. Extra API call cost — only incurred when violations exist, which is the uncommon path. Efficient.

I found no discrete, actionable problems introduced by this change. The logic correctly addresses the visibility-dependent author_association bug by checking effective repository permission, the placement of the check is efficient, the trusted-permission set matches GitHub's push-capable levels, and the tests cover both the new exempt and still-enforced cases. Tests pass locally (22/22).

LGTM!

github run

[ask-bonk]

All 23 tests pass. Let me assess the core logic for correctness and any introduced issues.

The change is sound. Let me evaluate the key design points:

1. The bug fix is correct. author_association is visibility-dependent — the Actions token sees maintainers as CONTRIBUTOR. Using getCollaboratorPermissionLevel returns the effective repository permission, which is not visibility-dependent, so this correctly fixes the Add OpenAI-compatible model provider #167 auto-close.

2. Permission set — admin/maintain/write are exactly the push-capable levels; triage/read/none are correctly excluded.

3. Placement — the extra API call only runs when violations exist (uncommon path), which is efficient.

4. Draft change — removing the draft bypass from both the workflow if: and the function is consistent, and the workflow test guards against reintroducing the draft condition.

One observation worth noting (non-blocking): the permission check at line 78-86 uses the first-fetch pullRequest.user?.login, and the re-fetch at line 94 recomputes violations but does not re-run the permission check. This is fine — the PR author cannot change during evaluation, so a single permission check is correct. There's no issue here.

I found no discrete, actionable problems introduced by this change. The fix correctly addresses the visibility-dependent author_association bug, the trusted-permission set matches GitHub's push-capable levels, the draft-enforcement changes are consistent across workflow and script, and tests cover both the new exempt path and the still-enforced path (23/23 pass locally).

LGTM!

github run