railiance-infra/docs/reef-first-wave-source-map.md

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.