SHR-WP-0002: correct the premise — gen 2 was retired properly
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>
This commit is contained in:
parent
a290d924df
commit
bf2b8f08ce
3 changed files with 106 additions and 44 deletions
27
DECISIONS.md
27
DECISIONS.md
|
|
@ -19,3 +19,30 @@ The four-action regression is a pin problem, not a policy-authoring problem. Ima
|
|||
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.**
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue