fix(branch-protection): bring PMOVES-OpenRoom under the drift ratchet - #2979
Open
POWERFULMOVES wants to merge 1 commit into
Open
fix(branch-protection): bring PMOVES-OpenRoom under the drift ratchet#2979POWERFULMOVES wants to merge 1 commit into
POWERFULMOVES wants to merge 1 commit into
Conversation
`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
Contributor
|
Important Review skippedAuto reviews are limited based on label configuration. 🏷️ Required labels (at least one) (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Team Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The ratchet exists. It wasn't watching this repo.
.github/workflows/branch-protection-drift.ymlruns daily at 06:00 UTC on the App token and audits every repo inpmoves_standard.json— 26 of them.PMOVES-OpenRoomwas not one, and the tool refused by name:So its live protection drifted with nothing objecting:
forkprofilerequired_approving_review_countsync/*deadlock)required_status_checks.contexts[]Protection on,
strict: true, requiring nothing.First look, first refusal
With the entry added, the documented audit runs:
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-builddoes 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 reporttotal_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 readschecks=-. Requiring a check on a fork will be a first for the fleet's ruleset spec, not just for this repo.BRANCH_PROTECTION_BASELINE.mddescribes 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-runis 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