activity-core/docs/gitops-release.md

Activity-core GitOps release lane

ACTIVITY-WP-0041 owns this lane; RPF-WP-0048 owns platform adoption. The founder requested implementation on 2026-09-27. Adoption is authorized; the existing 24-hour healthy observation period and release-identity proof remain mandatory.

Managed set and ownership

k8s/gitops/kustomization.yaml renders exactly nine resources: the API, worker and event-router Deployments; API and worker-metrics Services; runtime config, external definitions, report schemas and service-inventory ConfigMaps. scripts/render_gitops.py --check verifies the generated projection against k8s/railiance/20-runtime.yaml. Change that source and regenerate; after adoption, never apply the mixed legacy directory directly. Migration/sync Jobs are deliberately excluded. Sync definitions through the existing authenticated admin endpoint after ConfigMap projection refresh; this is an explicit release verification step.

The baseline includes live backup wrapper mounts and the API's Temporal UI setting. Dependencies stay with their existing owners: ESO/OpenBao secrets, verified backup ConfigMap, storage, host-path contents, Temporal/NATS/databases, llm-connect, edge relay, ingress/SSO and monitoring. ArgoCD must not prune or adopt them implicitly. Namespace classification remains production-tier (platform target, no authoritative rApp binding); MASON-WP-0006 is the mapping owner. Adoption does not invent a binding or lower readiness requirements.

Build and publication

The image workflow retrieves the full commit archive, builds the isolated test stage, and publishes only git-<full-sha> plus its registry digest. Python's base image digest, uv version and dependency lock are pinned. Deployments consume forgejo.coulomb.social/coulomb/activity-core@sha256:…, independently for each component. A commit tag is a lookup convenience, not an immutability guarantee. Existing images are retained during metadata-only adoption; do not replace a running component with newer code merely to complete adoption.

The pipeline uses its existing runner-held registry credentials. No credentials are copied into Git or into the coding-agent session. Successful publication and anonymous/cluster pull must be evidenced before the first digest promotion.

Bounded routine authority — implementation boundary

Proposed executable scope ACTIVITY-WP-0041-image-only-v1 is intentionally narrow: only the three Deployment image fields and transition from Never to IfNotPresent may change. No resource inventory, commands, mounts, environment, access, schema, replicas, resources, migrations, definition behavior or budget changes are admitted. Those changes require their owner review under the existing governance policy.

scripts/check_gitops_promotion.py refuses a non-digest image, widened diff, missing independent review/checks, unadmitted identity, stale health evidence, missing rollback revision, or less than 24 healthy hours. It is a validator, not an authority issuer: evidence fields are not signatures. The release executor must authenticate the CI/reviewer/health receipts and bind the exact candidate revision before invoking it. A producer-supplied JSON file cannot grant access.

No unattended merge/deployment identity has been admitted by this change. Do not mark this policy active or turn on automatic sync based only on these fixtures. After identity proof and the observation period, enable only the activity-core child's bounded promotion path; root-wide automation and destructive pruning stay off. The existing root remains manually reconciled for unrelated applications.

A release must name the prior pinned revision before promotion, sync through ArgoCD with pruning disabled, verify health and report-sink/schedule invariants, and revert its source revision through ArgoCD on failure. Prove both successful promotion and failed-health rollback before claiming unattended operation. The 24-hour observation begins with the recorded successful adoption; a stateful failure or unintended spec change invalidates that observation.

Live proof and current gates

The 2026-09-27 adoption and subsequent digest release are complete and healthy. See evidence for exact revisions, images, CI runs, nine-resource inventory, scheduled smoke and retention coverage. All three components now use registry digests of their previous binaries. Conservative healthy observation starts at 13:38:21Z after the digest rollout; earliest eligibility is September 28 at 15:38:21 Berlin, conditional on health.

The registry retention implementation currently protects tags, not digest-to-version mappings. Three baseline tag aliases have been added to the persistent protection union and checked with the owner parser. Every release must protect aliases for live and rollback digests until RPF-WP-0048-T03 supplies general digest protection. Unattended promotion is not ready merely because the admission fixtures pass: authenticated receipts, identity binding, retention coverage and failed-health rollback proof remain required in ACTIVITY-WP-0041-T03.

The subsequent retention safeguard rollout is recorded in evidence. RPF-WP-0048-T03 is complete: digest references now protect the whole package conservatively. The platform source pin and projected bytes are CI-verified; the worker reads the script from the existing GitOps ConfigMap. New healthy-since is September 27 14:06:22 UTC, replacing the earlier observation window. Earliest eligibility is September 28 at 16:06:22 Berlin, conditional on healthy evidence and admission.