Record ArgoCD v3.5.3 core install on railiance01 (blueprint 5.6: adopt) and the exhausted-CPU finding.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/kubernetes-change-gate-decision.md

@@ -93,3 +93,42 @@ Until the production row has a working path, the policy-nexus transition rule ap
 - **railiance-platform:** the ArgoCD lane is the production path, and policy-nexus onboarding is due by 2026-12-21.
 - **railiance-master:** ADR-0006 gains a deploy-path consequence for `production-approved`.
 - **rapp-policy-nexus:** the transition and its date.
+
+## ArgoCD installed on railiance01 (phase A), 2026-09-21
+
+**Decided by:** Bernd Worsch (founder), exercising `GOVERN @ estate`. This settles railiance-platform ArchitectureBlueprint §5.6 as option 1, **adopt properly**: ArgoCD runs on railiance01, and the live workloads are brought under GitOps one application at a time.
+
+**What was installed:** upstream Argo CD Core (headless: no API server, UI or Dex), **v3.5.3**.
+- Manifest: `core-install.yaml` at tag v3.5.3, sha256 `1a87025d8eb2eae621653fd312fb9ca51df1b4b3b6992a030e3a9ef38e45c448`.
+- Images: `quay.io/argoproj/argocd:v3.5.3` and `public.ecr.aws/docker/library/redis:8.2.3-alpine`.
+- Namespace `argocd`, created 2026-09-21T13:55:29Z.
+- 34 objects server-side applied after a clean server-side dry run.
+
+**Verified after the install:**
+- all four pods are Ready with 0 restarts;
+- there are 0 Applications and 0 AppProjects;
+- 0 namespaces carry an ArgoCD instance label, so nothing is adopted;
+- no Service is of type LoadBalancer or NodePort, so there is no new listener (ADR-0008).
+
+**The mode it was done in:** `ADMINISTER @ realm:kubernetes/railiance01`, `activation=APPROVED` by the founder, performed by the custodian session over SSH. By this record's own table the ArgoCD install is a platform object with no readiness state, so it is production-tier. It was done by direct apply under the transition rule, because the production row did not yet exist: this install is what creates it. Its declared state now has to be captured in its owning repository, so the install is not itself a hand-deployed object that nothing declares.
+
+**Rollback:** delete namespace `argocd` and the three `argoproj.io` CRDs. With no Applications, nothing else is affected.
+
+**Resource hygiene, open:** upstream core sets no resource requests or limits, so the ArgoCD pods are BestEffort. That makes them the first evicted under pressure, and unbounded. Set requests and limits when the install is captured in its owning repository.
+
+**Phase B**, adopting each application, and **phase C**, retiring coulombcore's ArgoCD, each need their own founder go-ahead. Phase B starts with the AppProjects and the root app with automated sync off. Then, per application, a diff, then a manual sync with prune off, and prune and self-heal only after that application is proven.
+
+## Found during phase A: the node's CPU requests are exhausted
+
+Before the install, railiance01 already had **100% of its allocatable CPU requested** (4 of 4 cores); limits are at 828%. Short scheduled jobs cannot be placed, and have been failing with `Insufficient cpu` for days:
+
+| Pod | Pending since |
+|---|---|
+| user-engine database backup | 2026-09-16 |
+| authelia backup | 2026-09-20 |
+| lldap backup | 2026-09-20 |
+| privacyidea backup | 2026-09-20 |
+| audit-core attest-chain | 2026-09-20 |
+| activity-core cert-manager ACME solver | 2026-09-19 |
+
+ArgoCD did not cause this: it requests no CPU. It is an existing capacity defect with a direct consequence: **identity and user-engine backups have not run.** The custodian has not changed anything; it is reported to the founder.