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:
parent
0fb86c8f24
commit
c6bccebe55
1 changed files with 29 additions and 0 deletions
29
DECISIONS.md
29
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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue