coulomb/the-custodian
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
46fff69fc0bce69b030d986abaf65dd80ac237dc
the-custodian/workplans/CUST-WP-0052-core-hub-fos-reset.md

11 KiB
Raw Blame History

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 finished 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: done
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.

Completed 2026-06-27: created Core Hub workplan CORE-WP-0008 (cc49cc00-2eb3-43e0-bed8-93cdf919d620) as the API-first execution counterpart. The next implementation task is CORE-WP-0008-T02 (6a594f9e-01ab-4be5-bf9f-2571722818c5) for the deployed API smoke harness, followed by activity-core consumer proof, staging profile, CLI wrappers, and gated UI rebuild criteria.

Task: Rewind And Redo CUST-WP-0025 Phase 3

id: CUST-WP-0052-T04
status: done
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.

2026-06-27 evidence handoff: docs/core-hub-replacement-evidence.md now summarizes the Core Hub replacement proof from CORE-WP-0008-T02 through T06, records why CUST-WP-0047-T05 and CUST-WP-0049-T06 should remain legacy/fallback wait tasks for now, and gives rewrite guidance for CUST-WP-0025-T13 through T19.

Completed 2026-06-27: rewrote CUST-WP-0025-T13 through T19 around Core Hub-owned API evidence, operator CLI parity, deployed smoke/cutover gates, and the whynot-aligned Core Hub UI backlog. The rewrite marks the old immediate standalone ops-hub MCP registration as cancelled, keeps deployed evidence and cutover tasks waiting on real staging/runtime proof, and does not claim Haskell retirement is unblocked.

Task: Align Helixforge Build And Environment Practices

id: CUST-WP-0052-T05
status: done
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.

Completed 2026-06-27: added docs/core-hub-helixforge-build-alignment.md. The note separates HelixForge's capability/workplan role from Railiance Forge's concrete build, registry, runner, and evidence contracts. It maps Core Hub's existing Make targets, staging profile, immutable image-tag expectation, operator CLI, smoke evidence, and future railiance-apps promotion path into a repeatable build/test/release lane without blocking API contract work on runner automation.

Task: UI Rebuild Criteria

id: CUST-WP-0052-T06
status: done
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.

Completed 2026-06-27: Core Hub CORE-WP-0008-T06 added docs/specs/operator-ui-rebuild-backlog.md, a compact first-screen backlog for readiness, registry, evidence stream, migration/cutover, action-required gates, and access metadata. The backlog gates UI work behind deployed API evidence and CLI parity, requires whynot-design primitives where practical, and preserves desktop/mobile/no-overlap/non-secret visual checks.

Task: Route External Requirements Through State Hub

id: CUST-WP-0052-T07
status: done
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.

Completed 2026-06-27: posted non-secret State Hub requirement messages for the external follow-ups discovered by this lane: 3ced85c7-9fde-4f67-8002-f7b6502d6690 to railiance-apps for eventual Core Hub app release ownership, and 89854bab-6f43-426c-84ea-9af326840621 to railiance-forge for registry and runner evidence prerequisites. No ops-warden implementation or secret-value ask was made.

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 Phase 3 has been rewritten so no one resumes the old standalone ops-hub scaffold sequence.
  • 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 View Git Blame Copy Permalink