fix(governance): reconcile stale stacked OpenCode ruleset audit authority #2037

Corrected owner-path finding — 2026-09-08

The original Noema handoff overstated the leaf contract. Fresh protected ContextualWisdomLab/noema@0dbfceb850cda3a016ceb39ae1c8a1a96a9f2ad5 AGENTS.md is authoritative and says Noema's inherited Security ruleset 18794436 targets ~DEFAULT_BRANCH. A deliberately stacked PR whose base is another feature branch is intentionally outside that Security rule until it is retargeted to protected main; an absent Security Scan on such a stacked head is neither success nor, by itself, a routing defect. Once retargeted to main, Security must materialize and pass on the unchanged exact head.

That is exactly what happened to noema#556: after prerequisite #535 normally merged, #556 was non-force restacked/retargeted to default main, and fresh Security Scan runs materialized. Therefore this issue must not require Security Scan on feature-base stacked PRs, and it must not recreate a broad non-default Security ruleset to satisfy the old handoff.

Remaining central owner mismatch

A narrower .github control-plane mismatch remains independently actionable. Protected central source at the last observed .github/main@7fd571dbcdbae6acf29d8f4ee704d7ba6297e4db documents/audits organization ruleset 21732164 (CWL Stacked OpenCode required workflow), while fresh repository-effective reads from Noema, naruon, scopeweave and contextual-orchestrator did not expose that ruleset; direct repository-effective lookup on the naruon sentinel returned 404. Current scripts/ci/audit_central_required_workflows.py also carries STACKED_RULESET_ID = 21732164 and an OpenCode-only stacked contract.

That remaining mismatch is about central stacked OpenCode audit/source authority, not Noema Security. It may mean the central audit/docs are stale, the organization rule is no longer intended, or an Administration-scope view is needed to establish its current existence/scope. Do not infer which one from the leaf repository.

Repair-first acceptance

1. Re-read the current protected .github AGENTS/CLAUDE/governance docs, current audit source/tests and an Administration-authoritative organization ruleset view before deciding the intended stacked OpenCode contract.
2. Reproduce the current source/live mismatch deterministically: if protected audit source still requires numeric ruleset 21732164, show whether the authoritative live organization rule exists and whether repository-effective sentinel reads are an appropriate observation surface.
3. If stacked OpenCode is no longer intended, remove the obsolete numeric-ID/source/docs/audit expectation through the canonical .github owner lane. If it remains intended, repair/adopt it through the existing governance owner plane with reviewed create/adopt semantics; do not create an ad-hoc parallel mutator.
4. Preserve the non-default branch deadlock constraint. Do not broaden Noema Security or default-branch required workflows onto every feature ref merely to make a source audit green.
5. Keep Noema's current contract unchanged: feature-base stacked heads may legitimately lack Security; after retarget to protected main, absent/queued/skipped/cancelled/failed Security is non-passing.
6. Record exact protected source, authoritative live ruleset identity/scope, tests, post-change audit evidence and a real stacked OpenCode canary if that contract remains supported.

The previous acceptance language requiring "at minimum OpenCode and Security Scan" on non-default stacked refs is superseded and must not be implemented.