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>
This commit is contained in:
tegwick 2026-08-20 08:47:23 +02:00
parent 4e0f10fe96
commit d9867bd783
2 changed files with 88 additions and 2 deletions

View file

@ -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)