From 8253276bdd6ef1c1c51e577d59d5f348b3b546e8 Mon Sep 17 00:00:00 2001 From: codex Date: Mon, 17 Aug 2026 10:41:03 +0200 Subject: [PATCH] docs(canon): retire RAIL-BS-WP-; cluster takes RCLUSTER-WP-, bootstrap RBS-WP- Neither repo keeps the shared prefix. railiance-cluster switches active and future plans (0007 backlog, 0014 ready) to RCLUSTER-WP- preserving running numbers; railiance-bootstrap takes RBS-WP- starting at 0010, above its historical maximum, so its finished plans could be adopted later without collision. Finished files keep RAIL-BS-WP- per the option 2 ruling. RAILIANCE-WP- should be retired the same way rather than awarded to one repo; successor prefixes still outstanding. Co-Authored-By: Claude Opus 5 --- ...kplan-identity-and-repo-worker-topology.md | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/canon/architecture/adr-007-workplan-identity-and-repo-worker-topology.md b/canon/architecture/adr-007-workplan-identity-and-repo-worker-topology.md index 303ef6a..1aa2516 100644 --- a/canon/architecture/adr-007-workplan-identity-and-repo-worker-topology.md +++ b/canon/architecture/adr-007-workplan-identity-and-repo-worker-topology.md @@ -239,6 +239,28 @@ produces, and it will recur at the next concurrent allocation. `CUST-` is dormant on the `state-hub` side — four legacy plans, one in `backlog` — and needs no split, only a prefix-ownership assertion. +### Prefix assignments + +`RAIL-BS-WP-` is **retired** (2026-08-17). Neither repository keeps it: +`railiance-cluster` adopts `RCLUSTER-WP-` for active and future plans; +`railiance-bootstrap` adopts `RBS-WP-` for future plans. Finished and archived +files keep `RAIL-BS-WP-` as historical record, consistent with option 2. + +Migrating plans keep their running numbers — the prefix changes, the number does +not. This preserves traceability and cannot violate forward-only allocation, +because neither new prefix has prior history. `railiance-bootstrap` begins at +`RBS-WP-0010`, above its historical maximum, leaving the lower range free should +its finished plans ever be adopted into the new prefix. + +`RAILIANCE-WP-` should follow the same pattern — retired rather than awarded to +one repository, since it names a family rather than a repository and so fails +decision 1 for the same reason `PRJ-WP-` does. Assignment of the four successor +prefixes is outstanding. + +Execution of each rename belongs to a worker in the owning repository under +decision 4. `RMGR-WP-0004-T09` records assignments and the numbering rule; it +does not perform renames. + **Consequence.** Prefix ownership must be assigned for all three shared prefixes before the next workplan is created in the affected repositories. This is forward conformance under decision 1, not migration, and is tracked as