1.8 KiB
INTENT
Why This Repo Exists
reef-railiance exists so Railiance has a first-class home for the grouped
home substrate boundary rather than treating each current or future Railiance
server as a separate architectural repo by default.
Before this repo, the relevant substrate facts lived only as source-backed S1
inventory and runbook context in railiance-infra. That remains the canonical
S1 authority, but it is the wrong long-term home for reef-local identity,
bindings, and substrate-specific coordination.
This repo establishes the durable answer to:
- what the Railiance home substrate is called
- which current servers are members of that grouped reef
- which rails are hosted there by default
- which workload bindings and substrate-local notes belong to that reef
What This Repo Must Protect
This repo must keep the first-wave home reef grouped and explicit.
That means:
- protect the distinction between grouped substrate identity and S1 ownership
- protect the distinction between reef-local bindings and generic rail behavior
- avoid one-repo-per-machine duplication when the grouped home substrate is the real boundary
- keep future split criteria explicit if member servers later diverge
What This Repo Is Not
This repo is not:
- the canonical S1 inventory authority
- the ownership home for Kubernetes runtime behavior
- the ownership home for OpenBao, Forgejo, or any other single workload
- proof that every Railiance server belongs in one reef forever
Initial Operating Context
Wave 1 starts with Railiance01 as the first current member of the grouped
home reef.
Future Railiance home servers should be represented here when they share the same lifecycle, access path, and workload-placement policy. If they stop sharing those traits, the grouped reef may need to split later.