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

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
ACTIVITY-WP-0041	workplan	Remove recurring deployment exceptions through governed GitOps adoption	infotech	activity-core	ready	codex	activity-core	2026-09-27	2026-09-27	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

id: ACTIVITY-WP-0041-T01
status: todo
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

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

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.