SHR-WP-0002 — predecessor generations and deployment reality
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 <noreply@anthropic.com>
This commit is contained in:
parent
48a40465c7
commit
a290d924df
1 changed files with 188 additions and 0 deletions
188
workplans/SHR-WP-0002-predecessor-and-deployment-reality.md
Normal file
188
workplans/SHR-WP-0002-predecessor-and-deployment-reality.md
Normal file
|
|
@ -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
|
||||
Loading…
Add table
Add a link
Reference in a new issue