Clarify core hub staging credential route

This commit is contained in:
2026-06-30 10:20:23 +02:00
parent cb7fd7b19d
commit 1f9ef92a66
4 changed files with 37 additions and 9 deletions

View File

@@ -1,6 +1,6 @@
# Core Hub Replacement Evidence Handoff
Date: 2026-06-27
Date: 2026-06-30
Related workplans: `CUST-WP-0052`, `CUST-WP-0025`, `CUST-WP-0047`,
`CUST-WP-0049`, `CORE-WP-0008`, `CORE-WP-0004`, `CORE-WP-0005`,
@@ -103,6 +103,13 @@ and CLI evidence through the rebuild backlog.
## Remaining Gates
2026-06-30 route refinement: `warden route find` for the Core Hub
staging smoke token need matched the OpenBao-owned `openbao-api-key`
lane for operator/runtime credentials, with `key-cape-oidc-login`
available for interactive auth and `ops-bridge-tunnel` for private
endpoint access when needed. ops-warden can route or assist eligible lanes,
but it does not own, mint, or store Core Hub token values.
- Run `make deployed-smoke` or `make operator-cli CLI_ARGS="deployed-smoke ..."`
against a real Core Hub staging URL with an approved operator token.
- Import the approved Inter-Hub export bundle into a staging Core Hub database

View File

@@ -1,6 +1,7 @@
# Credential Custody Unblock Board
Created: 2026-06-27
Updated: 2026-06-30
Owner: the-custodian coordination; credential owners remain with their owning repos.
## Purpose
@@ -55,7 +56,8 @@ Current read:
| Gate family | Posture/maturity read |
| --- | --- |
| Inter-Hub / ops-hub runtime keys | Production real-value gate; implementation can proceed with route evidence, but live smoke waits on OpenBao/operator custody. |
| Inter-Hub / ops-hub runtime keys | Legacy/fallback production real-value gate; implementation can proceed with route evidence, but live smoke waits on OpenBao/operator custody. |
| Core Hub deployed smoke/runtime token | Preferred replacement gate: `CORE_HUB_BASE_URL` is endpoint routing, operator/runtime token custody routes to `openbao-api-key`, and activity-core widget mapping belongs to Core Hub/activity-core. ops-warden does not mint or store this token. |
| activity-core to issue-core | Production service credential gate; the blocker is `ISSUE_CORE_API_KEY` injection/evidence, not repo-side contract work. |
| OpenBao unseal / issuer profile | M3-style operator ceremony. The narrow `warden-sign` lane is verified/banked; broader issuer/profile work remains separate. |
| ops-warden policy gate / warden-sign | Verified and banked: `SECRETS-WP-0004` and `FLEX-WP-0007` are finished, with `decision:032b096c433ad80c`, `ttl_out_of_bounds`, backend `vault`, and no secret material recorded. |
@@ -65,6 +67,7 @@ Current read:
| Gate | Blocking work | Owner and route | Expected execution host | Non-secret evidence | Fallback decision | Next action | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Core Hub deployed evidence and activity-core sink | `CUST-WP-0025-T16`, `CORE-WP-0004-T03/T04`, feeds `CUST-WP-0025-T17` | `openbao-api-key` for operator/runtime token custody; `ops-bridge-tunnel` if the staging URL is private; Core Hub/activity-core for widget mapping | Core Hub staging runtime, operator workstation, or trusted cluster job | deployed-smoke run id, hub/manifest/API-consumer ids, key prefix only, widget/event ids, counts, readiness and containment booleans | Keep Inter-Hub as legacy/fallback until Core Hub evidence exists or explicit supersede decision. | Provide `CORE_HUB_BASE_URL`, approved token custody, activity-core widget id/mapping, then run deployed smoke plus sink smoke. | Waiting on staging/custody handoff |
| Inter-Hub ops-hub bootstrap | `CUST-WP-0049-T06`, unblocks `CUST-WP-0047-T05` | `inter-hub-bootstrap-ssh` for the envelope; `openbao-api-key` for operator/runtime key custody; `ssh-cert-host-access` only for cert signing if remote execution is used | Local workstation with `IHUB_OPERATOR_KEY_FILE`, or trusted host with railiance-infra force-command wrapper | Hub id, manifest id, widget count, runtime key prefix only, bootstrap smoke result, State Hub progress id | Prefer API helper. Use deployment-side migration/bootstrap only by explicit operator approval. Manual SQL remains last-resort and must be recorded as an exception. | Operator materializes Inter-Hub operator key through approved custody, runs the ops-hub helper, stores generated runtime key outside Git, removes temp files. | Ready for operator handoff |
| Ops-hub runtime evidence key | `IHUB-WP-0022-T04`, then `IHUB-WP-0022-T07` | `openbao-api-key` owned by `railiance-platform` / OpenBao | Operator workstation, OpenBao UI/CLI session, or trusted cluster job; not a Codex-visible shell with printed values | OpenBao path/version or populated key count only, token exchange HTTP status, evidence submission smoke id | Attended one-time key file is acceptable only long enough to store in OpenBao and remove; no chat or State Hub transfer. | Store/provide `OPS_HUB_KEY` via OpenBao path, then run Inter-Hub submission smoke. | Waiting on operator custody |
| OpenBao unseal and token automation | `NET-WP-0020`, related OpenBao token-grant and policy-gate blockers | `openbao-api-key` for OpenBao issuer/token paths; `railiance-infra-principals` for host policy; `ssh-cert-host-access` for cert signing; `key-cape-oidc-login` for login/MFA | OpenBao operator terminal, cluster-admin context, or trusted railiance-infra deployment path | Policy names, role names, token accessor only, decision ids, allow/deny smoke result | Keep attended ceremony path until auto-unseal/profile is explicitly approved. Do not invent `warden secret` or paste `VAULT_TOKEN`. | Broader custody profile remains open; do not treat the completed `warden-sign` lane as a general OpenBao credential helper. | Needs operator design/approval |
@@ -85,10 +88,11 @@ uv run warden route show ops-bridge-tunnel --json
## Pickup Order
1. Inter-Hub ops-hub bootstrap, because it unlocks both the now-view and the
activity-core evidence lane.
2. Ops-hub runtime evidence key, because it is the immediate smoke gate after
bootstrap.
1. Core Hub deployed evidence and activity-core sink smoke, because this is
the preferred replacement proof for ops-hub evidence and can supersede
legacy Inter-Hub waits once real staging evidence exists.
2. Keep Inter-Hub ops-hub bootstrap and runtime keys as legacy/fallback only
unless the operator explicitly chooses rollback or compatibility proof.
3. OpenBao custody profile, because several credential-helper and policy-gate
blockers collapse once a narrow issuer path exists.
4. Forgejo production decisions, because those require human design approval

View File

@@ -1,6 +1,6 @@
# FOS Hub Bootstrap Sequence Status
Updated: 2026-06-27
Updated: 2026-06-30
## Purpose
@@ -21,7 +21,7 @@ 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 | Core Hub is now the replacement platform: `CORE-WP-0008` finished the API smoke harness, activity-core sink, staging profile, CLI wrappers, UI rebuild backlog, and Custodian handoff. Live deployed smokes and cutover evidence are still open. | Continue through Core Hub deployed evidence, migration import, activity-core smoke, and cutover gates. Treat Haskell Inter-Hub as legacy compatibility or rollback evidence. |
| Ops hub | Core Hub is now the replacement platform: `CORE-WP-0008` finished the API smoke harness, activity-core sink, staging profile, CLI wrappers, UI rebuild backlog, and Custodian handoff. Live deployed smokes and cutover evidence are still open. | Continue through Core Hub deployed evidence, migration import, activity-core smoke, and cutover gates. Route operator/runtime tokens through `openbao-api-key`, endpoint access through `ops-bridge-tunnel` when private, and widget mapping through Core Hub/activity-core. Treat Haskell Inter-Hub as legacy compatibility or rollback evidence. |
| Old ops-hub scaffold tasks | `CUST-WP-0025-T13`-`T19` have been rewritten around Core Hub API evidence, CLI parity, deployed smoke/cutover gates, whynot-aligned UI, and cancellation of immediate standalone ops-hub MCP registration. | Execute the remaining wait/todo gates in the rewritten Phase 3. Do not resume the obsolete standalone ops-hub scaffold sequence. |
| 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. |
@@ -30,5 +30,5 @@ Do not restart FOS bootstrap at the old `NK-WP-0001` Keycloak path. That workpla
1. Close the identity drift: T01 cancelled, T02 done, T03 remains as the one real identity integration test.
2. Use the finished `CORE-WP-0008` evidence lane and `CUST-WP-0052` reset notes as the Core Hub replacement baseline.
3. Keep `CUST-WP-0047`/`CUST-WP-0049` as legacy evidence/fallback until Core Hub deployed smoke evidence or an explicit supersede decision closes them.
4. Execute rewritten `CUST-WP-0025-T14`, `T16`, `T17`, and `T18` in API/CLI/UI order.
4. Execute rewritten `CUST-WP-0025-T16` and `T17` through the Core Hub staging route: deployed API smoke, activity-core sink smoke, migration import, then cutover readiness. Keep T14/T15/T18 as completed definition/CLI/UI inputs.
5. Start fin-hub/business work only after ops-hub proves the Core Hub pattern end-to-end.