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

2026-08-20 07:43:43 +02:00

8.4 KiB

Raw Blame History

id	type	title	domain	repo	status	owner	topic_slug	created	updated
SHR-WP-0002	workplan	Predecessor generations and deployment reality — stop retirement by attrition	infotech	prj-state-hub-retirement	proposed	unassigned	state-hub-retirement	2026-08-20	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:

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

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.

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.

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.

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.

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.

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.

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

8.4 KiB Raw Blame History