fix(governance): audit must fail on non-default branch scope drift

Owner-boundary defect from a live ScopeWeave canary

This is an organization-control-plane issue, not a request for a ScopeWeave leaf workaround.

Exact consumer evidence

On ContextualWisdomLab/scopeweave#523:

protected live base: develop@2c328875e00e86537df3e965170be80532571cad;
exact contributor head: fix/server-tests-exact-head-522@2304fb64bfeccadf588db52e5d9b4bd2051af3dc;
a normal contents write to that non-default contributor branch was rejected with HTTP 409: Changes must be made through a pull request, naming the central required workflows (Close Empty PR, Required Noema/OpenCode review, merge scheduler, SAST, Security Scan, Strix, etc.);
two distinct attempts to create a child repair branch from the exact contributor head/base ref were rejected with HTTP 422 Reference update failed, and fresh branch searches proved neither requested ref was created.

This prevents the repository-owned writer from putting a verified CI-gate repair through a fresh normal PR branch.

Independently verified central audit gap

scripts/ci/audit_central_required_workflows.py correctly requires ~DEFAULT_BRANCH to be present in the ruleset ref_name.include, but it does not reject additional ref include patterns. Therefore a ruleset that contains ~DEFAULT_BRANCH plus ~ALL, a branch glob, or another unintended non-default target can pass the audit even though central pull-request/required-workflow rules are over-scoped.

This audit gap is independently actionable even if the live ruleset ultimately proves correctly scoped. The ScopeWeave write denial is a canary that makes live scope verification urgent; it is not by itself proof that ruleset 18156473 is the only possible cause.

Required repair-first investigation

Refetch live inherited organization ruleset 18156473 and its exact conditions.ref_name through the existing central owner authority. Do not infer scope from remembered policy or the audit script.
Reproduce the audit defect with a deterministic RED fixture where ref_name.include contains ~DEFAULT_BRANCH plus an unintended extra branch target. Current audit behavior should be shown to pass before the repair.
Make the smallest central causal repair so the audit asserts the intended exact include/exclude semantics, not merely membership of ~DEFAULT_BRANCH.
If live ruleset scope has drifted, repair it through normal reviewed organization governance without weakening any default-branch required workflows, review count, last-push approval, thread resolution, deletion, or non-fast-forward protection.
If live ruleset scope is already exact, keep the strengthened audit and investigate the next owner boundary: GitHub App/ref-creation permission or another repository/ruleset policy causing the 409/422 behavior. Do not change the organization ruleset merely to make the canary green.

Acceptance evidence

focused RED -> GREEN audit tests covering exact default-only scope and an extra-scope negative fixture;
full central test suite and exact-head required checks;
fresh protected-main ruleset audit bound to the live ruleset payload;
a fresh ScopeWeave canary showing a non-default proposal branch can be created and changed through a normal PR flow while develop remains fully protected;
no bypass, direct protected-branch write, force update, reduced approval requirement, or required-workflow deletion.

The ContextualWisdomLab/.github dedicated writer remains the source/settings owner for this repair. ScopeWeave should only regenerate exact-head evidence after the owner fix integrates.

GRC exact consumer canary

The GRC repository reproduced the owner-boundary failure while attempting only normal PR work:

PR 🔒 보안 취약점 픽스: subprocess.run의 shell=False 강제화 #22 exact current branch head was 9c1923e8e6f6145d0f789a97db4dd15f94f2adf3. A locally verified review-fix commit 7e04e73 was rejected when pushed to the existing feature branch with GH013: Changes must be made through a pull request, followed by the seven central required workflows being unsatisfied.
PR 보안: CI 스크립트 실행 실패 시 민감 정보 스크러빙 및 shell=False 명시 #39 baseline refresh commit 6280a17 was rejected on its existing PR branch with the same required-workflow violations.
A fresh real documentation branch push was also rejected before a PR could be created; this time the rejection named the unsatisfied central workflows.
Live inherited ruleset 18156473 was re-read from GRC on 2026-08-21: active, conditions.ref_name.include=["~ALL"], empty exclude, two approving reviews, latest-push approval, thread resolution, deletion, non-fast-forward, and seven central required workflows from .github@main.

The local fixes remain unpushed; no bypass, direct protected write, force update, or ruleset weakening was used. This is an additional exact consumer showing that the current all-ref workflow enforcement prevents both updating an existing feature PR and creating a fresh normal repair PR until the central owner-boundary repair is integrated.

Ruleset owner-boundary detail

The live GRC ruleset payload also has workflows.parameters.do_not_enforce_on_create=false. With ref_name.include=["~ALL"], this explains why a genuinely new repair branch is rejected before it can obtain the required workflow statuses. The rejection is not only the existing-branch PR-only rule.

The exact normal-governance candidate is therefore to preserve all required workflows and review/deletion/non-fast-forward protections while changing only the create-transition behavior to allow a new proposal branch to be created; subsequent PR updates and merges must remain governed. The audit should pin this field and test the create-transition contract. No live ruleset mutation was attempted.

DiskSage exact consumer canary

DiskSage independently reproduced the same create/update-transition governance failure while attempting a test-first repair on an existing PR branch.

repository: ContextualWisdomLab/disksage
protected main: 5f7c7ae38adafd1f3b3640016a8333767c89d78a
PR Fix Strix dependency lock constraints #213 branch: feat/provider-sync-dynamic-goals
exact head before the attempted write: 108bba0e4737b09b1c09f6c3b5a86a43be22223e
target regression file: src-tauri/tests/provider_evidence_retention.rs, exact blob 2804378ce5a455b0193333a2f0260a5b73dab08c

The source defect is independently verified in current #213 source: provider-evidence retention sorts records by (confirmed_at_ms, record_id) and prunes the oldest after a successful immutable evidence write without protecting the just-written path. If the host clock moves backward, the newly written attestation can therefore be deleted immediately while write_immutable_sync_evidence returns success and a now-missing path.

A RED regression was prepared to seed 128 records at timestamps 100..227, write a new record at timestamp 1, and require the returned path to remain present/readable while total retention remains 128. An ordinary Contents API update of that exact existing PR branch was rejected with HTTP 409:

Changes must be made through a pull request.

followed by unsatisfied central required workflows (Close Empty PR, Required Noema/OpenCode review, merge scheduler, SAST, Security Scan, Strix, etc.). No mutation occurred; no lower-level/ref bypass was attempted.

This is a second product family showing the live ruleset prevents the normal test-first repair path on an already-open proposal branch, not just fresh branch creation. Central acceptance should therefore cover both: (1) creation of a non-default proposal branch and (2) subsequent normal commits to that branch while default-branch required workflows/review/deletion/non-fast-forward protections remain intact. Once the central owner repair integrates, DiskSage will retry the same RED regression on the unchanged/revalidated #213 lane and regenerate exact-head evidence.

Canonical owner repair is now on #1176 at exact head b628e88871ecc845a46989bde48b15292a41690e.

Test-first evidence:

RED: 8 focused failures against the predecessor, including ~ALL false acceptance and missing create-transition validation;
GREEN: 19 focused tests;
full suite: 1,300 tests + 16 subtests;
central coverage: 8,126 statements / 3,146 branches, 100%;
exact ref contract: only ["~DEFAULT_BRANCH"] with empty excludes; ~ALL, extra targets, globs, strings, and exclusions fail;
create contract: workflows.parameters.do_not_enforce_on_create must be true;
two approvals, stale-review dismissal, last-push approval, thread resolution, seven required workflows, deletion, and non-fast-forward protections remain required.

The live organization ruleset and ScopeWeave canary remain acceptance work after reviewed integration; no consumer source or protected branch was changed.

Fresh ScopeWeave update-transition canary

The previously blocked existing non-default branch update path is now passing for ScopeWeave without bypass or ruleset weakening.

Fresh evidence:

protected ScopeWeave base remains develop@2c328875e00e86537df3e965170be80532571cad;
PR ContextualWisdomLab/scopeweave#523 remains on fix/server-tests-exact-head-522;
starting observed contributor head for this repair sequence was 2304fb64bfeccadf588db52e5d9b4bd2051af3dc;
ordinary repository Contents API commits to that same existing proposal branch succeeded, ending at exact current head 95a15bc7413867fef1535ef4bcea4eab2478460c;
the commits added a Dependency Review exact-head/live-base regression, registered it in the canonical unit chain, then repaired .github/workflows/dependency-review.yml to exact-head checkout + runtime SHA attestation + independently resolved live base + fail-closed unavailable comparison evidence;
no force update, protected-branch write, bypass, temporary competing writer, gate deletion, or approval manufacture was used.

This narrows #1200 acceptance: the historical existing-branch update failure is no longer reproducible on this ScopeWeave lane. Fresh new proposal-branch creation remains untested from the ScopeWeave writer because creating a disposable/competing branch solely as a canary would violate its current single-writer/no-temporary-writer operating contract.

Owner-side acceptance is therefore still: integrate/review the canonical .github#1176 repair, refetch the live ruleset payload, prove the create-transition contract through the central owner authority, then let ScopeWeave regenerate exact-head checks on its unchanged/revalidated head. Current ScopeWeave runs for 95a15bc7413867fef1535ef4bcea4eab2478460c are queued and remain non-passing until they actually execute.

Current owner-path exact-head failures on #1176

Fresh evidence on canonical owner PR #1176 exact head f0bef61ba0898ae118d0262ffd6fbf4b8bf4a256 shows the governance repair itself is now blocked by two deterministic owner-repository failures; these are not ScopeWeave-local and should be repaired on the existing #1176 lane rather than by consumer retries.

Strix Changed Path Quality CI run 32505883021, job 96845819375 checked out the exact head and passed the full Python suite (1302 passed, 16 subtests) before scripts/ci/test_strix_quick_gate.sh failed two scheduler contract checks. The first failing boundary is .github/workflows/pr-review-merge-scheduler.yml: the test expects manual repository_dispatch queue scans to be isolated per run (github.event_name == 'repository_dispatch' && github.run_id) and expects the narrower cancellation expression cancel-in-progress: ${{ github.event_name == 'pull_request_target' || github.event_name == 'pull_request_review' || github.event_name == 'repository_dispatch' }}. The current merged-in scheduler instead groups generic repository dispatches by repository and also cancels workflow-run-without-PR scans. Treat the quick-gate failures as RED; reconcile current scheduler semantics with the contract at the owning central branch, preserving targeted/org-sweep concurrency behavior, then require the same exact-head quick gate + full suite GREEN.
Python Security run 32505882872, job 96850547285 failed pip-audit on exact merge result 5bc553ec4e98266e5e1d5fb070fb8a0a14a2fb0d: requirements-pip-audit-ci-hashes.txt pins pip==26.1.2, flagged as PYSEC-2026-3721, fixed in pip>=26.2. All other audited requirement sets shown in the log were clean. Smallest remedy is to regenerate the pip-audit CI lock/hash set with a non-vulnerable compatible pip release (>=26.2), preserving --require-hashes, then require installation and full pip-audit GREEN on the updated exact head.

Do not merge #1176 or treat predecessor evidence as current acceptance until both failures are root-cause repaired and all exact-head required checks plus qualifying independent reviews are terminal-passing. Once integrated, the consumer acceptance remains: re-read ruleset 18156473, prove normal non-default ScopeWeave branch creation/update without bypass, then regenerate ScopeWeave #523 exact-head checks.

Fresh owner-path narrowing on #1176

Current canonical owner PR #1176 is now at exact contributor head 6bf0447388c08f699f9550e4ed4f71c84fb4c723. Fresh exact-head workflow evidence materially narrows the remaining owner repair: Strix Changed Path Quality CI is now terminal success (32516562031), as are OSV, commercial-readiness quality, artifact/SBOM quality, mention-router quality, Secret Scan, SAST, Security Scan, Scorecard, SBOM generation, and CodeQL. Python Security remains terminal failure at run 32516562095 on this exact head.

The previously established first failing causal boundary remains owner-side requirements-pip-audit-ci-hashes.txt: the prior exact failure pinned vulnerable pip==26.1.2 (PYSEC-2026-3721, fixed in pip>=26.2). Treat the current Python Security failure as continuing RED evidence unless a fresh current-head log disproves that cause. The smallest repair remains to regenerate that dedicated pip-audit CI lock/hash set with a compatible non-vulnerable pip release while preserving --require-hashes, then require install + full pip-audit GREEN and refetch every exact-head gate/review on #1176. Do not alter consumer repositories or weaken the ruleset to make the check pass.

This comment only advances the existing owner control path; ScopeWeave source ownership remains with its dedicated writer.

DiskSage stacked-PR required-workflow canary

A fresh DiskSage stack shows the complementary failure mode of the current all-ref central workflow/ruleset contract: a non-default-base PR can have source changes but never receive the centrally injected Security Scan/SAST runs that the parent receives when targeting main.

Exact consumer evidence:

protected DiskSage main: 5f7c7ae38adafd1f3b3640016a8333767c89d78a;
parent PR ContextualWisdomLab/disksage#213: base main, exact head 0584bcc600e037d564a4ff254b6e8570361d9218; exact pull-request runs include Test 32531994023 SUCCESS, Release 32531994176 SUCCESS, Security Scan 32531993877 SUCCESS, and SAST Semgrep 32531994078 SUCCESS;
stacked PR ContextualWisdomLab/disksage#247: base feat/provider-sync-dynamic-goals@0584bcc600e037d564a4ff254b6e8570361d9218, exact head 61058e6fb4596c5c0b4916a54595a4e573e9d3ed; it changes 18 files / +674 -54 and its exact pull-request runs contain only Test 32560957112 SUCCESS and Release 32560957027 SUCCESS. Security Scan and SAST are absent, not pending or skipped;
the exact Fix Strix dependency lock constraints #213/fix: approve reviewed merge-update fallback #247 repository trees contain only DiskSage-owned hourly-product-loop.yml, release.yml, and test.yml. The Security Scan/SAST workflow IDs are therefore centrally injected owner-controlled evidence, not a missing DiskSage workflow file.

This means an inherited ruleset scoped to ~ALL can require central workflows on proposal refs while a stacked PR targeting a non-default branch does not produce at least Security Scan/SAST statuses. That creates an unsatisfiable normal stack lane: the consumer cannot correctly add a local substitute without duplicating/bypassing the central contract.

Acceptance test for the central owner repair should therefore include a real stacked PR canary: source-changing child PR -> non-default parent branch must receive the same applicable central required workflow identities on the child exact head, or the ruleset must explicitly avoid requiring identities that the central trigger cannot emit for that ref/PR shape. Preserve default-branch protection, review requirements, last-push approval, thread resolution, deletion/non-fast-forward protection, and do not weaken Security/SAST themselves.

DiskSage did not add a leaf Security/SAST workflow or mutate central source/settings; dependency latency blocks only this stacked lane.

Fresh ScopeWeave owner-path retry: canonical repair PR #1176 is still open, but its live identity has moved again. Current connector state is head 5b2a2163eead22ffe0a65708cd4136e51afe291a, base field 4c33442021d63b09f35a874c5e7a779dd46ef8f2, and mergeable=false; the PR body still describes predecessor head/base values. All currently associated repository-native runs on 5b2a2163... are terminal success (including central SAST/Security/CodeQL/SBOM/quality lanes), but mergeability/current formal review remain the first live integration boundary. Please keep the existing #1176 lane repair-first: refetch live main and the intervening delta, reconcile the same branch non-destructively if the semantic #1200 fix is still intact, regenerate exact-current-head evidence, then obtain the required independent current-head verdict and integrate normally. After protected integration, the acceptance canary remains unchanged: refetch ruleset 18156473, require exact default-branch-only ref scope plus do_not_enforce_on_create=true, then prove a fresh non-default ScopeWeave proposal branch can be created and subsequently updated without bypass while protected develop retains the full required-workflow/review/deletion/non-fast-forward gate. Do not weaken or duplicate the central ruleset.

Canonical owner branch reconciled to current protected main

PR #1176 is now exact head 49f6988795262194e4eda8b3ea7319b7b39c4e77 against protected base 885f2cd251999f21cf562cab3e2d9cc3cc3ec737 via a non-forced two-parent merge. The resulting PR is mergeable and changes exactly two owner paths:

scripts/ci/audit_central_required_workflows.py
tests/test_central_required_workflow_ruleset_audit.py

The retained contract requires ref_name.include == ["~DEFAULT_BRANCH"], empty excludes, and workflows.parameters.do_not_enforce_on_create == true; ~ALL, extra/glob targets, string scope, exclusions, and a blocked create transition remain deterministic failures. All currently materialized exact-head security/SBOM/CodeQL checks are terminal success and unresolved review threads are zero. A fresh exact-head formal OpenCode review/coverage run has been requested. Keep #1200 open through protected-main integration, live ruleset 18156473 revalidation, and a fresh create-then-update proposal-branch canary.

Central owner PR #1176 is now synchronized non-destructively to protected main@bdd8d72e731d47879819b436670b74da0053b3ed at exact head 2f16ea928fa24f386775f6bcc82ed0baed1fd2f7. The merge-result delta is limited to the ruleset audit source and its regression suite. Focused create-transition/ruleset audit: 20 passed; full central suite: 1,402 passed, 1 skipped, 16 subtests. Hosted exact-head workflows are queued and therefore non-passing. This does not close #1200: acceptance still requires reviewed protected-main integration, live ruleset 18156473 payload revalidation, and a fresh ScopeWeave proposal-branch create/update canary without bypass.

Fresh owner-boundary evidence from the ScopeWeave delivery lane confirms that #1176 is currently blocked by a protected-main Strix routing defect, not by its governance patch.

Exact evidence:

.github#1176 exact head 55a6a796d453ca4718859889fbbd4b416c20ebf1, live base main@613a33e0cb1c6db9790fae99f6253445712ac37a;
failing pull_request_target Strix run 32720645174, job 97411134879 fetched the trusted protected source and exact target head correctly;
primary nvidia_nim/nvidia/nemotron-3-super-120b-a12b returned HTTP 429 repeatedly;
NIM fallback nvidia_nim/nvidia/llama-3.3-nemotron-super-49b-v1.5 produced zero-vulnerability model output but the provider chain still continued/fail-closed;
final openai-direct/gpt-5.6-luna was given the OpenAI fallback key while inheriting LLM_API_BASE=https://integrate.api.nvidia.com/v1, so NVIDIA returned 404 page not found.

The same self-hosting boundary is independently reproduced by .github#1299 exact head b92648e1df52a9213f46dcbe88e9fc448f6d54a7, pull_request_target run 32719334448, job 97407200513: its PR-head workflow is materialized only for smoke validation, while the trusted protected-main Strix implementation that actually executes still routes the direct-OpenAI fallback through the NVIDIA base and fails 404. Therefore rerunning #1176 before the protected-main Strix repair integrates would only reproduce the same deterministic failure.

The current bounded owner candidate .github#1295 is open/mergeable at exact head cdf15180c37c3bbcb1e5fe2c48ece5ce006a6606. Its gate-script repair makes explicit openai_direct/* / openai-direct/* models resolve to no custom API base, preserving NIM/Vertex/GitHub Models routing and fail-closed semantics; its exact-head PR workflows are terminal-success, including Strix Changed Path Quality CI run 32723442486. #1299 contains additional workflow/base-file plumbing, but its own PRT failure is predecessor trusted-main behavior, not evidence that the PR-head implementation can authorize itself.

Please keep this in the existing central owner lane: canonicalize the smallest root-cause repair (preserving any unique useful regression/validation from the overlapping candidate), land it through normal reviewed protected-main governance, then regenerate #1176 evidence without changing its governance source. Acceptance for this dependency is a fresh downstream Strix run that proves (1) the exact #1176 contributor SHA was actually scanned, (2) direct OpenAI fallback uses the OpenAI platform endpoint rather than the NVIDIA base, (3) provider/outage states still fail closed, and (4) no predecessor or self-smoke success is transferred as downstream authorization. No ScopeWeave-local workaround or gate weakening is appropriate.

Fresh live ruleset regression from Orgmetra canary — review semantics weakened

A fresh supported read of inherited organization ruleset 18156473 — CWL Central required workflows from ContextualWisdomLab/Orgmetra now shows an exact effective-policy regression that belongs to this existing central owner boundary:

enforcement: active
scope remains exactly conditions.ref_name.include = ["~DEFAULT_BRANCH"], exclude = []
pull-request rule now reports required_approving_review_count: 1
dismiss_stale_reviews_on_push: true
require_last_push_approval: false
required_review_thread_resolution: true
require_extra_approval_for_unattributed_changes: true
OrganizationAdmin remains bypass_mode: always; current_user_can_bypass: always
ruleset updated_at: 2026-08-25T15:02:57.831-07:00

This conflicts with the intended central governance repeatedly documented in this owner issue family: do not reduce the approval requirement and do not weaken last-push approval while repairing ruleset scope/audit behavior. Orgmetra-local code/workflows cannot correctly repair an inherited organization ruleset.

RED acceptance: central ruleset/audit policy must fail if the live default-branch ruleset drifts below the intended independent-review count or disables required post-last-push approval semantics. A ruleset with exact default-only scope is not sufficient if its PR review parameters are weakened.

Smallest owner repair: restore the intended organization-level review parameters on ruleset 18156473 through the existing reviewed governance/settings owner path, and strengthen the central audit so it validates the exact required approval count and last-push-approval boolean in addition to exact ref scope. Preserve stale-review dismissal, conversation resolution, all central required workflows, deletion/non-fast-forward protection; do not use admin bypass.

Required GREEN proof: fresh API read of ruleset 18156473 showing the intended review count and last-push requirement, focused RED→GREEN audit regressions for count/last-push drift, full central exact-head checks, then unchanged downstream canaries. This comment advances the existing owner path only; no .github source/ref/workflow/PR state or organization settings were mutated from the Orgmetra loop.

DiskSage Strix required-workflow consumer canary — provider chain is currently non-executable

This is a read-only consumer handoff from ContextualWisdomLab/disksage; no .github source/settings mutation is requested from the DiskSage writer.

Exact affected consumer

repository/PR: ContextualWisdomLab/disksage#264
protected base: main@79067c1160ddedf7fc962cbf8067ce7e83c4564a
exact PR head: 5e7b33de8df7f7ce0c011837c2a9139ae7a16a75
central workflow source: ContextualWisdomLab/.github/.github/workflows/strix.yml@60a34005e59efe2b622897e3c7b06882bdf63aee
central Strix run: 32952499704
exact Strix job/check: 98194496006
job conclusion: failure

First failing boundary / causal evidence

Primary nvidia_nim/nvidia/nemotron-3-super-120b-a12b repeatedly fails with HTTP 429 Too Many Requests.
Configured NIM fallback nvidia_nim/nvidia/llama-3.3-nemotron-super-49b-v1.5 is no longer executable: NVIDIA returns HTTP 410 Gone and states the model reached end of life at 2026-08-26T09:00:00Z.
Final fallback openai-direct/gpt-5.4 reaches OpenAI but fails HTTP 400 because Strix uses function tools with reasoning_effort through /v1/chat/completions; the provider says this combination is unsupported and requires /v1/responses or reasoning_effort='none'.
The central workflow then correctly fails closed as STRIX_PROVIDER_UNAVAILABLE; no authoritative vulnerability report exists. Intermediate Vulnerabilities 0 output is therefore not clean security evidence.

This proves the blocker is the central Strix provider/model contract, not DiskSage #264's release-verifier source. The same consumer head's repository-owned Test/Release/Security/SAST are terminal-success.

Smallest owner-side remedy candidates

Remove/replace the retired NVIDIA fallback rather than retrying a permanently 410 model.
Make the direct OpenAI fallback use a Strix/provider combination that supports function tools (e.g. Responses API) or set reasoning_effort to a supported value for the current Chat Completions path.
Preserve the existing fail-closed rule: provider exhaustion/configuration failure must never be converted into passing security evidence.

Acceptance test
Re-run the inherited Strix required workflow against unchanged DiskSage #264 head 5e7b33de8df7f7ce0c011837c2a9139ae7a16a75 and require: exact target SHA attribution; terminal SUCCESS; a structured authoritative Strix report; no STRIX_PROVIDER_UNAVAILABLE; no retired-model 410; no gpt-5.4 function-tools/reasoning-effort 400; and no weakening/removal of the Strix gate. If provider capacity is still exhausted, the check must remain non-passing.

Fresh live review-control drift on ruleset 18156473

A current ScopeWeave consumer refetch of the inherited organization ruleset shows the create/scope repair is live, but two default-branch review protections have drifted below the canonical owner contract.

Exact live payload observed from ContextualWisdomLab/scopeweave:

ruleset 18156473, active, organization source;
ref_name.include=["~DEFAULT_BRANCH"], exclude=[];
required workflows do_not_enforce_on_create=true;
required_approving_review_count=1;
require_last_push_approval=false;
dismiss_stale_reviews_on_push=true and required_review_thread_resolution=true remain enabled.

This disagrees with the canonical audit at current owner PR ContextualWisdomLab/.github#1176@36d4fecd42d692f752afd2c4a8dee86dcefe92c3, where scripts/ci/audit_central_required_workflows.py explicitly requires exactly two approvals and last-push approval=true while preserving stale-review dismissal and thread resolution.

This is not a ScopeWeave-local defect and should not be worked around in consumers. Treat the live ruleset payload itself as RED owner evidence: refetch through organization authority, determine whether the settings drift is an incomplete/out-of-band application of the #1176 contract, and restore only the intended review protections through normal central governance if the live payload is authoritative. Preserve the now-correct default-only ref scope, do_not_enforce_on_create=true, all seven required workflows, deletion and non-fast-forward controls. GREEN should include the central audit against the actual post-change live payload and a fresh consumer refetch proving the ruleset matches the reviewed contract before ScopeWeave relies on it for protected integration.

Fresh live ruleset + proposal-branch acceptance (2026-08-28 KST)

The create-transition part of this owner defect is now operationally repaired.

inherited organization ruleset 18156473 is active with exact ref_name.include=["~DEFAULT_BRANCH"], exclude=[];
its required-workflow rule now has do_not_enforce_on_create=true;
ScopeWeave owner PR feat(wbs): add first-visit sample onboarding scopeweave#624 was created from non-default proposal branch feat/static-onboarding at 2026-08-28 12:48:05 KST;
that existing proposal branch was then updated normally to exact head 69eff955bc16295a6d82b72174b25d8ec94345c1 at 2026-08-28 17:55:50 KST, and the live branch ref and PR head both resolve to that SHA.

This is read-only consumer acceptance; no ScopeWeave source/ref was mutated by the central writer.

Keep #1200 open because the same live ruleset still contradicts the canonical protected-default-branch review contract in .github#1176: required_approving_review_count=1 and require_last_push_approval=false, while the executable audit requires exactly 2 approvals and last-push approval. Scope/create-transition is green; review-strength convergence remains non-passing.

Fresh repository-level overlap in default-branch review controls (2026-08-30 KST)

A supported live read of the active repository ruleset 17921150 on ContextualWisdomLab/.github exposes an additional owner boundary that must be included in #1200 convergence:

enforcement=active;
exact scope ref_name.include=["~DEFAULT_BRANCH"], exclude=[];
deletion and non-fast-forward protections remain enabled;
pull-request rule has required_approving_review_count=0;
require_last_push_approval=false;
stale-review dismissal and required thread resolution remain enabled;
live ruleset updated_at=2026-08-18T00:45:50.341-07:00.

This repository-level rule overlaps the inherited organization rule already recorded here (1 approval / last-push false) and is weaker than the reviewed executable contract (2 approvals / last-push true). Effective protection must be evaluated across both layers; validating only organization ruleset 18156473 is insufficient.

Keep the now-green default-only scope/create transition intact. The smallest owner repair is to converge the effective default-branch review semantics through normal settings governance and extend the audit/acceptance evidence to enumerate every active applicable ruleset. No bypass, reduced workflow set, or consumer-local workaround is acceptable.

Canonical owner PR advanced with repository-ruleset audit

PR #1176 now points at exact head 2a9d115813b814af2aaaa0763b175f2d65b72f79 on protected main@6c8ee24046d743b3981c566c6e29f99f09137f6a. The ref advanced non-force; commit tree 8a2cde46a36af04076b510fbe2688f893c0b45d0 and both parents were independently verified.

Fresh root-cause confirmation: the protected-main audit covered the inherited organization/stacked rulesets but did not fetch the .github repository ruleset 17921150. The live local ruleset remains active/default-only yet requires 0 approvals and no last-push approval, so this layered weakening was invisible to the central audit.

The smallest owner-boundary repair is now on #1176:

protected-main workflow fetches and audits repository ruleset 17921150;
auditor fails closed unless repository identity/scope/enforcement, two approvals, stale-review dismissal, last-push approval, thread resolution, merge/squash, deletion, and non-fast-forward controls match the contract;
existing default-only/create-transition and inherited/stacked audits remain intact.

TDD evidence:

RED: 2 focused missing-entry-point failures plus a failing workflow-wiring contract;
GREEN: 31 focused tests;
focused auditor coverage: 232/232 statements and 124/124 branches;
full tests: 1,883 passed, 1 skipped, 17 subtests;
compile and diff checks pass.

Repository-wide deterministic coverage is still non-passing at 99% because scripts/ci/pingora_edge_policy.py:274 has one unmeasured statement/branch owned by active #1398. Current-head hosted evidence is still regenerating and no qualifying exact-head formal approval exists, so #1176 was not merged and this issue remains open.

No live ruleset mutation, bypass, force update, protected-branch write, consumer-source change, or gate reduction was used.

Review-driven audit hardening at exact head `4ae3c618`

Fresh review exposed three additional false-negative paths in the canonical #1176 audit, all reproduced before repair:

an eighth valid required-workflow path and malformed extra entries could escape the seven-workflow contract;
allowed_merge_methods=[merge,squash,rebase] passed despite the documented merge/squash-only policy;
repository ruleset bypass actors were not audited, although the canonical governance record requires none.

Exact current source now rejects all three. RED produced 3 focused failures; GREEN is 35 focused tests with 241/241 auditor statements and 130/130 branches, plus 1,887 full-suite passes, 1 skip, and 17 passing subtests. The branch advanced non-force to 4ae3c6184ae96b588e98ac1e66820a63bdc9ca24; tree f03e6bacfc0269059d5ea33c0bd5de40898b8030 and parent 2a9d1158 were revalidated.

The live repository ruleset was re-read immediately before this note and still reports approvals 0, last-push approval false, rebase enabled, and OrganizationAdmin/always bypass. No setting was mutated. Hosted exact-head checks are regenerating, repository-wide coverage remains non-passing only at the #1398-owned Pingora line, and exact-head approval is absent, so #1176 was not merged and #1200 remains open.

Inherited bypass gap closed in source at `d2224010`

The first post-write sweep re-read organization ruleset 18156473 through ScopeWeave and found the same OrganizationAdmin/always bypass actor that the organization auditor did not reject. A deterministic RED fixture confirmed the false-negative. #1176 now audits bypass actors on both organization and repository rulesets and advanced non-force to exact head d2224010a7eafa5ff23682521e10cbf09f94b5b1; tree 4818cb8fad10065d95968adcaaab367c7f655d13 and parent 4ae3c618 match the independently built objects.

Final local evidence is 36 focused tests, 243/243 auditor statements, 132/132 branches, and 1,888 full-suite passes plus 17 passing subtests. Repository-wide coverage remains explicitly non-passing only at #1398-owned pingora_edge_policy.py:274. The live rulesets were not mutated, exact-head hosted evidence is still regenerating, and no exact-head approval exists; #1200 therefore remains open.

Owner PR #1176 advanced by non-force fast-forward to exact head 0b0a45b34aa135f10db82d2a81d685f2d5f64980 (tree e53c3cd497e3c1718d91fb0767023e1f1a6142ae). A fresh review exposed that omitted bypass_actors evidence was accepted as an empty list. RED fixtures reproduced the fail-open behavior for both inherited organization and repository rulesets; the narrow repair now accepts only explicit bypass_actors: [], so missing, malformed, or non-empty evidence fails closed. Focused ruleset audit: 38 passed with 243/243 statements and 132/132 branches; full central suite: 1,890 passed, 1 skipped, 17 subtests. Current threads are resolved. Hosted exact-head checks and independent formal review remain required; live ruleset approval/latest-push/bypass contradictions remain non-passing, so #1200 stays open.

GRC develop merge-policy scope observation — October 10, 2026

Consumer: ContextualWisdomLab/governance-risk-compliance#76, target develop@529cf321f134e26c0cd379ee53c06ab5297363b6, now published head faa716323f3ba6efe9c53010f8a0bdd047a4cfa0. Project AGENTS forbids bypass of protection/checks/independent review. The solo maintainer requests normal merge, independent Noema/OpenCode auto review, not a fictitious second human.

Fresh parent GraphQL confirms zero repository branchProtectionRules; default branch develop. Independent readonly audit at2026-10-10T14:07Z observed develop protection404, effective branch rules[], repository/inherited rulesets[]. Parent REST refetch at14:19Z was rate-limited403, not a reconfirmation of inherited absence. No settings changed. Empty protection is not permission to merge an unverified candidate.

Please return canonical applicable enforcement and the owned repair path for this exact develop target, reconciled with solo-maintainer issue772 and independent App/deterministic evidence. Preserve product/security/current-head checks, stale-review/thread resolution and branch-integrity controls. Do not impose impossible fictional-human requirements or count skipped/model-only evidence as pass. GRC source lane will not alter global settings.

Predecessor Product/CodeQuality jobs113305262705/113305250621 had no runner or steps due to billing lock. Independent source repair158tests/100%coverage passed on S1; current docstring-only delta also158passed/100% and approved with executable AST equality. This is not qualifying App approval or remote CI. Central GRC producer2602 still Draft and isolated runner admission ops326 pending.

Requested receipt: policy custodian, consumer accepted/denied/pending scope, reviewed settings/source revision, exact required evidence consumers, and live effective develop enforcement readback. No admin/force merge, self-approval or fabricated status requested.

Navigation Menu

Repository navigation

fix(governance): audit must fail on non-default branch scope drift #1200

Owner-boundary defect from a live ScopeWeave canary

Exact consumer evidence

Independently verified central audit gap

Required repair-first investigation

Acceptance evidence

GRC exact consumer canary

Ruleset owner-boundary detail

DiskSage exact consumer canary

Fresh ScopeWeave update-transition canary

Current owner-path exact-head failures on #1176

Fresh owner-path narrowing on #1176

DiskSage stacked-PR required-workflow canary

Canonical owner branch reconciled to current protected main

Fresh live ruleset regression from Orgmetra canary — review semantics weakened

DiskSage Strix required-workflow consumer canary — provider chain is currently non-executable

Fresh live review-control drift on ruleset 18156473

Fresh live ruleset + proposal-branch acceptance (2026-08-28 KST)

Fresh repository-level overlap in default-branch review controls (2026-08-30 KST)

Canonical owner PR advanced with repository-ruleset audit

Review-driven audit hardening at exact head `4ae3c618`

Inherited bypass gap closed in source at `d2224010`

GRC develop merge-policy scope observation — October 10, 2026

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

fix(governance): audit must fail on non-default branch scope drift #1200

Description

Owner-boundary defect from a live ScopeWeave canary

Exact consumer evidence

Independently verified central audit gap

Required repair-first investigation

Acceptance evidence

Activity

seonghobae commented on Aug 21, 2026

GRC exact consumer canary

seonghobae commented on Aug 21, 2026

Ruleset owner-boundary detail

seonghobae commented on Aug 21, 2026

DiskSage exact consumer canary

seonghobae commented on Aug 21, 2026

seonghobae commented on Aug 21, 2026

Fresh ScopeWeave update-transition canary

seonghobae commented on Aug 21, 2026

Current owner-path exact-head failures on #1176

seonghobae commented on Aug 21, 2026

Fresh owner-path narrowing on #1176

seonghobae commented on Aug 22, 2026

DiskSage stacked-PR required-workflow canary

seonghobae commented on Aug 22, 2026

seonghobae commented on Aug 23, 2026

Canonical owner branch reconciled to current protected main

seonghobae commented on Aug 24, 2026

seonghobae commented on Aug 24, 2026

seonghobae commented on Aug 25, 2026

Fresh live ruleset regression from Orgmetra canary — review semantics weakened

seonghobae commented on Aug 26, 2026

DiskSage Strix required-workflow consumer canary — provider chain is currently non-executable

seonghobae commented on Aug 27, 2026

Fresh live review-control drift on ruleset 18156473

seonghobae commented on Aug 28, 2026

Fresh live ruleset + proposal-branch acceptance (2026-08-28 KST)

seonghobae commented on Aug 29, 2026

Fresh repository-level overlap in default-branch review controls (2026-08-30 KST)

seonghobae commented on Aug 30, 2026

Canonical owner PR advanced with repository-ruleset audit

seonghobae commented on Aug 30, 2026

Review-driven audit hardening at exact head 4ae3c618

seonghobae commented on Aug 30, 2026

Inherited bypass gap closed in source at d2224010

seonghobae commented on Aug 30, 2026

seonghobae commented on Oct 10, 2026

GRC develop merge-policy scope observation — October 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Review-driven audit hardening at exact head `4ae3c618`

Inherited bypass gap closed in source at `d2224010`