activity-core/docs/release-runtime-owner-handoff.md

Bounded release runtime owner handoff

ACTIVITY-WP-0041-T03 implements the existing D2-authorized image-only scope ACTIVITY-WP-0041-image-only-v1. This source preparation does not request another founder decision and does not activate release authority. Platform custody remains independent preparation, tracked by RPF-IN-0011 rather than the dependent RPF48 gate.

The fixed target is system:serviceaccount:activity-core:activity-core-release-broker on cluster UID a553c742-0115-43d4-99a4-a5ca56fe0786, estate IP 92.205.62.239. The current native metadata observation found only default and activity-core-eso service accounts and no matching namespace/ArgoCD role bindings. The ESO account has unrelated secret projection custody and is not an interchangeable release actor. These observations do not attest ClusterRoleBinding absence or authenticate as a workload. No Secret read or credential value is part of this record.

Executable source

GET /release/health checks the three source-defined frontend-patterns definitions, exact deterministic report sinks, cron/calendar schedule semantics, actual Temporal workflow/action arguments, queue, pause state, overlap and catch-up policy. It reads only the fixed definition IDs and schedule IDs; it never updates either subsystem. Its 15-second probe deadline and sanitized boolean result bound failures.

python -m activity_core.release_sampler --database OWNER_PRIVATE_LEDGER --receipt OWNER_RECEIPT --watch polls fixed estate/Application/deployment/service metadata and that API route every 60 seconds. Gaps beyond 90 seconds, unavailability, revision changes or backwards clocks invalidate continuous observation. A fresh ledger starts now. Prior sync timestamps and two snapshots cannot manufacture a 24-hour receipt. Source-only preparation does not start this observer.

python -m activity_core.release_runtime --configuration OWNER_PRIVATE_CONFIGURATION starts the existing dedicated Temporal release dispatcher. The deployment-owned configuration requires schema activity-core-release-runtime/v1, enabled: true, principal activity-core-release-broker, exact cluster UID, private owned state_directory, kubeconfig, git_config, and receipt_trust. Every trust entry contains an independently admitted public key, principal and role set; all four build/review/health/retention roles are required. No private signing key or caller supplied credential is accepted. Config/custody drift or disabling stops subsequent calls. Inherited Git/Kubernetes overrides and SSH agent credentials are excluded.

At startup, the actual credential must report the exact Kubernetes username and pass four fixed Application allow checks plus seven negative boundary checks. The unchanged broker then verifies five-minute signed receipts, image-only source and CI bounds, retention and continuous health. Git publication changes only the fixed child targetRevision with compare-and-swap; root synchronization selects that one child and child pruning stays false. Temporal input is only an already-admitted release ID. Durable private SQLite audit delivery is idempotent and sanitized. A configuration flag or fixture key does not establish native owner acceptance.

Platform preparation and acceptance

Under the existing accepted scope, Platform supplies the dedicated workload identity, credential route and independently operated issuer custody. Fixed allowed operations are read-only estate/runtime metadata plus the reviewed broker's Git one-field publication and exact two-Application operations. Repository write credentials alone cannot enforce a field boundary; keep them exclusively behind this broker and prove real wrong-path, wrong-application, direct deployment, secret-read, RBAC, exec and revocation denials. Do not reuse workstation admin or ESO credentials. The runtime checks Kubernetes identity, but native Git push identity and custody require owner acceptance evidence before deployment.

Acceptance must bind exact source/runtime digests, principal/credential custody, independent issuers, observer process and durable ledger, real Temporal registration, one normal release and one failed-health rollback, restart/concurrency/denial and revocation receipts. The separately admitted signed owner acceptance must use the existing ACTIVITY-WP-0041-T03 scope and expire within five minutes. Platform's docs/activity-core-release-admission.md and readiness gate define this contract. No evidence is self-signed by this worker. RPF-WP-0036-T03 covers backup freshness, so it is not a substitute release-custody dependency.

Abort owner is activity-core for a candidate/invariant/dispatch failure and railiance-platform for custody/authentication or native Git/Argo admission failure. Stop before publication when identity, source or admission is uncertain. After publication, preserve the durable release row; the admitted broker reverses the one-field pin to its retained rollback revision and performs the same targeted, non-pruning sync. Failed rollback retains its active slot for recovery. No direct Deployment or broad root operation is a recovery shortcut. Disabling configuration halts new work; actual credential revocation and worker shutdown remain Platform operations. Attended admin login is orange only when a reviewed native custody command requires it; none has been scheduled or executed in this preparation.