governance: harden effective develop ruleset and remove routine admin bypass

[seonghobae]

Live Orgmetra governance defect — effective control plane

Fresh supported reads on 2026-09-05 confirm protected develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f is governed by inherited organization ruleset 18156473 — CWL Central required workflows, enforcement=active, scoped to ~DEFAULT_BRANCH. Classic branch-protection fields are not authoritative by themselves while this ruleset is active.

The live ruleset currently has:

• required_approving_review_count = 1;
• dismiss_stale_reviews_on_push = true;
• require_last_push_approval = false;
• require_code_owner_review = false;
• required_review_thread_resolution = true;
• require_extra_approval_for_unattributed_changes = true;
• required_reviewers = [];
• allowed merge methods merge and squash;
• deletion and non-fast-forward protection;
• OrganizationAdmin with bypass_mode = always; and
• current_user_can_bypass = always.

The current required-workflow set is seven identities, not the nine previously recorded in this issue: opencode-review, pr-review-merge-scheduler, security-scan, strix, sast-semgrep, noema-review, and codeql-pr. The prior statement that CodeQL was absent is stale and remains superseded by the live payload. Required-workflow identity remains owned by ContextualWisdomLab/.github; Orgmetra must not clone, remove or weaken these gates locally.

Repository-local workflow state

Orgmetra PR #161 integrated normally on 2026-09-04 as protected commit eb9757f8649aaad026a9865508d9aad50c1a7a4f. It consolidated repository-local quality workflows and replaced moving ubuntu-latest selectors with explicit ubuntu-24.04 without weakening the domain/PostgreSQL/repository-quality contract.

The earlier statement that all current #63/#64/#65 jobs remained queued before checkout is now only partly true. #63 exact head 72070cb4b8d636825ce5b1a326df4c296596ed7e materially acquired a GitHub-hosted ubuntu-24.04 runner: Foundation CI 33936088421 / Repository quality 101224196516 completed GREEN after exact checkout, owned unit/service contracts, isolated PostgreSQL contracts, and read-only validation. PR Review Merge Scheduler 33936086820 is also GREEN. The six remaining required lanes visible on that exact head—Security Scan 33936088403, SAST Semgrep 33936088456, CodeQL PR 33936088409, OpenCode 33936086812, Strix 33936086809, and Noema 33936086817—remain non-terminal, and there is still no qualifying APPROVED review. #64/#65 remain separately blocked on their own exact-head acceptance. Selector correctness is therefore protected and materially proven for Foundation, while shared required-workflow admission/capacity is still incomplete. Do not recreate deleted leaf workflows, copy workflow bytes into feature branches, or generate no-op commits to simulate execution.

Canonical owner boundary

The policy decision and privileged live-ruleset mutation remain owned by ContextualWisdomLab/.github. Orgmetra’s responsibility is to keep this consumer/canary evidence current and fail closed. Before any settings mutation or claim that the organization policy has converged, re-fetch the central owner’s live protected head, active writer, exact-head checks/reviews, relevant ruleset payload/history and controlled-credential evidence in that owner lane. Historical .github PR numbers/heads in older comments are predecessor evidence only and are not promoted here without a fresh owner read.

For the current sole-maintainer operating model, Orgmetra must not manufacture independent-human evidence through bot/service-account approval, self-approval, broadened reviewer credentials or routine administrator bypass. Review-thread resolution, deterministic required workflows, deletion and non-fast-forward protection must remain enforced. Any change to approval count or bypass policy must be made and verified in the canonical central owner, then proven with an unchanged Orgmetra canary through the ordinary protected path.

Acceptance criteria

• Effective scope remains the protected default branch without weakening normal PR enforcement.
• Current central required-workflow identities remain exact and material; no leaf shim substitutes for them.
• Required review conversations and deterministic security/review workflows materially execute on the exact candidate head.
• Force-push/non-fast-forward and branch deletion remain prohibited.
• Routine administrator bypass is not used to manufacture release/merge evidence; any break-glass path is separately governed and auditable.
• Central source/audit policy and live ruleset payload/history converge before GOV-01 is declared repaired.
• After central convergence, an unchanged eligible Orgmetra canary proves the ordinary protected path rather than bypass.
• Every later central policy or workflow change invalidates stale consumer snapshots and requires fresh Orgmetra reads.

No release/version/tag is authorized until one exact integrated protected head satisfies the complete governance, product, security, recovery and release evidence set.

[seonghobae]

Fresh owner-boundary verification on develop@9e3e4847510e1e612b48474ba42b177b8ed824df still reports protected: true while the effective branch-protection payload remains protection.enabled=false, required-status enforcement off, and required contexts/checks empty. This is therefore still an enforceability defect, not a CI-result defect. The currently available GitHub write surface in this Orgmetra loop exposes repository/branch/file/PR/issue mutations but no branch-protection or ruleset mutation endpoint, so there is no safe in-loop settings repair path to execute without bypassing the owner-control boundary. Acceptance remains unchanged: configure an enforcing branch protection/ruleset with PR-only integration, current-head required gates, independent non-author approval, stale-approval dismissal, required conversation resolution, and no routine force-push/delete/admin bypass; then refetch this exact payload (or equivalent ruleset evidence) and close only after enforcement is proven.

[seonghobae]

Fresh owner-control evidence (2026-08-23): develop remains at 9e3e4847510e1e612b48474ba42b177b8ed824df. GitHub still reports the branch as protected: true while its effective protection payload has protection.enabled=false, required-status enforcement off, and empty required contexts/checks. New PR #92 demonstrates that exact-head Foundation/SAST/Security/Recovery and feature-specific workflows materialize normally, so the first causal boundary remains repository branch/ruleset configuration rather than CI generation. Acceptance remains unchanged: enforce PR-only integration, exact-head required checks, qualifying independent non-author approval with stale-approval dismissal, resolved conversations, and no force-push/delete/admin bypass. Current connected GitHub actions expose no branch-protection/ruleset mutation path, so no weaker workflow workaround was introduced.

[seonghobae]

Fresh owner-boundary evidence (2026-08-23): develop remains 9e3e4847510e1e612b48474ba42b177b8ed824df. The live branch API still reports protected: true while the effective payload remains protection.enabled: false, required-status enforcement off, and required contexts/checks empty. This run also produced a fresh independent feature lane proving that exact-head gates themselves are functioning: PR #93 at bbb106aceeda3a3ac2ebf5caead9e174a9dbe21f has terminal-success Performance Context Evidence Quality 32615403552, Foundation CI 32615403537, Recovery 32615403519, SAST 32615403551, and Security 32615403560; its focused job checked out that exact SHA and passed 44 installed-wheel tests at exact 100% owned statement/branch coverage. Therefore the first causal boundary remains repository branch/ruleset configuration, not CI generation. #93, like the older GREEN root lanes, has no qualifying independent non-author APPROVE and was not merged. The currently available GitHub write surface exposes no branch-protection/ruleset mutation action; do not substitute workflow weakening or direct integration. Acceptance remains: configure an enforcing PR-only rule/ruleset with current-head required checks, independent non-author approval and stale-approval dismissal, required conversation resolution, and no force-push/delete/routine admin bypass; then prove enforcement with a fresh live read before closing this issue.