Commit graph

5 commits

Author SHA1 Message Date
c6bccebe55 Core Hub is off CoulombCore; gitea is the last dependent
core-hub executed CORE-WP-0011 overnight, one day after choosing the interim
path. core-hub-api runs 1/1 on railiance01, the hub.coulomb.social Ingress is
there, DNS resolves to 92.205.62.239 and /healthz returns 200. The
core-hub-staging tunnel is retired from the map.

The larger of the two blockers on the 2026-08-31 decommission is closed, and it
closed because continuity was decoupled from architecture — CORE-WP-0010 and
HUB-WP-0004 remain open and no longer sit on the critical path. That was
core-hub's argument rather than this project's, and it is the transferable
lesson: when a hard date meets an unresolved design question, move the running
thing and leave the question where it was.

gitea.coulomb.social is now the only name resolving to CoulombCore. kaizen-agentic
is done; reuse-surface, the whynot-design npm lane and issue-core's legacy target
remain.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 16:29:17 +02:00
23631f0239 Correct T07: reuse-surface is live and stale; state-hub was mostly a false alarm
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>
2026-08-20 08:54:21 +02:00
d9867bd783 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>
2026-08-20 08:47:23 +02:00
bf2b8f08ce SHR-WP-0002: correct the premise — gen 2 was retired properly
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>
2026-08-20 08:07:53 +02:00
48a40465c7 updated decisions 2026-08-19 20:31:26 +02:00