the-custodian/workplans/CUST-WP-0052-core-hub-fos-reset.md

id, type, title, domain, repo, status, owner, topic_slug, planning_priority, planning_order, created, updated, state_hub_workstream_id

id	type	title	domain	repo	status	owner	topic_slug	planning_priority	planning_order	created	updated	state_hub_workstream_id
CUST-WP-0052	workplan	Core Hub Reframe And FOS Bootstrap Reset	infotech	the-custodian	active	codex	custodian	high	52	2026-06-27	2026-06-27	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

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

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

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

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

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

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

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.