From a290d924df72ca9bab3186be25b941fb636b3ad0 Mon Sep 17 00:00:00 2001 From: tegwick Date: Thu, 20 Aug 2026 07:43:43 +0200 Subject: [PATCH] =?UTF-8?q?SHR-WP-0002=20=E2=80=94=20predecessor=20generat?= =?UTF-8?q?ions=20and=20deployment=20reality?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The project is retiring generation 1 with gates, inventories and evidence, while generation 2 has already retired itself by attrition and generation 3 runs only on a host being decommissioned. Neither fact appears in the project's records. Observed 2026-08-20: inter-hub runs nowhere (no repo, CoulombCore endpoint dead, railiance01 Deployment scaled 0/0) with no cutover evidence found, while core-hub/SCOPE.md still places retiring it out of scope and plans /api/v2 compatibility against it. core-hub itself is deployed only as staging on CoulombCore, and hub-core is a package rather than a service. The project's capability inventory does not mention inter-hub at all, so G-DISP has been applied to one generation only and lets gen-2 capabilities vanish unrecorded. Six tasks, all project-shaped per SCOPE.md — decide and inventory, route implementation to owners by identifier. The last proposes a G-GEN gate so a generation cannot be considered superseded until its capabilities have dispositions, its consumers are reconciled, its downstream lanes are swept, and its successor is deployed somewhere that will still exist. Co-Authored-By: Claude Opus 5 --- ...0002-predecessor-and-deployment-reality.md | 188 ++++++++++++++++++ 1 file changed, 188 insertions(+) create mode 100644 workplans/SHR-WP-0002-predecessor-and-deployment-reality.md diff --git a/workplans/SHR-WP-0002-predecessor-and-deployment-reality.md b/workplans/SHR-WP-0002-predecessor-and-deployment-reality.md new file mode 100644 index 0000000..29dc68d --- /dev/null +++ b/workplans/SHR-WP-0002-predecessor-and-deployment-reality.md @@ -0,0 +1,188 @@ +--- +id: SHR-WP-0002 +type: workplan +title: "Predecessor generations and deployment reality — stop retirement by attrition" +domain: infotech +repo: prj-state-hub-retirement +status: proposed +owner: unassigned +topic_slug: state-hub-retirement +created: "2026-08-20" +updated: "2026-08-20" +--- + +# SHR-WP-0002 — Predecessor generations and deployment reality + +## The problem in one sentence + +This project is retiring **generation 1** with gates, inventories and evidence, +while **generation 2 has already retired itself by attrition** and **generation 3 +runs only on a host being decommissioned** — and neither fact appears anywhere in +the project's records. + +## What was observed, 2026-08-20 + +The hub lineage is stated in `core-hub/INTENT.md`: gen 1 `state-hub`, gen 2 +`inter-hub`, gen 3 `core-hub` — *"The idea was right, but the Haskell/IHP/Nix +path was too heavy for the available infrastructure."* + +| Generation | Stated position | Observed reality | +| --- | --- | --- | +| 1 — `state-hub` | Being retired by this project, under gates | Running, and what the estate actually uses hourly | +| 2 — `inter-hub` | Superseded by core-hub | **Running nowhere.** No `~/inter-hub` repo; CoulombCore endpoint does not answer; railiance01 `inter-hub` Deployment is scaled `0/0`. **No cutover evidence found** | +| 3 — `core-hub` | The replacement | Deployed **only** as `core-hub-staging` on **CoulombCore**, the host being decommissioned. No core-hub namespace or Deployment on railiance01 | +| — `hub-core` | The surviving repository (GOAL §1) | A reusable Python package, not a running service | + +Three consequences follow, and none are recorded: + +1. **`core-hub/SCOPE.md` still places "retiring production Inter-Hub before + migration and smoke evidence exists" out of scope**, and lists `/api/v2` + compatibility and "data migration and production cutover planning from + Inter-Hub" as in scope. Those are the words of a repo expecting to migrate off + a *running* predecessor. It is not running. Either the migration completed and + the document is stale, or **the predecessor lapsed without one** — and those + demand different responses. +2. **`inventory/capabilities.yaml` does not mention `inter-hub` at all.** The + project has assigned dispositions for State Hub capabilities but never asked + what gen 2 was to provide, so nothing records whether those capabilities are + served, moved, or simply gone. On the stated lineage the unserved set is + plausibly: **domain hubs, shared manifests, widgets, registry facts, and the + unified operator surface** — state-hub covers coordination, not those. +3. **Consumers disagree with each other.** `reuse-surface/SCOPE.md` records + "inter-hub registration disabled on hub"; `llm-connect/SCOPE.md` still lists + `inter-hub` as a *current known consumer* using an LLM bridge for interaction + federation. One is stale and no one owns the reconciliation. + +## Why this belongs to the project and not to a child repo + +No single repository can see it. `core-hub` knows its own migration plan; +`llm-connect` knows its consumers; `ops-warden` knows its access lanes. Only this +project holds the cross-repository authority, the disposition inventory, and the +gates — and `G-DISP` ("full disposition inventory"), `G-CORE-ABSORB` and +`G-HUB-RUNTIME` are all currently gated on assumptions that the observations +above contradict. + +Per `SCOPE.md`, this workplan **decides and inventories; it does not implement**. +Every implementation task it identifies is routed to the owning repository by +identifier. + +## Tasks + +```task +id: SHR-WP-0002-T01 +status: todo +priority: high +``` + +**Establish what happened to inter-hub, on evidence.** Ask `core-hub` directly: +was there a migration and cutover, or did the runtime lapse? Look for cutover +evidence, the last known good deployment, and whether `/api/v2` compatibility was +ever exercised by a real consumer. + +Record the answer in `DECISIONS.md`. If it lapsed, say so plainly — a project +that documents an orderly gen-1 retirement while a gen-2 retirement happened by +attrition should own that contrast rather than let it sit unstated. It is the +single most useful lesson available to the gen-1 retirement now being planned. + +```task +id: SHR-WP-0002-T02 +status: todo +priority: high +``` + +**Extend the disposition inventory backwards to generation 2.** `G-DISP` demands +that every capability reach an explicit destination or retirement decision. +Applied only to State Hub, it lets gen-2 capabilities vanish unrecorded. + +Produce `inventory/inter-hub-disposition.yaml` in the shape of the existing +capability rollup: for each capability gen 2 was to provide — domain hubs, shared +manifests, widgets, registries, events, unified operator surface — record whether +it is **served today** (and by what), **planned** (and by whom, under which +workplan), or **dropped** (and by whose decision). + +The expected output is uncomfortable and worth having: a list of things the +estate intended to have, does not have, and has not decided to do without. + +```task +id: SHR-WP-0002-T03 +status: todo +priority: high +``` + +**Reconcile the gates with deployment reality.** `G-HUB-RUNTIME` and +`G-CORE-ABSORB` presume a runtime to absorb traffic into. Today the only +core-hub runtime is `core-hub-staging` on CoulombCore, which is being +decommissioned, and `hub-core` is a package rather than a service. + +Decide and record: does core-hub's runtime move to railiance01 first, or does +consolidation into `hub-core` (GOAL §1) happen directly, skipping a migration to +a host that is itself scheduled to disappear? Sequence it explicitly **against +the CoulombCore decommission date**, which is the real constraint and is not +currently represented in the gate model. + +Precedent worth reusing: `issue-core` was migrated off CoulombCore on 2026-08-19 +via `ISSUE-WP-0007` and a `rapp-issue-core` package. That is the pattern, and it +is one week old. + +```task +id: SHR-WP-0002-T04 +status: todo +priority: medium +``` + +**Reconcile stated scope against reality across participating repositories.** +The lineage confusion is visible in the documents: `core-hub/SCOPE.md` guards a +predecessor that is not running; `llm-connect/SCOPE.md` names a consumer +relationship that cannot exist; `ops-hub` describes itself as an extension *for +Core Hub*, a repository this project intends to retire into `hub-core`. + +Produce a table of every participating repository's stated position versus +observed reality, and route each correction to its owner. Do **not** edit their +files from here — the project's authority is the ledger, not the prose. + +```task +id: SHR-WP-0002-T05 +status: todo +priority: medium +``` + +**Sweep the downstream lanes that outlived their subject.** A retired generation +leaves access and credential lanes behind, and they do not expire on their own. + +Known instance: ops-warden's routing catalog carries `inter-hub-bootstrap-ssh` — +`status: active`, `risk: high`, last reviewed 2026-06-24 — a bootstrap SSH +envelope for a system that runs nowhere, whose runbook points at "the ops-hub +production activation lane tracked by `CUST-WP-0049`". ops-warden cannot retire +it alone: the lane may still serve ops-hub activation independently of inter-hub's +runtime, and only this project can see both sides. + +Ask each participating repository for lanes, tunnels, credentials and scheduled +jobs whose subject is a retired or lapsed generation. Route retirements to owners; +record the sweep here so the next generation change has a checklist rather than a +memory. + +```task +id: SHR-WP-0002-T06 +status: todo +priority: medium +``` + +**Add a generation-transition gate, so this cannot recur.** The project has gates +for retiring State Hub deliberately. It has none that would have caught a +predecessor lapsing, or a successor running only on a host scheduled for +shutdown. + +Propose `G-GEN` for `architecture/retirement-gates_v0.1.md`: no generation is +considered superseded until its capabilities carry explicit dispositions, its +consumers are reconciled, its downstream lanes are swept, and its successor is +deployed somewhere that will still exist. Take it through the project's normal +decision route rather than adding it unilaterally. + +## Related + +- `SHR-WP-0001` — foundation and architecture baseline (finished) +- `architecture/retirement-gates_v0.1.md` — `G-DISP`, `G-CORE-ABSORB`, `G-HUB-RUNTIME` +- `inventory/capabilities.yaml` — the gen-1 rollup this extends +- `core-hub/INTENT.md` — the stated lineage +- `issue-core` `ISSUE-WP-0007` — the CoulombCore migration precedent +- ops-warden `inter-hub-bootstrap-ssh` — a lane outliving its subject