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>
This commit is contained in:
tegwick 2026-08-21 16:29:17 +02:00
parent 0fb86c8f24
commit c6bccebe55

View file

@ -122,3 +122,32 @@ and the work is retag, push, update manifest. Routed to `railiance-platform`.
tunnels and workplans, and both missed this. A host is not free of dependents 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 because nothing *tunnels* to it — it is free when nothing *pulls, resolves or
authenticates* against it either. authenticates* against it either.
## 2026-08-21: Core Hub is off CoulombCore; the registry is the last dependent
`core-hub-api` serves from railiance01 (Deployment 1/1, Ingress 15h,
`hub.coulomb.social``92.205.62.239`, `/healthz` 200). `CORE-WP-0011` was
executed overnight, one day after the decision to take the interim path.
The larger of the two blockers on the 2026-08-31 decommission is therefore
closed, and it closed **because continuity was decoupled from architecture**.
`CORE-WP-0010`/`HUB-WP-0004` — the library-vs-thin-host question — remain open
and no longer sit on the critical path. That decoupling was core-hub's argument,
not this project's, and it is the transferable lesson: when a hard external date
meets an unresolved design question, move the running thing and leave the
question where it was.
**Remaining CoulombCore surface:** `gitea.coulomb.social` alone. It serves an
OCI registry, a PyPI index and an npm registry. Known dependents:
| Dependent | State |
| --- | --- |
| `kaizen-agentic` (PyPI) | **Done**`KAIZEN-WP-0010`, verified clean install from forgejo |
| `reuse-surface` (OCI **and** live federation) | **Open** — the one that breaks *on the day*, no reply yet |
| `whynot-design-npm-publish` (npm, ops-warden lane) | **Open** — routes to a registry that will not exist |
| `issue-core` legacy PyPI target | **Open** — trivial, a trap rather than an outage |
`inter-hub-coulombcore` remains in the tunnel map by deliberate choice: the
service is scaled to zero everywhere, and scaled-to-zero is not retired. It
carries no traffic, so it does not block the date.