From c6bccebe5531e70cf09d56c0c9273b4706bb267e Mon Sep 17 00:00:00 2001 From: tegwick Date: Fri, 21 Aug 2026 16:29:17 +0200 Subject: [PATCH] Core Hub is off CoulombCore; gitea is the last dependent MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- DECISIONS.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/DECISIONS.md b/DECISIONS.md index 5151b3b..ee06944 100644 --- a/DECISIONS.md +++ b/DECISIONS.md @@ -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 because nothing *tunnels* to it — it is free when nothing *pulls, resolves or 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.