|
|
|
|
@@ -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.
|
