--- id: RMASTER-WP-0018 type: workplan title: "First-Wave Repo Family Materialization" domain: financials repo: railiance-master status: finished owner: codex topic_slug: railiance planning_priority: high planning_order: 18 created: "2026-07-25" updated: "2026-07-26" related_repos: - railiance-master - railiance-cluster - railiance-platform - railiance-infra - railiance-fabric state_hub_workstream_id: "054a494c-e430-4164-b2c3-e32e759cc3e0" --- # RMASTER-WP-0018 - First-Wave Repo Family Materialization ## Goal Turn the completed separation architecture into the first concrete `rail-*`, `rapp-*`, and `reef-*` repo materialization wave. This workplan governs the first implementation wave that makes the new repo families real rather than only defined. It stays in `railiance-master` because the sequencing still spans multiple ownership repos and Fabric integration. ## Why This Exists `RMASTER-WP-0017` completed the architecture baseline and launched the first repo-local follow-up workplans. What is still missing is the shared control plane for: - creating the first concrete repo-family baselines - keeping their boundaries consistent across repos - aligning repo-local declarations with Fabric and State Hub ingestion - preventing the first repo creations from drifting into ad hoc local patterns ## Current Starting Point The architecture baseline already exists in `railiance-master`: - `docs/repository-axes.md` - `docs/rail-kubernetes-boundary.md` - `docs/rapp-first-wave-candidates.md` - `docs/reef-first-wave-rollout.md` - `docs/fabric-state-hub-adaptation.md` The first implementation follow-up work also already exists: - `railiance-cluster/workplans/RAIL-BS-WP-0012-rail-kubernetes-extraction.md` - `railiance-platform/workplans/RAILIANCE-WP-0012-rapp-openbao-extraction-boundary.md` - `railiance-infra/workplans/RAIL-HO-WP-0007-first-reef-rollout-and-s1-canonicalization.md` - `railiance-fabric/workplans/RAIL-FAB-WP-0025-rail-rapp-reef-fabric-adaptation.md` Fabric now has first repo-family-aware repository metadata, but the ecosystem still lacks: - the first actual `rail-*` repo - the first actual `rapp-*` repo - the first actual `reef-*` repo - relation projection for rail/rapp/reef topology ## Target Outcome When this workplan is complete: 1. Railiance has a repeatable bootstrap contract for first-wave `rail-*`, `rapp-*`, and `reef-*` repos. 2. The first concrete `rail-kubernetes` repo exists and is registered. 3. The first concrete `rapp-openbao` repo exists and is registered. 4. The first concrete `reef-railiance` repo exists and is registered. 5. Fabric can project the minimum rail/rapp/reef relation topology needed to answer placement questions. ## Boundaries This workplan may coordinate repo creation, repo-family bootstrap, and graph integration across Railiance repos. It must not weaken the existing ownership boundaries: - `railiance-cluster` remains the S2 ownership home - `railiance-platform` remains the S3 ownership home for OpenBao - `railiance-infra` remains the canonical S1 ownership home for first-wave reefs - `railiance-fabric` remains the implementation home for graph ingestion and projection ## Tasks ## T01 - Publish the first-wave repo bootstrap contract ```task id: RMASTER-WP-0018-T01 status: done priority: high state_hub_task_id: "d6ba9286-222d-49d2-83e9-fd251c534dde" ``` Record the minimum bootstrap contract future `rail-*`, `rapp-*`, and `reef-*` repos should follow so the first materialization wave does not invent three incompatible patterns. Acceptance: - one framework document defines the minimum file baseline - one framework document defines the first declaration path per repo family - the metadata projection rule into Fabric and State Hub is named 2026-07-25: Added `docs/repo-family-bootstrap-contract.md`. ## T02 - Launch the first `rail-kubernetes` repo materialization ```task id: RMASTER-WP-0018-T02 status: done priority: high state_hub_task_id: "726a0c5c-2fa5-4bb9-a730-3200abc40ac8" ``` Create the concrete repo bootstrap and extraction path for `rail-kubernetes` using the boundary already defined in `railiance-master` and the repo-local follow-up work already opened in `railiance-cluster`. Acceptance: - the new repo has the required baseline files - the repo declares the Kubernetes rail contract in source-controlled form - the compatibility path from `railiance-cluster` is preserved - the repo is ready for Fabric and State Hub registration 2026-07-25: Bootstrapped `/home/worsch/rail-kubernetes` with the baseline repo files, `declarations/rail.yaml`, repo-local docs, and `RAIL-K8S-WP-0001`. The repo is now registered in State Hub and seeded into `railiance-fabric/registry/railiance-repos.yaml`; live Fabric registry sync and had initially not yet been pushed to a remote. 2026-07-25: Reconciled `rail-kubernetes` with the server-side bootstrap commit on `forgejo-remote:coulomb/rail-kubernetes.git` and pushed `main`. The remaining registration gap is now only live Fabric registry sync. 2026-07-25: Attempted targeted live Fabric registry sync for `rail-kubernetes`, but the registry endpoint at `http://127.0.0.1:8765` refused the connection. The repo is now remote-backed and source-registered, while live registry ingestion remains blocked on the local Fabric registry service being up. 2026-07-25: Started the local Fabric registry service and completed the targeted live sync for `rail-kubernetes`. The repo is now State Hub registered, source-registered in the Fabric onboarding manifest, remote-backed in Forgejo, and live-ingested into the Fabric registry. Remaining wave-1 `rail-kubernetes` work is now about helper scripts and command implementations rather than registration. 2026-07-25: Imported the first core generic contract artifacts into `rail-kubernetes`: the canonical deployment lifecycle doc, the canonical `railiance/app.toml` contract doc, the machine-readable schema, and the example `railiance/app.toml`. Remaining helper-command and supporting-doc imports stay repo-local follow-up work. 2026-07-25: Imported the remaining reviewed generic supporting docs for the Kubernetes rail, including the overlay pattern, canary chart pattern, Stage 2 deploy/observe contract, promotion/rollback guide, and Stage 1 run-command contract. Remaining wave-1 import debt is now mainly helper scripts and command implementations rather than core contract documentation. 2026-07-25: Closed T02 after confirming the first-class repo baseline, source declaration, compatibility path, remote registration, State Hub registration, and live Fabric ingestion are all in place for `rail-kubernetes`. ## T03 - Launch the first `rapp-openbao` repo materialization ```task id: RMASTER-WP-0018-T03 status: done priority: high state_hub_task_id: "3e46e1bd-c730-4e41-a00a-6aa7a4645023" ``` Create the concrete repo bootstrap and workload-package declaration for `rapp-openbao` without letting the package repo absorb platform ownership. Acceptance: - the new repo has the required baseline files - the repo declares OpenBao as a managed workload package - the repo declares supported rails and rollout/smoke/rollback contract - the remaining ownership boundary with `railiance-platform` stays explicit 2026-07-25: Confirmed that `/home/worsch/rapp-openbao` does not yet exist. Bootstrap will start from the boundary and first move set already recorded in `railiance-platform/docs/rapp-openbao-boundary.md`. 2026-07-25: Bootstrapped `/home/worsch/rapp-openbao` with the first-wave repo baseline, `declarations/rapp.yaml`, a package-local Makefile, repo-local docs, the first imported OpenBao package assets from `railiance-platform`, and `RAPP-OPENBAO-WP-0001`. The repo is now registered in State Hub; Fabric registry onboarding remains open as repo-local follow-up work. ## T04 - Launch the first `reef-railiance` repo materialization ```task id: RMASTER-WP-0018-T04 status: done priority: medium state_hub_task_id: "f6f2ea73-0ff3-4cfa-b7a7-7b71db3afb4a" ``` Create the concrete repo bootstrap and substrate declaration for `reef-railiance` as the first grouped home reef repo. Acceptance: - the new repo has the required baseline files - the repo declares substrate kind, lifecycle, criticality, hosted rails, and primary rail - the repo stays compatible with the canonical S1 ownership role of `railiance-infra` 2026-07-26: Corrected the first-wave home reef target from singleton `reef-railiance01` to grouped `reef-railiance`, updated the framework and S1 source docs accordingly, and bootstrapped `/home/worsch/reef-railiance` with the baseline repo files, grouped reef declaration, substrate/topology files, repo-local docs, and `REEF-RAILIANCE-WP-0001`. The repo is now remote-backed in Forgejo, registered in State Hub, added to `railiance-fabric/registry/railiance-repos.yaml`, and live-ingested into the Fabric registry as `repo_family: reef` with `primary_rail: rail-kubernetes` and `substrate_kind: server-group`. ## T05 - Add relation projection for rails, `rapp`s, and reefs in Fabric ```task id: RMASTER-WP-0018-T05 status: done priority: medium state_hub_task_id: "ef999db5-e75e-467a-a72a-d45fda2b6fa7" ``` Extend Fabric beyond repo-family-aware metadata so it can project the minimum rail/rapp/reef relation topology. Acceptance: - Fabric can project `supports_rail` - Fabric can project `hosts_rail` - Fabric can project `binds_rapp` - Fabric can project `governed_by` - the projection path is grounded in repo-local declarations rather than registry-only guesses 2026-07-26: Completed the Fabric relation-projection slice in `railiance-fabric`. Repository records now retain local checkout paths, the registry combined graph reopens repo-local `rail`, `rapp`, and `reef` files to project `governed_by`, `supports_rail`, `hosts_rail`, and `binds_rapp`, and the graph explorer preserves the declaration evidence on projected repository nodes. Focused Fabric tests passed after the projection update. ## T06 - Verify first-wave registration and coordination end to end ```task id: RMASTER-WP-0018-T06 status: done priority: medium state_hub_task_id: "5834f122-b9e9-41c1-93e9-d5525cd720bf" ``` Verify that the first concrete repos participate cleanly in: - State Hub registration and indexing - Fabric registration and graph projection - workplan tracking across ownership repo and repo-family repo boundaries Acceptance: - the first concrete repos are visible to State Hub - the first concrete repos are visible to Fabric - cross-repo ownership and runtime relations are queryable - the wave can continue to second candidates without redefining the bootstrap model 2026-07-26: Verified the first-wave coordination path end to end. The live Fabric registry at `http://127.0.0.1:8765` now stores the local paths and repo-family metadata for `rail-kubernetes`, `rapp-openbao`, and `reef-railiance`, and its graph-explorer export emits live `governed_by`, `supports_rail`, and `hosts_rail` edges from repo-local declarations. State Hub consistency sync remains clean for the framework and repo-local workplans, so the first wave can continue without reopening the bootstrap model. ## Exit Criteria - [x] The first-wave bootstrap contract is published - [x] `rail-kubernetes` exists as a first-class repo baseline - [x] `rapp-openbao` exists as a first-class repo baseline - [x] `reef-railiance` exists as a first-class repo baseline - [x] Fabric projects the minimum rail/rapp/reef relation topology - [x] State Hub and Fabric can coordinate the first concrete repo-family wave end to end ## Notes This workplan should stay focused on the first concrete repo-family wave. Second-wave candidates such as `rapp-vergabe-teilnahme`, `reef-coulombcore`, or a future `rail-knative` should be launched only after the first wave proves the bootstrap contract, registration path, and relation model.