WS-002: Why Runtime and Control Plane are separate hubs¶
| Status | Accepted |
| Date | 2026-08 |
| Sources | product / Control Plane hub CLAUDE.md; series Control Plane terminology |
Context¶
The product needs a deterministic CLI (data plane) and optional fleet governance (control plane): policy distribution, audit collection, catalog, SaaS UI.
Problem¶
If Runtime and Control Plane share one deployable or one repo tree that must always be present, an unavailable portal or API can block engineering work. Teams also couple release cadence and credentials incorrectly.
Decision¶
Two hubs:
| Hub | Core | Promise |
|---|---|---|
| Product | engineering-runtime |
Execute engineering operations; works offline / without Control Plane |
| Control Plane | engineering-runtime-app-api |
Govern a fleet; optional |
Cross-hub integration is CI and published contracts only — never “clone the other hub to build.” Runtime pulls policy and forwards audit; it does not require the Control Plane for local execution.
Alternatives considered¶
| Alternative | Why not |
|---|---|
| One monorepo / one binary with embedded portal | Portal outage or SaaS deps block the CLI |
| Runtime exposes its own HTTP API for governance | Second public contract surface; ownership blur (see WS-003) |
| Control Plane as a required cloud dependency | Breaks Community / laptop-first adoption |
Consequences¶
- “Runtime must keep working if Control Plane is down” is load-bearing
- Catalog and OpenAPI bridges use
workflow_dispatchCI, not local sibling hooks across hubs - Demo/app UIs talk to
api., never invent a second API