Skip to content

fix(branch-protection): bring PMOVES-OpenRoom under the drift ratchet - #2979

Open
POWERFULMOVES wants to merge 1 commit into
mainfrom
fix/bp-openroom-spec
Open

fix(branch-protection): bring PMOVES-OpenRoom under the drift ratchet#2979
POWERFULMOVES wants to merge 1 commit into
mainfrom
fix/bp-openroom-spec

Conversation

@POWERFULMOVES

Copy link
Copy Markdown
Owner

The ratchet exists. It wasn't watching this repo.

.github/workflows/branch-protection-drift.yml runs daily at 06:00 UTC on the App token and audits every repo in pmoves_standard.json26 of them. PMOVES-OpenRoom was not one, and the tool refused by name:

BranchProtectionError: no per_repo_overrides entry for
POWERFULMOVES/PMOVES-OpenRoom; add one to the spec

So its live protection drifted with nothing objecting:

live fork profile
required_approving_review_count 1 0 (deliberate, per #2490 N5 — avoids sync/* deadlock)
required_status_checks.contexts []

Protection on, strict: true, requiring nothing.

First look, first refusal

With the entry added, the documented audit runs:

"compliant": false,
"drift": [{ "field": "rulesets[[ main ]]", "expected": "present",
            "actual": "missing", "severity": "block" }]

Same shape as PMOVES-OpenRoom#12 turning CI on — the gate's first act is to say no, which is the evidence it was never watching.

No required check in this PR, deliberately

lint-and-build does not exist on hardened until PMOVES-OpenRoom#12 merges. Requiring a context that has never reported would block the six open PRs that predate the trigger — #3, #4, #8, #9, #10 and #11 all report total_count: 0.

Sequence: #12 merges → CI reports lint-and-build → the context is added here. Not before.

One measurement worth having

Not one of the 26 existing entries carries ruleset_overrides.required_status_checks — every row reads checks=-. Requiring a check on a fork will be a first for the fleet's ruleset spec, not just for this repo.

BRANCH_PROTECTION_BASELINE.md describes per-fork checks (pinokio → CodeRabbit, hermes-agent → 9) as classic protection, which is consistent with the ruleset spec being empty. But it means the two mechanisms hold different facts and only one of them is ratcheted.

Not applied

apply --no-dry-run is a governance write. It belongs to the operator or the daily cron, not to this PR.

Refs: PMOVES-OpenRoom#12, #2966, #2976

🤖 Generated with Claude Code

https://claude.ai/code/session_01X9mpK1ZFjexjthZbvcb94f

`branch-protection-drift.yml` runs daily on the App token and audits every repo
in `pmoves_standard.json`. It covers 26 repos. PMOVES-OpenRoom was not one of
them, so the ratchet has never looked at it -- and the tool refused by name:

    BranchProtectionError: no per_repo_overrides entry for
    POWERFULMOVES/PMOVES-OpenRoom; add one to the spec

That is why its live protection drifted unobserved. Measured:
`required_approving_review_count: 1`, where the documented `fork` profile
specifies 0 deliberately (per #2490 review N5, to avoid sync/* deadlock), and
`required_status_checks.contexts: []` -- protection enabled, `strict: true`,
requiring nothing.

With the entry added, `audit --repo POWERFULMOVES/PMOVES-OpenRoom` runs and
immediately reports `compliant: false`, drift `rulesets[[ main ]]` missing,
severity block. Same shape as PMOVES-OpenRoom#12 turning CI on: the gate's
first act is to say no, which is the evidence it was never watching.

NO required_status_checks IN THIS COMMIT, deliberately. `lint-and-build` does
not exist on hardened until PMOVES-OpenRoom#12 merges, and requiring a context
that has never reported would block the five open PRs that predate the trigger
(#3, #4, #8, #9, #10, #11 all report total_count: 0). The check is added after
#12 lands, not before.

Worth recording while measuring: not one of the 26 existing entries carries
`ruleset_overrides.required_status_checks` -- every row reads `checks=-`. So
requiring a check on a fork will be a first for the fleet's ruleset spec, not
just for this repo. BRANCH_PROTECTION_BASELINE.md describes per-fork checks
(pinokio/CodeRabbit, hermes-agent/9) as classic protection, which is consistent
with the ruleset spec being empty -- but it means the two mechanisms hold
different facts and only one of them is ratcheted.

Not applied here. `apply --no-dry-run` is a governance write and belongs to the
operator or the daily cron, not to this PR.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X9mpK1ZFjexjthZbvcb94f
@coderabbitai

coderabbitai Bot commented Sep 6, 2026

Copy link
Copy Markdown
Contributor

Important

Review skipped

Auto reviews are limited based on label configuration.

🏷️ Required labels (at least one) (1)
  • coderabbit

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Team

Run ID: b3460d15-ac3c-4da0-9467-3c711226d275

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

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

Comment @coderabbitai help to get the list of available commands.

@github-actions github-actions Bot added the config pmoves/config(s)/ changes label Sep 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

config pmoves/config(s)/ changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant