chore(operations): provision and activate hourly maintainer App

[seonghobae]

Live correction — 2026-09-01

Protected main is GitHub-verified 8ae8f5e. The earlier PR #500/#501/#503 dependency narrative is historical; current open PRs are #510/#512/#513/#521. Repository source still cannot prove App installation, permission scope, key custody/rotation, or reviewer eligibility, so the external provisioning acceptance criteria remain open.

Problem

Noema contains repository-owned, fail-closed pre-activation logic for a dedicated Maintainer GitHub App and an independent Reviewer App identity, but live App installations, variables/secrets, activation state, key custody and any counted formal-review route are administrator controls outside source. Repository code, model output, bot-looking names, PR mergeability and green checks cannot prove them.

Historical protected/control-plane observation — 2026-08-27 (superseded)

Protected Noema main remains GitHub-verified 2c83355529447248c246805d1954f268e027d2ab.

Repository-effective organization ruleset 18794436 is active on ~DEFAULT_BRANCH, requires central .github/workflows/security-scan.yml@refs/heads/main, has bypass_actors=[], and reports current_user_can_bypass=never. This proves only that exact required-workflow rule; approval counts, stale-review dismissal, conversation resolution, force-push/deletion controls and separate classic bypass policy remain fail-closed/unproven unless independently observed. #27 owns that stronger governance evidence.

The available repository tooling still does not expose authoritative GitHub App-installation inventory, Actions secret inventory, private-key custody/rotation evidence, or administrator configuration writes. Real Maintainer/Reviewer App installation and secret presence therefore remain external controls.

Read-only central .github/main is protected and GitHub-verified 17052a7ca3c16db90932a4d6036b43165ddee418. .github#1222 remains OPEN and owns reusable Security/SAST exact-submitted-head/live-base evidence. Protected central Security Scan still has generic Dependency Review/Trivy checkout semantics and dependency comparison 403/404 unsupported-success behavior. Existing owner PR #897 is current-base aligned at exact head 1f834b4d0f86abb407fa286b1f7b857889d8ec33, open/Ready/mergeable; observed exact-head Security/SAST/OSV/CodeQL/Python/SBOM/Secret/Scorecard/Strix workflows are terminal-success and observed inline threads are resolved, but no qualifying formal APPROVE has been explicitly submitted on that exact head. Separate #834 owns the Noema OIDC consumer .token versus data.token mismatch and credential-byte output validation and remains non-mergeable on a historical base. Noema does not mutate those foreign source/ref/PR states.

Historical Noema dependency order — 2026-08-27 (superseded)

• fix(egress): bound anonymous GitHub API authority #500 is the earliest open root at exact head 3529a4ec8c06252322a08cbb83b70618dc0abdaa, Draft/mergeable, exact descendant of protected main, ahead 329 / behind 0. Current test-first repair binds protected reusable-workflow repository authority and readiness to byte-exact ContextualWisdomLab/.github. Hosted RED 15d495... failed Application 33116657706 / job 98672908572; production repairs 01d7c3... and b42691... plus fixture/coverage regressions converge on current 3529a4.... Application 33117247852, reviewer 33117247847, and Security 33117247830 are terminal-success; dedicated image 33117247791 remains in progress/non-passing.
• fix(acquisition): require canonical release and data-room authority #501 exact head 87899225ff559ea7241a786faa0c605634766ac8: Application/image are terminal-success but reviewer-ci 33066532748 is terminal-failure on the signed old Node distroless OpenSSL substrate; fix(egress): bound anonymous GitHub API authority #500 already owns the causal non-OpenSSL sandbox repair.
• fix(governance): preserve delegated capability path authority #503 exact head 32d8ea491af255edabf8c5c8c1132ece4375b34e: Application 33098672683, reviewer 33098672641, Security 33098672622, image 33098672819 terminal-success; downstream of fix(egress): bound anonymous GitHub API authority #500 and central owner repairs.
• fix(kpi): reject compact credential-shaped source IDs #496 remains diverged from protected main, ahead 34 / behind 1. feat(licensing): generate deterministic dependency license inventory #495/fix(readiness): reject local-only production endpoints #497 have independently advanced writer state and are not raced here; docs(readme): keep the default README customer/operator facing #425 remains separately Cursor-writer-owned and explicitly do-not-merge/do-not-approve.

None of these source/check facts proves live App installation, reviewer eligibility, private-key custody, production deployment, or publication authority.

Repository-owned preflight boundary

The workflow GITHUB_TOKEN must remain read-only and never become a maintenance write fallback. Reviewed administrator-supplied values include Maintainer App client ID/private key, Reviewer App client ID/private key, exact NOEMA_REVIEWER_LOGIN, and NOEMA_MAINTENANCE_ENABLED remaining non-true until provisioning/governance/reviewer evidence passes.

The identities remain separate:

1. Maintainer App — repository-scoped maintenance/publication authority only, with no administration, organization-wide or unrelated permissions.
2. Reviewer App — independently governed identity able to submit a formal review counted by live rules only if fresh live policy proves such a rule is configured, without source-author or merge authority.

A source preflight proves only facts exercised in that run; it cannot prove App-registration ownership, installation scope, key custody/rotation, bypass actors, break-glass ownership or long-term reviewer availability.

Current external-control status

• No repository-source mutation can prove the real Maintainer App installation, permission envelope or key custody.
• No repository-source mutation can prove the independent Reviewer App installation or whether its approval would be counted by live policy.
• COMMENTED review, check/status, model judgement, reaction or bot-looking login is never upgraded to formal APPROVED authority by assertion.
• Missing App evidence blocks only the external provisioning/activation lane and never justifies weakening checks, review, security or branch policy.

Acceptance criteria

External App provisioning

• Create/identify a Maintainer GitHub App distinct from the Reviewer App.
• Scope effective maintenance authority to ContextualWisdomLab/noema only.
• Grant no administration, organization-wide repository, issues-write, secrets-write or unrelated authority.
• Configure Maintainer App credentials without exposing them in source/issues/PRs/artifacts/model prompts.
• Provision/install the independent Reviewer App and configure its credentials plus exact reviewer login.
• Record App owner, key-rotation owner, installation identity, reviewer identity, activation owner and rollback contact in access-controlled evidence.

Reviewer eligibility proof

• Bind configured reviewer login to authenticated Reviewer App slug/installation identity.
• If fresh live governance requires approval, verify that exact Reviewer App can submit a formal APPROVED review counted by policy on a non-author test PR/head without gaining source-write/merge authority.
• Verify similar-looking or uninstalled identities cannot satisfy such a gate.
• Re-probe eligibility after provisioning; historical observations remain history until fresh authorized state supersedes them.

Pre-activation and controlled activation

• Keep NOEMA_MAINTENANCE_ENABLED unset/non-true during provisioning.
• Execute protected-source readiness preflight and retain bounded machine-readable governance/readiness/no-write evidence.
• Prove effective Maintainer token scope and no administrator authority.
• Require live main governance PASS through chore(governance): protect main and enforce release checks #27 and no-write commercial-readiness validation.
• Treat missing/malformed/symlinked/oversized/stale/write-enabled evidence as failure.
• Enable maintenance only after App records, preflight, governance and reviewer-route evidence are independently reviewed.
• Verify App-authored protected merge triggers normal downstream workflows and retain exact actor/source/run identities.
• Exercise rollback and prove no GITHUB_TOKEN write fallback exists.

Rollback / guardrails

Disable maintenance, revoke compromised installations, rotate keys before reactivation, correct reviewer identity when changed, and never broaden bot authority merely to manufacture approval. Repository source proves preflight logic, not external App configuration; green checks or the observed required-workflow ruleset are not App-installation evidence.

Related: #5, #27, #30, #96, #227, #425, #495, #496, #497, #500, #501, #503.

[seonghobae]

Current provisioning evidence — 2026-08-06

PR #65 exact head 5c2e6762d07598094e5301c491d15ba83dcdcd51 remains unchanged. Its current-head ci, reviewer-ci, and Security Scan runs are successful, all inline threads are resolved, and CodeRabbit completed a substantive read-only exact-head review with no actionable current-head finding. It still cannot obtain the required formal independent approval.

A formal reviewer request for opencode-agent and cwl-noema-review was rejected with HTTP 422: reviews may only be requested from collaborators. Direct permission inspection now isolates the identities:

• opencode-agent: repository permission is explicitly none.
• cwl-noema-review: GitHub returned no collaborator permission record (null).

Neither identity can currently be requested as an eligible reviewer. Mentions, model comments, check runs, and commit statuses are not approval evidence and must not satisfy merge policy.

Issue #29 therefore remains an active operational blocker. Provision and install the independent Reviewer App or add an eligible independent collaborator, set NOEMA_REVIEWER_LOGIN to the exact installed bot login including [bot], and verify that identity can submit an exact-head GitHub APPROVE. Keep NOEMA_MAINTENANCE_ENABLED disabled until the reviewer identity and dedicated Maintainer App are both verified. Do not introduce a GITHUB_TOKEN write fallback, repair workflow, self-modifying Action, or branch-protection bypass.