core-hub/docs/specs/runtime-absorption-inventory.md
tegwick c7b1ebb560
Some checks failed
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / pytest-smoke (push) Failing after 2s
docs: reconcile core hub state and intent
2026-08-21 08:49:15 +02:00

4.3 KiB

Core Hub runtime absorption inventory

Status: complete for CORE-WP-0010-T01
Reviewed: 2026-08-21

This inventory defines the runtime, contract, data, consumer, and deployment surfaces that a hub-core replacement must preserve. It is an input to the joint absorption plan in HUB-WP-0004; it does not choose hub-core's packaging or port model.

Public and operator contract

The checked-in OpenAPI snapshot documents 22 paths:

Area Paths / behavior to preserve
Discovery /api/v2/hubs, /api/v2/hub-registry, /api/v2/manifests, manifest patch and activation
Credentials /api/v2/api-consumers, /api/v2/api-consumers/{id}/keys, /api/v2/token
Interaction /api/v2/widgets, /api/v2/widget-types, /api/v2/interaction-events
Deferred resources annotation categories/annotations, policy scopes, requirement candidates, decision records, deployment records, outcome signals
Operations /healthz, /readyz, /console

Compatibility discovery also serves /api/v2/openapi.json, /api/v2/openapi.yaml, /api/v2/docs, and historical unprefixed aliases. These must either remain available or have an explicit compatibility gateway.

Durable data

The production schema contains these application tables:

  • hubs
  • hub_capability_manifests
  • api_consumers
  • api_keys
  • widgets
  • interaction_events
  • migration_runs

alembic_version is migration metadata. Annotation, requirement, decision, deployment, and outcome routes currently return empty collections and do not have durable models; absorption must not claim data that does not exist.

Contract and fixture assets

The contracts/ tree is portable compatibility evidence and should move with the runtime or remain versioned as historical fixtures. It includes the OpenAPI snapshot, JSON schemas, catalogs, and consumer fixtures. Database migrations and row-count/replay checks remain owned by the runtime migration slice until hub-core accepts them.

Consumers and smoke gates

  • ops-hub depends on protected hub records and the compatibility OpenAPI paths. Its bootstrap reads or creates hubs, manifests, API consumers, keys, widgets, and interaction events.
  • activity-core depends on health/readiness, widget types, protected hub resolution, and posting then reading back interaction-event evidence.

Both consumer gates must pass against hub-core during dual-run and again after traffic cutover. Core Hub remains the rollback runtime until those checks and data comparisons succeed.

Extension-port mapping

Gen3 port Current Core Hub coverage
Registry partial: hubs and manifests
Addressing partial: hub identity and protected records
Interaction events partial: durable event sink/readback
Projection partial: operator views and compatibility reads
Messaging absent / external
Progress and work absent / external
Repository and schedule absent / external
Telemetry health/readiness only
Policy names/catalog surface only; authorization remains external

This mapping prevents a route-for-route move from being mistaken for complete Gen3 extension absorption.

Deployment and ownership boundary

  • core-hub owns application code, contracts, migrations, image contents, and consumer compatibility evidence.
  • rapp-core-hub owns Helm values/templates, policy and secret references, rollout declaration, and live smoke evidence.
  • railiance-platform / rapp-postgres owns platform PostgreSQL, credential custody, backups, and restore posture.

The Kubernetes manifests checked into this repository describe the former CoulombCore deployment and are retained as source/history evidence. They are not current production deployment truth.

Move constraints

  1. HUB-WP-0004-T03 must decide whether hub-core ships the primary runtime image or a library with a permanently owned host.
  2. HUB-WP-0004-T04 must settle the minimal extension ports before absorption slices are designed.
  3. HUB-WP-0004-T06 and CORE-WP-0010-T02 must jointly define dual-run, traffic shift, rollback, and smoke ownership.
  4. Every durable slice needs schema/row-count comparison and fixture replay.
  5. Repository archive is last: only after public traffic, consumer gates, residual ownership, and rollback retirement are evidenced.