# 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:e3ae22e` - `state-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.