docs(CORE-WP-0007): point ops-hub extension at Core Hub

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
 

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

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
 

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