integration.cli-contractspec-builder

@lssm-tech/integration.cli-contractspec-builder

Optional Builder, delivery, control-plane, execution-lane, harness, and intelligence commands for the ContractSpec CLI.

commandPack.register(program) synchronously registers the canonical integration's six command objects and concrete handlers, including for a custom Commander host. The order remains Builder, Builder delivery, control plane, execution lanes, harness, and intelligence. Workspace CLI composition forwards to these same objects; callers do not need to bind action suppliers for this existing entry.

The canonical implementation lives in packages/integrations/cli-contractspec-builder. Builder production execution imports the existing Codex and OpenCode Go adapters from their canonical leaf owners, @lssm-tech/integration.provider-codex and @lssm-tech/integration.provider-opencode-go, so installing this command pack does not pull in the full @lssm-tech/integration.providers-impls provider collection (the /builder-execution collection entry remains available to other callers). Settings, approvals, visibility policy, and runtime authority retain their existing behavior.

Lazy adapters

Registering the pack, rendering help and running commands that execute no adapter never evaluate @lssm-tech/integration.harness-runtime, @lssm-tech/integration.runtime, @lssm-tech/integration.provider-codex or @lssm-tech/integration.provider-opencode-go. Each one loads through a literal dynamic import when a command action needs it: harness eval loads the harness runtime, control-plane commands load the channel runtime, and the Builder production commands, preflight and doctor load the Codex and OpenCode Go providers. Settings resolution loads the Codex provider only to default the model of a configured quality gate that names none. The pack's registration graph also stays clear of @lssm-tech/lib.contractspec-catalog, @lssm-tech/lib.contracts-runtime-server-mcp and @lssm-tech/lib.logger. The adapters remain regular dependencies, so installs and command behavior are unchanged. If an adapter package itself cannot be resolved, the command fails with a BuilderAdapterUnavailableError (code builderAdapterUnavailable) naming the package and the command. Only a not-found error whose unresolved specifier is that package or one of its subpaths is mapped; a missing dependency of an installed adapter and every other load error propagate unchanged.

./commands/builder/production/provider keeps createCodexOpenCodeProviderPort synchronous with both providers imported by that entry, so a fresh port serves every method, including createCompletionReceipt. The Builder commands use ./commands/builder/production/provider-port instead: loadCodexOpenCodeProviderPort loads both providers and builds the same port, and createCodexOpenCodeProviderPortWithAdapters builds it from adapters the caller already holds. resolveOpenCodeCliModel now lives in ./commands/builder/production/preflight next to the other OpenCode model checks.

Portable declarations are available separately from @lssm-tech/lib.cli-runtime/optional-command-declarations/builder. This additive entry creates fresh complete command trees without constructing workspace services. A host using the portable entry supplies actions explicitly through bindHostCommandPackActions; an unbound action rejects with missingHostBinding, while registration and help remain available.

Harness commands consume the canonical scenario and suite registry classes from @lssm-tech/lib.harness/harness/types. Registry identity and approval behavior are unchanged; the command pack no longer declares a direct compatibility-facade dependency.