fix(governance): restack production rule ambiguity on latest main

[seonghobae]

Purpose

Create a clean successor for #295 on the current protected-main lineage after #292 advanced main and #295 application CI failed closed at the live-base drift guard. This successor carries only the reviewed production-environment semantic-rule ambiguity hardening and its focused regressions; it does not rewrite or force-update the predecessor branch.

Exact construction identity

• protected main immediately before construction and PR creation: 7a62f6ddfc2b435ceab84a954714b97a9534161c;
• predecessor fix(governance): restack production protection ambiguity on current main #295 exact unchanged head: 4ef3af68879eae4f32259480843761b3a19fad7b;
• predecessor application ci 31794344889: terminal failure after protected main moved; predecessor reviewer-ci 31794344839 and central Security Scan 31794344727 were terminal success but remain predecessor-only evidence;
• predecessor formal reviews: 0; inline review threads: 0 at the latest pre-restack refetch;
• successor exact head: 2ecbd4c9bbbdb0130591cd63228c73bc3e37b398;
• successor ancestry: exactly one commit on current protected main, 1 ahead / 0 behind, merge base exactly 7a62f6ddfc2b435ceab84a954714b97a9534161c;
• successor scope: exactly two paths: scripts/lib/production-environment-governance.mjs and test/production-environment-governance.test.ts.

Both successor blobs are byte-identical to the reviewed #295 blobs; all unrelated bytes come from current protected main.

Fail-closed governance behavior

The evaluator no longer selects an arbitrary first semantic protection rule when GitHub returns duplicate rule families. It collects all required_reviewers and branch_policy rules and requires exactly one of each, emitting required_reviewers_rule_ambiguous or branch_policy_rule_ambiguous when duplicates make authority ambiguous. Existing concrete-reviewer validation, self-review prevention, protected-branch requirement, and custom-branch-policy prohibition remain unchanged.

Focused regressions require duplicate reviewer and branch-policy rule families to fail closed.

Evidence boundary

No predecessor CI, coverage, scanner, review, model, deployment, release, or production-environment evidence transfers. Keep this successor Draft until this unchanged exact head has fresh terminal-success application ci, reviewer-ci, protected-base-eligible central Security Scan, all other applicable checks/statuses, exact 100% owned production statement/branch/function/line coverage with realistic tests, and zero valid unresolved findings. Pending, queued, skipped, absent, neutral, failed, cancelled, stale, predecessor, status-only, model-only, or rate-limited evidence is non-passing.

Immediately before Ready or merge, independently re-resolve protected main, exact head/ref/ancestry, workflow checkout SHAs, live rulesets, the exact central .github Security Scan revision/triggers/base filters/thresholds, formal reviews, unresolved threads, statuses, and active-writer state. Current observable live Noema policy enforces the central Security Scan workflow and does not currently impose an independent formal-approval rule; no synthetic approval requirement is introduced.

This repository-owned evaluator hardening does not assert that the live GitHub production environment passes or that external deployment reviewer/admin controls exist. Issue #40 retains that operational acceptance. No gate weakening, self-modifying/repair workflow, secret/reviewer invention, release, deployment, or outbound-license decision is introduced.

Supersedes #295 only after fresh exact-head verification and protected integration.

[coderabbitai]

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 117 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

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.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c56e554a-f3da-4027-8c67-9e258e2f3dbb

📥 Commits

Reviewing files that changed from the base of the PR and between 1f4964f and 0f2f504.

📒 Files selected for processing (2)

• scripts/lib/production-environment-governance.mjs
• test/production-environment-governance.test.ts

---

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.}