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.
