core-hub/workplans/CORE-WP-0005-data-migration-and-cutover.md

id, type, title, domain, repo, status, owner, topic_slug, created, updated, state_hub_workstream_id

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
CORE-WP-0005	workplan	Migrate Inter-Hub data and cut over production	infotech	core-hub	active	codex	custodian	2026-06-27	2026-06-27	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

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

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

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

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.