ci(governance): bot-allowlist for low-risk dep/CI chore PRs

[chitcommit]

Summary

Adds a bot-allowlist branch to the Require Human Approval job in .github/workflows/governance.yml. Low-risk dependency / CI-chore PRs can satisfy the gate without a human approval when ALL of the following match:

1. Author is dependabot[bot], renovate[bot], or chitcommit
2. Label includes dependencies or chore, OR title starts with chore(deps): / chore(ci):
3. Files touched are a subset of: package.json, pnpm-lock.yaml, package-lock.json, .github/workflows/security-gates.yml, .github/dependabot.yml
4. No reviewer has requested changes (latest review per reviewer)
5. All other check runs on the head SHA are green (CodeQL, gates, Dependency Audit, Secret Scan, claude-review, etc.) — the gate re-evaluates as checks complete

If any criterion fails, the original required = 1 human-approval rule applies (unchanged).

Job name kept as Require Human Approval so branch protection rules continue to match. Workflow permissions extended with checks: read + statuses: read so the script can inspect sibling check runs.

This PR itself is not allowlist-eligible (touches governance) and requires the standard 1 human approval to bootstrap the policy.

Test plan

• Human reviewer approves this PR to bootstrap the change
• After merge, next dependabot chore(deps): PR with only lockfile/manifest changes should pass the gate with 0 human approvals once other checks go green
• A PR touching unrelated files should still require 1 human approval

🤖 Generated with Claude Code

[github-actions]

@coderabbitai review

Please evaluate:

• Security implications
• Credential exposure risk
• Dependency supply chain concerns
• Breaking API changes

[coderabbitai]

Warning

Review limit reached

@chitcommit, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 22 minutes and 3 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 51508000-50a4-4768-80e9-99ac7082c64c

📥 Commits

Reviewing files that changed from the base of the PR and between d579b98 and b8c8f65.

📒 Files selected for processing (1)

• .github/workflows/governance.yml

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch chore/governance-bot-allowlist

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[claude]

Code Review — ci(governance): bot-allowlist for low-risk dep/CI chore PRs

Overall: Solid intent and good defense-in-depth layering (author + label/title + file-allowlist + no-changes-requested + all-checks-green). A few correctness/security issues need addressing before merge.

---

Bugs / Correctness

1. The workflow will almost always require human approval anyway (missing re-trigger)

The governance workflow only fires on pull_request events. The bot-allowlist requires checksAllGreen, but those other checks (CodeQL, Secret Scan, etc.) haven't completed yet when the governance job first runs. There's no workflow_run or check_suite trigger to re-evaluate after they finish. In practice, checksAllGreen will be false on first run, so required = 1 applies and a human approval is needed anyway. The feature as written mostly doesn't fire.

Fix: add a workflow_run trigger (filtering on completed events for the checks that matter), or accept that this only activates on re-runs / pull_request_review events.

2. selfJobName filter is dead code

const selfJobName = 'Require Human Approval';  // never matches a check run name
const selfCheckName = 'PR Governance Check';    // correct

GitHub Actions creates check runs named after the job's name: field — which is PR Governance Check here. The selfJobName constant will never match anything in listForRef results. It's harmless since selfCheckName correctly excludes the current job, but it's misleading and should be removed.

3. Reviews list is not paginated

const { data: reviews } = await github.rest.pulls.listReviews({ owner, repo, pull_number });

listReviews defaults to 30 results and caps at 100 per page. A PR with many review cycles could have reviews silently truncated, causing hasChangesRequested to miss a block. Use:

const reviews = await github.paginate(github.rest.pulls.listReviews, { owner, repo, pull_number, per_page: 100 });

---

Security Concerns

4. .github/workflows/security-gates.yml in the file allowlist is risky

Allowing bot-authored changes to security-gates.yml to merge without human review is a meaningful weakening of the security posture. A compromised bot account (or a renovate/dependabot misconfiguration) could push changes that weaken security gates and auto-merge them. Recommend removing security-gates.yml from ALLOWED_FILES — security gate changes should always require a human eye.

5. chitcommit in ALLOWED_AUTHORS needs justification

chitcommit is the PR author and doesn't have [bot] in the login. If this is a human account or a general-purpose automation account (not a tightly-scoped GitHub App/bot), granting it the ability to bypass human approvals on CI changes deserves explicit documentation. At minimum: add a comment explaining what chitcommit is and why it's trusted at this level. If it's a GitHub App, the login should end in [bot].

6. chore label scope is broad

Any PR from an allowed author with a chore label on only the listed files bypasses review. If label assignment isn't access-controlled (i.e., any collaborator can add labels), this could be socially engineered. Consider tightening to dependencies only, or requiring chore(deps): / chore(ci): title prefix (already checked) instead of the chore label.

---

Minor / Nits

• ALLOWED_FILES uses exact filename matching, not path matching. A file subdir/package.json would not match package.json. This is probably fine for the intended use case but worth a comment noting the assumption.
• The core.info logging is well-structured and helpful — good call.
• The required = allowlistMatch ? 0 : 1 pattern is clean and preserves backward compatibility correctly.
• The else if (allowlistMatch) branch for the notice fires correctly when required = 0 and approvals pass — logic is sound.

---

Summary

Severity	Issue
High	Workflow trigger gap — checksAllGreen almost never true on first run
High	Reviews not paginated — could miss CHANGES_REQUESTED
Medium	security-gates.yml in file allowlist — should require human review
Medium	chitcommit author trust level unexplained
Low	selfJobName dead code
Low	chore label scope

The core design is sound. Fix the trigger gap and pagination issues before merge, and reconsider security-gates.yml in the allowlist.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b8c8f65709

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Re-run or wait before requiring green sibling checks

For an otherwise allowlisted bot PR, this evaluates checksAllGreen while the governance job is still running; any sibling check run such as Portfolio Hardening Check or another CI workflow that is still queued/in_progress makes this false and immediately falls back to requiring a human approval. Since this workflow only triggers on pull_request, it will not automatically re-evaluate when those checks later complete, so low-risk dependency/CI PRs can remain blocked despite all checks eventually passing.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Include commit statuses before waiving approval

When an allowlisted bot PR has required legacy commit status contexts (for example an external CI or coverage service), this only reads GitHub Check Runs and never reads commit statuses despite the comment and new statuses: read permission. In that context a failed or pending status is invisible here, so allowlistMatch can waive the human approval solely because all check runs are green.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Paginate reviews before trusting latest review states

On bot PRs with more than the first page of reviews, this single listReviews call can miss later review records, including a later CHANGES_REQUESTED from a reviewer. Because the allowlist then treats hasChangesRequested as false, a dependency/CI PR can have the human approval waived even though a reviewer has an outstanding change request.

Useful? React with 👍 / 👎.