[Feat] Add community-approved label for community code approvals - #1873

​Opened on behalf of @taltas. Follow up by mentioning @roomote, in the web UI, or in Discord.

Related GitHub Issue

Closes: #1872

Description

Adds the advisory community-approved label to the PR review-state workflow so maintainers can see which PRs in the awaiting-maintainer queue already have a fresh community approval for the current head. The label is a priority signal only — it grants no merge authority, and required checks plus maintainer review are unchanged.

Implementation notes:

• The label is defined in label-pr-review-state.yml (description ≤ 100 chars) but kept outside stateLabels; one shared reconcileCommunityApproval(pr, decision) helper applies the add / remove / preserve decision from every reconciliation branch.
• Eligibility reuses the existing decisive per-reviewer reduction (selected by review id, not array order): a non-null human reviewer with a valid login, not the PR author, without admin/maintain/write permission (a permission 404 qualifies), whose latest decisive review is an approval on the current head. One eligible approval is enough; bot-authored PRs follow the same rule with no new CodeRabbit requirement.
• Permission results are shared with maintainer classification through the existing memoized permissionFor. A lookup failure is unknown permission — it never counts as community eligibility; when it blocks maintainer classification the existing fail-closed behavior is kept, and a global failure that clears the queue also removes the label. A failed community label write only logs a warning — it never clears the queue label or fails the review gate.
• The existing awaiting-maintainer refetch now also compares latestPrDetail.head.sha with pr.head.sha: a known head change removes the label even when other checks are uncertain; unknown mergeability alone (unchanged head, no known invalidation) preserves an existing label without adding one.
• converted_to_draft was added to the pull_request_target types so draft conversions reconcile promptly.
• The managed guide comment explains the label meaning and says not to edit it manually (no reviewer lists). One sentence added to CONTRIBUTING.md under Review Process.
• Reviewer-account validation: the general review reduction is now ghost-account-safe (null-user reviews are skipped instead of throwing).

Test Procedure

• src/services/__tests__/pr-review-state-workflow.test.ts executes the embedded workflow script against deterministic GitHub API doubles. Added 25 focused tests covering: reviewer eligibility (ghost accounts, bots, author, maintainer permissions, permission 404), per-user permission failures (new permissionErrors harness option), freshness/dismissal/replacement with multiple reviewers, id-based selection vs array order, head change during reconciliation (new headShaSequence harness option), mergeability-unknown preservation, queue transitions and repeated runs, read-only fork review events, community change requests not routing to awaiting-author, invalidation beating uncertainty, advisory gate unchanged, and community label write failure not failing the gate.
• Focused suite: 154/154 pass. Mutation check: reverting only the workflow change fails 17 of the new tests.
• Full pnpm test at the repo root: all turbo tasks green. tsc --noEmit and ESLint (--max-warnings=0) on the touched test file are clean; eslint-suppressions.json counts unchanged.

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Testing: New and/or updated tests have been added to cover my changes (if applicable).
• Visual Snapshot (UI changes only): Not applicable — no UI change.
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Visual Snapshots

Not applicable — this change touches a GitHub Actions workflow, its test suite, and a CONTRIBUTING.md sentence; there is no user-facing UI.

Videos (interaction / animation only)

Not applicable.

Documentation Updates

• No documentation updates are required. The contributor-facing note lives in CONTRIBUTING.md (Review Process). The Zoo-Code-Docs site does not document this internal review workflow, so no docs-repo PR is needed.

Additional Notes

Out of scope per the issue: trusted event relay for faster fork updates, auto-merge, reviewer permission changes, reputation scores, reviewer-count requirements, commit-author exclusions, reviewer lists in the guide comment, and changes to branch protection, CODEOWNERS, publishing checks, or stale closure policy.

Get in Touch

Available on the project Discord for any reviewer questions.