prj-state-hub-retirement/workplans/SHR-WP-0002-predecessor-and-deployment-reality.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
SHR-WP-0002	workplan	Generation 3 serves from the host being decommissioned	infotech	prj-state-hub-retirement	proposed	unassigned	state-hub-retirement	2026-08-20	2026-08-20	c94c3ba1-6c31-4989-a2eb-650726add747

SHR-WP-0002 — Predecessor generations and deployment reality

The problem in one sentence

Core Hub's production runtime — the generation-3 replacement, cut over deliberately and correctly in July — serves from hub.coulomb.social, which resolves to CoulombCore: the host being decommissioned. No plan in any repository accounts for that.

Correction to this workplan's first draft

The first draft of SHR-WP-0002 (2026-08-20, superseded before any task ran) claimed generation 2 had "retired itself by attrition". That was wrong, and the evidence contradicting it is in core-hub's own archive:

• CORE-WP-0005 finished 2026-07-03: hub.coulomb.social ingress serves Core Hub; Inter-Hub compatibility, staging import, dual-run smokes, and production cutover gates all closed.
• CORE-WP-0007 finished 2026-07-08: Haskell/IHP infrastructure retired, the production Inter-Hub repo renamed/archived, ihp-railiance-probe archived — after "a short post-cutover stabilization window" and explicit operator approval to retire the Inter-Hub rollback deployment.

The inter-hub Deployment scaled 0/0 on railiance01 is that rollback deployment, held at zero exactly as the workplan describes. It is not a lapse; it is the designed end state of a careful retirement.

The lesson is the opposite of the one first drafted: generation 2 was retired well. What nobody checked was whether the successor's runtime was standing on durable ground.

What was observed, 2026-08-20

Generation	Position	Observed
1 — state-hub	Being retired by this project, under gates	Running; what the estate uses hourly
2 — inter-hub	Retired CORE-WP-0005/0007, Jul 2026	Correctly gone. Rollback deployment at 0/0 as designed
3 — core-hub	The replacement, in production since 2026-07-03	hub.coulomb.social → 92.205.130.254 = CoulombCore. 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, none recorded anywhere:

1. The gen-1 retirement is being planned onto a runtime that has no home. G-HUB-RUNTIME and G-CORE-ABSORB presume somewhere to absorb traffic into. That somewhere is currently a host with a decommission date, and the gate model does not represent that date at all.
2. core-hub/SCOPE.md is stale in a way that hides this. It still places "retiring production Inter-Hub before migration and smoke evidence exists" out of scope and lists /api/v2 compatibility and "cutover planning from Inter-Hub" as in scope — work its own archive shows finished in July. A reader cannot tell from the live documents that the cutover already happened.
3. inventory/capabilities.yaml does not mention inter-hub. The migration was real, so this is a smaller gap than first thought — but G-DISP still has no record of where gen-2 capabilities went, and the estate cannot currently answer "does anything still provide the unified operator surface?" without reading an archived workplan.

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
state_hub_task_id: "7bf75488-59c9-47ab-a2ff-6ae459dd1444"

Done 2026-08-20 — there was a proper cutover. CORE-WP-0005 closed the production cutover gates on 2026-07-03; CORE-WP-0007 retired the Haskell/IHP infrastructure by 2026-07-08 with operator approval and a stabilization window. The 0/0 rollback deployment is the designed end state.

Remaining sub-task: record this in DECISIONS.md with the correction, so the project's own record shows that the first reading was wrong and why. A retirement project that misreads a completed retirement as an attrition should keep the evidence trail for the next reader.

id: SHR-WP-0002-T02
status: todo
priority: high
state_hub_task_id: "d2dbe425-345f-46cf-af70-0ca4b69a336e"

Extend the disposition inventory backwards to generation 2. Smaller than first thought — the migration was real — but still unrecorded here. 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
state_hub_task_id: "3254b7d3-e319-44a6-ae63-23b0d080247a"

This is now the workplan's centre of gravity: get the gen-3 runtime off CoulombCore. G-HUB-RUNTIME and G-CORE-ABSORB presume a runtime to absorb traffic into. That runtime is hub.coulomb.social on CoulombCore — production since 2026-07-03 — plus a core-hub-staging tunnel to the same host. There is no core-hub presence on railiance01, and hub-core is a package, not 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.

Routed to core-hub 2026-08-20; waiting on their answer. The vehicle is CORE-WP-0010 (runtime absorption into hub-core, proposed, all tasks todo), which depends on HUB-WP-0004 — itself proposed, and still carrying an open decision about whether hub-core stays an importable library or becomes a library plus a permanent thin host.

So the chain that would move production off CoulombCore bottoms out in an unanswered architecture question. That is a sequencing problem rather than an implementation one, which is why it sits here and not in a child repo — but the answer is core-hub's.

Two shapes were put to them:

• (a) Interim move — package Core Hub as-is onto railiance01, absorb into hub-core later on a calm schedule. Costs a migration that would otherwise not happen; buys independence from the decommission date.
• (b) Absorb directly — skip the interim host and let CORE-WP-0010 / HUB-WP-0004 be the migration. Cheaper in total work; couples production continuity to finishing an architecture decision under a hard external deadline.

The project does not choose between them, but records the reasoning either way. The one position taken: leaving it implicit is not acceptable, because the decommission date is a real constraint currently represented in no plan — including this project's own gate model, which T06 addresses.

Also asked: whether the decommission date changes HUB-WP-0004's open library-vs-thin-host decision. Pinned 2026-08-20 by the operator: CoulombCore retires by 2026-08-31. Eleven days. See DECISIONS.md. On that constraint the project recommends the interim move — an architecture decision plus a production migration inside eleven days is not a plan. The choice remains core-hub's.

id: SHR-WP-0002-T04
status: todo
priority: medium
state_hub_task_id: "b2196340-fa22-4531-81a2-a34bc217d66c"

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
state_hub_task_id: "2b97a7c5-f877-4020-ba83-8eb00c3690e6"

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
state_hub_task_id: "9b390f80-1cbb-4485-a958-14b0e24a0b26"

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.

id: SHR-WP-0002-T07
status: todo
priority: high
state_hub_task_id: "07636ddf-a26b-4760-8353-2532af9fd938"

The registry dependency, found 2026-08-20 and not previously tracked. gitea.coulomb.social is a live container registry on CoulombCore, and two railiance01 workloads pull images from it: reuse/Deployment/reuse-surface and state-hub/Job/state-hub-alembic-init (checked across Deployments, StatefulSets, DaemonSets, Jobs and CronJobs — that is the complete set).

Nothing breaks on decommission day, because running pods already hold their images. It breaks at the next restart, reschedule or scale-up, as ImagePullBackOff.

The two are not equally urgent (corrected 2026-08-20 after checking each reference's liveness):

• reuse-surface — live and stale. A running Deployment on the old registry, pinned to a 2026-07-07 commit and 22 commits behind main. Its CI switched to forgejo three hours after that commit and has published there ever since; the deployment was never repointed. This is the one that must move before 2026-08-31.
• state-hub — mostly a false alarm. The Deployment is already on forgejo.coulomb.social/coulomb/state-hub:main-d8808bf. The gitea reference is a completed one-shot Job that will not re-run by itself; the residual risk is a chart template recreating it. Worth cleaning, not urgent.

There was no repository rename. This is a registry migration (gitea → forgejo, early July) in which producers moved and one consumer did not.

forgejo.coulomb.social is already on railiance01, so the work is retag, push, update manifest. Routed to railiance-platform; ownership of the reuse-surface manifest sits with that repo.

Why this is a project task and not a platform ticket: it was missed because the decommission inventory was assembled from tunnels and workplans. A host is not free of dependents because nothing tunnels to it. Feed that into T06's G-GEN gate — a generation or host transition must enumerate what pulls, resolves and authenticates against the thing being switched off, not only what connects to it.

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
• core-hub CORE-WP-0005 / archived CORE-WP-0007 — the July cutover and Haskell retirement, the evidence that corrected this workplan's first draft
• core-hub CORE-WP-0010 — runtime absorption into hub-core, all tasks todo; the likely vehicle for T03
• issue-core ISSUE-WP-0007 — the CoulombCore migration precedent
• ops-warden inter-hub-bootstrap-ssh — a lane outliving its subject