# 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.