Bus Services

The modules behind the Services product.

Bus Services has one user-facing product surface, but the implementation is split so CLI behavior, API access, runtime supervision, and provider-specific mechanics stay in the right ownership boundary.

Core modules

Module	Role	What users see
`bus-services`	User-facing CLI and profile client.	`bus services up`, `list`, `down`, validation, planning, and profile discovery.
`bus-api-provider-services`	API-hosted Services lifecycle surface.	Remote or hosted systems can request and inspect service lifecycle actions through a Bus API boundary.
`bus-integration-services`	Runtime integration and local supervision.	Dependency ordering, native process startup, frozen stack state, status, logs, shutdown, and foreground serving.

Provider boundaries

A service id should not encode how the service is powered. The profile declares the runtime kind and provider, then the correct integration module owns the mechanics. PostgreSQL can be a native process, a standard Docker sidecar for a runtime image, or a future managed provider without changing the basic Services workflow.

native services run as local processes supervised by Services.
container services route through the container integration boundary when that provider is enabled.
managed, system, and vm services keep their provider-specific lifecycle outside the generic CLI.

How the modules work together

bus services up
  -> bus-services validates the public stack
  -> bus-integration-services resolves profiles and starts services
  -> provider modules handle runtime-specific mechanics
  -> bus services list reports non-secret status from the state directory

This split is why the same product can support a laptop process stack, a Docker image entrypoint, a dedicated host, and future runtime providers without turning one module into a hard-coded database or container wrapper.