Refresh Current State against the live clusters

Verified against railiance01 on 2026-08-12 once API access was restored.

Corrections: two clusters are managed, not one - railiance01 is the current
primary running the live workloads, CoulombCore is the older frozen cluster.
Traefik is the ingress controller, not nginx. ArgoCD is not on railiance01 at
all; it runs on CoulombCore only, so the previous entry was accurate for that
host but misleading as a general cluster-level claim.

Adds the verified addon and CNPG cluster inventory, notes the absence of any
monitoring stack, and points at RAIL-HO-WP-0009 for the source-restricted k3s
API.

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

workplans/RAIL-BS-WP-0014-capacity-utilization-and-allocation-evidence.md

@@ -0,0 +1,83 @@
+---
+id: RAIL-BS-WP-0014
+type: workplan
+title: "Publish cluster capacity, utilization, and allocation evidence"
+domain: financials
+repo: railiance-cluster
+status: ready
+owner: codex
+topic_slug: railiance
+created: "2026-08-11"
+updated: "2026-08-11"
+related:
+  - RAIL-BS-WP-0007
+  - RESOURCE-WP-0003
+state_hub_workstream_id: "ea6ec98a-0d65-4afa-b6c5-6e7ed34011ac"
+---
+
+# RAIL-BS-WP-0014 — cluster resource evidence
+
+## Goal
+
+Publish reproducible non-secret evidence for
+`resource:railiance:reef-railiance:k3s`: capacity, requested and observed
+utilization, persistent-storage exposure, failure domains, and allocation
+drivers. Origin: `RESOURCE-WP-0003-T04` delegated evidence gap.
+
+## T01 — Produce periodic cluster capacity observations
+
+```task
+id: RAIL-BS-WP-0014-T01
+status: todo
+priority: high
+state_hub_task_id: "a144bf1d-0402-4526-9bda-17846390270c"
+```
+
+Collect node count, allocatable CPU/memory/storage/pods, workload requests and
+limits, observed usage when metrics are available, and PVC requested capacity.
+Aggregate by namespace/workload without exposing Secret data or pod
+environment. Preserve observation time, cluster identity, units, unavailable
+metrics, and source commands.
+
+Done when repeated observations use a stable machine-readable interface and
+resource-control can distinguish headroom, reservations, and actual usage.
+
+## T02 — Publish the failure-domain and storage contract
+
+```task
+id: RAIL-BS-WP-0014-T02
+status: todo
+priority: high
+state_hub_task_id: "6460d9aa-3ded-420a-bf01-f0ccdeee0a02"
+```
+
+Expose the current node-to-host/provider failure-domain map and the actual
+storage-class/PVC durability contract. Link the target ThreePhoenix work in
+`RAIL-BS-WP-0007` without reporting target nodes or distributed storage as
+current capacity.
+
+Done when consumers can calculate correlated-failure risk and recognize which
+state remains local to `railiance01`.
+
+## T03 — Define technical allocation-driver evidence
+
+```task
+id: RAIL-BS-WP-0014-T03
+status: todo
+priority: medium
+state_hub_task_id: "e5ff9b6c-e883-4356-9eca-b31757661d2f"
+```
+
+Evaluate namespace/workload CPU-request hours, memory-request hours, PVC
+GB-month, and observed usage as allocation drivers. Publish numerator,
+denominator, residual/unallocated capacity, method version, and uncertainty;
+do not convert the result into booked spend.
+
+Done when resource-control can create an explainable allocation and fin-hub can
+reconcile it to referenced financial facts.
+
+## Acceptance
+
+- [ ] Capacity evidence separates allocatable, requested, limited, and observed.
+- [ ] Current single-host/local-storage risk is machine-readable.
+- [ ] Allocation drivers reconcile to explicit totals and residuals.