Service Onboarding
July 30, 2026 ยท View on GitHub
This is the end-to-end checklist for bringing a service online in lab.
The current flow is manual wiring plus generated-doc verification. Older docs
referenced labby scaffold service and labby audit onboarding; those commands
are not part of the current CLI surface unless they are restored in code.
cargo check --workspace --all-features
cargo run -p labby --all-features -- docs generate
cargo run -p labby --all-features -- docs check
Required Steps
- Start from the upstream API spec or notes in
docs/upstream-api/. - Add pure client logic and serde types under
crates/lab-apis/src/<service>/. - Add the shared dispatch module under
crates/lab/src/dispatch/<service>/. - Keep CLI, MCP, and HTTP adapters thin; they must call dispatch instead of reimplementing service behavior.
- Register the service in metadata, registry construction, and only the CLI/MCP/API/web surfaces it actually exposes.
- Add a Cargo feature only when the service is an intended standalone product
slice or true
lab-apispassthrough. Do not add one feature per internal module by default. - Add or update
docs/coverage/<service>.mdwhen the service has a coverage contract. - Regenerate docs and run the all-features build/test path before handoff.
Source Documents
- DISPATCH.md owns the shared dispatch-layer contract.
- ERRORS.md owns stable error envelopes and status mapping.
- OBSERVABILITY.md owns logging, correlation, and redaction.
- SCAFFOLD_AND_AUDIT.md records the deferred scaffold/audit contract if those commands are restored.