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.

Deterministic platform readiness gate

python3 scripts/activity_promotion_readiness.py --live --observation observation.json --receipt readiness.json verifies only the current bounded adoption and reports an explicit owner-proof wait until ACTIVITY-WP-0041-T03 acceptance exists. This read-only check neither creates a principal nor activates a release worker. D2 removes the founder reapproval; the identity/custody and runtime proofs above remain required. ACTIVITY-WP-0042 scheduling acceptance does not supply them.

Later activation checks require operator-owned --trusted-owner-key (raw 32-byte Ed25519 public key) and --trusted-owner-principal, supplied separately from --owner-acceptance. No signer key supplied inside a receipt is trusted. The acceptance envelope has exactly payload and signature (base64 Ed25519 signature of sorted compact JSON). Its payload uses schema_version: activity-core-release-acceptance/v1, binds the existing owner_task: ACTIVITY-WP-0041-T03, issuer, dedicated release principal, authority: ACTIVITY-WP-0041-image-only-v1, application, exact estate cluster UID, adoption revision and full broker implementation revision. It expires within five minutes; the operator owns signer admission/revocation and actual native evidence verification. An agent must not synthesize this production acceptance from test fixtures or a producer's booleans.

The targets mapping is the exact single platform child targetRevision path on main, selective root sync of only activity-core, child activity-core and prune false, as named in the checker. checks must contain exactly its named acceptance checks, all actual owner-verified: bounded identity/custody/revocation/denials, independent authenticated receipts/CI digest binding, continuous observer, image-only scope, source CAS/single-flight, restart/lost-response recovery, retention, real failed-health rollback, Temporal registration, durable audit sink and report/schedule invariants. continuous_health binds the adoption revision and a current actual 24h sampled interval with at most 90-second gaps. A source timestamp or snapshot is not this proof. Signatures authenticate the accepted owner's assertions; the owner still must ground them in actual runtime receipts.

Native adoption mismatch or malformed/forged/stale/widened owner acceptance returns unverified. Missing owner acceptance/trust binding returns waiting on the existing owner task, with its cross-owner coordination case. Only ready returns exit code zero. No automatic-sync source candidate is generated: ACTIVITY-WP-0041's current broker contract still relies on explicit selective manual child/root sync and forbids an automated child policy.