governance: verify effective main gate under active organization ruleset

[seonghobae]

Current effective governance

Protected main is exact 87c4daa1830bac5a5228b6036752ad5633232085 at this refresh and carries a valid GitHub signature. The effective default-branch merge authority is inherited organization ruleset 18156473, CWL Central required workflows, enforcement: active, targeting ~DEFAULT_BRANCH. The live ruleset payload was updated 2026-09-04T21:34:39.804+09:00.

The current pull-request rule requires:

• required_approving_review_count: 1;
• stale-review dismissal after pushes;
• resolved review threads;
• extra approval for unattributed changes;
• no separate latest-push approval (require_last_push_approval: false); and
• merge or squash integration methods.

The live required-workflow set is 7, all owned by ContextualWisdomLab/.github@refs/heads/main:

1. opencode-review.yml
2. pr-review-merge-scheduler.yml
3. security-scan.yml
4. strix.yml
5. sast-semgrep.yml
6. noema-review.yml
7. codeql-pr.yml

close-empty-pr.yml, scorecard-pr.yml, and osv-scanner-pr.yml are not in this exact ruleset payload; codeql-pr.yml is. Historical 6/9/10-workflow snapshots must not be carried forward after a ruleset change. The ruleset also prohibits deletion and non-fast-forward updates and exposes an OrganizationAdmin bypass; that capability is not routine merge authority for this writer.

Repository-native product gates

Protected-main repository-native CI remains separate product evidence under AGENTS.md: exact-head Python repository contracts, rustfmt, Rust tests, strict Clippy, rustdoc and independent exact production coverage must retain their own executable evidence. Applicable Manifest V3 Compatibility evidence remains separate as well.

Those repository-native product gates are not enumerated in the organization ruleset workflow array. Do not assume the central merge scheduler transitively substitutes for them without executable proof. Issue #279 separately owns safe docs-only heavy-lane partitioning; runner admission, path partitioning, central required workflows and product-source failures remain distinct causal classes.

Current blockers / owner paths

The generic one-approval requirement remains structurally incompatible with the documented solo-maintainer organization unless a genuinely independent eligible human authority exists. Central .github#772 remains the canonical repair owner: remove or replace only the impossible human-approval deadlock while preserving deterministic workflow/security/coverage/thread/branch-integrity gates, self-approval prohibition and routine bypass prohibition.

Issue #212 separately records the current MV3 sandbox-helper ownership gap: #43 proves the helper mechanics on its own leaf generation, while #148 proves that current sandbox-preserving consumer source fails closed under the unchanged protected workflow. Runner admission, workflow-source defects, human-approval governance and product-source failures remain separate causal classes.

Current exact-head OriginWeave PRs also expose a repeated central CodeQL dispatch/verdict handoff failure after successful leaf CI/Security/Semgrep. That control-plane recurrence is handed to ContextualWisdomLab/.github#712; an unavailable or unpublished central verdict remains incomplete evidence and must not be synthesized locally.

Acceptance

1. Before every integration decision, re-read protected main, the live ruleset, exact PR head/base, formal reviews, unresolved threads, repository-native product gates, and all then-required central workflows.
2. Never hard-code a historical workflow count or membership. Bind the decision to the current ruleset payload and its update time.
3. A queued, skipped, cancelled, absent, predecessor, synthetic/status-only, model-only, author-only or wrong-head result is never passing evidence.
4. Verify whether repository-native CI/exact owned-production coverage and applicable MV3 evidence are transitively enforced by the central scheduler; if not, repair governance centrally rather than weakening product evidence.
5. Follow .github#772 for the one-approval solo-maintainer deadlock. If the live approval count changes, validate that exact new rule rather than carrying the old value forward.
6. Preserve deletion/non-fast-forward protection, resolved-thread enforcement, exact-head binding, self-approval prohibition and normal merge policy. Use bypass only under a separately proven emergency/chicken-and-egg governance policy, never for routine product integration.

Keep this issue open until the effective protected-main gate is both structurally satisfiable and demonstrably enforces the intended deterministic OriginWeave product/security evidence on unchanged exact heads.

[seonghobae]

Fresh exact-head evidence for the governance owner: PR #40 is currently open/Ready/mergeable at contributor head 93ce1e7efad0a1e8c107f1f465a5260ba568d466 against protected main b05d5acca82b9d916ada2c8e82f59f92a89817e1. Repository-native runs on that unchanged head are CI 32724060308 success, Manifest V3 Compatibility 32724060309 success, SAST Semgrep 32724060294 success, and Security Scan 32724060307 success; the PR's exact coverage evidence records all four owned-production dimensions at 100%. All current inline review threads are resolved. Nevertheless the latest OpenCode formal review is CHANGES_REQUESTED on this same exact head, citing central workflow run 32785566524 because its coverage-evidence job reported failure/not-proven. That run is not a repository-local Actions run (GET /repos/ContextualWisdomLab/OriginWeave/actions/runs/32785566524 returns 404), consistent with the organization-owned required-workflow boundary. Please use this as a concrete protected-test case when verifying the effective ruleset/scheduler contract: determine why central coverage evidence failed while repository-native same-head CI/coverage succeeded, and correct the organization-owned evidence path if it is a false negative. Do not work around it in OriginWeave product code or weaken the gate; exact current-head native evidence and central evidence must both remain independently truthful.

[seonghobae]

Fresh governance evidence on 2026-08-28:

• Protected main remains 542ca1e9c0a863595b8b6697790005d2471f5413.
• Organization ruleset 18156473 (CWL Central required workflows) is active for ~DEFAULT_BRANCH; its pull-request rule requires 1 approving review, stale-review dismissal, review-thread resolution, extra approval for unattributed changes, and merge/squash only. It also requires the organization-owned workflow set and prohibits deletion/non-fast-forward updates.
• The legacy repository branch-protection endpoint returns 404 Branch not protected; this does not override the active organization ruleset.
• Repository collaborator inventory currently contains only seonghobae with admin/maintain/push permissions. There is no eligible independent collaborator for a counted non-author approval, so the documented solo-maintainer condition remains in force: no approval is manufactured or bypassed, while exact-head checks, security, coverage, rustdoc, docs, threads, and ruleset evidence remain mandatory.

No ruleset/branch-protection mutation, bypass, approval, merge, or release was attempted.

[seonghobae]

Fresh central-SAST evidence for the governance owner: PR #195 exact head 5c111d0db6c363f9d1786c21cc01c5c7398007bd has repository-native CI 33230894881, Manifest V3 33230894868, and Security Scan 33230894871 GREEN, while organization-owned SAST Semgrep run 33230894874 fails on exactly one finding: javascript.lang.security.detect-insecure-websocket.detect-insecure-websocket at crates/originweave-core/src/webdriver_bidi_websocket_endpoint.rs:54, flagging the literal ws://. Exact source inspection shows this admission type permits ws:// only inside a first-Chromium-fixture boundary that subsequently requires loopback host identity; non-loopback IPv4/IPv6/domain hosts fail closed, and later connect-target code refuses ambient DNS and preserves the TLS requirement. The scanner is applying a JavaScript insecure-WebSocket heuristic to Rust transport metadata without recognizing this bounded loopback-only authority contract. Treat this as an evidence-system false positive requiring the organization-owned SAST rule/config/suppression-contract owner to distinguish reviewed loopback-only ws:// fixtures from remotely insecure WebSockets. Do not mutate OriginWeave transport semantics or obscure the string solely to satisfy the heuristic, and do not suppress the rule repository-wide. After a central repair, rerun SAST on this unchanged exact head (or its deliberately reconstructed descendant) and require the finding to disappear while real remote insecure-WebSocket cases remain blocking.

[seonghobae]

Fresh required-workflow evidence for PR #43 (test/mv3-downloads) identifies two non-OriginWeave-local central evidence failures on exact head 28e79febd47361c5fd41e45db7e1429b179afdd1.

1. Strix run 33162899596, job 98821643829, trusted workflow source ContextualWisdomLab/.github@cdde0d82602d9568128fd0c1e985ea40b2292710: setup, trusted-source self-test, exact-head fetch, and 2-file PR scoping succeeded. The first failing boundary was the contextual-orchestrator/provider path. orchestrator/free failed three bounded attempts with LLM CONNECTION FAILED / HTTP 500 internal_error (request ids dcdd2355593c48e2863949eb51f80db1, 195d3946bcaa43d7b5fcef1a7e06583e, e7a024b3a42d4c8d88521f0ccc1591be). The central gate backed off 90s then 180s and correctly failed closed as STRIX_PROVIDER_UNAVAILABLE after attempt 3; no authoritative vulnerability report was produced. Artifact 9682593758, SHA-256 d0cc83cb97749f4ee01a07ea7f0585302c451251d5c17796a8be99f06f5ef32f. The log also reports that it could not compute the PR merge base and fell back to direct base/head diff after using stored base f658f329c83a106b68385e17cb714c4147c12f49, even though protected main is now 542ca1e9c0a863595b8b6697790005d2471f5413.

2. OpenCode required-workflow run 33162899599, job 98821429121: the job did not execute a product review; it queried reviews and failed closed because there is no APPROVED or CHANGES_REQUESTED review from opencode-agent on exact head 28e79.... Bootstrap/coverage placeholder jobs succeeded, but that is not a current-head OpenCode verdict.

OriginWeave-native CI/MV3/auditability/docs/fuzz evidence on this exact head is GREEN. The scheduled OriginWeave writer will not patch product source, central .github, reviewer identity, or provider policy to mask these failures. Please treat #43 as a current concrete acceptance case for #215: prove the central review/scanner dispatch can obtain authoritative exact-head evidence against the independently resolved live base, and keep provider-unavailable/no-verdict outcomes non-passing. After any central repair, regenerate exact-head evidence rather than reusing these failed runs.

[seonghobae]

Fresh recurrence evidence for the existing governance/provider owner lane: PR #37 exact head 5e3dfcbd7a4daea297782cb99635990368589232 has repository-native CI 33146884129, SAST 33146884200, and Security Scan 33146884229 GREEN, while central Strix workflow run 33146883118 attempt 5, job 98969892849, fails only at Run Strix (quick) after trusted-source checkout, exact-head fetch, sidecar provisioning, and Strix installation succeed. The openai/orchestrator/free path repeatedly returns contextual-orchestrator/provider LLM CONNECTION FAILED / HTTP 500 internal_error; no authoritative vulnerability report is produced, so the gate correctly remains non-passing. Latest Strix artifact 9700347198, digest sha256:d504c7fa11e61b649eede12f0211cb61a85828c9792f415d4fd465f85bd2951e. The run also reports merge-base computation failure and falls back to a direct base/head diff. Because the same provider-unavailable class was already recorded here for #43, this is now recurrent central resilience/evidence-contract data rather than an OriginWeave product defect. Please repair or harden the owning central/contextual-orchestrator provider boundary without converting provider/auth/integrity failures to success, then regenerate exact-head Strix evidence; do not add an OriginWeave leaf workaround or weaken the security gate.