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