Add Core Hub FOS reset workplan
This commit is contained in:
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user