Updated by fix-consistency on 2026-08-25:
- update .custodian-brief.md for prj-state-hub-retirement
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
The remote row pointed at 127.0.0.1:18000, a reverse tunnel back to the
workstation. On railiance01 the State Hub runs in the cluster on that same
machine, so the request left the box and came back to reach a local service.
Refs CUST-WP-0067-T07
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
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>
core-hub chose the interim move (decision 8f0c1741) and created CORE-WP-0011,
ready with T01 in progress. Their reasoning improves on ours: the decommission
date does not change library-vs-thin-host, and the interim move deliberately
removes that architecture choice from the eleven-day continuity path — decoupling
continuity from architecture rather than racing both.
They also audited their own registry references unprompted and found two live
gitea ones we missed: the Makefile image default and deployed-smoke evidence.
kaizen-agentic finished KAIZEN-WP-0010 with the verification the workplan asked
for — forgejo serving 1.4.0 anonymously, clean install in a fresh venv with
--no-cache-dir following the documented command, and historical records left
truthful rather than rewritten.
Handed back: pin the decommission date into CORE-WP-0011's gates, and
CORE-WP-0011 awaits UUID bindings because the local hub is not the registrar.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
At the deployed commit, registry/federation/sources.yaml points at
gitea.coulomb.social for 50 of 61 sources; all 61 are forgejo at HEAD after
d1c1313. Production is actively federating from the host being switched off, so
it breaks on 2026-08-31 with no restart required — a different and worse failure
mode than the ImagePullBackOff risk it was first filed under.
This also inverts the conservative option: rebuilding the pinned commit onto
forgejo does not fix federation, because the gitea URLs are in the code at that
commit. Deploying HEAD is the smaller intervention once the runtime dependency is
counted.
Side finding routed to the repo: REUSE-WP-0019 is archived as finished and
records a production deploy of T01/T02, but T04-T06 — including hub freshness
monitoring — landed after the deployed commit and appear never to have shipped.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
86 repos carry forgejo workflows, but the only runner in the estate is
forgejo/forgejo-runner on railiance01, registered against FORGEJO_INSTANCE. No
runner on CoulombCore.
gitea-runner-status.sh, which prompted the check, is legacy: it defaults to
RUNNER_HOST=haskelseed and probes INTER_HUB_IMAGE, both already retired. The
gitea-era runner lived on haskelseed and died with it on 2026-08-19 without
anything breaking — evidence that gitea-based CI is no longer in use.
Six independent methods were needed to enumerate the surface, each finding
something the previous could not see. That is the lesson for the G-GEN gate: an
inventory is only as complete as the number of independent ways you looked.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The file sweep found the OCI registry and the PyPI index. Sweeping ops-warden's
routing catalog found what files could not: gitea.coulomb.social also serves an
npm registry at /api/packages/coulomb/npm/, and the catalog lane
whynot-design-npm-publish (risk: high, production-exercised) vends the token that
publishes @whynot/design to it.
After 2026-08-31 that lane routes to a registry that does not exist, and it does
not fail safe — an operator following it gets a working token for a dead endpoint
and debugs the token.
CI runners remain unswept; railiance-forge/tools/gitea-runner-status.sh suggests
gitea-registered Actions runners exist.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gitea.coulomb.social also serves a PyPI package index, so the container-image
finding was half the exposure.
Classified every operational reference by whether anything can still act on it.
Live and must move: reuse-surface's Deployment image, and kaizen-agentic, which
never migrated at all — it publishes to gitea PyPI and its README and five docs
instruct users to pip install from it, with no forgejo equivalent in the repo.
issue-core already dual-publishes and only needs its legacy gitea target retired.
Deliberately left alone: tests asserting historical facts, inventory snapshots,
asset registers and a Dockerfile comment. They record that gitea existed, which
remains true after it is switched off; rewriting them would destroy history to
tidy a grep.
Flagged unswept: CI runners, and any credential lane authenticating to gitea.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
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>
The vehicle is CORE-WP-0010, which depends on HUB-WP-0004, which still carries an
open decision about whether hub-core becomes a runtime at all. So the chain that
would move production off CoulombCore bottoms out in an unanswered architecture
question — a sequencing problem, which is why it sits with the project, though
the answer is core-hub's.
Two shapes put to them: interim move to railiance01 using the proven rapp
pattern, or absorb directly into hub-core and let that be the migration. The
project takes no side except that leaving it implicit is not acceptable.
Surfaced a dependency of our own: the CoulombCore decommission date is not
pinned anywhere citable.
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>
The project is retiring generation 1 with gates, inventories and evidence, while
generation 2 has already retired itself by attrition and generation 3 runs only
on a host being decommissioned. Neither fact appears in the project's records.
Observed 2026-08-20: inter-hub runs nowhere (no repo, CoulombCore endpoint dead,
railiance01 Deployment scaled 0/0) with no cutover evidence found, while
core-hub/SCOPE.md still places retiring it out of scope and plans /api/v2
compatibility against it. core-hub itself is deployed only as staging on
CoulombCore, and hub-core is a package rather than a service. The project's
capability inventory does not mention inter-hub at all, so G-DISP has been
applied to one generation only and lets gen-2 capabilities vanish unrecorded.
Six tasks, all project-shaped per SCOPE.md — decide and inventory, route
implementation to owners by identifier. The last proposes a G-GEN gate so a
generation cannot be considered superseded until its capabilities have
dispositions, its consumers are reconciled, its downstream lanes are swept, and
its successor is deployed somewhere that will still exist.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Add baseline evidence (2026-08-09) and executable retirement gates mapped to
GOAL.md. Mark all foundation tasks done and workplan finished; next work is
child implementation streams.
Add architecture/child-workplan-map_v0.1.md linking streams S1–S8 to local
workplans (RMGR, HUB-0004, CORE-0010, STATE-0079, ACTIVITY-0029, OPS-0003,
FIN-0002) with dependencies and project gates.
