Skip to content

chore(governance): protect main and enforce release checks #27

Description

@seonghobae

Live governance observation — 2026-09-07 KST

Noema protected source remains GitHub-verified main@e26d771470a4ece873c367b40b3cd6cb03ac7de3, the normal merge commit for #527. The branch API reports protected: true, while its classic protection summary reports protection.enabled: false with no classic required-status contexts. This does not mean the default branch is wholly unprotected: the repository-effective organization ruleset 18794436 remains the positively observed authority requiring central .github/workflows/security-scan.yml@refs/heads/main, with no configured bypass actor in the prior fresh ruleset observation and current actor bypass reported as never.

That evidence proves only the central Security Scan requirement and the observed absence of a configured bypass actor for that rule. It still does not prove required pull requests, approval counts, stale-review dismissal, conversation resolution, non-fast-forward/force-push protection, protected-branch deletion protection, administrator bypass controls, or an authorized break-glass route. Those stronger controls remain fail-closed/unproven until independently configured and behaviorally verified.

Protected central .github/main is now GitHub-verified ad0779bee66624c3997947d7691f4b0dbb973be1. Protected Noema still carries the earlier integrated central trust binding; PR #554 exact 888828dc35a6a45400c3e7fc5784ec7968fa2ba9 owns the narrow fail-closed OIDC job_workflow_sha roll-forward to ad0779b.... Its current exact-head application CI 34046378057, reviewer-ci 34046378191, required Security Scan 34046378099, and patch-validator-image 34046378064 are non-terminal. Current CI job 101522050369 and Security scope job 101522051034 have steps=[], runner_id=0, empty runner identity, and started_at == created_at; they are incomplete runner-assignment evidence, not failures and not PASS. Therefore the new central trust source remains candidate authority, not protected Noema truth.

#527 is merged: branch head d289bfcdb617249c90f9fcc1ba050a59334d07fd became protected merge commit e26d771470a4ece873c367b40b3cd6cb03ac7de3. Repository-wide semantic-review prerequisite #546 and runner-assignment evidence #533 are also protected lineage. Their source contracts do not create stronger GitHub branch-governance controls by themselves.

A fresh protected-source read-only governance audit remains bound to exact Noema main@e26d771..., live branch-protection/ruleset evidence, exact central source observation, and release state. Result: the central Security Scan rule is the only positively evidenced enforceable branch rule from the available live surface; stronger PR/review/history/deletion controls remain absent or unproven. Central source movement to ad0779b... creates a separate Noema trust prerequisite now owned by #554; it does not strengthen branch governance by itself.

Problem

Noema requires an enforceable and independently evidenced protected-main governance contract. Repository source can audit live evidence fail closed, but it cannot manufacture organization rules, independent reviewers, bypass policy, App installation, administrator settings, or production-environment controls.

The current live state is therefore only partially complete: the organization required Security workflow is real in the observed ruleset surface, while the stronger pull-request/review/history-rewrite/deletion governance target is not evidenced by the currently returned ruleset/classic-protection surface.

Acceptance criteria

Live ruleset / branch protection

  • Preserve prior governance observations as dated evidence rather than evergreen authority.
  • Freshly read repository-effective organization ruleset 18794436, including target, required workflow, bypass actors, and current-user bypass state.
  • Freshly read the default-branch protection summary and record that protected: true currently coexists with protection.enabled: false; do not misclassify the organization workflow ruleset as classic branch protection.
  • Configure and independently verify a rule requiring pull requests for ordinary protected-main changes, with only an explicit auditable break-glass path if one is authorized.
  • Require at least one eligible independent non-author approval once a real reviewer route exists and live policy actually configures that requirement.
  • Dismiss stale approvals when source head changes.
  • Require conversation resolution.
  • Prevent force pushes/non-fast-forward protected-main rewrites and protected-branch deletion.
  • Independently verify administrator/break-glass bypass behavior rather than infer it from the required-workflow ruleset.

Repository-owned governance audit

  • Keep current truth and stronger target policy separate.
  • Keep formal reviews, checks/statuses, scanners, model judgements, merge authority, release, deployment, and production evidence as distinct classes.
  • Preserve fail-closed behavior when live governance evidence is absent, malformed, stale, or inconsistent.
  • Preserve exact submitted-head Security Scan evidence from the current central workflow generation; predecessor scanner evidence never transfers across source movement.
  • After fix(trust): rebind audited central workflow source #527 and fix(reviewer): fail closed on empty CodeGraph semantics #546 reached protected truth, run a fresh protected-source governance/readiness audit bound to exact Noema main, exact central workflow source observation, observation time, and live ruleset response. The 2026-09-06 audit is read-only API evidence and records a FAIL/incomplete stronger-governance result rather than promoting desired policy to current truth.
  • Integrate fix(trust): roll audited central workflow source to c9052e6 #554 only after one unchanged exact head reaches terminal application CI/reviewer/Security/image success and fresh review/live-base authority remains clear; then re-run the read-only audit against the new protected Noema trust source.
  • Run the protected-main governance operator under an authorized live credential and retain bounded evidence of controls that cannot be proven from the read-only API surface.

Behavioral proof for stronger target policy

  • Pending/failed/absent/stale required evidence cannot merge.
  • Source-head movement invalidates predecessor evidence and, once configured, stale approval.
  • Author/self/model/status/check evidence cannot satisfy independent approval once live policy requires it.
  • Normal direct push, force push/non-fast-forward rewrite, and protected-main deletion are rejected.
  • Break-glass use, if any, is attributable, bounded, and independently reviewed.

Current merge discipline

Keep active source Drafts non-promotable until dependency order is satisfied, every applicable unchanged-current-head CI/reviewer/central-security/image/package/SBOM/vulnerability/provenance gate is terminal-clean, exact owned-code coverage/docstring obligations are proven, current findings/threads are resolved, and live base/governance are freshly unchanged. A queued/in-progress image, old successful run, stale ruleset observation, model judgement, or missing authority never becomes PASS by documentation.

Guardrails

Do not infer protections the APIs do not show, turn desired future governance into fake current requirements, manufacture reviewer/App authority, weaken the required central Security workflow, self-approve, force-push/destructively rebase, or mutate central .github implementation from the Noema writer. Organization/admin configuration that source cannot perform remains an explicit external-control blocker for this governance lane only.

Related: #5, #29, #30, #40, #73, #96, #227, #527, #533, #546, #554; ContextualWisdomLab/.github#712.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: authAuthentication, authorization, identity, or tenant isolationarea: ci-cdCI, GitHub Actions, checks, release, or supply chainarea: dependenciesDependency or lockfile maintenancearea: securitySecurity boundary, hardening, or vulnerability preventionpriority: mediumNormal-priority or P2 workstatus: triagedOpen issue has an organization taxonomy assignmenttype: maintenanceMaintenance, build, dependency, or operational upkeep

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions