Finish first repo-family materialization wave

docs/reef-first-wave-rollout.md

@@ -43,7 +43,7 @@ Railiance currently has three clearly different substrate realities:
 
 The first-wave reef rollout is:
 
-1. `reef-railiance01`
+1. `reef-railiance`
 2. `reef-coulombcore`
 3. `reef-ops-workstations`
 
@@ -51,17 +51,19 @@ Do **not** create `reef-workstation` as a singleton first-wave repo.
 
 ## Why These Three
 
-### `reef-railiance01`
+### `reef-railiance`
 
-This should be the first canonical reef.
+This should be the first canonical grouped home reef.
 
 Why:
 
-- it is already the clearest purpose-bound substrate
+- `Railiance01` is already the clearest current seed of that substrate
 - it is the default home for new Kubernetes-oriented Railiance workloads
-- it is the likely seed of the future Railiance home reef
+- more Railiance servers may join the same home substrate over time
+- keeping the grouped reef name stable now avoids renaming the substrate every
+  time membership changes
 - its lifecycle, access path, and workload-placement decisions are already
-  distinct enough to justify a dedicated reef
+  distinct enough to justify a dedicated home reef
 
 Primary rail stance:
 
@@ -69,8 +71,8 @@ Primary rail stance:
 - temporary multi-rail reality is acceptable here during early growth
 - later `rail-knative` may coexist on this reef if that is the most pragmatic
   path for early workloads such as `qonto-assistent`
-- if criticality or security pressure grows, reassess whether a broader grouped
-  home reef or a rail-specific separation is required
+- if criticality or security pressure grows, reassess whether the grouped home
+  reef should split by rail or security boundary
 
 ### `reef-coulombcore`
 
@@ -116,18 +118,18 @@ Interpretation:
 
 Applying the reef rules to the current hosts yields:
 
-- `RAILIANCE01`: singleton reef now, because the machine itself is the current
-  durable substrate boundary
+- `RAILIANCE01`: grouped home reef now, with `Railiance01` as the first current
+  member because additional Railiance servers should be represented from the
+  same named home substrate when they share lifecycle, access path, and
+  workload-placement policy
 - `COULOMBCORE`: singleton reef now, because it remains an independent
   operational and fallback boundary
 - workstation: grouped reef, because the substrate concept is "operator edge
   compute" rather than one permanently special laptop
 
-If Railiance01 later becomes one node in a clearly unified multi-node home
-substrate with shared lifecycle and placement policy, reassess whether the
-right target becomes a grouped reef such as `reef-railiance-home`.
-
-Until then, `reef-railiance01` is the cleaner decision.
+If future Railiance servers diverge enough to need separate lifecycle,
+placement, or recovery policies, reassess whether `reef-railiance` should stay
+grouped or split into narrower reefs.
 
 ## `railiance-hosts` Versus `railiance-infra`
 
@@ -156,7 +158,7 @@ What this means:
 
 The reef rollout should happen in this order:
 
-1. create `reef-railiance01` as the first canonical home reef seed
+1. create `reef-railiance` as the first grouped home reef seed
 2. create `reef-coulombcore` as the transitional legacy/fallback reef
 3. create `reef-ops-workstations` as the grouped operator-edge reef
 4. document `railiance-infra` as canonical S1 and plan the `railiance-hosts`
@@ -176,7 +178,7 @@ The reef rollout should happen in this order:
 
 Railiance now has a concrete first reef rollout:
 
-- `reef-railiance01` as the primary home-reef seed
+- `reef-railiance` as the primary grouped home-reef seed
 - `reef-coulombcore` as the transitional legacy/fallback reef
 - `reef-ops-workstations` as the grouped operator-edge reef