Skip to content

[Fleet incident] Activate dedicated publication identity for the orchestrator-backed hourly loop #227

Description

@seonghobae

Product boundary

Noema의 hourly product-development loop에는 두 개의 분리된 capability가 필요하다.

  1. contextual-orchestrator를 통해 한 번의 OpenCode proposal session을 실행하는 inference identity
  2. 검증된 proposal branch와 Draft PR만 게시하는 repository-scoped Maintainer GitHub App

Reviewer App, model/verifier, workflow GITHUB_TOKEN, upstream provider key는 publication authority가 아니다. Maintainer App은 review, merge, release, deployment, administration, secrets 또는 organization-wide repository 권한을 가져서는 안 된다.

Current protected observation — 2026-09-01

  • Protected main is GitHub-verified 8ae8f5eee4e913a8ee106c3e2e550b0c9316c0e4.
  • The current workflow calls the shared contextual-orchestrator contract through NOEMA_LLM_API_URL, NOEMA_LLM_MODEL, and NOEMA_LLM_API_KEY. The retired direct NVIDIA NIM candidate loop and upstream provider credentials are not the product contract.
  • Latest scheduled run 33408669511 executed at f29cc3d045e1284695b61bea446f87aab4360e38 and stopped successfully at the zero-open-PR single-flight gate. Proposal preparation, gateway preflight, OpenCode, packaging, and publication were skipped.
  • Because that run exited at the open-PR gate, it is not a current zero-PR activation canary and does not prove that gateway or Maintainer App provisioning is ready. The earlier maintainer_app_unavailable run remains historical evidence only.
  • Current open PR inventory must reach zero through normal exact-head checks/review/merge before the next activation canary is authoritative.

Required architecture

A. Repository-scoped Maintainer GitHub App

Provide the documented workflow contract values:

  • variable NOEMA_MAINTAINER_APP_CLIENT_ID
  • secret NOEMA_MAINTAINER_APP_PRIVATE_KEY

Limit the installation to ContextualWisdomLab/noema with metadata read, contents write, and pull-request write. Keep review and merge authority separate.

B. Contextual-orchestrator inference capability

Provide only the Noema gateway consumer contract (NOEMA_LLM_API_URL, routing alias NOEMA_LLM_MODEL, and dedicated NOEMA_LLM_API_KEY). Upstream NVIDIA_NIM_API_KEY, BYTEZ_API_KEY, OPENROUTER_API_KEY, OPENAI_API_KEY, provider fallback lists, and COPILOT_GITHUB_TOKEN remain ineligible for this workflow.

C. Alternative publication identity

A separately owned short-lived installation-token/OIDC exchange is acceptable only when it preserves repository, workflow ref/SHA, event, expiry, exact permissions, reviewer independence, and downstream PR workflow triggering. A PAT or renamed broad token is not an alternative.

Acceptance criteria

  1. Reach zero open PRs through normal protected integration; do not bypass or suppress required checks.
  2. Keep Reviewer and Maintainer identities cryptographically and operationally separate.
  3. Prove exact repository/permission/workflow binding and that publication credentials never reach the model, verifier, logs, artifacts, or patch-validator.
  4. Run one fresh protected-main scheduled/dispatch canary after the zero-PR gate is satisfied.
  5. The canary passes the contextual-orchestrator gateway preflight and runs one bounded OpenCode session, with no direct-provider fallback.
  6. Independent verification either records a verified no-mutation result or publishes exactly one Draft PR.
  7. A published Draft PR receives normal exact-head CI, Security Scan, and independent review workflows despite recursive-event restrictions.
  8. Retain bounded source/run/proposal/verification/publication identities and exercise rollback by disabling/revoking the Maintainer App without a GITHUB_TOKEN write fallback.

Guardrails

Do not use a PAT, COPILOT_GITHUB_TOKEN, broad secrets: inherit, direct provider credentials, model/verifier write authority, Reviewer App publication authority, self-modifying installer workflow, branch-policy weakening, or a skipped/no-op run as activation evidence. Missing external provisioning blocks only this operational lane and never converts source/check evidence into publication proof.

Related: #5, #9, #27, #29, #30, #66, #96.

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: accessibilityAccessibility and assistive-technology supportarea: authAuthentication, authorization, identity, or tenant isolationarea: ci-cdCI, GitHub Actions, checks, release, or supply chainarea: securitySecurity boundary, hardening, or vulnerability preventionbugSomething isn't workingpriority: mediumNormal-priority or P2 workstatus: triagedOpen issue has an organization taxonomy assignmenttype: bugDefect or incorrect behaviortype: featureNew or expanded product capability

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions