railiance-cluster/docs/threephoenix-implementation-gate.md

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.