railiance-platform/docs/activity-core-release-admission.md

# Activity-core unattended release admission

Owner: ACTIVITY-WP-0041-T03, with RPF-WP-0048-T02 for platform activation.
Status: proposed contract; no credential minted and no automatic sync enabled.
The user authorized implementation; these are enforcement requirements, not a
request to reapprove the existing adoption.

## Required enforcement

Use a dedicated non-admin service principal. Separate producer and reviewer
identities. Public source reads need no repository credential. A general repository
write PAT cannot enforce image-only changes by itself: the executor must validate
the exact before/after commits and authenticated receipts before writing, while
protected branches and required checks prevent bypass. Restrict its repository
membership to the release repository and reconciliation to the single
`activity-core/activity-core` application. This installation is ArgoCD Core:
there is no ArgoCD API-server role/token lane to reuse. Kubernetes RBAC cannot
restrict Application patch access to only the operation fields. Use a narrowly
implemented sync broker with admission enforcement before granting such patch
access; an Application-scoped Kubernetes Role alone is insufficient. No root-wide
sync, arbitrary application spec updates, project updates, exec, prune, overrides,
secrets or other applications.

The present parent Application pins the child's source revision in the platform
repository. Therefore an app-only ArgoCD sync grant alone cannot perform durable
promotion. Implement a reviewed broker for the single child revision field or a
separately reviewed source-tracking design; do not grant the executor unrestricted
platform repository writes to work around this boundary.

Keep credentials in OpenBao with the existing delivery subsystem; never in Git,
receipts or prompts. Publish the exact subject, repository/branch/path scope,
ArgoCD resource, TTL, revocation and negative-test evidence before admission.
The warden routing catalog currently has no ready release-specific lane. Do not
reuse source-read or package-admin credentials as deployment authority.

## Receipt and failure requirements

Authenticate CI completion against the expected Forgejo repository and full commit;
require the image-build and smoke checks. Bind the independently authenticated
reviewer result to that same commit and actual image digest. Fetch current ArgoCD
health from its authority, with bounded staleness; preserve observations proving
at least 24 healthy hours. Producer-provided booleans are insufficient.

Before promotion retain the exact prior source revision and protect both live and
rollback images in the additive registry inventory. Serialize releases, compare
the current revision before writing, persist state, and recover idempotently after
restart. Reconcile through ArgoCD without pruning. Check deployment readiness,
report sink and schedule invariants. On timeout/failure revert the pinned revision
through the same Git path, reconcile, verify recovery, and stop further promotion
if recovery fails. Store sanitized receipts in the activity-core/State Hub run.

Acceptance must include denied out-of-scope mutation, stale/mismatched/forged
receipts, concurrent release, restart, failed health and successful rollback.
Run destructive failure fixtures in an isolated environment; production must not
be intentionally broken to manufacture proof. Admit only after tests and the
observation gate pass. Access, budget or scope expansion stays a monthly decision.