The vehicle is CORE-WP-0010, which depends on HUB-WP-0004, which still carries an
open decision about whether hub-core becomes a runtime at all. So the chain that
would move production off CoulombCore bottoms out in an unanswered architecture
question — a sequencing problem, which is why it sits with the project, though
the answer is core-hub's.
Two shapes put to them: interim move to railiance01 using the proven rapp
pattern, or absorb directly into hub-core and let that be the migration. The
project takes no side except that leaving it implicit is not acceptable.
Surfaced a dependency of our own: the CoulombCore decommission date is not
pinned anywhere citable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
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>
Add baseline evidence (2026-08-09) and executable retirement gates mapped to
GOAL.md. Mark all foundation tasks done and workplan finished; next work is
child implementation streams.
Add architecture/child-workplan-map_v0.1.md linking streams S1–S8 to local
workplans (RMGR, HUB-0004, CORE-0010, STATE-0079, ACTIVITY-0029, OPS-0003,
FIN-0002) with dependencies and project gates.
