the-custodian/docs/hub-ecosystem-capability-bridge.md
codex aab187937b
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 5s
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

91 lines
No EOL
3.1 KiB
Markdown

# 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:**
```json
{
"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
1. **Registry ID is the stable public name** — manifests and catalog rows reference it in JSON metadata.
2. **Catalog rows are dev-lane** — maturity, disputes, requests, WSJF triage live in State Hub.
3. **Manifests are ops-lane** — bootstrap, API consumers, widgets, interaction events live in Core Hub.
4. **Activation does not copy secrets** — API key material stays hash/prefix only in Core Hub.
5. **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)
```text
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