tegwick
d9867bd783
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>
5.3 KiB
Decision Log
Auto-generated by the Custodian State Hub.
Restore the previously-live seven-action tenant-engine image rather than rebuild
Date: 2026-08-16
Decided by: grok
The four-action regression is a pin problem, not a policy-authoring problem. Image sha256:9320df39 was CI-built from e9911eb, previously live 2026-08-11, and confirmed by tenant-engine on 2026-08-13. The tenant-engine policy has not changed since that commit. A new image would re-bake unrelated later packages and would not be the artifact already verified. TEN-WP-0006 guardrail actions stay out of this restore.
Use the guardrail read/write split now: flex-auth may read, may not set
Date: 2026-08-16
Decided by: grok
TEN-WP-0006 split the actions so a PDP can read ceilings without changing them, and their tests call the read as actor=flex-auth. Leaving both actions on the single tenant-engine subject would keep the seam unused and leave the intended reader failing unknown_subject. This is a real difference: flex-auth set is denied action_not_granted. An ops write subject is out of scope; writes stay on the existing tenant-engine identity.
Generation 2 was retired correctly; the correction matters more than the finding
2026-08-20. SHR-WP-0002's first draft asserted that inter-hub had
"retired itself by attrition", inferring it from three true observations: no
~/inter-hub repo, a dead CoulombCore endpoint, and a railiance01 Deployment
scaled 0/0.
The inference was wrong. core-hub/workplans/archived/260708-CORE-WP-0007-haskell-retirement.md
records that CORE-WP-0005 closed the production cutover gates on 2026-07-03 —
hub.coulomb.social serving Core Hub, Inter-Hub compatibility, staging import
and dual-run smokes all closed — and that Haskell/IHP retirement followed on
2026-07-08 after a stabilization window and explicit operator approval to retire
the Inter-Hub rollback deployment. The 0/0 Deployment is that rollback
standby, at its designed end state.
Recorded because the failure mode generalises: live documents described a
retirement that had already happened, and the completed evidence was in an
archived workplan. core-hub/SCOPE.md still lists cutover planning as in
scope. A reader checking current files would reach the wrong conclusion, as this
project did. Retirement evidence needs to be discoverable from the live record,
not only from the archive — a requirement that applies directly to the State Hub
retirement this project is planning.
The real finding survived the correction and sharpened: the gen-3 runtime serves from the host being decommissioned.
CoulombCore decommission date: end of August 2026
2026-08-20, operator. CoulombCore is to be retired by 2026-08-31. This project treats that as a hard external constraint, not a target.
Eleven days. That materially decides SHR-WP-0002-T03: absorbing Core Hub
directly into hub-core depends on CORE-WP-0010 → HUB-WP-0004, the latter
still holding an open decision on whether hub-core becomes a runtime at all.
Finishing an architecture decision and a production migration inside eleven
days is not a plan, it is a hope. The project's recommendation to core-hub is
therefore the interim move (rmgr rapp wrap onto railiance01, absorb into
hub-core afterwards on a calm schedule) — the pattern issue-core used one week
earlier. The choice remains core-hub's; the reasoning is recorded either way.
What is actually still on CoulombCore
Established by resolving the public service names and inspecting railiance01, 2026-08-20:
| Service | Status | Consequence of shutdown |
|---|---|---|
hub.coulomb.social → Core Hub |
Production since 2026-07-03 | Loss of the gen-3 interaction framework. Tracked, SHR-WP-0002-T03 |
gitea.coulomb.social → container registry |
Live (200) | Not tracked anywhere before today. See below |
bao, forgejo, policy, risk and reuse all resolve to railiance01
already.
The registry dependency nobody had written down
gitea.coulomb.social is a container registry on CoulombCore, and two
workloads running on railiance01 pull their images from it:
reuse/Deployment/reuse-surface→gitea.coulomb.social/coulomb/reuse-surface:e3ae22estate-hub/Job/state-hub-alembic-init→gitea.coulomb.social/coulomb/state-hub:f2e042a
Checked across Deployments, StatefulSets, DaemonSets, Jobs and CronJobs; those two are the whole set.
This fails in the most inconvenient way available. Running pods survive
decommission because their images are already pulled locally — so nothing
breaks on the day. The failure arrives at the next restart, reschedule, node
reboot or scale-up, as ImagePullBackOff, at a moment chosen by circumstance
rather than by us. And one of the two is State Hub's own migration job — the
service this entire project exists to retire in an orderly way, unable to run its
schema migration.
forgejo.coulomb.social already runs on railiance01, so the destination exists
and the work is retag, push, update manifest. Routed to railiance-platform.
Generalisation worth keeping: the decommission 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.