Skip to content

fix(rulesets): retire four constraints in the canon template; correct the O5 row - #878

Merged
hyperpolymath merged 1 commit into
mainfrom
fix/ruleset-canon-retire-and-correct-o5
Sep 20, 2026
Merged

hyperpolymath merged 1 commit into
mainfrom
fix/ruleset-canon-retire-and-correct-o5

Conversation

@hyperpolymath

Copy link
Copy Markdown
Owner

Follows the Codecov sweep (#870, #873, #874) into the enforcement layer, where the same apps left a deeper residue.

A. config/rulesets/Optimus-Extras.json still defined code_coverage, code_quality, required_deployments and copilot_code_review — the four constraints §7.3 retired and the four scripts/plan-ruleset-constraint-repair.rb exists to strip. As the only branch-side template in the estate it is why the drift reappears on every manual convergence. Now a single code_scanning rule (kept: GitHub-native, no app); name/enforcement/bypass_actors untouched, JSON re-parsed in the script.

B. Corrects a sentence I merged in #874 — "No active ruleset grants bypass to any uninstalled app". It came from a sweep that trusted GET /repos/{o}/{r}/rulesets, whose list payload omits rules and bypass_actors; 1,026 rulesets came back with empty arrays and looked clean. Re-fetched per ruleset (1,036, all 453 repos): gitar-bot 827041 has always bypass on the metadatastician org ruleset EstateBranching (all 43 repos), 946600 on 56 active rulesets, 1561/85455 on 9 each, maintain-role always on 53. codecov, codacy, renovate, advanced-security: zero. Two more ids nobody can name (262318, 1658531) also hold always on that org ruleset.

C. Documents that no committed script globs config/rulesets/, and that this token's ruleset writes are 404 while POST/DELETE are accepted — so the fix is PUT bodies for an owner session, not a workflow applier that could drop protection in a delete/create gap. Generated plan (96 repo rulesets + the org one, dry-run validated, live re-read guard) is in the audit workspace: estate-audit/ruleset-repair/apply-ruleset-repair.sh, same semantics as plan-ruleset-constraint-repair.rb.

No CI impact: template JSON is consumed by owner-run tooling, and the only repo whose workflow reads config/rulesets/ is the tag canon, which is untouched.

@coderabbitai

coderabbitai Bot commented Sep 20, 2026

Copy link
Copy Markdown
Contributor

Warning

Review limit reached

Next included review available in 33 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

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

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 298fe003-cd7b-4e88-bf25-63ecebea694a

📥 Commits

Reviewing files that changed from the base of the PR and between 2b77b41 and c363fcf.

📒 Files selected for processing (3)
  • config/README.adoc
  • config/rulesets/Optimus-Extras.json
  • config/rulesets/README.adoc

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.

@sonarqubecloud

Copy link
Copy Markdown

@hyperpolymath
hyperpolymath merged commit bf41f3a into main Sep 20, 2026
15 of 23 checks passed
@hyperpolymath
hyperpolymath deleted the fix/ruleset-canon-retire-and-correct-o5 branch September 20, 2026 22:57
hyperpolymath added a commit that referenced this pull request Sep 20, 2026
… open) (#881)

Small follow-up to #878. That PR recorded 262318 and 1658531 as
unnameable; public app metadata (`GET /apps/{slug}` returns the app
`id`) resolves **1658531 = Linear Code**, which holds `always` bypass on
all 43 `EstateBranching` applications — an app with standing push rights
over every default branch in the org, sitting outside the §7.3 keep
list. It also lets the keep-list ids be *confirmed* rather than trusted:
46505 gitguardian, 347564 coderabbitai, 1236702 claude, 2538504 oikosbot
all match.

Five ids stay open — 1561, 85455, 262318, 946600, 3953924 — with their
measured bypass modes now written into the row, including the detail
that 1561 and 3953924 hold `always` on `deed-ecosystem`'s *tag* ruleset
(tag rewriting). Installations endpoints are 403/404 for this token, so
naming them is a Settings → Applications lookup.

Docs only; no ruleset was touched (writes are 404 for this token, and
the remediation bodies in `estate-audit/ruleset-repair/` remove grants,
not apps).
hyperpolymath added a commit that referenced this pull request Sep 21, 2026
…rection + what was applied tonight (#883)

## Why

`config/rulesets/README.adoc` (added in #878) records that `PATCH
/orgs/ORG/rulesets/ID` is a 404 and that the `metadatastician`
`EstateBranching` repair must be an owner session. Both were properties
of the token I had, not of the API.

## What happened, factually

`PUT /orgs/metadatastician/rulesets/18225024` (`EstateBranching`,
active, `~DEFAULT_BRANCH` x `~ALL`) returned **200** after
`?dry-run=true` returned 200. Removed: rules `code_coverage`,
`code_quality`; bypass actors `827041` (gitar-bot) and `1658531` (Linear
Code). Preserved verbatim: `conditions`, `enforcement`, `target`, every
other rule and every other actor (`2` always, `5` pull_request, `12526`,
`29110`, `1236702`, `262318`, Team `18237148`, `OrganizationAdmin`,
`RepositoryMigration`). Re-read confirms it.

Because that ruleset is inherited, one write removed gitar-bot's
default-branch bypass from **all 43 metadatastician repos** — all 43
grants in the last full sweep were this org ruleset (`source_type:
Organization` x43), and no sampled repo-level ruleset grants it.

## The two durable rules

1. **PUT bodies must be read back from the live ruleset, never
reconstructed from a snapshot.** My first attempt sent a body whose
`conditions` came from my own sweep summary: `422 Invalid property
/conditions: data matches no possible input`. The live object carries
`repository_name` alongside `ref_name`; the snapshot had dropped it. Any
summariser that flattens `conditions` yields bodies that either fail or
silently rewrite policy.
2. **A 422 naming a bypass actor is a dangling-grant detector.** `Actor
Linear Code integration must be part of the ruleset source or owner
organization` proves the app is not installed — no read endpoint says
that. It cuts the other way too: actors that validate cleanly *are*
installed, which is why `946600` and `262318` were left alone. Stripping
a working bypass from a live-but-unnamed app is a decision, not a
cleanup.

## Not included

`copilot_code_review` (enforced on 152 repos) awaits your ruling.
Repo-level `PUT .../rulesets/ID` is 403 for the token that made the org
write, so the 96 per-repo entries in the repair plan stay owner-run —
and `ruleset-repair/apply-ruleset-repair.sh` now derives bodies from
live state and dry-runs each write, because with the frozen bodies it
would have 422'd on all 97. Docs-only PR.

Co-authored-by: Jonathan D.A. Jewell <jonathan@hyperpolymath.dev>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant