Repository navigation
feat(OMN-14288): enforcement + merge-policy parity ratchet (report-only) - #2250
Conversation
Extend the branch-protection auditor (OMN-9034) to close the MISSING-direction
hole the enforcement-parity audit confirmed: the existing Check A/B only cover
the ORPHANED direction (a required context that no longer reports), never the
MISSING direction (a load-bearing gate CLAUDE.md CLAIMS is enforced but is
absent from live required_status_checks). That hole left deploy-gate +
reject-skip UNENFORCED on omnimarket/omniclaude dev (contexts=['CI Summary']).
- scripts/audit_branch_protection_lib.py: add PURE, unit-tested parity logic
(normalize_context_forms with reusable-context fuzzy-leaf matching,
is_gate_directly_required, compute_needs_closure, evaluate_gate_parity,
evaluate_manifest_parity). No yaml/network deps so existing Check A/B tests
keep running under bare python3.
- scripts/enforcement_parity_manifest.yaml: single machine-asserted org-wide
manifest {repo -> branch -> load_bearing_gates[]}, coverage=direct|needs_child.
Replaces the per-repo honor-system .github/required-checks.yaml.
- scripts/audit_required_context_parity_cli.py: thin gh/YAML I/O CLI, REPORT-ONLY
(never mutates branch protection, always exit 0; --fail-on-findings reserved
for the future enforcing gate).
- .github/workflows/branch-protection-audit.yml: non-blocking report-only step.
- tests/ci/test_required_context_parity.py: unit tests incl. a regression class
pinning the confirmed M1-M4 findings.
Live report reproduces M1-M4 (omnimarket+omniclaude deploy-gate+reject-skip
MISSING) with core/infra clean and omnimarket occ-preflight covered via
needs-closure. Does NOT mutate branch protection; does NOT flip to enforcing.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 14 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
…-only)
Fold the deterministic merge policy into the same config-as-data manifest the
required-context ratchet already uses — one manifest asserts enforcement AND
merge policy. Still REPORT-ONLY; no branch-protection mutation.
- scripts/enforcement_parity_manifest.yaml: schema is now
{repo -> branch -> {load_bearing_gates[], merge_policy{queue,strict}}}. Records
the DECIDED policy: queue=disabled on ALL dev branches; strict=true on the two
dashboards (omnidash, omnibase_compat), recorded as-is elsewhere. Adds the four
merge-policy-only dev repos (onex_change_control, omnidash, omnibase_compat,
omnibase_spi). Live values verified 2026-07-10.
- scripts/audit_branch_protection_lib.py: add PARITY_QUEUE_DRIFT / PARITY_STRICT_DRIFT
+ pure evaluate_merge_policy_parity(); integrate into evaluate_manifest_parity.
- scripts/audit_required_context_parity_cli.py: fetch live strict (from
required_status_checks.strict) + live merge-queue state (parameterized GraphQL
mergeQueue(branch:)); render a MERGE-POLICY drift block.
- tests: add merge-policy unit tests + a regression pinning the live-verified
omnibase_spi QUEUE_DRIFT (spi dev still has a queue vs the decided disabled).
- CLAUDE.md: document both dimensions + the merge-queue rationale.
Live report (report-only): 4 MISSING (M1-M4) + 1 QUEUE_DRIFT (omnibase_spi dev
still has a live merge queue against the decided queue=disabled policy) — the
merge-policy dimension caught real drift the "all disabled" belief had missed.
Remediating spi's queue is a separate operator/admin action; this ratchet does
not mutate branch protection.
jonahgabriel
changed the title
09c3b66 to
c0916ed
Compare
1 participant
OMN-14288 — enforcement + merge-policy parity ratchet (REPORT-ONLY)
Closes OMN-14288 (build phase; report-only). Head pinned to
c0916ed2(bound by the shared OCC companion onex_change_control#3837).Makes the FULL per-repo dev branch-protection policy deterministic config-as-data,
asserted against live state by one parity ratchet — two dimensions in one manifest.
1. Enforcement dimension (
load_bearing_gates[])Closes the MISSING-direction hole: the existing branch-protection auditor only
checks the ORPHANED direction; it never checks whether a load-bearing gate
CLAUDE.md claims is enforced is actually in live
required_status_checks. Thathole left
deploy-gate+reject-skipunenforced on omnimarket/omniclaudedev(
contexts == ["CI Summary"]; both gates in separate workflow files, unreachablevia
CI Summary's intra-workflowneeds:closure). Adds MISSING,NEEDS_CLOSURE, UNPROTECTED.
2. Merge-policy dimension (
merge_policy: {queue, strict})Records the DECIDED merge policy (queue disabled on all dev branches;
stricttrue on the two dashboards) and flags live drift: QUEUE_DRIFT / STRICT_DRIFT.
Rationale: a merge queue's only unique value is the
merge_groupre-test-against-latest-base, which wedges the saturated self-hosted fleet; required
contexts fire on
pull_request, so disabling the dev queue loses no enforcement(
strictis the lighter combine-breakage guard).Files
scripts/enforcement_parity_manifest.yaml— one org-wide manifest,{repo → branch → {load_bearing_gates[], merge_policy}}.scripts/audit_branch_protection_lib.py— PURE, unit-tested parity logic.scripts/audit_required_context_parity_cli.py— thingh/GraphQL/YAML CLI, REPORT-ONLY..github/workflows/branch-protection-audit.yml— non-blocking report-only step.tests/ci/test_required_context_parity.py— unit tests incl. M1–M4 + drift regressions.Live report (report-only)
Reproduces the confirmed MISSING findings — omnimarket + omniclaude
deploy-gateand
reject-skip(M1–M4) — with omnibase_core/omnibase_infra clean and omnimarketocc-preflight(needs_child) correctly COVERED via its aggregator'sneeds:closure.FAST-FOLLOW (documented, intentionally not applied here)
At this pinned head the manifest records
omnibase_spi.dev.merge_policy.strict: false(its value when this head was authored). omnibase_spi has since been brought into the
decided policy (dev queue disabled +
strictenabled, verified live), so thereport-only ratchet now emits a harmless spi
STRICT_DRIFTreport-onlyfalse-positive here. The
strict: truemanifest correction is deferred to the nextmanifest touch (or the enforce-flip) on purpose: re-heading #2250 now would
staleify the shared OCC companion (onex_change_control#3837, bound to
c0916ed2) andforce a re-author + re-queue through the saturated fleet — not worth it for a 1-line
report-only value.
Guardrails honored
M1–M4 MISSING gates is a separate operator/admin action (bundles with OMN-14279).
dod_evidence
reportreproduces confirmed M1–M4; merge-policy drift detection exercised.OCC companion: shared onex_change_control#3837, bound to this head
c0916ed2. NOT self-authored (no-self-authored-evidence rule).Do not merge/arm — Codex lands.
Evidence-Source: OCC#3837
Evidence-Ticket: OMN-14288
Evidence-Commit: bae37a0359453e36cf446447ce9dd741e31da6ac