Publish cluster resource evidence and gate ThreePhoenix

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02669-87ee-7a31-b111-edc95a16e0fa

docs/cluster-resource-evidence.md

@@ -0,0 +1,14 @@
+# Cluster resource evidence
+
+`make cluster-observe` captures a non-secret, timestamped observation for
+`resource:railiance:reef-railiance:k3s`. It separates allocatable capacity,
+requests, limits, optional observed usage, PVC demand, storage-class behavior,
+and measurement gaps. It never reads Secret objects or pod environments.
+
+The allocation section publishes raw numerators, denominators, residual
+capacity, and `cluster-raw-drivers-v1`. It does not select a financial
+allocation formula or write booked cost; those decisions remain with
+resource-control.
+
+Current failure-domain evidence remains explicit: one Ready node on
+`railiance01` with local storage. ThreePhoenix is a target, not live capacity.

docs/threephoenix-implementation-gate.md

@@ -0,0 +1,37 @@
+# ThreePhoenix implementation gate
+
+`RCLUSTER-WP-0007` stays in backlog until every gate below is backed by
+reviewable source or evidence. This prevents a target architecture from being
+reported as live capacity and prevents destructive work on the current
+single-node production cluster.
+
+## Required preflight
+
+- Three reef members have stable source-backed identities and map to three
+  independently provisioned, S1-converged hosts.
+- The failure-domain record covers physical host, provider/site, power,
+  storage, and network dependencies. Co-located guests count as one domain.
+- Private inter-node addresses, routes, and firewall rules are approved. The
+  Kubernetes API remains operator-only and no public 6443 grant is possible.
+- k3s server roles, embedded-etcd join order, version pin, rollback path, and
+  quorum checks are reviewed.
+- Join-token creation, delivery, rotation, and revocation use the approved
+  platform custody path; no token value is committed or copied into evidence.
+- Storage prerequisites and the Longhorn-or-alternative decision are approved
+  against the actual host/storage failure domains.
+- Backups and restore points exist before any migration or destructive test.
+- An operator explicitly approves each drain, rebuild, detach, or failure
+  injection against a named host and maintenance window.
+
+## Evidence required to open implementation
+
+Record a dated preflight artifact that identifies the three reef-member and
+host records, links the network and custody decisions, records current backup
+checks, and names the approving operator. After that evidence is reviewed, the
+workplan may move from `backlog` to `ready`; individual tasks still follow
+their own `todo` → `progress` → `done` lifecycle.
+
+Until then, allowed work is limited to source-only design, validation tooling,
+and dependency preparation. Provider purchase, live cluster joins, firewall
+mutation, Longhorn installation, and failure injection remain outside the
+authorized stage.