Pin the CoulombCore decommission at 2026-08-31; find the registry dependency

Operator set the date: CoulombCore retires by end of August. Eleven days, which
decides T03 — absorbing Core Hub directly into hub-core depends on HUB-WP-0004,
which still has not decided whether hub-core becomes a runtime at all. The
project recommends the interim move (the pattern issue-core used a week ago);
the choice stays core-hub's.

Resolving the public service names against the two hosts surfaced something no
plan contained: gitea.coulomb.social is a live container registry on CoulombCore,
and two railiance01 workloads pull images from it — reuse-surface, and State
Hub's own alembic-init migration job. Nothing breaks on the day, because running
pods already hold their images; it breaks at the next restart or reschedule as
ImagePullBackOff, at a time chosen by circumstance.

Added as T07 and routed to railiance-platform. forgejo.coulomb.social already
runs on railiance01, so the work is retag, push, update manifest.

The generalisation goes into T06's proposed G-GEN gate: the inventory was built
from tunnels and workplans and both missed this. A host is not free of dependents
because nothing tunnels to it — it is free when nothing pulls, resolves or
authenticates against it either.

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

DECISIONS.md

@@ -46,3 +46,58 @@ retirement this project is planning.
 
 The real finding survived the correction and sharpened: **the gen-3 runtime
 serves from the host being decommissioned.**
+
+
+## CoulombCore decommission date: end of August 2026
+
+**2026-08-20, operator.** CoulombCore is to be retired **by 2026-08-31**. This
+project treats that as a hard external constraint, not a target.
+
+Eleven days. That materially decides `SHR-WP-0002-T03`: absorbing Core Hub
+directly into `hub-core` depends on `CORE-WP-0010` → `HUB-WP-0004`, the latter
+still holding an open decision on whether hub-core becomes a runtime at all.
+Finishing an architecture decision *and* a production migration inside eleven
+days is not a plan, it is a hope. **The project's recommendation to core-hub is
+therefore the interim move** (`rmgr rapp wrap` onto railiance01, absorb into
+hub-core afterwards on a calm schedule) — the pattern `issue-core` used one week
+earlier. The choice remains core-hub's; the reasoning is recorded either way.
+
+### What is actually still on CoulombCore
+
+Established by resolving the public service names and inspecting railiance01,
+2026-08-20:
+
+| Service | Status | Consequence of shutdown |
+| --- | --- | --- |
+| `hub.coulomb.social` → Core Hub | Production since 2026-07-03 | Loss of the gen-3 interaction framework. Tracked, `SHR-WP-0002-T03` |
+| `gitea.coulomb.social` → container registry | Live (200) | **Not tracked anywhere before today.** See below |
+
+`bao`, `forgejo`, `policy`, `risk` and `reuse` all resolve to railiance01
+already.
+
+### The registry dependency nobody had written down
+
+`gitea.coulomb.social` is a container registry on CoulombCore, and **two
+workloads running on railiance01 pull their images from it**:
+
+- `reuse/Deployment/reuse-surface` → `gitea.coulomb.social/coulomb/reuse-surface:e3ae22e`
+- `state-hub/Job/state-hub-alembic-init` → `gitea.coulomb.social/coulomb/state-hub:f2e042a`
+
+Checked across Deployments, StatefulSets, DaemonSets, Jobs and CronJobs; those
+two are the whole set.
+
+This fails in the most inconvenient way available. Running pods survive
+decommission because their images are already pulled locally — **so nothing
+breaks on the day**. The failure arrives at the next restart, reschedule, node
+reboot or scale-up, as `ImagePullBackOff`, at a moment chosen by circumstance
+rather than by us. And one of the two is **State Hub's own migration job** — the
+service this entire project exists to retire in an orderly way, unable to run its
+schema migration.
+
+`forgejo.coulomb.social` already runs on railiance01, so the destination exists
+and the work is retag, push, update manifest. Routed to `railiance-platform`.
+
+**Generalisation worth keeping:** the decommission inventory was built from
+tunnels and workplans, and both missed this. A host is not free of dependents
+because nothing *tunnels* to it — it is free when nothing *pulls, resolves or
+authenticates* against it either.

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

@@ -172,8 +172,10 @@ 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
+library-vs-thin-host decision. **Pinned 2026-08-20 by the operator: CoulombCore retires by 2026-08-31.**
-CoulombCore decommission date is not pinned anywhere we can cite.**
+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.
 
 ```task
 id: SHR-WP-0002-T04
@@ -232,6 +234,35 @@ 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.
 
+```task
+id: SHR-WP-0002-T07
+status: todo
+priority: high
+```
+
+**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`. One of the two is **State Hub's own migration job** — this
+project's subject, unable to run its schema migration.
+
+`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)