Reopen the ArgoCD question on corrected evidence

The 2026-08-11 decision to keep ArgoCD rested on a claim that turned out to be
wrong. Verified against both clusters once API access was restored: ArgoCD is
not on railiance01, it runs on CoulombCore, its Applications target CoulombCore
in-cluster, nothing on railiance01 is ArgoCD-managed, and the live S3 workloads
- target-revenue, openbao, external-secrets - deploy outside GitOps. Two
Applications are Degraded and one is OutOfSync/Missing.

The earlier claim that removing ArgoCD documentation would describe a system
that does not exist was backwards: the documentation already describes a
deployment path that is largely not in effect. Restates the question with three
real options - adopt properly on railiance01, retire, or relocate to Helix Forge
- and notes that doing nothing is the option with a cost.

Same defect class as RAIL-HO-WP-0009: declared and live state diverged, and
nothing detected it.

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

ArchitectureBlueprint.md

@@ -332,16 +332,42 @@ to `railiance-master` (`04c776c4`, amended `f88f938d`).
 - delete the local `~/railiance-bootstrap` directory, which is a mis-cloned copy
   of `railiance-cluster.git`
 
-### 5.6 Does Railiance use ArgoCD? → **DECIDED 2026-08-11: keep it**
+### 5.6 Does Railiance use ArgoCD? → **REOPENED 2026-08-12 on corrected evidence**
 
-Briefly questioned as possibly Helix Forge tooling rather than a Railiance
+Decided 2026-08-11 as "keep it", on the basis that S3 runs ArgoCD as its live
-concern. Resolved on the evidence: S3 runs ArgoCD as its live deployment
+deployment mechanism. **That basis was wrong.** Verified against both clusters
-mechanism — four Application manifests (`external-secrets`, `issue-core`,
+once API access was restored:
-`openbao-secretstore`, `target-revenue`), AppProjects under `argocd/bootstrap/`,
-`docs/argocd-gitops.md`, and its two most recent commits add Applications.
 
-ArgoCD stays and its documentation stays accurate. Relocating GitOps tooling to
+| Fact | Evidence |
-Helix Forge is noted as possible future cleanup, not current work.
+| --- | --- |
+| ArgoCD does **not** run on railiance01 | namespace `argocd` NotFound |
+| ArgoCD runs on **CoulombCore** | `argocd` namespace, Active 344d |
+| The Applications target **CoulombCore, not railiance01** | all four declare `server: https://kubernetes.default.svc` — in-cluster |
+| Their health is poor | `issue-core` Degraded, `openbao-secretstore` Degraded, `target-revenue` OutOfSync/Missing |
+| The real workloads run on **railiance01** | `target-revenue` deploy 1/1 up 6d, `openbao` sts 1/1, `external-secrets` 3 deploys 1/1 |
+| Nothing on railiance01 is ArgoCD-managed | no namespace carries an `argocd.argoproj.io/instance` label |
+
+So the live S3 workloads are deployed **outside GitOps**, by Makefile and hand,
+while the ArgoCD Applications describe a deployment path into the **frozen**
+CoulombCore cluster — where `target-revenue` is registered but Missing, and two
+others are Degraded.
+
+The earlier claim that removing ArgoCD documentation would "describe a system
+that does not exist" was backwards: **the ArgoCD documentation already describes
+a deployment path that is largely not in effect.**
+
+This does not settle the question — it restates it honestly. Three real options:
+
+1. **Adopt properly** — stand up ArgoCD on railiance01 and bring the live
+   workloads under GitOps. The Applications become true.
+2. **Retire** — remove the Applications and `docs/argocd-gitops.md`, and accept
+   Makefile-driven deployment as the declared method.
+3. **Relocate** — GitOps becomes Helix Forge tooling, as originally suspected.
+
+Doing nothing is the one option with a cost: a stale control plane on a frozen
+cluster, showing Degraded, that no longer reflects how anything ships. Note this
+is the same defect class as `RAIL-HO-WP-0009` — declared state and live state
+diverged, and nothing detected it.
 
 ### 5.5 Rapp granularity and composition → decided, implementation open