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
---
id: SHR-WP-0002
type: workplan
2026-08-20 08:07:53 +02:00
title: "Generation 3 serves from the host being decommissioned"
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
domain: infotech
repo: prj-state-hub-retirement
status: proposed
owner: unassigned
topic_slug: state-hub-retirement
created: "2026-08-20"
updated: "2026-08-20"
2026-08-20 08:07:53 +02:00
state_hub_workstream_id: "c94c3ba1-6c31-4989-a2eb-650726add747"
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
---
# SHR-WP-0002 — Predecessor generations and deployment reality
## The problem in one sentence
2026-08-20 08:07:53 +02:00
**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.
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
2026-08-20 08:07:53 +02:00
## 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.
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
2026-08-20 08:07:53 +02:00
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
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
2026-08-20 08:07:53 +02:00
| Generation | Position | Observed |
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
| --- | --- | --- |
2026-08-20 08:07:53 +02:00
| 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 |
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
| — `hub-core` | The surviving repository (GOAL §1) | A reusable Python package, not a running service |
2026-08-20 08:07:53 +02:00
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.
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
## 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
2026-08-20 08:07:53 +02:00
state_hub_task_id: "7bf75488-59c9-47ab-a2ff-6ae459dd1444"
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
```
2026-08-20 08:07:53 +02:00
**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.
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
2026-08-20 08:07:53 +02:00
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.
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
```task
id: SHR-WP-0002-T02
status: todo
priority: high
2026-08-20 08:07:53 +02:00
state_hub_task_id: "d2dbe425-345f-46cf-af70-0ca4b69a336e"
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
```
2026-08-20 08:07:53 +02:00
**Extend the disposition inventory backwards to generation 2.** Smaller than
first thought — the migration was real — but still unrecorded here. `G-DISP` demands
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
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
2026-08-20 08:07:53 +02:00
state_hub_task_id: "3254b7d3-e319-44a6-ae63-23b0d080247a"
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
```
2026-08-20 08:07:53 +02:00
**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.
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
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.
2026-08-20 08:41:48 +02:00
**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. **Open dependency for this project: the
CoulombCore decommission date is not pinned anywhere we can cite.**
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
```task
id: SHR-WP-0002-T04
status: todo
priority: medium
2026-08-20 08:07:53 +02:00
state_hub_task_id: "b2196340-fa22-4531-81a2-a34bc217d66c"
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
```
**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
2026-08-20 08:07:53 +02:00
state_hub_task_id: "2b97a7c5-f877-4020-ba83-8eb00c3690e6"
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
```
**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
2026-08-20 08:07:53 +02:00
state_hub_task_id: "9b390f80-1cbb-4485-a958-14b0e24a0b26"
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
```
**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
2026-08-20 08:07:53 +02:00
- `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
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
- `issue-core` `ISSUE-WP-0007` — the CoulombCore migration precedent
- ops-warden `inter-hub-bootstrap-ssh` — a lane outliving its subject
