codex aab187937b

CI Smoke / host-smoke (push) Successful in 0s

Details

CI Smoke / container-smoke (push) Successful in 5s

Details

docs(ecosystem): complete hub stack consolidation (CUST-WP-0057)

Publish ecosystem architecture, event mapping, capability bridge, and async-base
decision docs; add cross-repo regression script; update extraction boundary and
bootstrap status; archive WP-0058 touch-ups.

2026-07-11 01:26:53 +02:00

3.1 KiB

Raw Permalink Blame History

Hub Ecosystem Capability Bridge

Updated: 2026-07-09
Workplan: CUST-WP-0057-T07

Purpose

Map reuse-surface capability IDs to State Hub catalog rows and Core Hub hub_capability_manifests without inventing parallel naming schemes.

Three representations

Representation	Location	Identifier	Purpose
Reuse-surface registry	`registry/capabilities/*.md` + federation index	`capability.<domain>.<name>`	Discovery, maturity, consumer guidance
State Hub catalog	`capability_catalog` table	UUID row + `capability_type` + `title`	Dev workflow, requests, maturity tracking
Core Hub manifest	`hub_capability_manifests` table	UUID row + `body_json`	Inter-Hub `/api/v2` bootstrap, widget activation

These are complementary, not duplicates of the same row.

Worked example: hub stack capabilities

`capability.infotech.hub-core-library`

Field	Value
Registry owner	`hub-core`
State Hub catalog	Optional row with `capability_type=library`, linked to `hub-core` repo
Core Hub manifest	Not required — library is not a deployed hub

`capability.infotech.core-hub`

Field	Value
Registry owner	`core-hub`
State Hub catalog	Row referencing `core-hub` managed repo
Core Hub manifest	Activated manifest for `hubSlug=core-hub` with widgets for ops evidence

Manifest body_json should include:

{
  "reuseSurfaceId": "capability.infotech.core-hub",
  "manifestVersion": "0.1.0",
  "capabilities": []
}

`capability.statehub.workstream-coordinate` (if registered)

Field	Value
Registry owner	`state-hub`
State Hub catalog	Native — describes the dev coordination service
Core Hub manifest	None — state-hub is not an Inter-Hub framework hub

Bridge rules

Registry ID is the stable public name — manifests and catalog rows reference it in JSON metadata.
Catalog rows are dev-lane — maturity, disputes, requests, WSJF triage live in State Hub.
Manifests are ops-lane — bootstrap, API consumers, widgets, interaction events live in Core Hub.
Activation does not copy secrets — API key material stays hash/prefix only in Core Hub.
One reuse-surface ID per deployed hub — ops-hub manifest references capability.infotech.ops-hub (when registered), not the core-hub library ID.

Registration flow (recommended)

1. Author capability.infotech.<name> in repo registry/
2. State Hub: register repo + optional capability_catalog row citing reuseSurfaceId
3. Core Hub: POST /api/v2/hub-capability-manifests with reuseSurfaceId in body
4. Core Hub: activate manifest → widgets → interaction-events for ops evidence
5. reuse-surface federation publish indexes maturity from registry files

Anti-patterns

Using hub-core manifest activation for a library that has no runtime widgets
Creating a second capability ID in manifest JSON that disagrees with reuse-surface
Storing full API keys in State Hub progress or catalog rows

3.1 KiB Raw Permalink Blame History