---
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