4.10.3

Jul 16, 2026 · 3 packages · 7 unique changes · 3 release entries

appsbundles

This release affects the solutions family.

Run contractspec connect adoption resolve --family solutions to see how it impacts your project.

Release summaries

builder-local-onboarding-api-resolution
Fix Builder local onboarding so setup writes usable control-plane defaults and the CLI resolves Builder API settings from workspace config.
maintainer
Builder-local setup now writes control-plane API defaults, doctor checks all Builder presets for missing auth, and the Builder CLI reads `.contractsrc.json` before falling back to the default hosted API.
integrator
Fresh `contractspec init --preset builder-local` workspaces now include the Builder API base URL in both `.contractsrc.json` and VS Code settings, while older local-only configs still work through the hosted API fallback.
can-help-capability-discovery
Add the `can-help` offline capability-discovery surface (CLI command + workspace service) over a two-tier capability corpus.
maintainer
bundle.workspace ships a new `canHelp` service (buildCapabilityCorpus, queryCanHelp, rankCapabilities, vectorize/cosine) that composes the adoption catalog and a local workspace overlay into a two-tier capability corpus and ranks free-text intents with a model-free offline term-vector blended with lexical tag overlap, returning have-it/can-help/gap verdicts. The CLI exposes it as `can-help`/`ask`.
integrator
Consumers and agents can call `contractspec can-help "<intent>" --json` (scope all|local|ecosystem, optional --family) to discover whether ContractSpec already provides a capability before reinventing it. Fully offline; no model or network required.
customer
Teams adopting ContractSpec across many verticals get a guided way to find and reuse existing capabilities instead of rebuilding them, improving velocity and consistency.
stabilize-current-release-artifacts
Stabilize release artifact generation so customer-facing release files stay current-release-only and deterministic.
maintainer
Release builds now default to compact current-release artifacts, while full historical output must be requested explicitly with `--scope all`.
integrator
Tooling that needs full changelog history should consume `generated/releases/history/manifest.json`; current release guidance stays under `generated/releases/*`.
customer
Customer-facing release bundles are smaller and avoid repeatedly rewriting old release entries.

Migration guide

Generate full release history explicitly
Consumers that previously treated `generated/releases/manifest.json` as a full historical changelog should build the history output path.
1. Run `contractspec release build --scope all --output generated/releases/history` before building full changelog surfaces.
2. Keep `generated/releases/*` for current GitHub Release notes, upgrade prompts, and customer AI guidance.

Upgrade steps

Discover ContractSpec capabilities from the CLI
manual
Run `contractspec can-help "<what you want to do>"` (or `contractspec ask ...`) to get a have-it/can-help/gap verdict and the canonical surface to adopt. Add `--json` for agents and CI. No configuration required.
Packages: @lssm-tech/bundle.workspace, @lssm-tech/app.cli-contractspec
Refresh existing builder-local workspace config when convenient
manual
Existing local-only configs keep working through the hosted API fallback, but rerunning init will persist the new API defaults into workspace config.
Packages: @lssm-tech/bundle.workspace, @lssm-tech/app.cli-contractspec
1. Re-run `contractspec init --preset builder-local` if you want the generated `builder.api.baseUrl` and `builder.api.controlPlaneTokenEnvVar` fields written into `.contractsrc.json`.
2. Set the configured control-plane token environment variable before running `contractspec builder` commands.
Keep current release artifacts compact
manual
Use the default release build for current release communication and the explicit history scope only when a full changelog is required.
Packages: @lssm-tech/bundle.workspace, @lssm-tech/app.cli-contractspec, @lssm-tech/app.web-landing, contractspec
1. Run `bun run release:build` for the current release bundle.
2. Run `bun packages/apps/cli-contractspec/src/cli.ts release check --strict --baseline main` after regenerating artifacts.
3. Use `--scope all --output generated/releases/history` for website changelog history builds.

Unique release changes

- Consumers that previously treated `generated/releases/manifest.json` as a full historical changelog should build the history output path.
3 packages · 3 occurrences
- Stabilize release artifact generation so customer-facing release files stay current-release-only and deterministic.
3 packages · 3 occurrences
- Use the default release build for current release communication and the explicit history scope only when a full changelog is required.
3 packages · 3 occurrences
- Add the `can-help` offline capability-discovery surface (CLI command + workspace service) over a two-tier capability corpus.
2 packages · 2 occurrences
- Existing local-only configs keep working through the hosted API fallback, but rerunning init will persist the new API defaults into workspace config.
2 packages · 2 occurrences
- Fix Builder local onboarding so setup writes usable control-plane defaults and the CLI resolves Builder API settings from workspace config.
2 packages · 2 occurrences
- Run `contractspec can-help "<what you want to do>"` (or `contractspec ask ...`) to get a have-it/can-help/gap verdict and the canonical surface to adopt. Add `--json` for agents and CI. No configuration required.
2 packages · 2 occurrences

Impacted packages

@lssm-tech/app.cli-contractspec
Layer: apps · 3 changes
@lssm-tech/app.web-landing
Layer: apps · 3 changes
@lssm-tech/bundle.workspace
Layer: bundles · 3 changes