Skip to content

[Governance] Establish a counted independent-review path for protected CWL pull requests #772

Description

@seonghobae

Problem

CWL repositories require an approving review from a reviewer whose repository permission GitHub counts before protected-branch merge. Current pull requests can have successful exact-head CI, security, SAST, fuzz, coverage, Javadoc, generated-evidence, and advisory review results while remaining unmergeable because no eligible independent human reviewer is available.

  • The pull-request author is @seonghobae; GitHub does not count author self-review as independent approval.
  • The organization CODEOWNERS path currently depends on the same maintainer identity.
  • opencode-agent, cwl-noema-review, and coderabbitai provide advisory evidence but do not have repository write permission that GitHub counts for protected-branch approval.
  • Administrator bypass or a second credential representing the same author would destroy the intended separation-of-duties evidence.

This is a governance deadlock, not a source, test, or CI failure.

Security objective

Create a durable, least-privilege human independent-review path without weakening required reviews, disabling stale-review protection, bypassing branch protection, or changing the existing review-agent credential model.

Required design

  1. Create an organization team such as independent-reviewers with at least two active human maintainers.
  2. Grant the team the minimum repository permission GitHub accepts for counted approvals (write, unless an organization custom role can satisfy the rule with less authority).
  3. Add the team to relevant CODEOWNERS paths and reviewer assignment rules while preserving repository-specific subject-matter ownership.
  4. Keep automated reviewers read-only and advisory. Do not grant a bot broad contents-write permission merely to manufacture approvals.
  5. Require approval of the exact current head by someone other than the author and, where configured, someone other than the most recent pusher.
  6. Document backup coverage, reviewer rotation, stale-review behavior, incident handling, leave coverage, and offboarding.
  7. Add an organization-level reviewer-availability check that reports a precise governance blocker without weakening any repository gate.
  8. Record approving identity, permission snapshot, exact head SHA, required-check set, merge SHA, and timestamp as governance evidence.

Acceptance criteria

  • At least two non-author human identities can submit approvals that GitHub counts for protected CWL repositories.
  • Reviewer assignment is team-based and does not depend on one person being continuously available.
  • Existing CodeRabbit, OpenCode, Noema, GHAS, Dependabot, CI, SAST, security, fuzz, coverage, documentation, generated-evidence, and unresolved-thread gates remain unchanged.
  • Existing review-agent secrets and authentication flows are not broadened or replaced.
  • CODEOWNERS and organization governance documentation are updated.
  • A dry-run PR proves author self-approval is rejected, advisory bot review is non-counting, and a non-author team approval enables auto-merge only after every exact-head gate passes.
  • A commit after approval dismisses or invalidates stale approval as configured.
  • Reviewer removal or loss of counted permission makes the workflow fail closed with an actionable message.

Current ready-but-blocked evidence — 2026-08-06

PR Exact head Technical state Remaining gate
clearfolio#270 26563218ae42eaa876c784fcf56b27f8cb810080 Exact-head CI, Security Scan, SAST, fuzz, CodeRabbit source review, zero unresolved threads; auto-merge enabled Formal OpenCode/Noema evidence and counted independent write-authorized approval

clearfolio#264 is no longer in the ready queue. It was returned to Draft because it overlaps #270 in shared build, CI, and changelog files and must not auto-merge ahead of the authoritative parent. Its prior green head remains provenance only until post-#270 reconciliation.

Intentional dependency order

  1. clearfolio#270 is the authoritative privacy, Netty, deterministic SBOM/attribution, exact-head CI, zero-missed coverage, warning-free Javadoc, and fail-closed Maven test-evidence parent.
  2. clearfolio#274 is a clean five-file artifact-token parsing descendant of fix: avoid thread-only review autofix dispatches #270 and remains Draft until the parent integrates.
  3. clearfolio#271 is a clean five-file hourly PR/OpenCode-loop descendant of fix: avoid thread-only review autofix dispatches #270 and remains Draft until the parent integrates.
  4. clearfolio#265 readiness/liveness and clearfolio#268 administrative tenant authorization remain Draft until cleanly reconciled onto the protected main produced by fix: avoid thread-only review autofix dispatches #270.
  5. clearfolio#264 accessibility must be reconciled after fix: avoid thread-only review autofix dispatches #270 because both touch shared acceptance infrastructure.

Operational runbook

For each protected pull request:

  1. Resolve all source-backed review findings.
  2. Verify the exact current head across every required check and reject stale, queued, pending, cancelled, skipped-required, or absent-required evidence.
  3. Request review from the independent-reviewer team.
  4. Confirm the approving identity is not the author and currently has a permission GitHub counts.
  5. Confirm no commit has superseded the approved head.
  6. Let expected-head-safe auto-merge execute only after all branch/ruleset gates pass.
  7. Store reviewer, permission, head SHA, check set, merge SHA, and timestamp in governance evidence.

Non-goals

  • Reducing required approving-review count to zero.
  • Adding a branch-protection bypass for routine development.
  • Treating CodeRabbit, OpenCode, Noema, Copilot, or another advisory bot as a substitute for a counted independent human approval.
  • Granting autonomous development agents unrestricted repository write access.
  • Reusing the pull-request author's identity through another credential or automation path.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions