--- id: CORE-WP-0005 type: workplan title: "Migrate Inter-Hub data and cut over production" domain: infotech repo: core-hub status: active owner: codex topic_slug: custodian created: "2026-06-27" updated: "2026-06-27" state_hub_workstream_id: "a36efc08-5906-40c7-b1de-f3a553ffea02" --- # Migrate Inter-Hub data and cut over production Move production framework responsibility from Haskell Inter-Hub to Core Hub only after compatibility evidence exists. ## Design Migration Path ```task id: CORE-WP-0005-T01 status: done priority: high state_hub_task_id: "01909b75-2229-41e2-a61a-c4c9ef84c232" ``` Result 2026-06-27: Defined and implemented the `core-hub.migration.v1` bundle path with validation, dry-run/import CLI, idempotent framework-record import, row-count reports, relationship diagnostics, non-secret API key handling, persisted `migration_runs`, fixture/schema coverage, and rollback procedure. ## Run Staging Import ```task id: CORE-WP-0005-T02 status: done priority: high state_hub_task_id: "e0ea0928-a3ea-4ece-bbb7-ee08f8a3279b" ``` Import production-safe or full approved Inter-Hub data into Core Hub staging. The importer is ready; this now waits on an approved Inter-Hub export bundle and target staging database. Record counts and discrepancies from the generated migration report. 2026-06-27 continuation: `CORE-WP-0008-T04` added the Core Hub staging deployment profile and migration job/runbook. This task still waits for an approved Inter-Hub export bundle and provisioned staging database before an actual import can run. ## Dual-Run Smokes ```task id: CORE-WP-0005-T03 status: done priority: high state_hub_task_id: "9166afe8-27ef-4345-a7b1-c33f15c90673" ``` Run public and protected smokes against both Inter-Hub and Core Hub. Record compatibility deltas. 2026-06-27 continuation: `CORE-WP-0008` provides the API-first deployed smoke and staging profile that should feed this dual-run gate. ## Production Cutover ```task id: CORE-WP-0005-T04 status: wait priority: high state_hub_task_id: "fa68858a-b18e-4f09-a477-6b11e54099d4" ``` With operator approval, switch production traffic such as `hub.coulomb.social` to Core Hub. Keep rollback available until stabilization passes. **Prerequisites (blocking, found in T03 dual-run 2026-07-02):** 1. **Migrate/seed the ops-* type vocabularies.** Migrated Inter-Hub widgets reference 7 widget types (`ops-endpoint`, `ops-environment`, `ops-host`, `ops-migration-wave`, `ops-readiness-gate`, `ops-service`, `ops-service-catalog`) plus their event types, none of which exist in Core Hub's seeded registries. Either extend the `core-hub.migration.v1` bundle with `widgetTypeRegistry` / `eventTypeRegistry` collections, or seed the ops-* vocabularies into Core Hub before cutover, or migrated widgets are referentially incomplete. 2. **Auth-posture change is a consumer break.** `/api/v2/hubs` is public on Inter-Hub but protected on Core Hub — any anonymous consumer of the hub list must gain a token before cutover. 3. Operator approval + rollback plan (existing gate). **Prerequisite resolutions 2026-07-03:** 1. **Catalog gap — resolved by seeding.** Core Hub's catalogs are static in-code seeds (`seeds.py`), not DB registries, so extending the migration bundle schema was the wrong shape. Seeded the complete Inter-Hub vocabulary instead (23 widget types incl. all 7 orphaned `ops-*` types, 30 event types) as an explicit Inter-Hub-compatibility block; existing Core Hub seeds retained. 22 tests pass. Migrated widgets are referentially complete once the new image ships. 2. **Auth posture — resolved by keeping Core Hub protected.** Consumer audit found only two `/api/v2/hubs` status consumers: `ops-hub/interhub_gate_probe.py` **asserts 401** (it encodes the desired hardened contract and currently fails against Inter-Hub production, which serves 200), and `railiance-forge/tools/gitea-runner-status.sh` is informational. No anonymous consumer depends on a 200. Core Hub's protected listing is therefore an intentional hardening that satisfies the ops-hub gate at cutover; no code change made. ## Progress 2026-07-02 — staging import completed Built the Inter-Hub exporter (`scripts/migration/inter_hub_export.sql`, read-only against the `interhub` DB on net-kingdom-pg) emitting a validated `core-hub.migration.v1` bundle (sha256 `e1b53b7f2d67ef7a…`): 1 hub (`ops-hub`), 1 manifest, 2 api consumers, 8 api keys (prefix+hash only), 15 widgets, 1 interaction event. `migration validate` passed with zero errors/warnings and no secret material. Imported into Core Hub staging via an in-cluster Job (staging DB URL from `core-hub-staging-env` secretKeyRef, bundle via ConfigMap): dry-run `ok=true` (28 would-create), real import created all 28 records with zero errors, and a second run proved idempotency (created=0, updated=28, no duplicates). Server-side confirmed: the imported `ops-hub` hub and its 15 widgets are visible via `/api/v2/*`. T02 done; the staging DB now holds real Inter-Hub data for the T03 dual-run smokes. ## Progress 2026-07-02 — dual-run smokes and compatibility deltas Ran unauthenticated + authenticated probes against both live surfaces via ops-bridge tunnels (Inter-Hub `inter-hub-coulombcore`:18020, Core Hub staging `core-hub-staging-coulombcore`:18010). Status parity table (unauthenticated GET): | Endpoint | Inter-Hub | Core Hub | Note | | --- | --- | --- | --- | | `/healthz`, `/readyz` | 404 | 200 | Core Hub adds liveness/readiness (new capability, not a regression). | | `/api/v2/hubs` | 200 | 401 | **Auth delta**: hub listing is public on Inter-Hub, protected on Core Hub. Anonymous consumers must authenticate against Core Hub. | | `/api/v2/hub-registry` | 401 | 401 | Parity. | | `/api/v2/widget-types`, `event-types`, `annotation-categories`, `policy-scopes` | 200 | 200 | Public-catalog status parity. | | `/api/v2/widgets`, `interaction-events` | 401 | 401 | Parity. | Content/shape deltas: - Catalog record shape differs: Core Hub uses `{name, slug, description}`; Inter-Hub uses `{name, label, description, ownerHubId, status}`. Consumers parsing catalog records need updates for the `slug`-based shape. - **Cutover blocker found**: the migrated Inter-Hub widgets reference 7 widget-type names (`ops-endpoint`, `ops-environment`, `ops-host`, `ops-migration-wave`, `ops-readiness-gate`, `ops-service`, `ops-service-catalog`) that are **absent** from Core Hub's seeded widget-type registry (which has only `Event Stream`, `Status Summary`, `Workplan Board`). The `core-hub.migration.v1` bundle schema (COLLECTIONS) carries widgets but not the `widget_type_registry` / `event_type_registry`, so migrated widgets land referentially incomplete. **Production cutover (T04) must first migrate or seed the ops-* widget-type and event-type vocabularies into Core Hub.** Filed as the top T04 prerequisite. T03 done: compatibility surface is characterized; the auth-hardening delta and the missing-catalog-vocabulary blocker are the two items the cutover decision must account for.