diff --git a/docs/retirement-cutover-slice-plan.md b/docs/retirement-cutover-slice-plan.md index 281360b..fcff017 100644 --- a/docs/retirement-cutover-slice-plan.md +++ b/docs/retirement-cutover-slice-plan.md @@ -26,7 +26,7 @@ Two rules constrain the ordering: | Owner | Items | Gating workplan | Status | Can receive? | | --- | --- | --- | --- | --- | -| `repo-manager` | 167 | RMGR-WP-0001/0002/0003 | `finished` | **Yes** | +| `repo-manager` | 167 | RMGR-WP-0001/0002/0003 | `finished` | **Partial — see correction below** | | `hub-core` | 128 | HUB-WP-0004 runtime + extension contract | `proposed` | No | | `state-hub-until-cutover` | 55 | — (keep/retire in place) | — | n/a | | `activity-core` | 18 | ACTIVITY-WP-0029 hub port alignment | `active` | Partial | @@ -36,9 +36,49 @@ Two rules constrain the ordering: | `ops-bridge` | 2 | — (`keep`) | — | n/a | | `the-custodian` | 2 | — | — | Yes | -Only the `repo-manager` lane is fully unblocked today. **Wave A is the whole of -the near-term executable surface**; everything else is correctly waiting on an -owner-side contract, not on State Hub. +Only the `repo-manager` lane is unblocked today, and **only partly** — see the +correction immediately below. Everything else is waiting on an owner-side +contract, not on State Hub. + +### Correction (2026-08-20): repo-manager readiness is per-capability + +The table above reads owner readiness off workplan status, which is too coarse. +RMGR-WP-0001/0002/0003 are `finished`, but what they delivered is **work-record +dual-run, repository observation, and scaffolding** — not a general register +surface. Verified against `repo-manager/src/repo_manager/` on 2026-08-20: + +| `rmgr` surface | Covers | Slice | +| --- | --- | --- | +| `observe`, `load_classification` | repository representation, classification | A1 (partial) | +| `reconcile`, `index_store`, `parse/workplan.py`, `task-status`, `dual_run` | work records | A2 | +| `conform`, `standards.py`, `scaffold` | standards, onboarding | A1 `repo-onboarding` (already cut over) | +| `prefix` | workplan prefix registry | A1 (partial) | + +`parse/` contains **only** `workplan.py`. A grep for `sbom`, `repo_goal`, +`contribution`, `technical_debt`, and `extension_point` across the whole source +tree returns **nothing**. + +**Consequence:** A3, A4, and A5 have no owner-side surface to receive them. + +| Slice | Items | Receivable? | +| --- | --- | --- | +| A1 repository registry | 27 | Partial — `observe`/`conform` cover representation; registry CRUD does not exist | +| A2 work records | 59 | **Yes** — this is exactly what RMGR-WP-0002/0003 proved | +| A3 registers | 49 | **No** — no register surface of any kind in repo-manager | +| A4 work + repo UI | 22 | **No** — `rmgr` is a CLI; there is no owner-side dashboard | +| A5 topic spine | 8 | **No** — no topic/classification contract beyond `observe` | + +The near-term executable surface is therefore **A1 + A2, not 165 items**, and +A2 is the only slice with a proven adapter. + +**A3 is not the low-blast-radius first cut this plan originally recommended** — +it is the least ready slice in Wave A. The recommendation is withdrawn. + +**Do not build the register surface in State Hub.** New register capability here +would be new permanent ownership in the component being retired, which +`policies/retirement-freeze.md` makes inadmissible. A3/A4/A5 need a +`repo-manager` workplan; RMGR-WP-0004 (standards conformance) and RMGR-WP-0005 +(registrar consolidation) do not cover them. ## Adapter mechanism @@ -107,11 +147,16 @@ and leave the job dual-running. | | | | --- | --- | | Flag | `RM_SLICE_REGISTERS` | -| Owner API | `rmgr` register endpoints | -| Rollback | flag → `off`; these are append-mostly, so replay is cheap | +| Owner API | **does not exist** — see the readiness correction above | +| Rollback | n/a until there is something to roll back from | -Low coupling and low write volume — the natural place to prove the -`RM_SLICE_*` pattern before A2's blast radius. +**Blocked.** repo-manager has no register surface: no SBOM ingest, no repo +goals, no contributions, no technical-debt or extension-point registry. This +slice cannot start until a repo-manager workplan builds one. + +Low coupling and low write volume still make this the right slice to prove the +`RM_SLICE_*` pattern **once the owner side exists** — but that is a +repo-manager-side prerequisite, not a State Hub task. ### A4 · Work + repo UI — 22 items `work-coordination-ui` (14, `replace`) · `repo-ui` (8) @@ -327,6 +372,15 @@ discovered live at cutover. ## Next actions -1. Resolve the legacy-meter window discrepancy above — it gates E2 and T05. -2. Implement `RM_SLICE_REGISTERS` (A3) first as the pattern proof. -3. Do not open Wave B until HUB-WP-0004 reaches `ready`. +1. ~~Resolve the legacy-meter window discrepancy~~ — done 2026-08-20; E1 and the + evidenced part of E2 are executed. +2. **Raise a `repo-manager` workplan for the register surface** (A3), the UI + surface (A4), and the topic-spine contract (A5). Until that exists, 79 of + Wave A's 165 items have nowhere to go. This is now the critical path for the + whole retirement, ahead of anything State Hub can do to itself. +3. Cut **A2** (work records, 59 items) as the first real slice — it is the only + Wave A slice with a proven adapter. Split `RM_SLICE_WORKRECORDS` by record + kind to manage the blast radius rather than cutting it whole. +4. Do not open Wave B until HUB-WP-0004 reaches `ready`; 125 items sit behind it. +5. Do not build register, UI, or topic capability in State Hub to unblock + items 2–3 — `policies/retirement-freeze.md` makes that inadmissible. diff --git a/workplans/STATE-WP-0079-retirement-strangler.md b/workplans/STATE-WP-0079-retirement-strangler.md index 0019f29..b833ef8 100644 --- a/workplans/STATE-WP-0079-retirement-strangler.md +++ b/workplans/STATE-WP-0079-retirement-strangler.md @@ -124,6 +124,27 @@ state_hub_task_id: "db5291f2-3801-40fa-abf2-ceb0e77687c9" Implement strangler handoffs coordinated with RMGR-WP-0001 and HUB-WP-0004. Compatibility tests for each dispositioned route family. +**Owner-readiness correction (2026-08-20):** T02's slice plan marked all 167 +repo-manager items receivable because RMGR-WP-0001/0002/0003 are `finished`. +That reads readiness off workplan status, which is too coarse. Verified against +`repo-manager/src/repo_manager/`: those workplans delivered work-record +dual-run, repository observation, and scaffolding. `parse/` holds only +`workplan.py`, and the source tree has **no** reference to `sbom`, `repo_goal`, +`contribution`, `technical_debt`, or `extension_point`. + +So only **A1 (partial) and A2** are receivable — 86 items, not 165. A3 +(registers, 49), A4 (UI, 22) and A5 (topic spine, 8) have no owner-side surface +at all, and RMGR-WP-0004/0005 do not cover them. + +**Critical path is now repo-manager-side**, not here: a repo-manager workplan +must build the register, UI, and topic surfaces before 79 Wave A items can move. +Building them in State Hub is inadmissible under `policies/retirement-freeze.md` +— it would be new permanent ownership in the component being retired. + +First executable slice is therefore **A2** (work records, 59 items), the only +one with a proven adapter, with `RM_SLICE_WORKRECORDS` split by record kind to +manage blast radius. + **Inherited (2026-08-19) from `STATE-WP-0080-T04`:** this slice now also owns deletion of the templating path in `statehub_register.py` — `INTENT.md` generation, the `AGENTS.md` / `CLAUDE.md` / `.custodian-brief.md` templates,