Add Core Hub FOS reset workplan
This commit is contained in:
251
workplans/CUST-WP-0052-core-hub-fos-reset.md
Normal file
251
workplans/CUST-WP-0052-core-hub-fos-reset.md
Normal file
@@ -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.
|
||||
Reference in New Issue
Block a user