Bootstrap grouped home reef repo

INTENT.md

@@ -0,0 +1,49 @@
+# 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.