activity-core/workplans/ACTIVITY-WP-0041-gitops-adoption.md

---
id: ACTIVITY-WP-0041
type: workplan
title: "Remove recurring deployment exceptions through governed GitOps adoption"
domain: infotech
repo: activity-core
status: blocked
owner: codex
topic_slug: activity-core
created: "2026-09-27"
updated: "2026-09-27"
state_hub_workstream_id: "12798750-3eee-5d81-a411-c3c4c5ce2d2c"
---

Origin: founder asked what must change to avoid the scoped deployment exception
for frontend-patterns reporting (ACTIVITY-WP-0040 / FEP-WP-0008). This is the
reviewed implementation handoff, not permission to adopt additional live objects.
The exception is recorded as State Hub decision
e5dd02cb-b5b2-45c8-a600-748ea2ffd31b and does not change estate policy.

## Reconcile live state with deployable source and publish reproducible images

```task
id: ACTIVITY-WP-0041-T01
status: done
priority: high
state_hub_task_id: "fadce2e0-67c8-5dab-98cc-3a08d466a39f"
```

Owner activity-core, with railiance-platform for image distribution. Inventory
all resources and external ownership first. Separate runtime declarations from
one-shot migration/sync Jobs; prevent hooks from rerunning accidentally. Capture
live backup wrappers/mounts and other deliberate patches missing from the main
runtime manifest. The 2026-09-27 worker diff preserved live backup mounts through
three-way apply; that is not proof a fresh render fully describes the runtime.

Replace workstation-only image imports and mutable/local tags with reproducible
CI builds, registry publication and immutable digests. Keep worker/API compatibility
checks and pin both independently. Add a projection check that frontend-patterns
source definitions exactly match the external-definition ConfigMap. Render and
server-dry-run the proposed managed set; no unintended spec change or pruning.

## Adopt the declared resource set into railiance01 ArgoCD

```task
id: ACTIVITY-WP-0041-T02
status: wait
priority: high
state_hub_task_id: "af09865d-8cc9-5571-9c34-20ae679a1e4e"
```

Owner railiance-platform for AppProject/root Application; activity-core for its
resource set. Follow RPF-WP-0044's existing per-app adoption procedure in a dedicated
activity-core adoption record (activity-core is not one of that plan's four apps).
Create a least-privilege project/source allowance and child Application with a
pinned revision, initially no automated sync, finalizer or pruning. Verify repo
access, metadata-only adoption, healthy worker/API and unchanged existing schedules.
Observe at least 24 hours before enabling automation, following the existing policy.

Record namespace/resource-to-binding classification with the MASON-WP-0006 mapping
owner. An explicit mapping improves routing; it must not downgrade a production
target to bypass the GitOps path. Keep secrets under existing ESO/OpenBao custody.
The founder-approved exception covers WP0040 only; adoption activation is a separate
one-time governance decision.

## Establish standing authority for bounded routine releases

```task
id: ACTIVITY-WP-0041-T03
status: wait
priority: high
state_hub_task_id: "8e2b4ed9-d455-5367-85d9-8e4222ce75f3"
```

Owner estate governance with activity-core and railiance-platform. ArgoCD adoption
alone still leaves manual root/child sync and per-change founder go-ahead under
current policy. To meet monthly-only human review, approve once the exact autonomous
scope: who may merge which paths, mandatory tests/review, allowed images/definitions,
resource/spend ceilings, stop conditions, rollback and audit retention. Bind the
execution identity to those grants; do not infer standing authority from one rollout.

Then permit automated promotion/sync within that scope, after the adoption soak;
keep pruning disabled until the complete tracked set is proven. Changes to access,
secrets, schema/maturity rules, destructive operations or budget ceilings remain in
the monthly decision packet. Failed routine checks stop/retry/roll back automatically
and produce visible evidence rather than asking the founder to approve each run.
Prove one normal release and one failed health-check rollback through Git/ArgoCD.

## Acceptance

A normal authorized change builds/tests, publishes a digest, updates reviewed source,
merges and reconciles through ArgoCD, verifies health, and records evidence without
kubectl apply or a fresh founder exception. Failure recovers through the declared
rollback path. Human involvement is limited to the agreed monthly policy review.
GLAS-WP-0012/HFACT-WP-0001 readiness remains a separate prerequisite for automated
pattern editing; completing this plan does not imply that executor is admitted.

## Implementation authorization and scope — 2026-09-27

The founder explicitly requested implementation of these actionable tasks. This
supersedes the earlier wait for adoption authorization; it does not waive the
24-hour healthy observation period or invent an unattended release credential.
RPF-WP-0048 owns the scoped AppProject/child adoption. Nine runtime resources are
reconciled to live state with an empty client diff and successful server dry-run;
Jobs/custody/infrastructure are excluded. See docs/gitops-release.md.

Image CI now tests before publishing full-commit tags/digests with pinned build
inputs. Local container tests passed. Registry publication/readback must still be
observed. The image-only promotion validator has negative fixtures for widened
authority, stale/missing evidence, non-digest references and incomplete soak.
It is not a credential issuer or proof of an admitted unattended executor.

## Verified delivery — 2026-09-27

T01 complete: commit 12e08878d19e61ce41c534cc10ca56acd0c3efc1 passed CI
smoke and image publication (runs 307/308). Nine-resource projection and pinned
frontend definitions are checked before publication. All three live components
now pull immutable registry digests of their exact prior binaries. Registry
readback, node pulls, all three rollouts and a Temporal scheduled report passed.
Baseline registry tags are protected in the additive live-image retention union.

T02 adoption complete, observation outstanding: metadata-only initial sync at
12:07:35Z; digest release through root/child ArgoCD succeeded at 13:37:56Z.
Healthy transition at 13:38:21Z starts the conservative 24-hour window; earliest
eligibility is 2026-09-28 15:38:21 Europe/Berlin, conditional on healthy evidence.
Automated sync and pruning remain off. RPF-WP-0048 owns observation/admission;
its T03 owns general digest-aware registry retention, with current tags protected.

T03 has a tested image-only admission validator and one successful Git/ArgoCD
release. Authenticated receipt verification, narrowly bound unattended identity,
and failed-health automatic rollback remain required. Producer JSON flags do not
provide authority. No executor credential has been invented or broad operator
authority delegated. Existing GLAS/HFACT pattern-editing readiness is unchanged.

Evidence: docs/evidence/2026-09-27-gitops-adoption.json. Activation authorization
is State Hub decision 78a4b859-dd00-4623-b95b-121b0e1c915d.

## Retention safeguard release — 2026-09-27

RPF-WP-0048-T03 completed through the existing nine-resource GitOps projection.
The platform-owned retention script is pinned to source commit/hash, CI verified,
and mounted read-only from the existing ConfigMap. ArgoCD synced a12f116 and is
Healthy; live worker hash/readback and a non-destructive rollback planner check
passed. Digest-referenced packages are conservatively protected in full.
No prune was executed. Evidence: docs/evidence/2026-09-27-digest-retention-release.json.

This worker change resets conservative observation: healthy since 14:06:22Z,
earliest eligibility September 28 at 16:06:22 Berlin. T03 still requires the
scoped source/sync broker: ArgoCD Core offers no API-server token lane, and a
Kubernetes Application patch grant cannot restrict fields. Concrete enforcement
contract is platform docs/activity-core-release-admission.md. Authenticated
receipts and automatic rollback proof remain required; no broad token is admitted.

## Broker core and isolated recovery proof — 2026-09-27

Implemented Ed25519 receipt verification with trusted role/principal bindings,
independent producer/reviewer keys, exact commit/manifest/image bindings, mandatory
CI contexts, freshness, 24-hour signed observation and live/rollback retention
coverage. Shared image policy remains the admission gate. Fixed mutation builders
restrict platform edits to the child revision and ArgoCD operations to selective
root/child sync without pruning. SQLite serializes releases and records signed
receipts plus transitions; publication intent precedes external calls. Isolated
fixtures prove restart, lost publication responses, failed-health rollback and
failed rollback holding the release lock. No production authority is inferred.

See docs/release-broker.md for implemented behavior and exact remaining work:
authenticated Git/ArgoCD adapter, custody/admission, real attestation issuers and
continuous observer, Temporal dispatch and isolated transport/rollback proof.
The broker is disabled by default and not connected to live credentials or a
production schedule. Current deployed revision and healthy-soak clock are unchanged.
T03 stays progress; the full unattended acceptance is not complete.

## Transport adapter and sampled health observer — 2026-09-27

Implemented the fixed Git/ArgoCD adapter: exact source/hash verification, static
Kustomization restriction, one-field child revision commits, non-force publication,
remote-tip recovery after lost responses, cluster UID binding, resourceVersion/spec
CAS, selective sync and deployment health checks. A bounded report/schedule probe
remains a required trusted integration. Implemented persistent health sampling with
90-second maximum gaps, revision/failure reset, clock-regression invalidation and
24-hour attestation refusal unless the complete sample interval exists.

Tests use disposable real Git repositories and simulated Kubernetes responses.
The broker completes failed-health rollback through the real Git adapter; tests
cover lost push responses, concurrent publication, source tampering, wrong cluster,
foreign Argo operations and observer restart/gaps. Latest focused suite: 48 passed;
full affected suite before the final cluster-binding test: 75 passed. CI includes
all these tests. No production credentials or activation were introduced.

T03 remains progress for admitted identity/custody, authenticated isolated Kubernetes
verification, real build/review/retention issuers, production invariant probes,
Temporal observer/dispatcher registration and evidence sinks. The implemented
observer cannot retroactively assert the earlier soak interval. See docs/release-broker.md.

## Loose-end implementation and blockers — 2026-09-27

Completed another repo-side portion of T03: `release_dispatch.py` supplies a
Temporal workflow and explicitly constructed dedicated worker for resuming an
already-admitted ledger release. Requests carry only its ID; source, transport,
keys and sinks come from trusted worker configuration. Durable transition audit
acknowledgements survive restart, repeat the same event ID after a lost response,
and export only normalized facts. Nonterminal audit outages do not prevent
rollback; terminal completion waits for audit delivery. Adapter errors are
sanitized before reaching Temporal history. The ordinary worker remains unchanged.

Tests cover restart, lost publication and audit responses, rollback, unknown IDs,
identity disablement and Temporal sandbox construction. The image CI test target
includes the new suite. This is isolated implementation evidence, not authenticated
Kubernetes proof or production activation.

T02 and T03 are now wait and the workplan blocked. T02 cannot close before the
September 28 16:06:22 Berlin observation eligibility and healthy owner evidence
(RPF-WP-0048-T02). T03 still requires admitted identity/custody, real independent
receipt issuers, bounded production report/schedule probes, authenticated isolated
transport/denial/rollback proof, and deployment/registration of the observer,
dispatcher and audit sink. Local code cannot supply those trust inputs. The new
worker factory neither enables a schedule nor grants an identity; deployment and
continuous health observation must be established through the existing owner lane.
No new workplan/task, production mutation or authority expansion was introduced.