From 7ac1871f9419ae2323cc71ad18958be417fdbd9a Mon Sep 17 00:00:00 2001 From: tegwick Date: Wed, 8 Jul 2026 12:48:04 +0200 Subject: [PATCH] docs(CORE-WP-0007): point ops-hub extension at Core Hub --- INTENT.md | 17 +++++++++-------- README.md | 7 ++++--- SCOPE.md | 19 +++++++++---------- docs/readiness-gates.md | 4 ++-- 4 files changed, 24 insertions(+), 23 deletions(-) diff --git a/INTENT.md b/INTENT.md index 8c02217..28c2a81 100644 --- a/INTENT.md +++ b/INTENT.md @@ -7,16 +7,17 @@ updated: "2026-06-06" ## Why it exists -`ops-hub` is the Operations / System 1 extension for Inter-Hub. It turns -operational reality into governed, queryable, and evidence-backed hub records: -environments, hosts, clusters, services, endpoints, releases, backups, +`ops-hub` is the Operations / System 1 extension for the interaction framework. +It turns operational reality into governed, queryable, and evidence-backed hub +records: environments, hosts, clusters, services, endpoints, releases, backups, incidents, risks, runbooks, readiness gates, and migration waves. It exists because Railiance and HelixForge operations need a durable -operational truth surface while the current CoulombCore environment transitions -toward the ThreePhoenix production shape. State Hub continues to own -workstreams and decisions; Inter-Hub continues to own the generic hub substrate. -`ops-hub` owns the operations extension behavior built on top of that substrate. +operational truth surface while the fleet transitions toward railiance01 +production. State Hub continues to own workstreams and decisions; **Core Hub** +owns the production framework API (`hub.coulomb.social` since 2026-07-03). +Historical Haskell Inter-Hub lives in `inter-hub-haskell` (retired). `ops-hub` +owns the operations extension behavior and posts evidence to Core Hub. ## Governing principle @@ -25,7 +26,7 @@ authority, ownership boundaries, or operational promises should be captured in a workplan before implementation. The first implementation rule is: domain-specific runtime code belongs here, -while generic hub framework behavior belongs in `inter-hub`. +while generic hub framework behavior belongs in Core Hub. ## What it enables diff --git a/README.md b/README.md index 7f2a5eb..75ed6d6 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,7 @@ -Operations / System 1 extension for Inter-Hub. +Operations / System 1 extension for Core Hub. `ops-hub` is the operational truth surface for environments, hosts, clusters, services, endpoints, releases, backups, incidents, risks, runbooks, readiness -gates, and migration waves. Generic hub framework work stays in `inter-hub`; -operations-specific extension code belongs here. +gates, and migration waves. Generic hub framework work stays in `core-hub`; +operations-specific extension code belongs here. Historical Haskell Inter-Hub is +`inter-hub-haskell` (retired 2026-07-08). diff --git a/SCOPE.md b/SCOPE.md index 7d0adf3..5777e5b 100644 --- a/SCOPE.md +++ b/SCOPE.md @@ -2,33 +2,32 @@ ## One-liner -Operations / System 1 extension for Inter-Hub, focused on operational truth, +Operations / System 1 extension for Core Hub, focused on operational truth, readiness evidence, and migration gates. ## Core Idea -`ops-hub` is a domain-specific Inter-Hub extension. It should professionalize +`ops-hub` is a domain-specific Core Hub extension. It should professionalize operations by making environments, hosts, clusters, services, endpoints, releases, backups, incidents, risks, runbooks, readiness gates, and migration waves explicit and evidence-backed. -The repo is intentionally separate from `inter-hub`: generic framework and API -substrate work remains in `inter-hub`; operations-specific collectors, -adapters, probes, bootstrap clients, UI/extensions, tests, and packaging belong -here. +The repo is intentionally separate from Core Hub: generic framework and API +substrate work remains in `core-hub`; operations-specific collectors, adapters, +probes, bootstrap clients, UI/extensions, tests, and packaging belong here. ## In Scope - Operations hub implementation code and tests. - Ops vocabulary clients, collectors, adapters, and scheduled probes. -- Inter-Hub bootstrap/smoke tooling for the `ops-hub` extension. +- Core Hub bootstrap/smoke tooling for the `ops-hub` extension. - Operations service catalog, readiness, migration, endpoint, backup, restore, incident, and runbook models. - Repo-local workplans for growing the Operations / System 1 extension. ## Out of Scope -- Generic Inter-Hub framework behavior, API substrate, authentication, or +- Generic Core Hub framework behavior, API substrate, authentication, or registry semantics. - State Hub workstream, task, decision, or progress implementation. - Railiance infrastructure, cluster, platform, enablement, or app desired state. @@ -41,8 +40,8 @@ here. - Status: production bootstrap complete (2026-07-07). - Implementation: Python package under `src/ops_hub/`, operator scripts, seeds, tests, and Makefile targets for gate probe and attended bootstrap. -- Inter-Hub: `ops-hub` hub, active manifest, seed widgets, and first - `ops-endpoint-verified` event are live in production. +- Core Hub: `ops-hub` hub, active manifest, seed widgets, and + `ops-endpoint-verified` events post to production Core Hub. ## Getting Oriented diff --git a/docs/readiness-gates.md b/docs/readiness-gates.md index 8af8326..a5f9301 100644 --- a/docs/readiness-gates.md +++ b/docs/readiness-gates.md @@ -29,11 +29,11 @@ Statuses: | OPS-G08 | Secrets path is governed | `railiance-infra` / `railiance-apps` | SOPS/age keys and operator secret paths are documented; no required secret depends on shell memory. | `partial` | | OPS-G09 | Cluster runtime is reproducible | `railiance-cluster` | Kubernetes runtime, ingress, CNI, operators, and routing primitives are recreated through repo-owned automation. | `unknown` | | OPS-G10 | Platform services are reproducible | `railiance-platform` | PostgreSQL/CNPG, object storage, secret management, and identity dependencies have repo-owned deployment evidence. | `unknown` | -| OPS-G11 | Application deployment is reproducible | `railiance-apps` | Gitea, Inter-Hub, State Hub, and other application releases are declared with Helm values and deployment runbooks. | `partial` | +| OPS-G11 | Application deployment is reproducible | `railiance-apps` | Gitea, Core Hub, State Hub, and other application releases are declared with Helm values and deployment runbooks. | `partial` | | OPS-G12 | Rollback path is documented | owning service repos | Each migration wave has rollback conditions, steps, and data safety notes. | `unknown` | | OPS-G13 | Operator runbooks exist | owning service repos | Deploy, restore, rotate, incident response, and migration runbooks exist for each critical service. | `unknown` | | OPS-G14 | Observability and health checks are explicit | `railiance-cluster` / `railiance-platform` / service repos | Health checks, logs, metrics, and endpoint probes are documented and tied to service catalog entries. | `unknown` | -| OPS-G15 | Inter-Hub ops bootstrap is available | `inter-hub` / `ops-hub` / `helix-forge` | `ops-hub` can be created through UI, supported API, or explicit migration fallback, manifest activated, API consumer/key created, widgets seeded, and events accepted. | `partial` | +| OPS-G15 | Core Hub ops bootstrap is available | `core-hub` / `ops-hub` | `ops-hub` evidence posts to Core Hub; manifest, API consumer, widgets, and interaction events verified in production. | `ready` | ## Initial Migration Waves