the-custodian/workplans/CUST-WP-0025-fos-hub-bootstrap.md

---
id: CUST-WP-0025
type: workplan
title: "FOS Hub Bootstrap — Identity, Hub Extraction, Ops Hub, Fin Hub"
domain: infotech
repo: the-custodian
status: finished
owner: custodian
topic_slug: custodian
created: "2026-03-20"
updated: "2026-07-08"
state_hub_workstream_id: "293a74fe-a85a-4ad6-8933-23d52a72fe8b"
---

# FOS Hub Bootstrap — Identity, Hub Extraction, Ops Hub, Fin Hub

## Goal

Progress the Custodian from FOS maturity Level 1 (Single-Hub Emergence) toward
Level 3 (Core Federation) by:

1. Finalizing shared identity infrastructure (NetKingdom SSO)
2. Extracting a generic reusable hub-core package from state-hub
3. Renaming state-hub to dev-hub and transitioning all repos
4. Creating the ops-hub for runtime operations coordination
5. Building the fin-hub with railiance-as-a-service as first monetization path

## Context

The state-hub has matured through 24 completed workplans (62 workstreams, 573 tasks)
but remains a monolithic single hub mixing dev-coordination, governance, and generic
infrastructure. Per FOS §13.1, this risks becoming the "Mega-Hub" anti-pattern.

Two standards govern the architecture:
- **FOS** (Federated Organisation Standard): organizational recursion via domain hubs
- **OAS** (Orthogonal Architecture Standard): compute substrate via 6 dimensions

Together they form a complete cybernetic stack: FOS gives the viable organization,
OAS gives the viable infrastructure.

## Key Decisions

| Decision | Choice | Rationale |
|----------|--------|-----------|
| Hub-core packaging | Separate pip-installable package | Clean separation, versioned independently, each hub depends via uv |
| Phase sequencing | Parallel start (Phase 1 + 2) | Identity and extraction run concurrently; auth bolted on later |
| Ops Hub location | New standalone repo | FOS separation principle — each hub independently deployable |
| First monetization | Railiance-as-a-service | Package OAS infra stack as managed/consultancy for EU SMEs |

## Phase 1 — Identity Infrastructure

**Goal**: Finalized user-id infrastructure so all future hubs share one SSO plane.
**Repos**: net-kingdom, railiance-cluster, railiance-platform
**Runs in parallel with Phase 2.**

### T01 — Complete NK-WP-0001: Keycloak + privacyIDEA on k3s

```task
id: CUST-WP-0025-T01
status: cancel
priority: high
state_hub_task_id: "f55078b6-7fa3-49ab-be30-37db622d64c9"
```

Complete the SSO/MFA platform deployment. Keycloak as OIDC provider with
privacyIDEA for MFA, running on the k3s cluster. This is the identity
foundation for all hubs and services.

Cross-reference: net-kingdom NK-WP-0001.

2026-06-27 sequencing update: cancelled as an obsolete prerequisite. `NK-WP-0001` is archived and superseded by the KeyCape/Authelia/LLDAP lightweight stack, `NK-WP-0012` IAM Profile v0.2, and the proposed `NK-WP-0011` expanded-mode Keycloak federation lane. FOS bootstrap should not wait for this old Keycloak path.

### T02 — Complete NK-WP-0002: Local identity bootstrap

```task
id: CUST-WP-0025-T02
status: done
priority: high
state_hub_task_id: "0d7792f7-5695-4e1a-9726-b9661d5e7108"
```

Implement lightweight file-based OIDC server for dev/sandbox/bootstrap
scenarios where the full Keycloak cluster is unavailable. Enables local
development of hub services without cluster dependency.

Cross-reference: net-kingdom NK-WP-0002.

2026-06-27 sequencing update: marked done. `NK-WP-0002` is complete: local-identity file store, Keycloak export, minimal localhost OIDC provider, permissions hardening, audit log, and docs are all delivered.

### T03 — IAM Profile integration test

```task
id: CUST-WP-0025-T03
status: done
priority: medium
state_hub_task_id: "e9894ac9-add3-45a6-9893-ea67c6e5e260"
```

Prove a FastAPI service can authenticate via NetKingdom OIDC end-to-end.
Write a minimal test service + integration test that:
- Obtains a token via OIDC/PKCE flow
- Calls a protected endpoint
- Validates token claims (sub, roles, expiry)

This test becomes the template for hub-core auth middleware.

2026-06-27 sequencing update: this was kept as the real identity gate, targeted at the current NetKingdom IAM Profile v0.2 contract and either local-identity or KeyCape lightweight issuer, not the archived `NK-WP-0001` Keycloak path.

Completed 2026-06-27: Core Hub now has a reusable FastAPI IAM Profile verifier
and dependency in `/home/worsch/core-hub/src/core_hub/iam_profile.py`.
`tests/test_iam_profile.py` proves a fixture IAM Profile issuer can expose OIDC
discovery/JWKS, issue an authorization-code + PKCE token, call a protected
FastAPI endpoint, and validate issuer, audience, expiry, roles, groups, scopes,
tenant, principal type, and assurance claims. Negative tests reject missing
bearer tokens, wrong audience, and production use of local-development issuers.
This closes the identity integration template without requiring NetKingdom repo
changes or production secrets.

### T04 — Canon standard: IAM Profile specification

```task
id: CUST-WP-0025-T04
status: done
priority: medium
state_hub_task_id: "69acc880-394b-478a-94f0-476c9cbc1bc6"
```

Document the OIDC contract as `canon/standards/iam-profile_v0.1.md`:
- Discovery endpoint structure
- Required claims and scopes
- Token lifecycle (access + refresh)
- Hub-to-hub service account pattern
- Human override / emergency access

## Phase 2 — Hub Extraction & Dev Hub Rename

**Goal**: Extract generic hub-core package; rename state-hub to dev-hub.
**Repo**: the-custodian (governance and workplan), `/home/worsch/state-hub`
(authoritative source), `/home/worsch/hub-core` (new target repo)
**Runs in parallel with Phase 1.**

**Current repo reality (2026-06-06):** `CUST-WP-0043` completed the State Hub
repo extraction, so this repository now keeps only the `state-hub/README.md`
pointer. Phase 2 implementation work must read and refactor the standalone
`/home/worsch/state-hub` checkout, while this workplan keeps the coordination
record in `the-custodian`.

### Extraction Boundary

**Generic hub-core (~17 MCP tools, ~6 models, ~6 routers):**
- Models: Domain, AgentMessage, CapabilityCatalog, CapabilityRequest, ManagedRepo, TPSC*, ProgressEvent (generic event_types)
- Routers: domains, repos, messages, capability_requests, tpsc, policy
- MCP tools: orientation, messaging, capability routing, repo management, TPSC/GDPR, DoI

**Dev-hub-specific (~51 MCP tools, ~12 models):**
- Topics, workstreams, tasks, decisions, dependencies, EP/TD, contributions, SBOM, goals, DoI cache, kaizen agents, consistency checker

### T05 — Create hub-core package

```task
id: CUST-WP-0025-T05
status: done
priority: high
state_hub_task_id: "04bf480c-8847-4a89-a4f2-e7c5fc51088d"
```

Create `/home/worsch/hub-core` as a standalone repo with `pyproject.toml`
(uv-managed). Extract from `/home/worsch/state-hub`:
- Generic SQLAlchemy models (Domain, AgentMessage, CapabilityCatalog, CapabilityRequest, ManagedRepo, TPSC*, ProgressEvent)
- Generic Pydantic schemas
- Generic FastAPI routers (domains, repos, messages, capability_requests, tpsc, policy)
- Alembic migration templates for core schema
- Shared utilities (slug resolution, pagination, trailing-slash normalization)

Implementation start (2026-06-06): reviewed the standalone State Hub source and
captured the first extraction boundary in
`docs/hub-core-extraction-boundary.md`. Several candidate "generic" models still
reference dev-hub tables (`topics`, `workstreams`, `tasks`, `decisions`), so the
initial package slice should start with base DB primitives, domains, repos,
messages, TPSC catalog/snapshots, and adapter seams for progress and capability
requests rather than a blind file copy.

Implementation slice 2 (2026-06-06): expanded `/home/worsch/hub-core` with
router factory functions for domains, repos, messages, TPSC, and policy lookup.
The factories receive the host hub's `get_session` dependency instead of
binding to State Hub globals, preserving the package boundary for future hubs.
Verification currently covers package compilation, SQLAlchemy metadata
registration, and router factory construction.

Implementation slice 3 (2026-06-06): added hub-core shared utilities for slug
normalization, pagination, repo path resolution, and trailing-slash path
normalization. Added Alembic migration templates plus an initial core schema
migration covering domains, managed repos, agent messages, capability catalog,
and TPSC tables. Hub-core verification now covers package compilation, router
construction, registered metadata, and utility behavior.

Implementation slice 4 (2026-06-06): added progress event and capability
request adapter seams to `/home/worsch/hub-core`. The core progress event uses
generic `subject_refs` JSON instead of dev-hub foreign keys, and capability
requests use JSON request/fulfillment context fields instead of workstream/task
columns. This keeps hub-core reusable while giving State Hub a migration path
for its dev-specific references.

Completed package slice (2026-06-07): added the remaining generic REST router
factories for progress events and capability catalog/request lifecycle. With
models, schemas, routers, Alembic templates, and shared utilities present in
`/home/worsch/hub-core`, T05 is complete enough for T06 MCP base-server work
and T08 State Hub import refactoring to begin.

### T06 — Hub-core FastMCP base server

```task
id: CUST-WP-0025-T06
status: done
priority: high
state_hub_task_id: "6b49d94a-b1ea-4507-a8a3-e27c1a918491"
```

Add a base MCP server class to hub-core that provides the ~17 generic tools:
- Orientation: get_state_summary, get_domain_summary, list_domains
- Messaging: send_message, get_messages, mark_message_read, reply_to_message
- Capability routing: register_capability, list_capabilities, request_capability, accept_capability_request, update_capability_request_status, list_capability_requests, get_capability_request
- Repo management: register_repo, update_repo_path, list_domain_repos
- TPSC/GDPR: register_service, list_services, ingest_tpsc_tool, get_gdpr_report
- DoI: check_repo_doi, get_doi_summary

Domain-specific hubs inherit and add their own tools.

Implementation start (2026-06-07): added `HubCoreMCPServer` in
`/home/worsch/hub-core` as a thin FastMCP wrapper over hub-core REST endpoints.
The base class registers generic tools for domains, messages, capability
catalog/requests, repos, TPSC, and progress.

Completed MCP slice (2026-06-07): added the remaining orientation tools
(`get_state_summary`, `get_domain_summary`), DoI passthrough tools
(`check_repo_doi`, `get_doi_summary`), and FOS §10 risk/alert read tools to
`HubCoreMCPServer`. The DoI evaluator still remains host-hub-owned, but the
generic MCP contract now exposes the required DoI tools.

### T07 — FOS §10 risk and alert tools

```task
id: CUST-WP-0025-T07
status: done
priority: medium
state_hub_task_id: "5a54af24-f7cb-451f-874f-66bd6979ab07"
```

Add `get_risks()` and `get_alerts()` to hub-core, formalizing existing
ProgressEvent patterns. Define canonical event_type values:
- `risk_surfaced`, `risk_mitigated`, `risk_escalated`
- `alert_raised`, `alert_acknowledged`, `alert_resolved`

This completes the FOS §10 cross-hub contract.

Completed (2026-06-07): added canonical FOS §10 event constants to
`hub_core.events`, exposed `/progress/risks` and `/progress/alerts` filtered
views, and registered matching `get_risks` / `get_alerts` MCP tools. Hub-core
tests cover the event contract, router views, and MCP tool registration.

### T08 — Refactor state-hub to import from hub-core

```task
id: CUST-WP-0025-T08
status: done
priority: high
state_hub_task_id: "daf1d8ac-b55a-4692-b359-2671ddf6fc8a"
```

Refactor the standalone `/home/worsch/state-hub` codebase:
- Replace generic models/routers/schemas with imports from hub-core
- Keep dev-specific code (topics, workstreams, tasks, decisions, etc.) in state-hub
- Ensure all existing tests pass with the new import structure
- Update pyproject.toml to depend on hub-core

Completed 2026-06-22: child workplan `CUST-WP-0048` finished. Generic schemas,
routers, capability write callbacks, and MCP composition now import from
hub-core. State Hub regression: 426 tests. Deferred couplings documented in
`docs/hub-core-extraction-boundary.md` (ProgressEvent FK mapping, optional
workplan column → JSON migration). Phase 2 proceeds to dev-hub rename (T09+).

### T09 — Rename MCP server state-hub to dev-hub

```task
id: CUST-WP-0025-T09
status: done
priority: high
state_hub_task_id: "2148a804-7d6a-4e26-b1a8-08da24929c88"
```

Rename across all integration points:
- `/home/worsch/state-hub/mcp_server/server.py`: name="state-hub" → "dev-hub"
- `~/.claude/CLAUDE.md`: 3 locations (registration commands, references)
- `/home/worsch/state-hub/scripts/register_project.sh`: validation checks
- `/home/worsch/state-hub/scripts/patch_mcp_cwd.py`: config checks
- `/home/worsch/state-hub/custodian_cli.py`: config checks
- `/home/worsch/state-hub/scripts/project_rules/session-protocol.template`: template text
- `/home/worsch/state-hub/api/main.py`: service metadata response

Completed 2026-06-22: MCP server identifier is `dev-hub`; legacy `state-hub` accepted
during transition. Global `~/.claude/CLAUDE.md` registration section updated.

### T10 — MCP config migration script

```task
id: CUST-WP-0025-T10
status: done
priority: medium
state_hub_task_id: "5953f129-089d-4d90-bbe5-f86da4eac1bf"
```

Create `/home/worsch/state-hub/scripts/migrate_mcp_config.py` that:
- Reads `~/.claude.json`
- Renames `mcpServers["state-hub"]` to `mcpServers["dev-hub"]`
- Preserves all other settings
- Backs up original file before writing

Completed 2026-06-22: `scripts/migrate_mcp_config.py` plus unit tests in
`tests/test_mcp_registration.py`. Local `~/.claude.json` migrated.

### T11 — Regenerate domain repo rule files

```task
id: CUST-WP-0025-T11
status: done
priority: medium
state_hub_task_id: "7b41766b-f97f-4e9f-9f3c-c0937edb355f"
```

After template update, regenerate `.claude/rules/session-protocol.md` for
all registered domain repos:
- railiance-infra, railiance-cluster, railiance-platform
- railiance-enablement, railiance-apps
- net-kingdom, markitect, coulomb.social
- personhood, foerster-capabilities

Completed 2026-06-22: `scripts/update_agent_instruction_files.py` regenerated
session-protocol and related rule files for 66 local repos.

### T12 — Full test suite and consistency check

```task
id: CUST-WP-0025-T12
status: done
priority: high
state_hub_task_id: "e55ae544-3cea-485e-80d5-a9696ef97b96"
```

Gate: all of the following must pass before Phase 2 is considered complete:
- `cd /home/worsch/state-hub && make test` — full test suite
- `make fix-consistency REPO=the-custodian` — workplan ↔ DB sync
- `make check-consistency-all` — all registered repos
- Manual smoke test: start dev-hub MCP server, run get_domain_summary from a domain repo

Completed 2026-06-22: state-hub 434 tests pass; `fix-consistency` passes.
`check-consistency-all` completes with pre-existing assessment-fail items in a
few repos (unrelated to dev-hub rename); no new automation errors introduced.

## Phase 3 — Ops Hub

**Goal**: Runtime operations coordination per FOS §7.3.
**Depends on**: Phase 2 (hub_core available), Phase 1 (identity for service auth).
**Repo**: core-hub for replacement runtime; the-custodian for coordination; standalone ops-hub is deferred until post-cutover need is proven.

**Inventory-first implementation slice (2026-06-05):** `CUST-WP-0047`
carves out the minimum useful part of T14/T16/T18 before the replacement runtime
is fully proven: a repo-owned service inventory contract, an initial
service/location/evidence seed, and the handoff path for Inter-Hub widgets and
activity-core probes. After the Core Hub reset, these artifacts feed Core Hub
ops evidence first; a separate ops-hub repo should ingest them only if a
post-cutover service boundary is proven useful.

**Inter-Hub bootstrap access lane (2026-06-17):** `CUST-WP-0049` extracts the
repeatable authenticated bootstrap routine needed to finish ops-hub production
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. T13-T19 below have been rewritten
around Core Hub: API-first replacement contracts, CLI helpers second, deployed
evidence and cutover gates, and a rebuilt whynot-aligned operator UI third. Keep
Haskell Inter-Hub as legacy compatibility or rollback evidence, not the preferred
implementation target.

### T13 — Open Core Hub replacement lane

```task
id: CUST-WP-0025-T13
status: done
priority: high
state_hub_task_id: "2c6d1429-a67a-4f66-84d1-cb32ffdb890f"
```

Replace the old immediate standalone `ops-hub` repo scaffold with a Core
Hub-owned replacement lane.

The replacement lane must keep the FOS intent of runtime operations
coordination while using the current implementation order:

- Core Hub API resources and compatibility/evidence smokes first;
- thin operator CLI wrappers second;
- web UI rebuild third, after API/CLI parity is stable.

Completed 2026-06-27: Core Hub workplan `CORE-WP-0008` finished as the
API-first execution counterpart, and Custodian recorded the replacement evidence
handoff in `docs/core-hub-replacement-evidence.md`. This task is complete as a
reframe/open-lane task; it does not claim production cutover is complete.

### T14 — Define Core Hub ops evidence contract and read-model gaps

```task
id: CUST-WP-0025-T14
status: done
priority: medium
state_hub_task_id: "0e811e9b-23a5-49f9-979e-cd1c5dcd937f"
```

Define the Core Hub-owned operations evidence contract that replaces the old
standalone ops-specific model list.

The contract should reconcile:

- `CUST-WP-0047` service inventory and current evidence vocabulary;
- Core Hub hubs, manifests, widgets, API consumers, and interaction events;
- activity-core probe metadata and `core-hub-interaction-event` sink output;
- migration runs, deployment records, outcome signals, and cutover evidence;
- non-secret custody rules for key prefixes, hashes, routes, and evidence ids.

Known Core Hub API/read-model gaps to resolve before UI expansion:

- a protected migration-run read route such as `/api/v2/migration-runs`;
- non-deferred deployment/outcome evidence routes where needed;
- a mapping from service inventory ids to Core Hub widgets/events.

Done when Core Hub has a workplan or spec that names the API resources, record
shape, evidence event vocabulary, and migration path from the existing
Custodian inventory artifacts.

Completed 2026-06-27: Core Hub now owns the replacement ops evidence contract in
`/home/worsch/core-hub/docs/specs/ops-evidence-contract.md`. The spec names the
implemented API resources (`hubs`, manifests, API consumers/keys, widgets,
interaction events, hub registry, migration runs), required read-model gaps
(`migration-runs`, deployment records, outcome signals, service inventory
mapping, event filters, registry containment summary), event vocabulary,
non-secret access metadata rules, and the migration path from `CUST-WP-0047`
service inventory into Core Hub widgets/events. T14 is complete as a definition
gate; implementation remains in T16/T17/T18 and follow-up Core Hub read-model
work.

### T15 — Core Hub operator CLI parity

```task
id: CUST-WP-0025-T15
status: done
priority: medium
state_hub_task_id: "3fdd1f61-4c8e-4614-898b-df7a9aa4a514"
```

Replace the old MCP-first ops tool plan with API and CLI parity first.

Required CLI surface:

- deployed Core Hub smoke evidence;
- ops-hub bootstrap/status checks;
- migration bundle validate/import;
- cutover readiness summary from non-secret evidence reports.

Completed 2026-06-27: `CORE-WP-0008-T05` added `make operator-cli` and
`scripts/core_hub_cli.py` with wrappers around the same Core Hub API behavior
used by tests and smokes. Any MCP surface should consume these proven APIs later
rather than becoming the first implementation path.

### T16 — Deployed ops evidence and activity-core smokes

```task
id: CUST-WP-0025-T16
status: done
priority: high
state_hub_task_id: "702849c5-b253-4ede-afa7-0ab4f81e49a5"
```

Run the production-like Core Hub evidence smokes that replace the old direct
Railiance infrastructure integration task.

Minimum evidence:

- `make deployed-smoke` or `make operator-cli CLI_ARGS="deployed-smoke ..."`
  against a real Core Hub staging URL;
- deployed activity-core Core Hub sink smoke with approved runtime token and
  widget mapping;
- non-secret report fields only: run id, hub/manifest/API-consumer ids,
  key prefixes, widget/event ids, counts, statuses, and containment booleans;
- State Hub progress note linking the evidence and naming any remaining gates.

Blocked until an approved `CORE_HUB_BASE_URL`, operator/runtime token custody
path, and activity-core widget mapping are available. This task can close or
supersede `CUST-WP-0047-T05` and `CUST-WP-0049-T06` only after deployed Core
Hub evidence exists or an explicit supersede decision is recorded.

Progress 2026-07-02: the first evidence bullet is met. Core Hub staging is
deployed on CoulombCore (operator-approved: namespace `core-hub-staging`,
image `gitea.coulomb.social/coulomb/core-hub:3ed8531`, dedicated apps-pg
database, migrate job complete). The deployed smoke ran in-cluster with the
operator token confined to the namespace: run `20260702143544-6c8f18`,
`ok=true`, 10/10 API checks plus the full ops-hub bootstrap sequence (hub
`6798723a`, activated manifest, API consumer prefix `ch_N0ZhsXIbD`, widget,
interaction event `21d09f99`, hub registry containment true). Completed 2026-07-02: the
deployed activity-core Core Hub sink smoke also passed — activity-core's real
sink code posted interaction event `ae43db56-902d-411a-a495-25acd464fdd8`
(`ops-endpoint-verified`) to deployed Core Hub staging with an approved runtime
token (consumer `6cfcbc56`, prefix `ch_ztkSv9PK`) and widget mapping (widget
`6768aaa2`); server-side containment confirmed. `CORE-WP-0004` is finished. Both
minimum-evidence bullets (deployed API smoke + activity-core sink smoke) are met,
so T16 is done. Follow-on (not blocking T16): the supersede decision for
`CUST-WP-0047-T05` / `CUST-WP-0049-T06` is now decidable on this deployed
evidence; and the staging import `CORE-WP-0005-T02` plus dual-run/cutover
readiness remain the Core Hub cutover path.

### T17 — Core Hub, dev-hub, and cutover decision coupling

```task
id: CUST-WP-0025-T17
status: done
priority: medium
state_hub_task_id: "b99a3ed8-440b-4e28-88f5-495de7276f66"
```

Replace the old ops-hub-to-dev-hub protocol task with Core Hub replacement
coupling and cutover decision records.

Minimum scope:

- Core Hub readiness summary from deployed smoke, migration import,
  activity-core sink, and optional legacy Inter-Hub reference evidence;
- State Hub progress/decision records that state whether legacy Inter-Hub
  fallback remains required;
- compatibility notes for consumers that still expect Inter-Hub `/api/v2`;
- rollback and Haskell retirement gates kept explicit.

Blocked until `CORE-WP-0005` staging import, dual-run smokes, and cutover
readiness evidence exist. Do not unblock `CORE-WP-0007` Haskell retirement from
local-only evidence.

Completed 2026-07-08: upstream gates cleared (`CORE-WP-0005` finished 2026-07-03).
Non-secret evidence stubs in `docs/evidence/`, aggregated readiness summary
(`readyForCutover: true`), cutover decision record in
`docs/core-hub-cutover-decision-coupling.md`, public stabilization probes pass
on `hub.coulomb.social`, and supersede decisions recorded for `CUST-WP-0047-T05`
and `CUST-WP-0049-T06`. Inter-Hub remains rollback-only through
`CORE-WP-0007` stabilization sign-off.

### T18 — Core Hub operator UI first screens

```task
id: CUST-WP-0025-T18
status: done
priority: medium
state_hub_task_id: "5b6cea8b-3982-49be-bacf-7269a3d2104e"
```

Replace the old Observable Framework dashboard task with the Core Hub operator
UI rebuild backlog.

Initial UI work should implement only the first operator-critical screens:

- readiness overview;
- registry explorer;
- evidence stream;
- migration/cutover state;
- action-required gates;
- access metadata as a support panel, not a broad expansion area.

Use whynot-design tokens/components wherever practical and preserve
`make visual-check` style desktop/mobile, no-overlap, text-overflow, protected
route, and non-secret assertions. Start implementation from Core Hub
`docs/specs/operator-ui-rebuild-backlog.md`, not from old Inter-Hub screens.

Completed 2026-06-27: Core Hub `CORE-WP-0006` is finished with a protected
server-rendered `/console` prototype, whynot-aligned shell/classes, readiness
gates, registry explorer, migration state, action-required gates, access
metadata, recent evidence events, auth tests, and full-key non-disclosure tests.
`CORE-WP-0008-T06` extracted the compact rebuild backlog in
`/home/worsch/core-hub/docs/specs/operator-ui-rebuild-backlog.md` so broader UI
work stays behind API/CLI readiness. Fresh verification passed with
`make visual-check`, producing desktop/mobile screenshots and no-overlap,
horizontal-overflow, protected-route, PNG, and non-secret assertions. This
closes the first-screen UI gate without expanding old Inter-Hub screens.

### T19 — Ops-hub MCP server registration decision

```task
id: CUST-WP-0025-T19
status: cancel
priority: medium
state_hub_task_id: "f033c80e-4ebb-49cf-8987-20c9b2ff4c13"
```

Cancel the old immediate registration of a standalone `ops-hub` MCP server.

The preferred replacement path is Core Hub API first and operator CLI second.
Register a separate ops-hub MCP server only if post-cutover usage proves that a
separate service boundary is still useful. Until then, State Hub progress and
Core Hub API/CLI evidence are the coordination surfaces.

## Phase 4 — Business Model & Fin Hub

**Goal**: First monetization via railiance-as-a-service + resource viability hub.
**Depends on**: Phase 3 (multi-hub pattern proven).

### T20 — Business model canvas: railiance-as-a-service

```task
id: CUST-WP-0025-T20
status: done
priority: medium
state_hub_task_id: "55db0560-2733-481d-adba-b72c3839ba45"
```

Define the offering:
- Target: EU SMEs needing sovereign, GDPR-compliant DevOps infrastructure
- Core: managed k3s cluster + observability + GitOps + backup
- Differentiator: VSM-based organizational architecture, not just infra
- Pricing tiers: self-hosted (open-source), managed, fully operated
- Document as `canon/projects/railiance/business-model-canvas_v0.1.md`

Completed 2026-07-08: `canon/projects/railiance/business-model-canvas_v0.1.md`
defines target segments, value proposition, three pricing tiers, MVP scope,
and open legal/GmbH questions.

### T21 — Canon: Bootstrap Protocol document

```task
id: CUST-WP-0025-T21
status: done
priority: medium
state_hub_task_id: "ce54d3fc-140e-49be-a181-779abc434d4e"
```

Address FOS blindspot #2 (bootstrapping & initial capital):
- Seed funding strategy and minimum viable budget
- MVP scope definition (what must exist before first customer)
- First 3 mandated roles: Constitutional Steward, Technical Operator, Financial Allocator
- Revenue threshold for role formalization
- Document as `canon/constitution/bootstrap-protocol_v0.1.md`

Completed 2026-07-08: `canon/constitution/bootstrap-protocol_v0.1.md` defines
seed budget (€9–15k), MVP scope checklist, three mandated roles, revenue
thresholds for role formalization, and bootstrap exit criteria.

### T22 — Create fin-hub repo from hub-core scaffold

```task
id: CUST-WP-0025-T22
status: done
priority: low
state_hub_task_id: "670757d8-305d-4736-9056-e79a150114b1"
```

Create `fin-hub` repo with same scaffold pattern as ops-hub.
Register under custodian domain.

Completed 2026-07-08: `/home/worsch/fin-hub` created with hub-core editable
dependency, README/INTENT/SCOPE, pyproject.toml, and passing model smoke tests.

### T23 — Fin-specific models

```task
id: CUST-WP-0025-T23
status: done
priority: low
state_hub_task_id: "8ebffb3f-0dbb-4672-b4e9-928992c41cf4"
```

Define SQLAlchemy models for:
- **Budget**: domain, period, allocated, committed, spent
- **Commitment**: type (subscription/contract/salary), amount, cadence, start/end
- **BurnRate**: domain, period, actual_spend, projected_spend
- **RunwayProjection**: current_balance, monthly_burn, months_remaining, alert_threshold
- **TokenSpend**: provider (anthropic/openai), model, tokens_in, tokens_out, cost, session_id

Completed 2026-07-08: models defined in `fin-hub/src/fin_hub/models/budget.py`
with SQLAlchemy tables `fin_budgets`, `fin_commitments`, `fin_burn_rates`,
`fin_runway_projections`, `fin_token_spends`. Tests pass via `uv run pytest`.

### T24 — Fin-hub implementation: cost tracking + runway

```task
id: CUST-WP-0025-T24
status: done
priority: low
state_hub_task_id: "405f81d3-dec5-4154-a1b8-a3af344a0cc4"
```

Implement:
- Cloud cost ingestion (manual CSV import initially, OpenCost integration later)
- Anthropic API token spend tracking (parse billing exports)
- HostEurope server cost tracking
- Runway calculator with burn-rate projection
- Budget alerts when projected runway drops below threshold

Completed 2026-07-08: fin-hub CLI (`finhub`) with CSV importers for cloud,
Anthropic billing, and HostEurope costs; runway calculator and budget alert
evaluation in `src/fin_hub/services/`; fixture-backed tests pass.

### T25 — Cross-hub coupling: fin-hub connections

```task
id: CUST-WP-0025-T25
status: done
priority: low
state_hub_task_id: "90a41790-7290-4145-b89f-88bf491d7652"
```

Implement FOS §9 cross-hub coupling:
- fin→dev: resource pressure signals (budget alerts surface in dev-hub)
- fin→ops: infrastructure cost attribution (per-service cost view)
- fin→canon: viability alerts (runway below threshold escalates to System 5)

Completed 2026-07-08: `src/fin_hub/coupling/` emits fin→dev resource-pressure
alerts, fin→ops per-service cost reports, and fin→canon viability escalations
via State Hub progress events (`--emit` on `finhub runway`).

### T26 — Pricing and packaging: railiance-as-a-service MVP

```task
id: CUST-WP-0025-T26
status: done
priority: low
state_hub_task_id: "e17ef269-e349-44cc-ab14-6c57b43199b1"
```

Concrete pricing:
- Define 3 tiers with feature matrix
- Create landing page content
- Define onboarding workflow (customer → provisioned k3s + monitoring)
- Legal: GmbH implications, liability, SLA framework
- First customer acquisition strategy

Completed 2026-07-08: `fin-hub/docs/raas-mvp-packaging.md` defines tier matrix,
landing page draft, onboarding workflow, legal/GmbH framework outline, and first
customer acquisition strategy.