railiance-master/docs/adr/ADR-0004-first-wave-reef-rollout.md
2026-07-25 10:54:37 +02:00

61 lines
1.9 KiB
Markdown

# ADR-0004: First-Wave `reef-*` Rollout
Date: 2026-07-25
Status: Accepted
## Context
Railiance now has a reef model, but it needs a concrete first rollout.
The current substrate reality is not uniform:
- Railiance01 is the clearest new-workload home
- CoulombCore is still active but transitional
- the workstation role is operator edge compute rather than server substrate
At the same time, S1 ownership is ambiguous because `railiance-hosts` and
`railiance-infra` duplicate each other.
## Decision
The first-wave reef rollout is:
1. `reef-railiance01`
2. `reef-coulombcore`
3. `reef-ops-workstations`
`railiance-infra` is the canonical S1 ownership repo going forward.
`railiance-hosts` is treated as predecessor or duplicate state to be retired,
frozen, or reduced later rather than as a second canonical S1 architecture home.
## Consequences
### Positive
- Railiance gets a primary home-reef seed without waiting for a multi-node
future.
- Transitional CoulombCore reality is acknowledged without being treated as the
long-term preferred production pattern.
- Operator edge compute is modeled without defaulting to one repo per machine.
- Reef planning now rests on one canonical S1 ownership line.
### Required Follow-On Work
- Create repo-local rollout work for the first reef repos.
- Decide whether Railiance01 later remains a singleton reef or becomes part of
a grouped home reef.
- Plan the `railiance-hosts` cleanup direction relative to `railiance-infra`.
### Constraints
- Multi-rail reefs are acceptable early, especially on transitional substrates.
- Production-grade separation should still prefer clearer purpose and primary
rail boundaries as criticality rises.
- Transitional substrate nicknames should remain provisional until the pattern
is stable enough to canonize.
## Notes
This ADR chooses the first rollout set. It does not require that every future
substrate be modeled the same way.