Define S1 reef rollout handoff

docs/age-keys.md

@@ -107,6 +107,15 @@ If everything works, you are ready to store secrets securely in Git.
 
 ## 🔑 Secrets Handling Digest
 
-In RailianceHosts, **age private keys never leave your workstation**. Secrets in the repo are encrypted to one or more **public keys** listed in `.sops.yaml`. To decrypt, you either load your private key into the environment (`SOPS_AGE_KEY`) or keep it in your local `~/.config/sops/age/keys.txt` (never in Git). Ansible and Terraform decrypt files only on the control machine, so plaintext is injected at runtime but never stored on servers. For teams, simply add multiple public keys as recipients; each operator decrypts with their own private key. In CI/CD, the private key is injected securely as a secret variable. This ensures encryption is repo-wide and portable, while private keys remain personal, local, and outside version control.
+In `railiance-infra`, **age private keys never leave your workstation**.
+Secrets in the repo are encrypted to one or more **public keys** listed in
+`.sops.yaml`. To decrypt, you either load your private key into the environment
+(`SOPS_AGE_KEY`) or keep it in your local `~/.config/sops/age/keys.txt` (never
+in Git). Ansible and Terraform decrypt files only on the control machine, so
+plaintext is injected at runtime but never stored on servers. For teams, simply
+add multiple public keys as recipients; each operator decrypts with their own
+private key. In CI/CD, the private key is injected securely as a secret
+variable. This ensures encryption is repo-wide and portable, while private keys
+remain personal, local, and outside version control.
 
 ✅ That’s it — your secrets are now protected with your own master key.

docs/convergence.md

@@ -1,6 +1,7 @@
 # 🔧 Server Convergence
 
-After provisioning servers with Terraform, RailianceHosts uses **Ansible** to bring them into a secure and usable baseline state.  
+After provisioning servers with Terraform, `railiance-infra` uses **Ansible**
+to bring them into a secure and usable baseline state.  
 This process is called **convergence**.
 
 ## What Convergence Does

docs/provisioning.md

@@ -1,4 +1,4 @@
-# 🚀 Provisioning Servers with RailianceHosts
+# 🚀 Provisioning Servers with railiance-infra
 
 This guide explains **where you declare servers**, **how Terraform uses that declaration**, and **how to provision** (and later destroy) machines on Hetzner.
 

docs/reef-first-wave-source-map.md

@@ -0,0 +1,150 @@
+# First-Wave Reef Source Map
+
+Date: 2026-07-25
+
+## Purpose
+
+Prepare the S1 source-backed handoff for the first reef rollout without turning
+`railiance-infra` into a second reef repo family.
+
+This document records:
+
+- why `railiance-infra` is the canonical S1 source for reef creation
+- which substrate facts are already stable enough to seed the first reefs
+- which labels or future interpretations must remain provisional
+
+This follows
+`/home/worsch/railiance-master/docs/reef-first-wave-rollout.md`.
+
+## Canonical S1 Stance
+
+For future architecture work:
+
+- `railiance-infra` is the canonical S1 ownership repo
+- `railiance-hosts` is a predecessor or compatibility duplicate, not a second
+  authority for new reef planning
+- future `reef-*` repos should project from the source-backed facts here rather
+  than recreate their own incompatible substrate inventories
+
+Practical rule:
+
+- use `inventory/servers.yaml` as the starting identity source for server reefs
+- use S1 docs and operator-runbook facts for grouped workstation reefs
+- treat legacy `railiance-hosts` references in historical ADRs, inbox evidence,
+  and archived workplans as historical context, not as current authority
+
+## Stable Source Files
+
+The current first-wave reef rollout should anchor on these files:
+
+- `inventory/servers.yaml`
+- `ansible/inventory/host_vars/CoulombCore.yml`
+- `docs/deploy-stack.md`
+- `docs/age-keys.md`
+- `docs/adr/ADR-003-railiance-5repo-stack-architecture.md`
+- `docs/adr/ADR-004-forgejo-in-cluster-actions-runner.md`
+
+These files are not a complete future reef schema, but they already provide the
+minimum operational facts needed to seed the first reef repos.
+
+## First-Wave Reef Source Map
+
+### `reef-railiance01`
+
+Stable facts available now:
+
+- server identity: `Railiance01`
+- IP: `92.205.62.239`
+- SSH user: `tegwick`
+- authoritative source today: `inventory/servers.yaml`
+- current role in the ecosystem: the clearest home for new Kubernetes-first
+  production-oriented workloads
+- operational evidence in this repo: ADR-004 records Forgejo production and
+  Actions runner placement on `railiance01`
+- primary rail stance for first rollout: `rail-kubernetes`
+
+Known gaps that must stay explicit:
+
+- no dedicated `host_vars/Railiance01.yml` exists yet
+- the long-term grouped-home-reef shape is not decided yet
+- whether later `rail-knative` shares this reef or warrants separation remains
+  a workload- and security-driven decision
+
+### `reef-coulombcore`
+
+Stable facts available now:
+
+- server identity: `CoulombCore`
+- IP: `92.205.130.254`
+- SSH user: `tegwick`
+- authoritative source today: `inventory/servers.yaml`
+- host-specific S1 operational facts already recorded in
+  `ansible/inventory/host_vars/CoulombCore.yml`
+- `docs/deploy-stack.md` still treats CoulombCore as an active operator access
+  and execution point for convergence and stack bring-up
+- ops-bridge naming already distinguishes `state-hub-coulombcore`
+
+Operational interpretation for rollout:
+
+- create it as a transitional reef
+- keep mixed-purpose and fallback realities visible instead of pretending it is
+  already the preferred long-term home
+
+### `reef-ops-workstations`
+
+Stable facts available now:
+
+- this is a grouped substrate class, not a permanent singleton machine
+- age private keys stay on operator workstations; see `docs/age-keys.md`
+- ops-bridge and attended control-plane access originate from the workstation;
+  see `docs/deploy-stack.md`
+- kubeconfig use, SSH key custody, and attended control actions are currently
+  workstation responsibilities rather than server responsibilities
+
+Operational interpretation for rollout:
+
+- model this as operator or edge compute
+- keep machine membership inside reef-local topology rather than creating one
+  repo per laptop
+
+## Stable Facts Versus Provisional Labels
+
+Stable now:
+
+- the first-wave reef set:
+  - `reef-railiance01`
+  - `reef-coulombcore`
+  - `reef-ops-workstations`
+- `railiance-infra` as canonical S1 ownership source
+- inventory-backed server identity for `Railiance01` and `CoulombCore`
+- operator workstation responsibilities for age key custody, bridge usage, and
+  attended control-plane actions
+- `rail-kubernetes` as the first primary rail stance for `reef-railiance01`
+
+Provisional for now:
+
+- whether `reef-railiance01` later widens into a grouped `reef-railiance-home`
+- whether `rail-knative` should share `reef-railiance01` or later move to a
+  separate reef
+- narrative labels such as "associate", "sidecar", or "comet"
+- any claim that CoulombCore has a settled long-term role beyond being an
+  active transitional substrate
+
+## Handoff For First Reef Creation
+
+Each first-wave reef repo should start with:
+
+- substrate identity from the source-backed facts above
+- declared substrate kind:
+  - `server` for `reef-railiance01`
+  - `server` for `reef-coulombcore`
+  - `workstation-group` for `reef-ops-workstations`
+- lifecycle stance:
+  - primary home-reef seed for `reef-railiance01`
+  - transitional legacy or fallback reef for `reef-coulombcore`
+  - grouped operator-edge reef for `reef-ops-workstations`
+- initial primary rail statement where applicable
+- explicit unresolved questions instead of invented certainty
+
+That is enough to create the first reef repos without reopening the
+`railiance-hosts` versus `railiance-infra` ambiguity.

docs/ssh-access.md

@@ -1,6 +1,8 @@
 # 🔑 SSH Access & Connectivity Test
 
-RailianceHosts provisions Hetzner servers with your SSH key so you can log in securely (no passwords). Follow these steps to add your key and verify access.
+`railiance-infra` provisions Hetzner servers with your SSH key so you can log
+in securely (no passwords). Follow these steps to add your key and verify
+access.
 
 ---
 

docs/verification.md

@@ -1,6 +1,6 @@
 # Server Verification
 
-RailianceHosts ships a declarative baseline spec and a Goss test suite that
+`railiance-infra` ships a declarative baseline spec and a Goss test suite that
 asserts every managed node matches it. This replaces manual spot-checks with
 a reproducible, CI-friendly pass/fail verdict.