coulomb/railiance-cluster
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
railiance-cluster/workplans/RAIL-BS-WP-0012-rail-kubernetes-extraction.md
codex 33bf6e7f3d
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 2s
Details
fix(workplans): adopt ADR-007 derived identifiers for unregistered records 
These workplans exist only in the retired local hub. Their random pre-ADR-007
identifiers are refused by C-06 as stale references, so they cannot be
registered. Deriving from the canonical record id takes no identity from
anything: central does not hold them and the old ids die with the cache.

Records central already holds were deliberately left untouched.

Refs CUST-WP-0068-T06

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
2026-08-25 20:18:34 +02:00

4.3 KiB
Raw Blame History

id type title domain repo status owner topic_slug created updated state_hub_workstream_id
RAIL-BS-WP-0012 workplan rail-kubernetes extraction from railiance-cluster financials railiance-cluster finished codex railiance 2026-07-25 2026-07-26 1efc2877-ab91-5137-bb02-a640d8f8dca5

RAIL-BS-WP-0012 - rail-kubernetes extraction from railiance-cluster

Goal

Prepare the S2 side of the rail-kubernetes split so railiance-cluster can return to a clean Kubernetes substrate identity while the generic workload-on-Kubernetes contract moves to a future rail-kubernetes repo.

This workplan follows the boundary defined in /home/worsch/railiance-master/docs/rail-kubernetes-boundary.md.

Boundaries

This workplan may:

  • clarify cluster-owned scope and retained files
  • prepare compatibility notes and substrate-profile outputs
  • identify exact move candidates and compatibility shims

It must not:

  • silently move files into a new repo that does not exist yet
  • break current bin/railiance users during the migration window
  • reassert S2 ownership over generic workload lifecycle semantics once the boundary is clear

T01 - Align railiance-cluster scope with the wave-1 boundary

id: RAIL-BS-WP-0012-T01
status: done
priority: high
state_hub_task_id: "1d410b6c-8359-51a1-b11f-8fde0d4d3f06"

Update S2 scope and related docs so they clearly distinguish:

  • Kubernetes substrate ownership that stays in railiance-cluster
  • generic workload lifecycle ownership that belongs to rail-kubernetes

Done when the repo no longer describes the staged workload lifecycle as a long-term S2 ownership concern.

2026-07-25: Updated SCOPE.md, README.md, and docs/README.md so S2 now claims Kubernetes substrate ownership only, while the generic workload lifecycle is marked as transitional material targeted for future rail-kubernetes.

T02 - Inventory exact extraction candidates and retained files

id: RAIL-BS-WP-0012-T02
status: done
priority: high
state_hub_task_id: "cb54055b-3bcf-5746-be81-3c664c5dedbf"

Inventory the current lifecycle docs, schema, examples, CLI commands, and scaffolding assets that should move to rail-kubernetes, and record which files remain cluster-owned.

Done when the repo has one reviewed move map tied to real file paths.

2026-07-25: Added docs/rail-kubernetes-extraction-map.md with reviewed file paths for material that moves to rail-kubernetes, material that remains cluster-owned, and migration debt that must be rehomed elsewhere.

T03 - Define the cluster substrate profile consumed by rail-kubernetes

id: RAIL-BS-WP-0012-T03
status: done
priority: high
state_hub_task_id: "4625e5e1-c953-5148-bd8a-4a04e76d6d6f"

Define the minimum cluster profile that S2 publishes for the future rail:

  • ingress class and routing modes
  • supported canary capabilities
  • certificate path
  • storage constraints
  • operator/runtime prerequisites
  • namespace and RBAC expectations

Done when rail-kubernetes has a narrow substrate contract to depend on.

2026-07-25: Added docs/rail-kubernetes-substrate-profile.md to publish the current S2 substrate facts, guaranteed canary mode, operator/runtime expectations, and explicit non-guarantees for wave 1.

T04 - Prepare compatibility shims for the migration window

id: RAIL-BS-WP-0012-T04
status: done
priority: medium
state_hub_task_id: "c452d2c6-dc96-5a10-9ab2-16c7f03bc5ae"

Blocked on T01-T03 and the creation of the future rail-kubernetes repo.

Plan the thin compatibility path that keeps current operators functional during the split, including any temporary bin/railiance delegation or short pointer docs left behind in railiance-cluster.

Done when the migration can proceed without a flag day for current users.

2026-07-26: Added docs/rail-kubernetes-compatibility-shim.md and updated the cluster dispatcher so create-overlay, run, deploy, observe, promote, and rollback delegate to rail-kubernetes/bin/railiance when a configured or sibling checkout exists. The cluster repo keeps a temporary local fallback for those six commands, while retained S2 commands and unrelated helper debt stay outside the handoff.

Notes

This workplan is intentionally repo-local. The framework-level separation plan lives in railiance-master/workplans/RMASTER-WP-0017-rail-rapp-reef-repo-separation.md.