Finish first repo-family materialization wave

docs/adr/ADR-0004-first-wave-reef-rollout.md

@@ -20,7 +20,7 @@ At the same time, S1 ownership is ambiguous because `railiance-hosts` and
 
 The first-wave reef rollout is:
 
-1. `reef-railiance01`
+1. `reef-railiance`
 2. `reef-coulombcore`
 3. `reef-ops-workstations`
 
@@ -33,8 +33,8 @@ frozen, or reduced later rather than as a second canonical S1 architecture home.
 
 ### Positive
 
-- Railiance gets a primary home-reef seed without waiting for a multi-node
-  future.
+- Railiance gets a grouped home-reef seed whose name remains stable as more
+  home servers are added.
 - Transitional CoulombCore reality is acknowledged without being treated as the
   long-term preferred production pattern.
 - Operator edge compute is modeled without defaulting to one repo per machine.
@@ -43,8 +43,8 @@ frozen, or reduced later rather than as a second canonical S1 architecture home.
 ### Required Follow-On Work
 
 - Create repo-local rollout work for the first reef repos.
-- Decide whether Railiance01 later remains a singleton reef or becomes part of
-  a grouped home reef.
+- Define how additional Railiance home servers join `reef-railiance` and what
+  future split criteria would justify narrower reefs.
 - Plan the `railiance-hosts` cleanup direction relative to `railiance-infra`.
 
 ### Constraints

docs/fabric-state-hub-adaptation.md

@@ -53,8 +53,8 @@ Add or derive the following repo-level concepts:
   not `ownership`
 - `primary_rail`: for reefs or workloads where one rail is the declared default
 - `supported_rails`: for `rapp-*` repos
-- `substrate_kind`: for `reef-*` repos, such as `server`, `cluster`,
-  `workstation-group`, or `edge`
+- `substrate_kind`: for `reef-*` repos, such as `server`, `server-group`,
+  `cluster`, `workstation-group`, or `edge`
 
 These fields may start in `.repo-classification.yaml` or a repo-local
 companion metadata file if the classification schema should stay smaller.

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
 

docs/reef-substrate-model.md

@@ -128,7 +128,7 @@ A reef name should follow the durable substrate identity used by operators.
 Good examples:
 
 - `reef-coulombcore`
-- `reef-railiance01`
+- `reef-railiance`
 - `reef-workstation`
 - `reef-ops-workstations`
 
@@ -176,18 +176,18 @@ kind of substrate. Terms such as "associate", "sidecar", or "comet" may be
 useful exploration language, but they should stay provisional until the pattern
 repeats and earns a stable place in the framework vocabulary.
 
-### `RAILIANCE01`
+### Railiance Home Substrate
 
-`reef-railiance01` is reasonable if Railiance01 is separately managed, migrated,
-or recovered, rather than being just another fungible node in a larger
-substrate.
+`reef-railiance` is reasonable when Railiance home servers are expected to
+share one durable operational substrate boundary, with `Railiance01` as the
+first current member rather than the permanent repo name anchor.
 
-At the current maturity level, it is acceptable for `reef-railiance01` to host
+At the current maturity level, it is acceptable for `reef-railiance` to host
 `rail-kubernetes` and later also `rail-knative` if that is the most pragmatic
-way to support early workloads.
+way to support early workloads across that grouped home substrate.
 
-If that substrate becomes production-critical or security-sensitive, reassess
-whether a clearer reef separation is warranted.
+If member servers later diverge enough in lifecycle, access path, or security
+boundary, reassess whether the grouped reef should split into narrower reefs.
 
 ### `WORKSTATION`
 

docs/repo-family-bootstrap-contract.md

@@ -149,7 +149,7 @@ The first materialization wave should target:
 
 - `rail-kubernetes`
 - `rapp-openbao`
-- `reef-railiance01`
+- `reef-railiance`
 
 The follow-on first-wave candidates after those anchors are stable:
 

docs/repository-axes.md

@@ -145,7 +145,7 @@ are bound.
 Examples:
 
 - `reef-coulombcore`
-- `reef-railiance01`
+- `reef-railiance`
 - `reef-workstation`
 - `reef-ops-workstations`