diff --git a/DECISIONS.md b/DECISIONS.md
index 85c194f..44cdf03 100644
--- a/DECISIONS.md
+++ b/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.
diff --git a/workplans/SHR-WP-0002-predecessor-and-deployment-reality.md b/workplans/SHR-WP-0002-predecessor-and-deployment-reality.md
index f8fa0f8..df8125d 100644
--- a/workplans/SHR-WP-0002-predecessor-and-deployment-reality.md
+++ b/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
-CoulombCore decommission date is not pinned anywhere we can cite.**
+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.
 
 ```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)