# First-Wave Reef Source Map

Date: 2026-07-25

## Purpose

Prepare the S1 source-backed handoff for the first reef rollout without turning
`railiance-infra` into a second reef repo family.

This document records:

- why `railiance-infra` is the canonical S1 source for reef creation
- which substrate facts are already stable enough to seed the first reefs
- which labels or future interpretations must remain provisional

This follows
`/home/worsch/railiance-master/docs/reef-first-wave-rollout.md`.

## Canonical S1 Stance

For future architecture work:

- `railiance-infra` is the canonical S1 ownership repo
- `railiance-hosts` is a predecessor or compatibility duplicate, not a second
  authority for new reef planning
- future `reef-*` repos should project from the source-backed facts here rather
  than recreate their own incompatible substrate inventories

Practical rule:

- use `inventory/servers.yaml` as the starting identity source for server reefs
- use S1 docs and operator-runbook facts for grouped workstation reefs
- treat legacy `railiance-hosts` references in historical ADRs, inbox evidence,
  and archived workplans as historical context, not as current authority

## Stable Source Files

The current first-wave reef rollout should anchor on these files:

- `inventory/servers.yaml`
- `ansible/inventory/host_vars/CoulombCore.yml`
- `docs/deploy-stack.md`
- `docs/age-keys.md`
- `docs/adr/ADR-003-railiance-5repo-stack-architecture.md`
- `docs/adr/ADR-004-forgejo-in-cluster-actions-runner.md`

These files are not a complete future reef schema, but they already provide the
minimum operational facts needed to seed the first reef repos.

## First-Wave Reef Source Map

### `reef-railiance`

Stable facts available now:

- current first member: `Railiance01`
- current member IP: `92.205.62.239`
- current member SSH user: `tegwick`
- authoritative source today: `inventory/servers.yaml`
- current role in the ecosystem: the clearest home for new Kubernetes-first
  production-oriented workloads
- operational evidence in this repo: ADR-004 records Forgejo production and
  Actions runner placement on `railiance01`
- primary rail stance for first rollout: `rail-kubernetes`
- grouped-home intent: additional Railiance servers should be represented here
  when they share the same home substrate lifecycle and workload-placement
  policy

Known gaps that must stay explicit:

- only one source-backed member (`Railiance01`) is recorded today
- no dedicated `host_vars/Railiance01.yml` exists yet
- whether later `rail-knative` shares this reef or warrants separation remains
  a workload- and security-driven decision

### `reef-coulombcore`

Stable facts available now:

- server identity: `CoulombCore`
- IP: `92.205.130.254`
- SSH user: `tegwick`
- authoritative source today: `inventory/servers.yaml`
- host-specific S1 operational facts already recorded in
  `ansible/inventory/host_vars/CoulombCore.yml`
- `docs/deploy-stack.md` still treats CoulombCore as an active operator access
  and execution point for convergence and stack bring-up
- ops-bridge naming already distinguishes `state-hub-coulombcore`

Operational interpretation for rollout:

- create it as a transitional reef
- keep mixed-purpose and fallback realities visible instead of pretending it is
  already the preferred long-term home

### `reef-ops-workstations`

Stable facts available now:

- this is a grouped substrate class, not a permanent singleton machine
- age private keys stay on operator workstations; see `docs/age-keys.md`
- ops-bridge and attended control-plane access originate from the workstation;
  see `docs/deploy-stack.md`
- kubeconfig use, SSH key custody, and attended control actions are currently
  workstation responsibilities rather than server responsibilities

Operational interpretation for rollout:

- model this as operator or edge compute
- keep machine membership inside reef-local topology rather than creating one
  repo per laptop

## Stable Facts Versus Provisional Labels

Stable now:

- the first-wave reef set:
  - `reef-railiance`
  - `reef-coulombcore`
  - `reef-ops-workstations`
- `railiance-infra` as canonical S1 ownership source
- inventory-backed server identity for `Railiance01` and `CoulombCore`
- operator workstation responsibilities for age key custody, bridge usage, and
  attended control-plane actions
- `rail-kubernetes` as the first primary rail stance for `reef-railiance`
- `Railiance01` as the first current member of the grouped Railiance home reef

Provisional for now:

- the future member set beyond `Railiance01`
- whether `rail-knative` should share `reef-railiance` or later move to a
  separate reef
- narrative labels such as "associate", "sidecar", or "comet"
- any claim that CoulombCore has a settled long-term role beyond being an
  active transitional substrate

## Handoff For First Reef Creation

Each first-wave reef repo should start with:

- substrate identity from the source-backed facts above
- declared substrate kind:
  - `server-group` for `reef-railiance`
  - `server` for `reef-coulombcore`
  - `workstation-group` for `reef-ops-workstations`
- lifecycle stance:
  - primary grouped home-reef seed for `reef-railiance`
  - transitional legacy or fallback reef for `reef-coulombcore`
  - grouped operator-edge reef for `reef-ops-workstations`
- initial primary rail statement where applicable
- explicit unresolved questions instead of invented certainty

That is enough to create the first reef repos without reopening the
`railiance-hosts` versus `railiance-infra` ambiguity.