Follow-up to rpt-2610121533020069: the copied main review ruleset does not stop the owner's own PRs, and may not stop anyone's

Follow-up to rpt-2610121533020069: the copied main review ruleset does not stop the owner's own PRs, and may not stop anyone's

Addendum to rpt-2610121533020069

That report proposes a GitHub settings baseline taken from intentdriven/abcd. One of its rulesets, "main review", does less than its name suggests.

What was tested

intentdriven/a managed repository has the "main review" ruleset copied from intentdriven/abcd: a pull_request rule with require_code_owner_review true and required_approving_review_count 0. Its CODEOWNERS file assigns .github/, .githooks/, the .abcd/ config, AGENTS.md and LICENSE to the repository owner.

Test PR #1 was opened as the owner and changed .github/CODEOWNERS, a path the owner owns. Once the two required checks (gitleaks, zizmor) passed, GitHub reported:

• mergeStateStatus CLEAN, mergeable MERGEABLE;
• reviewDecision null, and no review requested.

The PR could have entered the merge queue with no approval at all. It was closed unmerged.

What it means

• For the owner's own PRs, the code-owner rule does nothing. That includes every PR an agent or autonomous run opens under the owner's identity. Practically this is convenient: autonomous runs are not stuck waiting for a self-approval GitHub would refuse anyway. But the rule's name and the CODEOWNERS comment in intentdriven/abcd ("requires a code-owner review on any pull request touching them") promise a gate that, for the owner, does not exist.
• Untested: other authors. With required_approving_review_count 0, GitHub may not require a code-owner approval from anyone, which would make the rule a no-op for every contributor. Confirming this needs a PR from a second account (another org member).
• intentdriven/abcd carries the same setting, plus require_extra_approval_for_unattributed_changes. Whether that parameter changes the outcome there is also untested.

Expected

The baseline either enforces what it claims (code-owner approval on the publish surface, from someone other than the author where that matters) or says plainly that it is advisory for the owner. The audit proposed in rpt-2610121533020069 should check what a rule actually does, not only that it is present.

Remedy the reporter proposes: Decide what code-owner review is meant to guard, then set required_approving_review_count to at least 1 or drop the rule; make the baseline in rpt-2610121533020069 test the rule's effect, not only its presence.

Reported by a managed repository (root commit b7297501ef3f6f39707c6c9d08ead29240ed1f0b) through the abcd inbox as rpt-2610121624558512, a defect against abcd v0.13.4, surface GitHub ruleset baseline copied from intentdriven/abcd (main review: pull_request rule).

Evidence:

• rpt-2610121624558512 (the report, kept in the inbox)
• rpt-2610121533020069
• https://github.com/a managed repository/pull/1
• https://github.com/intentdriven/abcd

Grounds

• pursued: a pull request from a maintain-role account that changes an owned path stays blocked until a code owner approves; a CLEAN merge state on such a pull request with no approval would show it wrong.