Retire CoulombCore references; correct the 16443 diagnosis

CoulombCore is being retired, so the docs stop using it as the reference host:
state-hub-coulombcore examples become state-hub-railiance01, and the reuse-surface
playbook no longer attributes bao.coulomb.social to it — that resolves to
92.205.62.239, which is railiance01. The openrouter lane keeps its factual note
about ESO on the CoulombCore cluster, with a retirement flag for its owner.

Also corrects this session's own error. The WP-0031 evidence blamed the
Unauthorized on a local-port collision between k3s-api-coulombcore and
k3s-api-haskelseed. That was wrong: the haskelseed tunnel is a reverse forward,
where local_port is a destination rather than a listener, so they never competed.
16443 was simply CoulombCore's k3s — a different cluster whose client CA does not
know that cert. The wrong reason had already gone to flex-auth, so it is
corrected in the file rather than quietly dropped.

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

.claude/rules/session-protocol.md

@@ -82,7 +82,7 @@ then sync from the repo checkout:
 git pull --ff-only
 statehub fix-consistency
 ```
-For repos where implementation runs on a remote machine (e.g. CoulombCore),
+For repos where implementation runs on a remote machine (e.g. railiance01),
 use the pull-before-fix mode from any shell with the State Hub CLI:
 ```bash
 statehub fix-consistency --repo ops-warden --remote

WORK-RECORDS.md

@@ -112,5 +112,5 @@
 | task | WARDEN-WP-0031-T01 | done | — | workplans/WARDEN-WP-0031-policy-caller-identity.md |
 | task | WARDEN-WP-0031-T02 | done | — | workplans/WARDEN-WP-0031-policy-caller-identity.md |
 | task | WARDEN-WP-0031-T03 | done | — | workplans/WARDEN-WP-0031-policy-caller-identity.md |
-| task | WARDEN-WP-0031-T04 | wait | — | workplans/WARDEN-WP-0031-policy-caller-identity.md |
+| task | WARDEN-WP-0031-T04 | done | — | workplans/WARDEN-WP-0031-policy-caller-identity.md |
 | task | WARDEN-WP-0031-T05 | wait | — | workplans/WARDEN-WP-0031-policy-caller-identity.md |

history/2026-08-19-flex-auth-caller-identity-evidence.md

@@ -8,11 +8,20 @@ Service `flex-auth-ops-warden:8080`, digest `sha256:138aa347…`, running
 (read off the live Deployment, matching FLEX-WP-0016 T02).
 
 Reached from the workstation by port-forward; the tunnel `k3s-api-railiance01`
-(local `16444`) carries the API. Note `~/.kube/config` / `config-hosteurope`
-points at `16443`, which two bridge tunnels claim
-(`k3s-api-coulombcore` and `k3s-api-haskelseed`) — that collision is why a
-`system:masters` cert returns `Unauthorized` there. Use
-`--kubeconfig ~/.kube/config-railiance01`.
+(local `16444`) carries the API. Use `--kubeconfig ~/.kube/config-railiance01`.
+
+`~/.kube/config` / `config-hosteurope` — which `.bashrc` exports as `KUBECONFIG`
+— points at `16443`, and that was **CoulombCore's** k3s API, a different cluster
+whose client CA does not know this cert. Hence `Unauthorized`. CoulombCore is
+being retired and that tunnel was removed on 2026-08-19, so the port is simply
+gone now; `KUBECONFIG` was repointed at `config-railiance01`.
+
+*(An earlier revision of this file blamed a local-port collision between
+`k3s-api-coulombcore` and `k3s-api-haskelseed`. That was wrong: the haskelseed
+tunnel is a **reverse** forward, where `local_port` is the destination on this
+workstation rather than a listener, so the two never competed for the port. The
+correction is recorded here because the wrong reason was also sent to flex-auth
+and would have misdirected whoever followed the handoff.)*
 
 ## Baseline — before
 

wiki/CertCommandInterface.md

@@ -75,8 +75,8 @@ ssh-keygen -s /path/to/ca -I agt-test -n agt-task -V +24h /tmp/key.pub && cat /t
 
 ```yaml
 tunnels:
-  state-hub-coulombcore:
-    host: coulombcore
+  state-hub-railiance01:
+    host: railiance01
     remote_port: 8001
     local_port: 8000
     ssh_user: agt-state-hub-bridge

wiki/OpsWardenConfig.md

@@ -225,7 +225,7 @@ actors:
 hosts:
   # Optional: documents which principals are allowed on each host.
   # Not enforced by warden; used for reference and future tooling.
-  coulombcore:
+  railiance01:
     allowed_principals:
       agt:
         - agt-task-bridge
@@ -271,8 +271,8 @@ Add `cert_command` to a tunnel in `~/.config/bridge/tunnels.yaml`:
 
 ```yaml
 tunnels:
-  state-hub-coulombcore:
-    host: coulombcore
+  state-hub-railiance01:
+    host: railiance01
     remote_port: 8001
     local_port: 8000
     ssh_user: agt-state-hub-bridge

wiki/playbooks/openrouter-llm-connect.md

@@ -54,6 +54,10 @@ the Secret in cluster. The earlier manually created bootstrap Secret has been
 taken over by ESO on the CoulombCore cluster; the railiance01 k3s llm-connect
 instance still uses its bootstrap Secret (separate migration, not this lane).
 
+**Retirement note (2026-08-19):** CoulombCore is being retired, so the ESO-backed
+side of this lane needs to move to railiance01 rather than being the reference
+implementation. Owner is railiance-platform; ops-warden only routes here.
+
 ---
 
 ## Worker checklist

wiki/playbooks/ops-bridge-tunnel-cert.md

@@ -92,8 +92,8 @@ Edit `~/.config/bridge/tunnels.yaml` (ops-bridge repo owns schema; example below
 
 ```yaml
 tunnels:
-  state-hub-coulombcore:
-    host: coulombcore
+  state-hub-railiance01:
+    host: railiance01
     remote_port: 8001
     local_port: 8000
     ssh_user: agt-state-hub-bridge
@@ -115,8 +115,8 @@ tunnels:
 
 ```bash
 # ops-bridge (from ops-bridge repo)
-bridge status state-hub-coulombcore
-bridge up state-hub-coulombcore
+bridge status state-hub-railiance01
+bridge up state-hub-railiance01
 ```
 
 - [ ] Tunnel establishes without static cert file on disk
@@ -153,7 +153,7 @@ Post a State Hub progress note or save under `history/` with these fields:
 
 | Field | Example / instruction |
 | --- | --- |
-| Tunnel id | `state-hub-coulombcore` |
+| Tunnel id | `state-hub-railiance01` |
 | Actor | `agt-state-hub-bridge` |
 | Readiness gate | `check_tunnel_cert_readiness.py` exit code + date |
 | First `bridge up` success | ISO timestamp (tunnel established) |

wiki/playbooks/reuse-surface-hub-write-token.md

@@ -15,7 +15,7 @@ ops-warden does not vend this token — custody belongs to `railiance-platform`
 
 | Field | Value |
 | --- | --- |
-| OpenBao server | `https://bao.coulomb.social` (coulombcore) |
+| OpenBao server | `https://bao.coulomb.social` (railiance01, `92.205.62.239`) |
 | KV path | `platform/workloads/reuse/reuse-surface/runtime-secrets` |
 | Hub write field | `REUSE_SURFACE_TOKEN` |
 | Webhook HMAC field | `REUSE_SURFACE_FORGEJO_WEBHOOK_SECRET` |

workplans/WARDEN-WP-0031-policy-caller-identity.md

@@ -127,8 +127,9 @@ that line, not the allow, is the evidence.
 
 Done 2026-08-19. Source is `mode: command` — `kubectl create token ops-warden
 -n ops-warden --audience flex-auth --duration 10m` against the railiance01
-cluster (tunnel `k3s-api-railiance01`, local `16444`; note `16443` is claimed by
-two tunnels at once, which is why a `system:masters` cert 401s there).
+cluster (tunnel `k3s-api-railiance01`, local `16444`; `16443` was CoulombCore's
+k3s, a different cluster, which is why a `system:masters` cert 401s there —
+not a port collision, as first reported).
 `deploy/kubernetes/caller-identity.yaml` creates the Namespace and
 ServiceAccount the binding names — no RBAC, `automountServiceAccountToken:
 false`; it exists only to be TokenReviewed. Gate exits 0 live: