Checking each image reference's liveness separated the two cases the first pass
treated alike.
reuse-surface is a live Deployment on gitea, pinned to a 2026-07-07 commit and 22
commits behind main. Its CI moved to forgejo at 21:25 that same day, three hours
after the pinned commit, and has published :latest and :main-<short> there ever
since. Producer migrated, consumer did not.
state-hub's Deployment is already on forgejo with the current tag scheme. Its
only gitea reference is a completed one-shot alembic-init Job that does not
re-run on its own, so "unable to run its schema migration" was wrong. Residual
risk is a chart template recreating it.
No repository rename occurred — this is a registry migration in which one
consumer was left behind.
An image reference is not a dependency until something can act on it.
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>
