From f490d184231932a2f4ec0d71070a1cf7f2bc34bc Mon Sep 17 00:00:00 2001 From: tegwick Date: Sat, 27 Jun 2026 19:31:09 +0200 Subject: [PATCH] Add Core Hub FOS reset workplan --- docs/fos-hub-bootstrap-sequence-status.md | 13 +- ...ructure-stabilization-pickup-checkpoint.md | 28 +- workplans/CUST-WP-0025-fos-hub-bootstrap.md | 7 + ...0047-ops-hub-service-inventory-now-view.md | 7 + ...-WP-0049-interhub-bootstrap-access-lane.md | 7 + ...1-infrastructure-stabilization-metaplan.md | 23 +- workplans/CUST-WP-0052-core-hub-fos-reset.md | 251 ++++++++++++++++++ 7 files changed, 317 insertions(+), 19 deletions(-) create mode 100644 workplans/CUST-WP-0052-core-hub-fos-reset.md diff --git a/docs/fos-hub-bootstrap-sequence-status.md b/docs/fos-hub-bootstrap-sequence-status.md index f359ec3..b9fc5af 100644 --- a/docs/fos-hub-bootstrap-sequence-status.md +++ b/docs/fos-hub-bootstrap-sequence-status.md @@ -4,7 +4,7 @@ Updated: 2026-06-27 ## Purpose -Track `CUST-WP-0051-T07`: sequence `CUST-WP-0025` so FOS Hub bootstrap can resume from current repo reality rather than the older mega-hub/Keycloak assumptions. +Track `CUST-WP-0051-T07` and `CUST-WP-0052`: sequence `CUST-WP-0025` so FOS Hub bootstrap can resume from current repo reality rather than the older mega-hub/Keycloak/Inter-Hub assumptions. ## Current Decision @@ -21,13 +21,14 @@ Do not restart FOS bootstrap at the old `NK-WP-0001` Keycloak path. That workpla | --- | --- | --- | | Identity | Old `CUST-WP-0025-T01` pointed at archived `NK-WP-0001`; local identity and IAM Profile v0.2 are done. | Keep T01 cancelled, T02 done, and make T03 the remaining identity gate: a protected FastAPI fixture using IAM Profile v0.2 against local-identity or KeyCape. | | Hub extraction/dev-hub | `CUST-WP-0025-T05` through `T12` are done: hub-core exists, State Hub imports hub-core, and MCP naming moved to dev-hub. | Treat Phase 2 as complete. Do not spend pickup energy here unless consistency drift appears. | -| Ops hub | The `ops-hub` repo exists as an Inter-Hub Operations extension. `OPS-WP-0001` is finished; `OPS-WP-0002` has T01-T03 done and waits on authenticated bootstrap/runtime key. | Finish the Inter-Hub evidence lane first: align the activity-core mapping with the live ops vocabulary, run attended bootstrap, store runtime key by approved route, then send the first governed ops event. | -| Old ops-hub scaffold tasks | `CUST-WP-0025-T13`-`T19` still describe a standalone hub-core/FastAPI/MCP scaffold. Current implementation direction is Inter-Hub extension-first. | Reconcile these tasks after the Inter-Hub evidence lane closes: either rewrite them to extension-owned implementation tasks or explicitly defer the standalone hub-core service. | +| Ops hub | The old `ops-hub`/Inter-Hub extension path has useful seed evidence, but Core Hub now has the credible replacement platform: local `/api/v2` compatibility, ops-hub bootstrap smoke, protected persistence-backed resources, and `/console` visual checks. | Create or update the Core Hub API-first continuation workplan. Treat Haskell Inter-Hub as legacy compatibility or rollback evidence. | +| Old ops-hub scaffold tasks | `CUST-WP-0025-T13`-`T19` still describe a standalone hub-core/FastAPI/MCP scaffold. Current implementation direction is Core Hub replacement-first, not Inter-Hub extension-first. | Reconcile these tasks after Core Hub has a deployed compatibility/evidence smoke: rewrite them to Core Hub-owned API/CLI/UI tasks or explicitly defer/cancel the old standalone scaffold. | | Fin hub/business | `CUST-WP-0025-T20`-`T26` are all todo and depend on a proven multi-hub pattern. | Defer until ops-hub has a working first signal and the identity integration gate is proven. | ## Stable Pickup Order 1. Close the identity drift: T01 cancelled, T02 done, T03 remains as the one real identity integration test. -2. Finish `CUST-WP-0051-T03` / ops-hub Inter-Hub evidence alignment before expanding ops-hub models/tools. -3. Reconcile `CUST-WP-0025-T13`-`T19` against `OPS-WP-0002` once the first ops event lands. -4. Start fin-hub/business work only after ops-hub proves the extension pattern end-to-end. +2. Use `CUST-WP-0052` to open or update the Core Hub API-first continuation lane. +3. Keep `CUST-WP-0047`/`CUST-WP-0049` as legacy evidence/fallback until Core Hub smoke evidence or an explicit supersede decision closes them. +4. Rewrite `CUST-WP-0025-T13`-`T19` after Core Hub proves the replacement path. +5. Start fin-hub/business work only after ops-hub proves the Core Hub pattern end-to-end. diff --git a/docs/infrastructure-stabilization-pickup-checkpoint.md b/docs/infrastructure-stabilization-pickup-checkpoint.md index 1b1de16..5528237 100644 --- a/docs/infrastructure-stabilization-pickup-checkpoint.md +++ b/docs/infrastructure-stabilization-pickup-checkpoint.md @@ -58,6 +58,10 @@ maturity first. Dev/test work can use synthetic contract doubles; production real-value work needs owner custody, policy gates where applicable, and non-secret evidence. See `docs/ops-warden-secret-posture-review.md`. +Do not implement ops-warden changes from this Custodian lane. New ops-warden +needs should be posted through State Hub as requirements or suggestions for the +separate ops-warden worker. + | Gate | Owner/route | Non-secret evidence to collect | Next action | | --- | --- | --- | --- | | State Hub pragmatic cutover | Custodian operator approval; `CUST-WP-0011-T07` | Final dump id/time, row-count comparison, chosen private endpoint, stabilization notes | Approve freeze/final restore and make railiance01 State Hub primary, or leave WSL2 primary explicitly. | @@ -95,8 +99,8 @@ Resume from `docs/daily-triage-stabilization-status.md` and | Surface | Stable fact | Remaining gate | | --- | --- | --- | | State Hub | Pragmatic railiance01 path has image, manifests, empty deploy, migrations, restored WSL2 data, row-count comparison, and healthy API through `CUST-WP-0011-T06`. | `CUST-WP-0011-T07` cutover approval, then stabilization; HA path stays deferred. | -| Inter-Hub | Public `https://hub.coulomb.social/api/v2/hubs` exposes `ops-hub`; public registry vocabulary is visible; Inter-Hub contract docs now target the live seed vocabulary. | Protected widget lookup, runtime key custody, and authenticated event smoke remain. | -| ops-hub evidence | `ops-hub` exists as the Inter-Hub Operations extension; `OPS-WP-0001` finished; `OPS-WP-0002` has early seed tasks done. | Attended bootstrap, runtime key custody, protected widget/event smoke. | +| Inter-Hub / Core Hub | Public `https://hub.coulomb.social/api/v2/hubs` exposes `ops-hub`; Core Hub has local `/api/v2` compatibility and ops-hub bootstrap smoke evidence. | Reframe remaining Inter-Hub evidence as Core Hub API-first replacement work, keeping Haskell Inter-Hub only for migration/rollback proof. | +| ops-hub evidence | `ops-hub` exists as the Inter-Hub Operations extension; Core Hub can locally create the ops-hub resources through protected persistence-backed routes. | Create/update Core Hub continuation workplan, then prove deployed ops-hub bootstrap/evidence smoke with approved custody. | | issue-core | ArgoCD service is healthy on port `8765`; image `0.2.1`; ExternalSecret Ready; authenticated smoke created Gitea issue `175`. | activity-core still needs `ISSUE_CORE_API_KEY`, URL port `8765`, `ISSUE_SINK_TYPE=rest`, and a safe emission smoke. | | Forgejo | Migration inventory/design lane is active but pre-cutover. | Production design decisions, SMTP/email recovery, package registry, Actions, backup/restore, migration drill, cutover approval. | | artifact-store | Workplan is active with all tasks open and no current live secret handoff recorded. | Start D7.1 fork/object-store landscape and D7.2 compatibility harness. | @@ -104,19 +108,21 @@ Resume from `docs/daily-triage-stabilization-status.md` and ## Next-Pick List -1. Run the attended Inter-Hub ops-hub bootstrap with the aligned live-vocabulary - mapping, confirm protected widget ids, and seed any missing backup/risk target widgets. -2. Store/confirm `OPS_HUB_KEY` through approved custody and run the protected - widget/hub-registry/event smoke. -3. Deploy the activity-core WP-0016 code/schema and bounded runtime prompt +1. Use `CUST-WP-0052` to open or update the Core Hub API-first continuation + lane for ops-hub bootstrap/evidence replacement. +2. Keep `CUST-WP-0047` and `CUST-WP-0049` as legacy evidence/fallback until + Core Hub smoke evidence or an explicit supersede decision closes them. +3. Store/confirm `OPS_HUB_KEY` through approved custody only when a deployed + Core Hub or explicit legacy Inter-Hub smoke is ready to use it. +4. Deploy the activity-core WP-0016 code/schema and bounded runtime prompt bundle, then run the railiance01 daily-triage smoke. -4. Complete the issue-core handoff by wiring activity-core to port `8765` with +5. Complete the issue-core handoff by wiring activity-core to port `8765` with `ISSUE_SINK_TYPE=rest` and one known-safe emission smoke. -5. Request explicit State Hub cutover approval for `CUST-WP-0011-T07`, or +6. Request explicit State Hub cutover approval for `CUST-WP-0011-T07`, or record that WSL2 remains primary for the next operating period. -6. Start artifact-store D7.1/D7.2; Forgejo and storage work can now inherit +7. Start artifact-store D7.1/D7.2; Forgejo and storage work can now inherit the finished staged-promotion gates. -7. Keep Forgejo cutover and State Hub HA work parked until their human decision +8. Keep Forgejo cutover and State Hub HA work parked until their human decision and drill gates are satisfied. ## Resume Commands diff --git a/workplans/CUST-WP-0025-fos-hub-bootstrap.md b/workplans/CUST-WP-0025-fos-hub-bootstrap.md index 67be8b2..f258f03 100644 --- a/workplans/CUST-WP-0025-fos-hub-bootstrap.md +++ b/workplans/CUST-WP-0025-fos-hub-bootstrap.md @@ -366,6 +366,13 @@ activation without leaking keys into agent sessions: ops-hub owns the helper, ops-warden owns the short-lived SSH certificate envelope, and operator secret custody remains outside Git. +**Core Hub reset (2026-06-27):** `CUST-WP-0052` supersedes the Inter-Hub-first +implementation direction for future work. The old T13-T19 standalone ops-hub +scaffold should not be executed literally until it is rewritten around Core Hub: +API-first replacement contracts, CLI helpers second, and a rebuilt whynot-aligned +operator UI third. Keep this phase active as a coordination record, not as a +mandate to expand Haskell Inter-Hub. + ### T13 — Create ops-hub repo from hub-core scaffold ```task diff --git a/workplans/CUST-WP-0047-ops-hub-service-inventory-now-view.md b/workplans/CUST-WP-0047-ops-hub-service-inventory-now-view.md index 0ddb604..0510f01 100644 --- a/workplans/CUST-WP-0047-ops-hub-service-inventory-now-view.md +++ b/workplans/CUST-WP-0047-ops-hub-service-inventory-now-view.md @@ -163,6 +163,13 @@ require the approved operator/runtime-key lane. The activity-core mapping contract also needs reconciliation with the live ops-hub seed vocabulary before smoke closure. +2026-06-27 Core Hub pivot: keep this task as the record of legacy Inter-Hub +evidence, but do not expand the Haskell Inter-Hub widget path as the preferred +implementation. `CUST-WP-0052` reframes the closure target as Core Hub +API-first replacement evidence. T05 can close through a Core Hub deployed +compatibility/evidence smoke or by an explicit supersede decision that preserves +the non-secret Inter-Hub facts above. + ## Task: Build First Ops-Hub Service Catalog View ```task diff --git a/workplans/CUST-WP-0049-interhub-bootstrap-access-lane.md b/workplans/CUST-WP-0049-interhub-bootstrap-access-lane.md index 5072ea6..47a1cab 100644 --- a/workplans/CUST-WP-0049-interhub-bootstrap-access-lane.md +++ b/workplans/CUST-WP-0049-interhub-bootstrap-access-lane.md @@ -186,6 +186,13 @@ runtime-key custody, plus a contract-alignment issue between `IHUB-WP-0022` activity-core mapping docs and the live ops-hub seed vocabulary. Do not spend operator key time on the smoke until the vocabulary/mapping direction is chosen. +2026-06-27 Core Hub pivot: retain this access lane as the legacy/fallback +routine for Haskell Inter-Hub production, but do not make it the main +replacement implementation path. `CUST-WP-0052` moves the preferred closure +toward Core Hub API-first work. Any new ops-warden capability need discovered +from this lane should be posted as a State Hub requirement/suggestion for the +separate ops-warden worker rather than implemented here. + ## Acceptance Criteria - The repeatable access lane is documented in the owning repos. diff --git a/workplans/CUST-WP-0051-infrastructure-stabilization-metaplan.md b/workplans/CUST-WP-0051-infrastructure-stabilization-metaplan.md index 1f33e94..b92f0e4 100644 --- a/workplans/CUST-WP-0051-infrastructure-stabilization-metaplan.md +++ b/workplans/CUST-WP-0051-infrastructure-stabilization-metaplan.md @@ -80,8 +80,8 @@ The critical path is: issue-core GitOps pilot, Forgejo production migration, artifact-store STS, staged promotion, and State Hub migration strategy. 4. Federation buildout: - identity completion, ops-hub scaffold, ops-hub MCP registration, fin-hub - scaffold, and business/runway canon. + identity completion, Core Hub replacement evidence, ops-hub scaffold reset, + fin-hub scaffold, and business/runway canon. ## Task: Normalize Registry And Workplan Hygiene @@ -206,6 +206,16 @@ Progress 2026-06-27 contract alignment: - Remaining T03 gate is authenticated widget lookup, any missing backup/risk seed widget, runtime key custody, and protected submission smoke. +Progress 2026-06-27 Core Hub pivot: + +- Created `CUST-WP-0052` to drive the reframe from old Inter-Hub production + bootstrap toward Core Hub-owned replacement implementation. +- Treat remaining Inter-Hub evidence as legacy compatibility or fallback + evidence. Do not spend new design work on Haskell Inter-Hub unless it is + needed for migration proof or rollback. +- Next implementation lane should be Core Hub API first, CLI second, and web UI + third, with whynot-design used for the rebuilt UI where practical. + ## Task: Stabilize Daily-Triage Automation ```task @@ -453,6 +463,15 @@ Progress 2026-06-27: - Fin-hub/business tasks remain deliberately deferred until identity integration and ops-hub extension evidence are proven. +Progress 2026-06-27 Core Hub reset: + +- `CUST-WP-0052` now owns the reset criteria. `CUST-WP-0025-T13` through + `T19` should not be executed literally as the old standalone ops-hub scaffold + until Core Hub replacement evidence is good enough and the tasks are rewritten. +- Core Hub is promising enough to stop expanding the Inter-Hub-first path: + local ops-hub bootstrap compatibility and `/console` visual checks exist, but + staging import, deployed dual-run smokes, and cutover evidence are still open. + ## Task: Create The Stable Pickup Checkpoint ```task diff --git a/workplans/CUST-WP-0052-core-hub-fos-reset.md b/workplans/CUST-WP-0052-core-hub-fos-reset.md new file mode 100644 index 0000000..0f75967 --- /dev/null +++ b/workplans/CUST-WP-0052-core-hub-fos-reset.md @@ -0,0 +1,251 @@ +--- +id: CUST-WP-0052 +type: workplan +title: "Core Hub Reframe And FOS Bootstrap Reset" +domain: infotech +repo: the-custodian +status: active +owner: codex +topic_slug: custodian +planning_priority: high +planning_order: 52 +created: "2026-06-27" +updated: "2026-06-27" +state_hub_workstream_id: "555b9b95-390e-4a2c-9f15-9f377bbc84e2" +--- + +# CUST-WP-0052 - Core Hub Reframe And FOS Bootstrap Reset + +## Goal + +Drive the pivot from closing old Inter-Hub production bootstrap work toward a +Core Hub-owned replacement lane, while keeping the Custodian workplans clean and +sequenced. + +This workplan coordinates: + +- `CUST-WP-0051`: stabilization and pickup sequencing; +- `CUST-WP-0047`: ops-hub service inventory now-view evidence; +- `CUST-WP-0049`: legacy Inter-Hub bootstrap access routine; +- `CUST-WP-0025`: FOS hub bootstrap reset after Core Hub confidence improves; +- Core Hub follow-up workplans, opened or updated in `core-hub` when execution + moves there. + +## Direction Locked + +- Do not implement ops-warden changes from this lane. If Custodian needs a new + ops-warden capability or catalog behavior, post it as a State Hub requirement + or suggestion for the ops-warden worker. +- Treat the Haskell Inter-Hub path as legacy production compatibility. Do not + spend new design energy there unless needed for migration evidence or rollback. +- Reframe the remaining ops-hub evidence/bootstrap work as Core Hub work. +- Deliver implementation in this order: API first, CLI second, web UI third. +- For web UI, rebuild from scratch around the most important operator tasks and + consume whynot-design tokens/components wherever practical. Avoid carrying + old Inter-Hub UI assumptions forward. +- Prefer Helixforge build tools, environment conventions, and release practices + as the implementation lane matures. + +## Current Assessment + +Core Hub is promising but not yet the proven production replacement: + +- `CORE-WP-0004` has local compatibility evidence: protected `/api/v2` routes, + persistence-backed hub/manifest/API-key/widget/event resources, and a local + ops-hub bootstrap smoke. +- `CORE-WP-0005` still waits on staging import, dual-run smokes, and cutover + evidence. +- `CORE-WP-0006` has an authenticated `/console` prototype plus desktop/mobile + visual checks. + +That is enough to stop expanding the old Inter-Hub workplan model, but not yet +enough to rewrite all of `CUST-WP-0025` as complete. The reset should proceed +after Core Hub has a named API-first continuation plan and at least one deployed +compatibility/evidence smoke. + +## Task: Capture Pivot Guardrails + +```task +id: CUST-WP-0052-T01 +status: done +priority: high +state_hub_task_id: "57dd6ee2-0104-47e6-921f-7c9272c00e3d" +``` + +Create this coordination workplan and record the guardrails: + +- no ops-warden implementation here; +- Core Hub owns the replacement lane; +- API before CLI before web UI; +- whynot-design is the preferred UI source contract; +- CUST-WP-0025 is reset only after Core Hub evidence is strong enough. + +Done when the pivot is explicit enough that future agents do not resume the old +Inter-Hub-first path by accident. + +Completed 2026-06-27: created this workplan and updated the linked Custodian +checkpoint/workplans with the pivot. + +## Task: Reframe CUST-WP-0047 And CUST-WP-0049 + +```task +id: CUST-WP-0052-T02 +status: done +priority: high +state_hub_task_id: "5cad98c7-9490-49bc-b1ec-d139350514c4" +``` + +Convert the remaining ops-hub evidence/bootstrap lane from "finish Inter-Hub +production activation" to "preserve legacy evidence while Core Hub takes over +replacement implementation." + +Minimum scope: + +- Update `CUST-WP-0047-T05` so Inter-Hub widget activation is no longer the + preferred implementation target. +- Update `CUST-WP-0049-T06` so the access routine is legacy/fallback execution + evidence, not the main replacement path. +- Keep the existing non-secret evidence, route ids, and operator gates intact. +- Do not close the old wait tasks until a Core Hub smoke or explicit supersede + decision exists. + +Done when 0047/0049 no longer pull new work toward Haskell Inter-Hub, and the +remaining wait state is either Core Hub smoke evidence or a deliberate legacy +operator step. + +2026-06-27 progress: added pivot notes to `CUST-WP-0047`, `CUST-WP-0049`, and +the infrastructure pickup checkpoint. + +Completed 2026-06-27: CUST-WP-0047 and CUST-WP-0049 now preserve legacy +Inter-Hub evidence while pointing future implementation toward Core Hub +API-first replacement. The old live wait tasks remain open until Core Hub smoke +evidence or an explicit supersede decision closes them. + +## Task: Open Or Update Core Hub API-First Continuation + +```task +id: CUST-WP-0052-T03 +status: todo +priority: high +state_hub_task_id: "4b102619-2fb0-4bcc-87b9-3549a748cabe" +``` + +Create or update the Core Hub workplan that owns the replacement implementation +for ops-hub evidence and bootstrap. + +Expected shape: + +1. API contract and deployed compatibility smokes. +2. CLI helpers that wrap the API for attended/bootstrap operations. +3. Web console rebuilt from scratch only after the API and CLI are stable. + +Acceptance should include: + +- ops-hub bootstrap/evidence smoke against deployed Core Hub; +- activity-core consumer smoke against Core Hub or a clearly named dual-run + bridge; +- migration/cutover evidence from CORE-WP-0005; +- no secret material in logs, fixtures, screenshots, or workplans. + +## Task: Rewind And Redo CUST-WP-0025 Phase 3 + +```task +id: CUST-WP-0052-T04 +status: todo +priority: high +state_hub_task_id: "04c9c807-68d0-4750-bd72-a484730cd55d" +``` + +After Core Hub replacement evidence is good enough, rewrite the `CUST-WP-0025` +ops-hub phase instead of executing the old standalone scaffold literally. + +Likely changes: + +- keep T03 as the remaining IAM Profile integration gate; +- preserve completed hub-core/dev-hub extraction tasks; +- rewrite or cancel T13-T19 so they describe Core Hub-owned APIs, ops-hub + evidence contracts, CLI helpers, and a new whynot-aligned web console; +- defer fin-hub/business tasks until the new ops-hub signal is proven. + +Done when CUST-WP-0025 reflects the current Core Hub architecture and no longer +points future agents at the obsolete mega-hub/Inter-Hub scaffold sequence. + +## Task: Align Helixforge Build And Environment Practices + +```task +id: CUST-WP-0052-T05 +status: todo +priority: medium +state_hub_task_id: "b46e608d-0174-422d-baf4-26b5d027e761" +``` + +Before Core Hub implementation broadens, collect the Helixforge build/tooling +practices that should shape this lane. + +Minimum scope: + +- identify relevant build commands, local dev environment assumptions, and + release/check commands; +- map how Core Hub should consume those practices without blocking the API + contract work; +- record any required updates in Core Hub or Helixforge workplans. + +Done when the Core Hub continuation has a concrete build/test/release surface +rather than one-off shell recipes. + +## Task: UI Rebuild Criteria + +```task +id: CUST-WP-0052-T06 +status: todo +priority: medium +state_hub_task_id: "f4dbc298-997a-497c-a56c-0d2293f3aec9" +``` + +Define when the web UI work may start and what it must prioritize. + +Rules: + +- do not start by recreating every old screen; +- choose the most operationally valuable first views: readiness, hub registry, + evidence intake, migration/cutover state, and action-required gates; +- use whynot-design tokens/components where practical; +- keep visual checks across desktop/mobile and no-overlap constraints; +- preserve API/CLI parity so the UI is not the only execution path. + +Done when the Core Hub UI workplan has a compact first-screen backlog and +acceptance checks grounded in real operator workflows. + +## Task: Route External Requirements Through State Hub + +```task +id: CUST-WP-0052-T07 +status: todo +priority: medium +state_hub_task_id: "a2977870-60f4-47c3-a531-81b4b38ebf55" +``` + +When this lane discovers requirements owned by other workers, post them through +State Hub instead of editing those repos directly from this thread. + +Known policy: + +- ops-warden requests are suggestions/requirements for the separate ops-warden + worker; +- credential needs stay route/evidence-only; +- Core Hub implementation work may proceed in the Core Hub repo when explicitly + picked up as the next work item. + +Done when cross-worker asks are recorded as non-secret State Hub messages or +workplan notes, not buried in chat. + +## Acceptance + +- CUST-WP-0051, CUST-WP-0047, and CUST-WP-0049 point toward Core Hub replacement + instead of further Inter-Hub expansion. +- CUST-WP-0025 has a clear reset gate and no one resumes the old standalone + ops-hub scaffold until it is rewritten. +- The next implementation lane is API first, CLI second, web UI third. +- UI rebuild expectations name whynot-design and operator-priority views. +- External ops-warden needs are routed through State Hub requirements, not + direct implementation in this thread.