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

[seonghobae]

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

1. 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.
2. 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.
3. Make the smallest central causal repair so the audit asserts the intended exact include/exclude semantics, not merely membership of ~DEFAULT_BRANCH.
4. 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.
5. 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.

[seonghobae]

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.

[seonghobae]

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.

[seonghobae]

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.

[seonghobae]

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.

[seonghobae]

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.

[seonghobae]

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.

1. 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.

2. 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.

[seonghobae]

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.

[seonghobae]

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.