coulomb/the-custodian
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add Core Hub FOS reset workplan

Browse Source
This commit is contained in:
Bernd Worsch
2026-06-27 19:31:09 +02:00
parent acbe4976af
commit f490d18423
7 changed files with 317 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
docs/fos-hub-bootstrap-sequence-status.md
View File

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

28
docs/infrastructure-stabilization-pickup-checkpoint.md
View File

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

7
workplans/CUST-WP-0025-fos-hub-bootstrap.md
View File

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

7
workplans/CUST-WP-0047-ops-hub-service-inventory-now-view.md
View File

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

7
workplans/CUST-WP-0049-interhub-bootstrap-access-lane.md
View File

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

23
workplans/CUST-WP-0051-infrastructure-stabilization-metaplan.md
View File

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

251
workplans/CUST-WP-0052-core-hub-fos-reset.md Normal file
View 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.