SHR-WP-0002: correct the premise — gen 2 was retired properly

T01 executed and disproved the workplan's own first draft. core-hub's archive
shows CORE-WP-0005 closed the production cutover gates on 2026-07-03 and
CORE-WP-0007 retired the Haskell/IHP infrastructure by 2026-07-08, with a
stabilization window and explicit operator approval to retire the Inter-Hub
rollback deployment. The 0/0 Deployment on railiance01 is that rollback standby
at its designed end state, not a lapse.

The surviving finding is sharper and more urgent: hub.coulomb.social resolves to
92.205.130.254 — CoulombCore — so Core Hub's production runtime, in service since
July, sits on the host being decommissioned, with no core-hub presence on
railiance01 and hub-core still a package rather than a service. The workplan is
retitled and re-centred on that.

DECISIONS.md records the correction and why it generalises: the live documents
described a retirement that had already happened while the completed evidence sat
in an archived workplan, so a reader checking current files reaches the wrong
conclusion. That requirement applies directly to the State Hub retirement this
project is planning.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

DECISIONS.md

@@ -19,3 +19,30 @@ The four-action regression is a pin problem, not a policy-authoring problem. Ima
 TEN-WP-0006 split the actions so a PDP can read ceilings without changing them, and their tests call the read as actor=flex-auth. Leaving both actions on the single tenant-engine subject would keep the seam unused and leave the intended reader failing unknown_subject. This is a real difference: flex-auth set is denied action_not_granted. An ops write subject is out of scope; writes stay on the existing tenant-engine identity.
 
 ---
+
+
+## Generation 2 was retired correctly; the correction matters more than the finding
+
+**2026-08-20.** `SHR-WP-0002`'s first draft asserted that `inter-hub` had
+"retired itself by attrition", inferring it from three true observations: no
+`~/inter-hub` repo, a dead CoulombCore endpoint, and a railiance01 Deployment
+scaled `0/0`.
+
+The inference was wrong. `core-hub/workplans/archived/260708-CORE-WP-0007-haskell-retirement.md`
+records that `CORE-WP-0005` closed the production cutover gates on 2026-07-03 —
+`hub.coulomb.social` serving Core Hub, Inter-Hub compatibility, staging import
+and dual-run smokes all closed — and that Haskell/IHP retirement followed on
+2026-07-08 after a stabilization window and explicit operator approval to retire
+the Inter-Hub rollback deployment. The `0/0` Deployment **is** that rollback
+standby, at its designed end state.
+
+Recorded because the failure mode generalises: **live documents described a
+retirement that had already happened, and the completed evidence was in an
+archived workplan.** `core-hub/SCOPE.md` still lists cutover planning as in
+scope. A reader checking current files would reach the wrong conclusion, as this
+project did. Retirement evidence needs to be discoverable from the live record,
+not only from the archive — a requirement that applies directly to the State Hub
+retirement this project is planning.
+
+The real finding survived the correction and sharpened: **the gen-3 runtime
+serves from the host being decommissioned.**

WORK-RECORDS.md

@@ -9,9 +9,16 @@
 | Kind | ID | Status | Lane | Source |
 | --- | --- | --- | --- | --- |
 | workplan | SHR-WP-0001 | finished | — | workplans/SHR-WP-0001-foundation.md |
+| workplan | SHR-WP-0002 | proposed | — | workplans/SHR-WP-0002-predecessor-and-deployment-reality.md |
 | task | SHR-WP-0001-T01 | done | — | workplans/SHR-WP-0001-foundation.md |
 | task | SHR-WP-0001-T02 | done | — | workplans/SHR-WP-0001-foundation.md |
 | task | SHR-WP-0001-T03 | done | — | workplans/SHR-WP-0001-foundation.md |
 | task | SHR-WP-0001-T04 | done | — | workplans/SHR-WP-0001-foundation.md |
 | task | SHR-WP-0001-T05 | done | — | workplans/SHR-WP-0001-foundation.md |
 | task | SHR-WP-0001-T06 | done | — | workplans/SHR-WP-0001-foundation.md |
+| task | SHR-WP-0002-T01 | todo | — | workplans/SHR-WP-0002-predecessor-and-deployment-reality.md |
+| task | SHR-WP-0002-T02 | todo | — | workplans/SHR-WP-0002-predecessor-and-deployment-reality.md |
+| task | SHR-WP-0002-T03 | todo | — | workplans/SHR-WP-0002-predecessor-and-deployment-reality.md |
+| task | SHR-WP-0002-T04 | todo | — | workplans/SHR-WP-0002-predecessor-and-deployment-reality.md |
+| task | SHR-WP-0002-T05 | todo | — | workplans/SHR-WP-0002-predecessor-and-deployment-reality.md |
+| task | SHR-WP-0002-T06 | todo | — | workplans/SHR-WP-0002-predecessor-and-deployment-reality.md |

workplans/SHR-WP-0002-predecessor-and-deployment-reality.md

@@ -1,7 +1,7 @@
 ---
 id: SHR-WP-0002
 type: workplan
-title: "Predecessor generations and deployment reality — stop retirement by attrition"
+title: "Generation 3 serves from the host being decommissioned"
 domain: infotech
 repo: prj-state-hub-retirement
 status: proposed
@@ -9,49 +9,65 @@ owner: unassigned
 topic_slug: state-hub-retirement
 created: "2026-08-20"
 updated: "2026-08-20"
+state_hub_workstream_id: "c94c3ba1-6c31-4989-a2eb-650726add747"
 ---
 
 # SHR-WP-0002 — Predecessor generations and deployment reality
 
 ## The problem in one sentence
 
-This project is retiring **generation 1** with gates, inventories and evidence,
+**Core Hub's production runtime — the generation-3 replacement, cut over
-while **generation 2 has already retired itself by attrition** and **generation 3
+deliberately and correctly in July — serves from `hub.coulomb.social`, which
-runs only on a host being decommissioned** — and neither fact appears anywhere in
+resolves to CoulombCore: the host being decommissioned.** No plan in any
-the project's records.
+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
 
-The hub lineage is stated in `core-hub/INTENT.md`: gen 1 `state-hub`, gen 2
+| Generation | Position | Observed |
-`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 |
+| 1 — `state-hub` | Being retired by this project, under gates | Running; what the estate 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** |
+| 2 — `inter-hub` | Retired `CORE-WP-0005`/`0007`, Jul 2026 | Correctly gone. Rollback deployment at `0/0` as designed |
-| 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 |
+| 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 follow, and none are recorded:
+Three consequences, none recorded anywhere:
 
-1. **`core-hub/SCOPE.md` still places "retiring production Inter-Hub before
+1. **The gen-1 retirement is being planned onto a runtime that has no home.**
-   migration and smoke evidence exists" out of scope**, and lists `/api/v2`
+   `G-HUB-RUNTIME` and `G-CORE-ABSORB` presume somewhere to absorb traffic into.
-   compatibility and "data migration and production cutover planning from
+   That somewhere is currently a host with a decommission date, and the gate
-   Inter-Hub" as in scope. Those are the words of a repo expecting to migrate off
+   model does not represent that date at all.
-   a *running* predecessor. It is not running. Either the migration completed and
+2. **`core-hub/SCOPE.md` is stale in a way that hides this.** It still places
-   the document is stale, or **the predecessor lapsed without one** — and those
+   "retiring production Inter-Hub before migration and smoke evidence exists"
-   demand different responses.
+   out of scope and lists `/api/v2` compatibility and "cutover planning from
-2. **`inventory/capabilities.yaml` does not mention `inter-hub` at all.** The
+   Inter-Hub" as in scope — work its own archive shows finished in July. A
-   project has assigned dispositions for State Hub capabilities but never asked
+   reader cannot tell from the live documents that the cutover already happened.
-   what gen 2 was to provide, so nothing records whether those capabilities are
+3. **`inventory/capabilities.yaml` does not mention `inter-hub`.** The migration
-   served, moved, or simply gone. On the stated lineage the unserved set is
+   was real, so this is a smaller gap than first thought — but `G-DISP` still
-   plausibly: **domain hubs, shared manifests, widgets, registry facts, and the
+   has no record of where gen-2 capabilities went, and the estate cannot
-   unified operator surface** — state-hub covers coordination, not those.
+   currently answer "does anything still provide the unified operator surface?"
-3. **Consumers disagree with each other.** `reuse-surface/SCOPE.md` records
+   without reading an archived workplan.
-   "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
 
@@ -72,25 +88,28 @@ identifier.
 id: SHR-WP-0002-T01
 status: todo
 priority: high
+state_hub_task_id: "7bf75488-59c9-47ab-a2ff-6ae459dd1444"
 ```
 
-**Establish what happened to inter-hub, on evidence.** Ask `core-hub` directly:
+**Done 2026-08-20 — there was a proper cutover.** `CORE-WP-0005` closed the
-was there a migration and cutover, or did the runtime lapse? Look for cutover
+production cutover gates on 2026-07-03; `CORE-WP-0007` retired the Haskell/IHP
-evidence, the last known good deployment, and whether `/api/v2` compatibility was
+infrastructure by 2026-07-08 with operator approval and a stabilization window.
-ever exercised by a real consumer.
+The `0/0` rollback deployment is the designed end state.
 
-Record the answer in `DECISIONS.md`. If it lapsed, say so plainly — a project
+Remaining sub-task: record this in `DECISIONS.md` **with the correction**, so
-that documents an orderly gen-1 retirement while a gen-2 retirement happened by
+the project's own record shows that the first reading was wrong and why. A
-attrition should own that contrast rather than let it sit unstated. It is the
+retirement project that misreads a completed retirement as an attrition should
-single most useful lesson available to the gen-1 retirement now being planned.
+keep the evidence trail for the next reader.
 
 ```task
 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.** `G-DISP` demands
+**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.
 
@@ -107,12 +126,14 @@ 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"
 ```
 
-**Reconcile the gates with deployment reality.** `G-HUB-RUNTIME` and
+**This is now the workplan's centre of gravity: get the gen-3 runtime off
-`G-CORE-ABSORB` presume a runtime to absorb traffic into. Today the only
+CoulombCore.** `G-HUB-RUNTIME` and `G-CORE-ABSORB` presume a runtime to absorb
-core-hub runtime is `core-hub-staging` on CoulombCore, which is being
+traffic into. That runtime is `hub.coulomb.social` on CoulombCore — production
-decommissioned, and `hub-core` is a package rather than a service.
+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
@@ -128,6 +149,7 @@ is one week old.
 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.**
@@ -144,6 +166,7 @@ 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
@@ -165,6 +188,7 @@ 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
@@ -184,5 +208,9 @@ decision route rather than adding it unilaterally.
 - `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