6.3.0

Apr 29, 2026 · 49 packages · 87 unique changes · 25 release entries

appsbundlesintegrationslibsmodulesBreaking changes

Release summaries

adoption-engine-and-authoring-targets
Add a family-aware ContractSpec Adoption Engine, expand contract authoring targets across CLI and VS Code tooling, and refresh release-facing schema and policy artifacts for downstream workspaces.
maintainer
Maintainers get a shared adoption catalog and resolver, Connect adoption hooks, MCP exposure for reuse decisions, expanded authoring-target coverage, and updated static policy artifacts.
integrator
Integrators can resolve existing workspace or ContractSpec OSS surfaces before adding new implementations, and can scaffold more contract families from the CLI and VS Code extension.
customer
Customer workspaces gain setup-managed adoption guidance, Connect `adoption sync/resolve` flows, stronger runtime-import and deprecated-monolith guardrails, and updated bundled schemas in the published CLI entrypoint.
builder-v3-control-plane-rollout
Introduce the Builder v3 control plane as a governed authoring layer over external execution providers.
maintainer
Builder v3 now has a governed contract, runtime, and provider surface that keeps authoring, readiness, and export orchestration aligned across the package stack.
integrator
Integrators can compose managed, local, and hybrid runtime modes with Builder workbench/mobile-review modules and provider adapters for Codex, Claude Code, Gemini, Copilot, STT, and local models.
customer
Builder operators now get a unified workbench and mobile-review experience across provider routing, readiness, export approval, and omnichannel control flows.
byok-monorepo-env-config
Add first-class monorepo-aware environment contracts and managed/BYOK credential setup helpers.
integrator
Monorepos can declare logical environment variables once and materialize framework-specific aliases such as NEXT_PUBLIC_* and EXPO_PUBLIC_* per app target.
maintainer
Integration specs can expose managed/BYOK credential manifests while runtime reports redact secret and sensitive values.
customer
BYOK setup can be validated from shared contracts without placing raw secrets in specs, docs, reports, or generated env examples.
connect-spec-alignment-april-2026
Implement ContractSpec Connect as a first-class spec, runtime, and CLI workflow.
maintainer
Connect is now a governed repo surface with CLI commands, workspace services, and versioned docs that keep risky edits, review packets, and replay artifacts aligned.
integrator
Integrators can enable `.contractsrc.json > connect`, emit local context/plan/verdict artifacts, and route adapter-facing review or replay flows through the shared workspace services.
agent
Coding-agent surfaces now have a first-class Connect workflow for context packs, plan packets, mutation verdicts, review packets, and replay/eval evidence instead of relying on ad hoc governance prose.
contract-dx-first-slice
Improve app-config, theme, and feature authoring with explicit validation APIs, first-class theme discovery and scaffolding, and key-based app-config generation across contracts, workspace tooling, and the CLI.
maintainer
Maintainers can rely on authored validators for app-config, theme, and feature specs instead of shallow per-surface checks, and can scaffold theme specs directly from the CLI.
integrator
Integrators get a stable `defineTheme` authoring path, new theme and feature validation helpers, and key-based app-config DTOs and templates across shared tooling.
customer
CLI users can now run `contractspec create theme`, and validation catches more app-config, theme, and feature mistakes before publish or CI promotion.
contracts-spec-root-crypto-surface
Remove avoidable Node crypto imports from ContractSpec runtime surfaces and keep signing helpers isolated.
integrator
Browser and Next.js consumers can use workflow, telemetry, experiments, root, and broad control-plane surfaces without static Node crypto imports.
contractspec-i18n-runtime
Add a ContractSpec-native production-grade translation runtime and optional i18next adapter.
maintainer
Translation specs now keep stable bundle identity separate from locale variants while the runtime owns formatter-backed ICU resolution, fallback chains, overrides, diagnostics, async loading, SSR snapshots, and optional downstream i18next projection.
integrator
Integrators should use the production translation runtime for server, React, React Native, and CLI resolution, and use the i18next subpath only as a downstream adapter with caller-owned ICU formatting configuration.
customer
Multilingual surfaces can now rely on BCP 47 locale variants, ICU formatting, deterministic SSR snapshots, and safer migration away from locale-suffixed translation bundle keys.
data-table-overflow-policy
Add contract-driven overflow behavior and typed DataView hints for shared DataView and DataTable surfaces.
maintainer
DataView contracts, renderers, scaffolds, and docs now expose overflow hints and typed data hints end-to-end, from spec authoring through table rendering and generated starter files.
integrator
OSS consumers can specify `overflow` on DataView fields or table columns, while the CLI and workspace scaffolds emit the new shape and richer format/filter metadata.
customer
Published data-view docs now describe overflow behavior, expansion mode, and generated table defaults more concretely.
data-views-collection-readiness
Add production-ready collection defaults and renderer mode switching for DataView list, grid, and table specs.
maintainer
DataView collection specs now share view-mode, toolbar, pagination, and density defaults under view.collection.
integrator
DataViewRenderer can switch among allowed list, grid, and table projections while preserving existing specs and caller-controlled props.
customer
Generated data-view screens can expose modern list/grid/table switching, search, filters, pagination, and density controls.
data-views-personalization-integration
Add preference-aware DataView collection defaults and personalization adapters.
maintainer
DataView contracts now expose neutral data-depth and collection personalization hints while keeping contracts-spec independent from personalization runtime code.
integrator
Apps can resolve preferred DataView mode, density, and data depth through personalization helpers and pass plain props to web/native DataViewRenderer.
customer
Collection screens can remember or infer list/grid/table mode and compact/detail preferences without duplicating DataView specs.
forms-autocomplete-combobox
Improve FormSpec autocomplete rendering and resolver-backed search.
maintainer
FormSpec autocomplete docs now describe local and resolver-backed authoring without adding transport fields to the contract.
integrator
React FormSpec autocomplete resolvers receive query, dependency values, field name, and AbortSignal args while stale responses are ignored.
customer
Contract-rendered autocomplete fields now use an accessible editable combobox on web and show loading, empty, error, and selected states more reliably.
forms-email-field
Add first-class FormSpec email fields with native renderer affordances.
maintainer
Maintainers can declare single-address email inputs with `kind: "email"` while keeping validation in the form model.
integrator
Integrators get native email input attributes through the existing form renderer driver slots without adding an EmailInput slot.
customer
Contract-driven email fields now use email keyboards, autofill, and browser email input behavior by default.
forms-layout-input-groups
Add FormSpec layout hints, semantic field rendering, and portable text/textarea input-group addons.
maintainer
Maintainers can express richer FormSpec layout and field chrome without embedding renderer-specific UI.
integrator
Integrators can render contract forms with semantic legends, descriptions, errors, grid rows, colspans, and input addons through driver slots.
customer
Contract-driven forms can now present dense multi-column layouts and input adornments while preserving accessible field semantics.
forms-numeric-temporal-fields
Add numeric and temporal FormSpec field kinds with shared renderer support for number, percent, currency, and duration inputs.
maintainer
FormSpec contracts and examples can now declare numeric and temporal field-specific formatting metadata without bespoke renderer code.
integrator
Custom form drivers can implement `NumberField`, `PercentField`, `CurrencyField`, and `DurationField` slots, while older drivers fall back to standard inputs.
customer
Contract-driven forms can now express budgets, completion ratios, currency amounts, and durations with consistent metadata and shared rendering defaults.
forms-password-rendering
Add password-aware FormSpec rendering with current/new password manager hints and visibility toggles.
maintainer
Maintainers can declare current and new password fields as additive FormSpec text metadata.
integrator
Integrators can render password fields through an optional driver slot while older drivers fall back to masked inputs.
customer
Contract-driven password forms now mask values, expose a visibility toggle, and provide password-manager autocomplete hints.
forms-progressive-layout
Add progressive FormSpec section and step layout metadata with shared React and design-system rendering support.
maintainer
Maintainers can declare progressive form sections or steps as additive FormSpec layout metadata while keeping the field list canonical.
integrator
Integrators can render long contract-driven forms through shared section or step layouts without custom per-form wrappers.
customer
Long forms can now be split into scannable sections or progressive steps, improving completion ergonomics without changing submitted data.
formspec-layout-scoped-filters
Add mobile-safe FormSpec layout helpers and scoped DataView filters.
maintainer
Maintainers can add mobile-safe FormSpec layout metadata and first-class scoped filter contracts without breaking existing numeric layout semantics.
integrator
Integrators can reuse one DataView contract for generic and restricted list/search screens while locked filters stay out of user-editable URL state.
customer
Contract-driven forms can opt into mobile-safe layouts, and scoped listings now show non-removable locked filter chips by default.
harness-browser-verification
Add OSS harness CLI verification with deterministic Playwright, optional agent-browser visual runs, auth profile refs, visual diff evidence, replay bundles, and core scenario success semantics.
maintainer
Harness scenarios now support typed browser actions, auth profile refs, visual-diff assertions, setup/reset hook execution, required evidence enforcement, success rules, and a shared CLI runtime used by both `contractspec harness eval` and `contractspec connect eval`.
integrator
Integrators can run OSS full-app verification locally or in CI with Playwright, agent-browser, or both, while writing replay bundles and browser evidence under `.contractspec/harness`.
customer
Browser, authenticated, and visual app flows can now be verified with replayable evidence before accepting provider or agent-generated work.
notification-library-shell
Move notifications to library-first contracts/runtime surfaces and add AppShell in-app notification affordances.
maintainer
Notification contracts now live in contracts-spec, reusable notification helpers live in lib.notification, and the old module remains as a compatibility shim.
integrator
Applications can adopt the new library imports without breaking existing module imports, then wire AppShell notification state through props.
phone-number-field-support
Add first-class FormSpec phone input support with country detection, split outputs, and flag rendering.
maintainer
FormSpec phone contracts now expose input, output, country, and display configuration while keeping the schema-owned value model backward compatible.
integrator
Host renderers can set phone defaults through `createFormRenderer({ phone })`, while individual FormSpecs can choose object, E.164, or split linked outputs.
customer
Form-rendered phone fields can show country flags, detect countries from international input, and keep single or split controls synchronized.
pwa-update-management
Add PWA update management contracts and runtime helpers.
integrator
App developers can define PWA release policy once, override it per release, and consume a standard update-check API from the frontend.
maintainer
Maintainers get typed contracts, registry helpers, server evaluation helpers, and React prompt state helpers for PWA update workflows.
roles-permissions-rbac-policy-system
Add a shared roles and permissions policy system across contracts, RBAC evaluation, AppShell adaptation, and personalization suppression.
maintainer
Contract authors can declare shared static policy requirements while RBAC providers evaluate static, dynamic, and hybrid workspace-scoped grants.
integrator
AppShell navigation and personalization adapters can consume runtime policy decisions without becoming enforcement authorities.
customer
Workspace applications can hide or disable unauthorized navigation and avoid promoting denied fields while server-side policy decisions remain authoritative.
theme-tailwind-bridge
Add ThemeSpec light/dark modes and a design-system Tailwind bridge for CSS variables, presets, CSS text, and OKLCH color pass-through.
maintainer
Maintainers can keep ThemeSpec as the source of truth while exposing Tailwind variables and runtime theme modes from the design-system package.
integrator
Integrators can resolve ThemeSpec tokens for light or dark mode, consume a Tailwind preset, or serialize CSS text without adding a required generation step.
customer
Product surfaces can use ThemeSpec-backed light/dark themes with OKLCH colors while keeping existing Tailwind semantic classes such as `bg-primary` and `text-foreground`.
typed-result-system
Add a canonical typed result system for ContractSpec success and failure propagation across operations, workflows, jobs, server adapters, MCP, GraphQL, and React clients.
maintainer
Maintainers can declare operation, workflow, and job result catalogs and have runtime registries enforce custom success and failure outcomes.
integrator
Integrators get consistent result mapping for REST, NextResponse, Nest-compatible filters/interceptors, GraphQL extensions, MCP tool errors, and React client parsing.
customer
Product surfaces can rely on consistent success metadata, retry hints, field issues, and Problem Details-style errors across API, job, workflow, and frontend boundaries.
versioning-release-system
Add versioning-backed release capsules, generated patch notes, and guided upgrade flows.
maintainer
Release communication is now generated from versioning-backed release capsules and enforced on release branches.
integrator
Guided upgrade plans and agent prompts now come from generated upgrade manifests instead of ad hoc prose.
customer
Web changelog consumers can prefer generated release manifests while older package changelogs remain supported as fallback.

Deprecations

- `FieldSpec.wrapper.orientation` remains supported but should be replaced by `FieldSpec.layout.orientation` in new specs.
- Prefer `ContractSpecError`, `createContractError`, and `contractFail` from `@contractspec/lib.contracts-spec/results`; `@contractspec/lib.error` remains as a compatibility bridge for existing `AppError` users.
- The `@contractspec/module.notifications` package remains import-compatible for this release, but new code should import contracts from `@contractspec/lib.contracts-spec/notifications` and runtime helpers from `@contractspec/lib.notification`.
- The standalone release domain under `@contractspec/lib.contracts-spec/release` is deprecated in favor of versioning-owned release metadata.

Migration guide

Enable the new Connect adoption engine in workspace config
ContractSpec workspaces can now opt into family-aware reuse guidance and local catalog sync through `connect.adoption`.
When: When a workspace uses `contractspec init --preset connect`, Connect hooks, or custom `.contractsrc.json` management.
1. Add or review `.contractsrc.json > connect.adoption`.
2. Run `contractspec connect adoption sync --json` to mirror the local catalog.
3. Route uncertain reuse decisions through `contractspec connect adoption resolve --family <family> --stdin`.
Use the expanded authoring-target surface in CLI and VS Code flows
Shared workspace discovery and IDE/CLI create flows now recognize additional contract families beyond the original core set.
When: When using `contractspec create`, VS Code create commands, or custom authoring-target integrations.
1. Use the new create targets for capability, policy, translation, visualization, job, agent, product-intent, harness scenario, and harness suite scaffolds where appropriate.
2. Update any custom file-name or directory assumptions to rely on shared authoring-target helpers instead of hard-coded extensions.
Enable ContractSpec Connect in the workspace config
Turn on the Connect adapter flow before relying on task-scoped context, review, replay, or evaluation artifacts.
When: When a workspace wants coding-agent gating, local review packets, or replay/eval evidence tied to file and command mutations.
1. Add or merge a `connect` section in `.contractsrc.json` with `enabled: true` and the storage paths that should hold Connect artifacts.
2. Route risky edits or shell execution through `contractspec connect plan` and `contractspec connect verify` so decisions, review packets, and replay bundles are captured.
3. Use the generated docs and exported agentpacks metadata so downstream agent tooling sees the same Connect contract surface as the CLI.
Update custom app-config DTO callers to key-based refs
Shared app-config authoring DTOs and templates now use `key`-based spec references instead of older `name`-based helper fields.
When: When custom tooling imports `AppBlueprintSpecData`, `AppConfigMappingData`, or related route reference DTOs from workspace or bundle packages.
1. Replace `name` fields with `key` for app-config spec references.
2. Replace `guardName` and `experimentName` with `guardKey` and `experimentKey` in route DTOs.
3. Keep versions as semver strings rather than numeric literals.
Adopt `defineTheme(...)` for new theme specs
Theme authoring now has a canonical helper and authored-validator support.
When: When creating or refreshing theme specs used by generators, docs, or CI validation.
1. Import `defineTheme` from `@contractspec/lib.contracts-spec/themes`.
2. Prefer `defineTheme({...})` for new theme specs, while keeping existing `ThemeSpec` object literals valid.
3. Add `validateThemeSpec` or `assertThemeSpecValid` to CI or publish-time checks where theme correctness matters.
Import control-plane skill signing helpers from direct subpaths
Required
Replace broad root or `control-plane` imports for signing and verification helpers with `@contractspec/lib.contracts-spec/control-plane/skills`, `/signer`, or `/verifier`.
Review sticky experiment bucket assignment changes
Required
Sticky experiment variants may rebucket because the evaluator now uses a browser-safe deterministic hash instead of Node SHA-256.
Separate stable bundle keys from locale variants
Prefer `meta.key: "bundle.messages"` with `locale: "fr-FR"` over stable keys that encode locale suffixes.
1. Move locale identity into `TranslationSpec.locale`.
2. Keep fallback declarations on locale variants through `fallback` or `fallbacks`.
3. Re-run translation validation after migration.
Configure ICU formatting when rendering through i18next
The i18next adapter exports ContractSpec ICU messages intact and does not make i18next canonical.
1. Import adapter helpers from `@contractspec/lib.translation-runtime/i18next`.
2. Initialize a caller-owned i18next instance with generated resources and `keySeparator: false`.
3. Configure an ICU-capable i18next format plugin before rendering ICU plural/select/selectordinal messages through i18next.
Add explicit overflow behavior where defaults are not enough
Existing tables keep working, but long prose, markdown, and detail-heavy columns can now declare their intended behavior.
When: When a table column needs wrapping, row-expansion detail, initial hiding, or unmodified rendering.
1. Set `overflow` on `DataViewField` for behavior shared by every table using that field.
2. Set `overflow` on `DataViewTableColumn` when a specific table needs to override the field default.
3. Use `expand` for compact rows with full detail in row expansion, and `hideColumn` for low-priority columns that should start hidden when column visibility is enabled.
Keep existing text email fields as-is
Existing `kind: "text"` fields with email input hints continue to render normally.
1. No migration is required for existing text fields.
2. Prefer `kind: "email"` for new single-address email fields.
Keep email validation in the model
`kind: "email"` only describes rendering intent; strict validation remains schema-owned.
1. Use `z.string().email()` or the existing schema email scalar for email format validation.
Keep existing forms as-is
Existing forms render exactly as before unless they opt into `layout.flow`.
1. No migration is required for forms without `layout.flow`.
Use FormSpec layout hints for dense forms
New multi-column forms should use `FormSpec.layout`, `group.layout`, and `field.layout.colSpan`.
1. Add `layout.columns` at form or group level.
2. Use `field.layout.colSpan` for fields that should expand across columns.
Use input-group addons for text fields
New input addons should use `inputGroup.addons` on text and textarea fields.
1. Add `inputGroup.addons` to text or textarea field specs.
2. Resolve icon keys in the host driver through the `InputGroupIcon` slot.
Use dedicated numeric field kinds instead of generic text inputs
New field kinds provide stronger semantics and formatting metadata for finance and operations forms.
1. Replace ad hoc numeric `text` fields with `number`, `percent`, `currency`, or `duration` where the schema intent is known.
2. Set `format` metadata when locale, precision, currency display, or duration display needs to be explicit.
Keep existing text fields as-is
Existing text fields and custom driver slots remain compatible.
1. No migration is required for non-password text fields.
Mark password fields explicitly
Prefer `text.password.purpose` for password fields instead of renderer-specific `uiProps.type`.
1. Use `password: { purpose: "current" }` for existing-password entry.
2. Use `password: { purpose: "new" }` for new-password creation or reset fields.
Add section or step flow metadata to long forms
Use `layout.flow.sections` to group existing fields by immediate field name.
1. Add `layout.flow.kind: "sections"` when all sections should remain visible.
2. Add `layout.flow.kind: "steps"` when the renderer should show one section at a time.
3. Keep field definitions in `FormSpec.fields` and reference them through section `fieldNames`.
Keep existing numeric layouts as-is
Existing `layout.columns: 2` contracts continue to render as base two-column layouts.
1. No migration is required for existing numeric column specs.
2. Use `responsiveFormColumns(...)` in new specs that should collapse to one mobile column.
Move fixed list constraints into DataView filter scope
Use `view.filterScope.locked` for non-removable list constraints such as category-scoped posts.
1. Keep user-editable filter definitions in `view.filters`.
2. Put removable defaults in `view.filterScope.initial`.
3. Put non-removable constraints in `view.filterScope.locked`.
Prefer library-first notification imports
Move new notification integrations away from the module shim.
1. Import notification contracts from `@contractspec/lib.contracts-spec/notifications`.
2. Import notification schema contribution, channels, templates, and i18n helpers from `@contractspec/lib.notification`.
3. Keep existing `@contractspec/module.notifications` imports during migration when consumers need the legacy schema contribution module id.
Connect AppShell notifications through host state
Provide notification items and callbacks to the design-system shell without coupling it to a delivery runtime.
1. Pass the `notifications` prop to `AppShell` with items, unread count, and mark-read callbacks.
2. Resolve live delivery, persistence, and subscriptions in the host app or runtime package.
3. Use the native shell entrypoint for Expo surfaces so the same notification state appears through the native header/menu affordance.
Adopt the PWA update-check contract
Register the PWA update operation, bind it to a manifest resolver, and call it from the frontend on startup or polling intervals.
1. Define a PWA app manifest with `defaultUpdatePolicy` and release entries.
2. Add per-release `updatePolicy` overrides when a release must be optional, required, or disabled.
3. Bind `createPwaUpdateCheckHandler` to the `pwa.update.check` operation.
4. Use `usePwaUpdateChecker` in the frontend and keep service worker activation inside the host app callback.
Adopt shared PolicyRequirement metadata incrementally
Existing policies continue to work; add roles, permissions, policy refs, and field policies when a contract needs stronger authorization metadata.
1. Import shared policy requirement types from `@contractspec/lib.contracts-spec/policy` when authoring reusable contract metadata.
2. Keep server/runtime `ctx.decide` or RBAC evaluation as the source of enforcement authority.
3. Pass evaluated decisions to AppShell and personalization helpers only for UX adaptation and suppression.
Prefer contracts-spec result primitives for new error handling
Replace new uses of `AppError` with `ContractSpecError` or `contractFail`; existing `AppError` consumers can convert to a compatible problem shape with `appErrorToProblem`.
1. Import new result helpers from `@contractspec/lib.contracts-spec/results`.
2. Keep existing `AppError` consumers until they are touched for feature work.
3. Use `appErrorToProblem` when a compatibility conversion is needed.
Add .release.yaml companions for changesets
Published release changesets now require a structured release capsule.
When: When preparing release branches, publish workflows, or release communication bundles.
1. Create `.changeset/<slug>.release.yaml` next to each published changeset.
2. Record customer impact, migration notes, validation commands, and evidence in the release capsule.
3. Run `contractspec release build` before `contractspec release check --strict`.

Upgrade steps

Wire adoption-aware Connect hooks in consumer environments
assisted
The consumer plugin and Connect CLI now expose adoption-aware hook events in addition to contracts-spec review hooks.
Packages: @contractspec/lib.contracts-spec, @contractspec/module.workspace, @contractspec/bundle.workspace, @contractspec/bundle.library, @contractspec/app.cli-contractspec, vscode-contractspec, contractspec, @contractspec/lib.knowledge, @contractspec/biome-config, @contractspec/app.cursor-marketplace
1. Install or reference the `contractspec-adoption` marketplace/plugin assets where Connect hooks are consumed.
2. Use `contractspec connect hook adoption before-file-edit|before-shell-execution|after-file-edit --stdin` in host hook wiring.
Prefer higher-level runtime package entrypoints in imports
manual
Generated Biome policy artifacts now flag deprecated monolith usage and obvious deep runtime entrypoint imports.
Packages: @contractspec/lib.contracts-spec, @contractspec/module.workspace, @contractspec/bundle.workspace, @contractspec/bundle.library, @contractspec/app.cli-contractspec, vscode-contractspec, contractspec, @contractspec/lib.knowledge, @contractspec/biome-config, @contractspec/app.cursor-marketplace
1. Replace `@contractspec/lib.contracts` imports with `@contractspec/lib.contracts-spec` plus the appropriate split runtime package.
2. Prefer package-level runtime entrypoints such as `@contractspec/lib.contracts-runtime-server-mcp` when they already expose the required surface.
Adopt the Builder v3 control-plane packages
assisted
Wire provider/runtime integrations through the governed Builder v3 workbench and mobile-review surfaces.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.builder-spec, @contractspec/lib.provider-spec, @contractspec/lib.builder-runtime, @contractspec/lib.mobile-control, @contractspec/lib.provider-runtime, @contractspec/module.builder-workbench, @contractspec/module.mobile-review, @contractspec/integration.runtime, @contractspec/integration.runtime.managed, @contractspec/integration.runtime.local, @contractspec/integration.runtime.hybrid, @contractspec/integration.builder-telegram, @contractspec/integration.builder-voice, @contractspec/integration.builder-whatsapp, @contractspec/integration.provider.codex, @contractspec/integration.provider.claude-code, @contractspec/integration.provider.gemini, @contractspec/integration.provider.copilot, @contractspec/integration.provider.stt, @contractspec/integration.provider.local-model
1. Install the Builder v3 contracts and runtime packages alongside the provider integrations you intend to expose in the authoring surface.
2. Use the Builder workbench and mobile-review modules as the host UI surfaces instead of building separate readiness or export orchestration shells.
3. Validate managed, local, and hybrid runtime mode selection plus provider routing before promoting the control-plane workflow to operators.
Declare logical env variables before framework aliases
assisted
Use workspace environment definitions and app targets instead of duplicating public env names across apps.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.contracts-integrations, @contractspec/integration.runtime, @contractspec/bundle.workspace
1. Define shared logical variables under `.contractsrc.json > environment.variables`.
2. Add app targets for each package/framework that needs concrete aliases.
3. Keep secret values behind `secretRef` or environment/secret providers.
Adopt the Connect CLI workflow
manual
Use the built-in Connect commands instead of custom local wrappers for risky file or command mutations.
Packages: @contractspec/lib.contracts-spec, @contractspec/bundle.workspace, @contractspec/app.cli-contractspec, @contractspec/bundle.library, agentpacks
1. Initialize the workspace with `contractspec connect init --scope workspace`.
2. Use `contractspec connect context`, `plan`, and `verify` to capture task context and mutation verdicts before edits or shell execution.
3. Keep replay and evaluation artifacts under `.contractspec/connect/` so review and audit flows can consume the same evidence bundle.
Use the authored validators for contract setup and CI
assisted
Prefer the package-level validators over shallow AST checks for the three upgraded surfaces.
Packages: @contractspec/lib.contracts-spec, @contractspec/module.workspace, @contractspec/bundle.workspace, @contractspec/app.cli-contractspec
1. Use `validateBlueprint` or `assertBlueprintValid` for app-config specs.
2. Use `validateThemeSpec` or `assertThemeSpecValid` for theme specs.
3. Use `validateFeatureSpec` or `assertFeatureSpecValid` for feature specs before registry installation or release review.
Adopt the new theme authoring target across workspace tools
manual
Shared workspace discovery and the CLI now treat `theme` as a first-class authored surface.
Packages: @contractspec/lib.contracts-spec, @contractspec/module.workspace, @contractspec/bundle.workspace, @contractspec/app.cli-contractspec
1. Use `.theme.ts` files and `defineTheme(...)` for new theme specs.
2. Update any custom create flows or discovery logic to include the `theme` authoring target where needed.
Adopt the ContractSpec translation runtime for production surfaces
manual
Use runtime instances or snapshots instead of legacy simple string interpolation for production i18n paths.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.translation-runtime, @contractspec/lib.design-system, @contractspec/example.locale-jurisdiction-gate
1. Build runtime instances from canonical `TranslationSpec[]` catalogs.
2. Create one runtime per SSR request and hydrate clients from serialized snapshots.
3. Keep React, React Native, and i18next integrations downstream from the runtime.
Re-run focused table overflow verification after upgrading
assisted
The contract, runtime, web, native, design-system, CLI, and workspace layers all participate in overflow behavior.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.presentation-runtime-core, @contractspec/lib.presentation-runtime-react, @contractspec/lib.ui-kit-web, @contractspec/lib.ui-kit, @contractspec/lib.design-system, @contractspec/module.workspace, @contractspec/bundle.workspace, @contractspec/app.cli-contractspec, @contractspec/bundle.library
1. Run the focused data-view and data-table test suites for contracts-spec, presentation-runtime-react, ui-kit-web, ui-kit, and design-system.
2. Run typecheck and lint checks for the touched libraries, CLI, and workspace packages.
Add optional collection defaults to collection DataView specs
assisted
Existing specs keep working; add view.collection when a renderer should expose shared collection controls or query page-size defaults.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.design-system, @contractspec/module.workspace, @contractspec/bundle.workspace, @contractspec/app.cli-contractspec, @contractspec/bundle.library
1. Add view.collection.viewModes to declare allowed list/grid/table projections.
2. Add view.collection.pagination.pageSize when query generation should use a contract default.
3. Keep table view.density where already used; it remains a permanent compatibility alias.
Resolve personalized DataView defaults in the host app
assisted
Keep DataViewRenderer dependency-free by resolving personalization preferences before rendering.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.design-system, @contractspec/lib.personalization, @contractspec/bundle.library
1. Import `resolveDataViewPreferences` from `@contractspec/lib.personalization/data-view-preferences`.
2. Pass the resolved `viewMode`, `density`, and `dataDepth` values to `DataViewRenderer` as controlled or default props.
3. Record user changes with `trackDataViewInteraction` when persistence or behavioral insights are desired.
Forward optional autocomplete async props in custom drivers
manual
Custom autocomplete driver slots can opt into loading/error rendering without changing existing fields.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.contracts-runtime-client-react, @contractspec/lib.design-system, @contractspec/lib.ui-kit-web
1. Accept optional `loading`, `error`, `emptyText`, `loadingText`, and `errorText` props on custom autocomplete components.
2. Keep existing `query`, `options`, `selectedOptions`, and selection callbacks unchanged.
Adopt first-class email fields
manual
Replace renderer-specific email text hints with `kind: "email"` where a field captures one email address.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.contracts-runtime-client-react, @contractspec/lib.design-system
1. Use `{ kind: "email", name: "contactEmail" }` for single-address email fields.
2. Use an `array` of email fields when a form must collect multiple addresses.
Use FormSpec layout hints for dense forms
manual
Replace renderer-specific row wrappers with portable column and colspan metadata.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.contracts-runtime-client-react, @contractspec/lib.design-system, @contractspec/lib.ui-kit-web, @contractspec/lib.ui-kit
1. Add `layout.columns` at form or group level.
2. Use `field.layout.colSpan` for fields that should expand across columns.
3. Use `group.legendI18n` when a section needs a semantic legend.
Use serializable input-group addons
manual
Add text or icon addon descriptors to text and textarea fields.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.contracts-runtime-client-react, @contractspec/lib.design-system, @contractspec/lib.ui-kit-web, @contractspec/lib.ui-kit
1. Add `inputGroup.addons` to text or textarea field specs.
2. Resolve icon keys in the host driver through the `InputGroupIcon` slot.
Add numeric field slots to custom form drivers
assisted
Shared drivers can opt into richer rendering for the new field kinds.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.contracts-runtime-client-react, @contractspec/lib.design-system
1. Implement the optional `NumberField`, `PercentField`, `CurrencyField`, and `DurationField` driver slots when custom styling is required.
2. Keep relying on the `Input` fallback when a separate visual treatment is unnecessary.
Add PasswordInput to custom drivers
manual
Custom form renderers can provide the optional `PasswordInput` slot to get a visibility toggle.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.contracts-runtime-client-react, @contractspec/lib.design-system, @contractspec/lib.ui-kit-web, @contractspec/lib.ui-kit, @contractspec/lib.ui-kit-core
1. Implement a driver component that accepts input props plus `passwordPurpose`, `visibilityToggle`, `showLabelI18n`, and `hideLabelI18n`.
2. Omit the slot to keep the fallback masked input behavior.
Verify custom form driver button and fieldset slots
manual
Custom drivers should confirm their existing `Button`, `FieldSet`, `FieldLegend`, `FieldDescription`, and `FieldGroup` slots render the new flow structure cleanly.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.contracts-runtime-client-react, @contractspec/lib.design-system
1. Render a form with `layout.flow.kind: "sections"`.
2. Render a form with `layout.flow.kind: "steps"`.
3. Confirm unlisted fields remain visible and step navigation buttons inherit expected styling.
Opt into mobile-safe form columns
manual
Replace ad hoc responsive column objects with `responsiveFormColumns(...)` where mobile forms should render one field per row.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.contracts-runtime-client-react, @contractspec/lib.presentation-runtime-core, @contractspec/lib.presentation-runtime-react, @contractspec/lib.presentation-runtime-react-native, @contractspec/lib.design-system
1. Import `responsiveFormColumns` from `@contractspec/lib.contracts-spec/forms`.
2. Set `layout.columns` to `responsiveFormColumns(2)` or another supported column count.
Adopt scoped DataView filters
manual
Declare initial and locked filters in the DataView contract instead of passing all filters as removable renderer state.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.contracts-runtime-client-react, @contractspec/lib.presentation-runtime-core, @contractspec/lib.presentation-runtime-react, @contractspec/lib.presentation-runtime-react-native, @contractspec/lib.design-system
1. Add `filterScope.initial` for removable default filters.
2. Add `filterScope.locked` for fixed constraints.
3. Use `lockedChips: "hidden"` only when the surrounding UI explains the constraint elsewhere.
Configure named harness auth profiles
assisted
Authenticated browser scenarios should reference named storage-state, browser-profile, session-name, or headers-env profiles instead of embedding secrets.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.harness, @contractspec/integration.harness-runtime, @contractspec/app.cli-contractspec, @contractspec/example.harness-lab
1. Add `.contractsrc.json > testing.harness.authProfiles` entries for any authenticated browser flows.
2. Keep raw credentials, cookies, and bearer tokens outside scenario specs and replay bundles.
3. Use `contractspec harness eval --auth-profile <key>` when running a scenario that should apply a configured auth profile.
Install optional browser runtimes for full local proof
manual
Playwright and agent-browser are optional runtime dependencies, but local full-app proof requires the corresponding browser binaries or CLI.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.harness, @contractspec/integration.harness-runtime, @contractspec/app.cli-contractspec, @contractspec/example.harness-lab
1. Run `bunx playwright install chromium` before local Playwright harness runs when browsers are missing.
2. Install `agent-browser` where visual computer-use scenarios should run.
3. Use `--browser-engine playwright`, `--browser-engine agent-browser`, or `--browser-engine both` to select the runtime lane.
Verify notification schema contribution identity
manual
Confirm old module imports keep the legacy module id while new library imports use the library module id.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.notification, @contractspec/module.notifications, @contractspec/lib.design-system, @contractspec/example.crm-pipeline, @contractspec/example.wealth-snapshot, @contractspec/example.saas-boilerplate
1. Check `notificationsSchemaContribution.moduleId` from `@contractspec/lib.notification` is `@contractspec/lib.notification`.
2. Check `notificationsSchemaContribution.moduleId` from `@contractspec/module.notifications` is still `@contractspec/module.notifications`.
Configure phone fields where split values or single-input UX are needed
assisted
Existing `kind: "phone"` object-valued fields continue to work; opt into new modes through field metadata.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.contracts-runtime-client-react, @contractspec/lib.design-system
1. Use `phone.input.mode` to choose `single` or `split` rendering.
2. Use `phone.output.mode` with linked path names to write split country/national/E.164 values.
3. Use `phone.country.defaultIso2` and `phone.display.flag` for country defaults and flag affordances.
Wire app-owned dynamic RBAC providers
assisted
Apps that store workspace-specific role bindings can implement a role-permission source and pass it to `RBACPolicyEngine.evaluateRequirement`.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.identity-rbac, @contractspec/lib.design-system, @contractspec/lib.personalization
1. Resolve static templates and dynamic role/binding records for the current tenant/workspace.
2. Mark explicit denies with `effect: "deny"` so they override static/template grants.
3. Treat provider failure as a protected-operation denial unless an audited break-glass path exists.
Use ThemeSpec as the Tailwind theme source
assisted
Resolve ThemeSpec tokens for the active mode and feed them to the Tailwind preset or CSS serializer.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.design-system
1. Keep existing `tokens` as the default/light-compatible token bag.
2. Add `modes.dark.tokens` when a dark-mode overlay is needed.
3. Use `themeSpecToTailwindPreset` for config-based Tailwind usage or `themeSpecToTailwindCss` when an app wants an importable CSS artifact.
Declare operation-specific success and failure outcomes
assisted
Use `defineResultCatalog`, `standardSuccess`, `standardErrors`, `success`, and `failure` from `@contractspec/lib.contracts-spec/results` when an operation, workflow, or job needs custom codes.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.contracts-runtime-server-rest, @contractspec/lib.contracts-runtime-server-graphql, @contractspec/lib.contracts-runtime-server-mcp, @contractspec/lib.contracts-runtime-client-react, @contractspec/lib.jobs, @contractspec/lib.error
1. Keep raw handler returns for ordinary `OK` responses.
2. Use `contractAccepted`, `contractQueued`, `contractNoContent`, or `contractPartial` for non-default success outcomes.
3. Throw `createContractError` or return `contractFail` for known failures with typed args.
4. Declare custom success codes in `spec.results.success` or `io.success`, and custom failures in `spec.results.errors` or `io.errors`.
Use canonical result mappers in adapters and clients
assisted
Route transport boundaries through the new result helpers while preserving raw success compatibility by default.
Packages: @contractspec/lib.contracts-spec, @contractspec/lib.contracts-runtime-server-rest, @contractspec/lib.contracts-runtime-server-graphql, @contractspec/lib.contracts-runtime-server-mcp, @contractspec/lib.contracts-runtime-client-react, @contractspec/lib.jobs, @contractspec/lib.error
1. Use `OperationSpecRegistry.executeResult` in adapters that need success metadata or typed failures.
2. Set REST `resultEnvelope: true` only when clients should receive `{ ok, data }` success envelopes.
3. Enable GraphQL `resultExtensions` only when the server integration publishes collected success metadata.
4. Use React runtime parser/hooks to normalize REST, GraphQL, MCP, workflow, and job responses into `ContractResult`.
Scaffold release capsule companions
manual
Add release capsules for changesets and include validation evidence.
Packages: @contractspec/lib.contracts-spec, @contractspec/bundle.workspace, @contractspec/app.cli-contractspec, @contractspec/app.web-landing
1. Run `contractspec release init` for new release work.
2. Keep `.changeset/*.md` and `.changeset/*.release.yaml` together in the same PR.
3. Use `contractspec release brief` or `contractspec upgrade prompt` to generate maintainer, customer, and agent guidance.
Use generated release manifests in tooling
assisted
Prefer generated release artifacts for changelog and upgrade flows.
Packages: @contractspec/lib.contracts-spec, @contractspec/bundle.workspace, @contractspec/app.cli-contractspec, @contractspec/app.web-landing
1. Run `contractspec release build` to populate `generated/releases/`.
2. Point changelog or upgrade tooling at `generated/releases/manifest.json` and `generated/releases/upgrade-manifest.json`.

Unique release changes

- Introduce the Builder v3 control plane as a governed authoring layer over external execution providers.
21 packages · 21 occurrences
- Wire provider/runtime integrations through the governed Builder v3 workbench and mobile-review surfaces.
21 packages · 21 occurrences
- Add contract-driven overflow behavior and typed DataView hints for shared DataView and DataTable surfaces.
10 packages · 10 occurrences
- Existing tables keep working, but long prose, markdown, and detail-heavy columns can now declare their intended behavior.
10 packages · 10 occurrences
- The contract, runtime, web, native, design-system, CLI, and workspace layers all participate in overflow behavior.
10 packages · 10 occurrences
- Add a canonical typed result system for ContractSpec success and failure propagation across operations, workflows, jobs, server adapters, MCP, GraphQL, and React clients.
7 packages · 7 occurrences
- Add a family-aware ContractSpec Adoption Engine, expand contract authoring targets across CLI and VS Code tooling, and refresh release-facing schema and policy artifacts for downstream workspaces.
7 packages · 7 occurrences
- ContractSpec workspaces can now opt into family-aware reuse guidance and local catalog sync through `connect.adoption`.
7 packages · 7 occurrences
- Generated Biome policy artifacts now flag deprecated monolith usage and obvious deep runtime entrypoint imports.
7 packages · 7 occurrences
- Prefer `ContractSpecError`, `createContractError`, and `contractFail` from `@contractspec/lib.contracts-spec/results`; `@contractspec/lib.error` remains as a compatibility bridge for existing `AppError` users.
7 packages · 7 occurrences
- Replace new uses of `AppError` with `ContractSpecError` or `contractFail`; existing `AppError` consumers can convert to a compatible problem shape with `appErrorToProblem`.
7 packages · 7 occurrences
- Route transport boundaries through the new result helpers while preserving raw success compatibility by default.
7 packages · 7 occurrences
- Shared workspace discovery and IDE/CLI create flows now recognize additional contract families beyond the original core set.
7 packages · 7 occurrences
- The consumer plugin and Connect CLI now expose adoption-aware hook events in addition to contracts-spec review hooks.
7 packages · 7 occurrences
- Use `defineResultCatalog`, `standardSuccess`, `standardErrors`, `success`, and `failure` from `@contractspec/lib.contracts-spec/results` when an operation, workflow, or job needs custom codes.
7 packages · 7 occurrences
- Add mobile-safe FormSpec layout helpers and scoped DataView filters.
6 packages · 6 occurrences
- Add password-aware FormSpec rendering with current/new password manager hints and visibility toggles.
6 packages · 6 occurrences
- Add production-ready collection defaults and renderer mode switching for DataView list, grid, and table specs.
6 packages · 6 occurrences
- Custom form renderers can provide the optional `PasswordInput` slot to get a visibility toggle.
6 packages · 6 occurrences
- Declare initial and locked filters in the DataView contract instead of passing all filters as removable renderer state.
6 packages · 6 occurrences
- Existing `layout.columns: 2` contracts continue to render as base two-column layouts.
6 packages · 6 occurrences
- Existing specs keep working; add view.collection when a renderer should expose shared collection controls or query page-size defaults.
6 packages · 6 occurrences
- Existing text fields and custom driver slots remain compatible.
6 packages · 6 occurrences
- Prefer `text.password.purpose` for password fields instead of renderer-specific `uiProps.type`.
6 packages · 6 occurrences
- Replace ad hoc responsive column objects with `responsiveFormColumns(...)` where mobile forms should render one field per row.
6 packages · 6 occurrences
- Use `view.filterScope.locked` for non-removable list constraints such as category-scoped posts.
6 packages · 6 occurrences
- `FieldSpec.wrapper.orientation` remains supported but should be replaced by `FieldSpec.layout.orientation` in new specs.
5 packages · 5 occurrences
- Add FormSpec layout hints, semantic field rendering, and portable text/textarea input-group addons.
5 packages · 5 occurrences
- Add text or icon addon descriptors to text and textarea fields.
5 packages · 5 occurrences
- Existing forms continue to render without changes.
5 packages · 5 occurrences
- New input addons should use `inputGroup.addons` on text and textarea fields.
5 packages · 5 occurrences
- New multi-column forms should use `FormSpec.layout`, `group.layout`, and `field.layout.colSpan`.
5 packages · 5 occurrences
- Replace renderer-specific row wrappers with portable column and colspan metadata.
5 packages · 5 occurrences
- Add a shared roles and permissions policy system across contracts, RBAC evaluation, AppShell adaptation, and personalization suppression.
4 packages · 4 occurrences
- Add first-class monorepo-aware environment contracts and managed/BYOK credential setup helpers.
4 packages · 4 occurrences
- Add OSS harness CLI verification with deterministic Playwright, optional agent-browser visual runs, auth profile refs, visual diff evidence, replay bundles, and core scenario success semantics.
4 packages · 4 occurrences
- Add preference-aware DataView collection defaults and personalization adapters.
4 packages · 4 occurrences
- Add release capsules for changesets and include validation evidence.
4 packages · 4 occurrences
- Add versioning-backed release capsules, generated patch notes, and guided upgrade flows.
4 packages · 4 occurrences
- Apps that store workspace-specific role bindings can implement a role-permission source and pass it to `RBACPolicyEngine.evaluateRequirement`.
4 packages · 4 occurrences
- Authenticated browser scenarios should reference named storage-state, browser-profile, session-name, or headers-env profiles instead of embedding secrets.
4 packages · 4 occurrences
- Confirm old module imports keep the legacy module id while new library imports use the library module id.
4 packages · 4 occurrences
- Custom autocomplete driver slots can opt into loading/error rendering without changing existing fields.
4 packages · 4 occurrences
- Existing policies continue to work; add roles, permissions, policy refs, and field policies when a contract needs stronger authorization metadata.
4 packages · 4 occurrences
- Implement ContractSpec Connect as a first-class spec, runtime, and CLI workflow.
4 packages · 4 occurrences
- Improve app-config, theme, and feature authoring with explicit validation APIs, first-class theme discovery and scaffolding, and key-based app-config generation across contracts, workspace tooling, and the CLI.
4 packages · 4 occurrences
- Improve FormSpec autocomplete rendering and resolver-backed search.
4 packages · 4 occurrences
- Keep DataViewRenderer dependency-free by resolving personalization preferences before rendering.
4 packages · 4 occurrences
- Move new notification integrations away from the module shim.
4 packages · 4 occurrences
- Move notifications to library-first contracts/runtime surfaces and add AppShell in-app notification affordances.
4 packages · 4 occurrences
- Playwright and agent-browser are optional runtime dependencies, but local full-app proof requires the corresponding browser binaries or CLI.
4 packages · 4 occurrences
- Prefer generated release artifacts for changelog and upgrade flows.
4 packages · 4 occurrences
- Prefer the package-level validators over shallow AST checks for the three upgraded surfaces.
4 packages · 4 occurrences
- Provide notification items and callbacks to the design-system shell without coupling it to a delivery runtime.
4 packages · 4 occurrences
- Published release changesets now require a structured release capsule.
4 packages · 4 occurrences
- Shared app-config authoring DTOs and templates now use `key`-based spec references instead of older `name`-based helper fields.
4 packages · 4 occurrences
- Shared workspace discovery and the CLI now treat `theme` as a first-class authored surface.
4 packages · 4 occurrences
- The `@contractspec/module.notifications` package remains import-compatible for this release, but new code should import contracts from `@contractspec/lib.contracts-spec/notifications` and runtime helpers from `@contractspec/lib.notification`.
4 packages · 4 occurrences
- The standalone release domain under `@contractspec/lib.contracts-spec/release` is deprecated in favor of versioning-owned release metadata.
4 packages · 4 occurrences
- Theme authoring now has a canonical helper and authored-validator support.
4 packages · 4 occurrences
- Turn on the Connect adapter flow before relying on task-scoped context, review, replay, or evaluation artifacts.
4 packages · 4 occurrences
- Use the built-in Connect commands instead of custom local wrappers for risky file or command mutations.
4 packages · 4 occurrences
- Use workspace environment definitions and app targets instead of duplicating public env names across apps.
4 packages · 4 occurrences
- `kind: "email"` only describes rendering intent; strict validation remains schema-owned.
3 packages · 3 occurrences
- Add a ContractSpec-native production-grade translation runtime and optional i18next adapter.
3 packages · 3 occurrences
- Add first-class FormSpec email fields with native renderer affordances.
3 packages · 3 occurrences
- Add first-class FormSpec phone input support with country detection, split outputs, and flag rendering.
3 packages · 3 occurrences
- Add numeric and temporal FormSpec field kinds with shared renderer support for number, percent, currency, and duration inputs.
3 packages · 3 occurrences
- Add progressive FormSpec section and step layout metadata with shared React and design-system rendering support.
3 packages · 3 occurrences
- Add PWA update management contracts and runtime helpers.
3 packages · 3 occurrences
- Custom drivers should confirm their existing `Button`, `FieldSet`, `FieldLegend`, `FieldDescription`, and `FieldGroup` slots render the new flow structure cleanly.
3 packages · 3 occurrences
- Existing `kind: "phone"` object-valued fields continue to work; opt into new modes through field metadata.
3 packages · 3 occurrences
- Existing `kind: "text"` fields with email input hints continue to render normally.
3 packages · 3 occurrences
- Existing forms render exactly as before unless they opt into `layout.flow`.
3 packages · 3 occurrences
- New field kinds provide stronger semantics and formatting metadata for finance and operations forms.
3 packages · 3 occurrences
- Prefer `meta.key: "bundle.messages"` with `locale: "fr-FR"` over stable keys that encode locale suffixes.
3 packages · 3 occurrences
- Register the PWA update operation, bind it to a manifest resolver, and call it from the frontend on startup or polling intervals.
3 packages · 3 occurrences
- Replace renderer-specific email text hints with `kind: "email"` where a field captures one email address.
3 packages · 3 occurrences
- Shared drivers can opt into richer rendering for the new field kinds.
3 packages · 3 occurrences
- The i18next adapter exports ContractSpec ICU messages intact and does not make i18next canonical.
3 packages · 3 occurrences
- Use `layout.flow.sections` to group existing fields by immediate field name.
3 packages · 3 occurrences
- Use runtime instances or snapshots instead of legacy simple string interpolation for production i18n paths.
3 packages · 3 occurrences
- Add ThemeSpec light/dark modes and a design-system Tailwind bridge for CSS variables, presets, CSS text, and OKLCH color pass-through.
2 packages · 2 occurrences
- Resolve ThemeSpec tokens for the active mode and feed them to the Tailwind preset or CSS serializer.
2 packages · 2 occurrences
- Remove avoidable Node crypto imports from ContractSpec runtime surfaces and keep signing helpers isolated.
1 packages · 1 occurrences
- Replace broad root or `control-plane` imports for signing and verification helpers with `@contractspec/lib.contracts-spec/control-plane/skills`, `/signer`, or `/verifier`.
1 packages · 1 occurrences
- Sticky experiment variants may rebucket because the evaluator now uses a browser-safe deterministic hash instead of Node SHA-256.
1 packages · 1 occurrences

Impacted packages

@contractspec/app.cli-contractspec
Layer: apps · 5 changes
@contractspec/app.cursor-marketplace
Layer: apps · 5 changes
@contractspec/app.web-landing
Layer: apps · 5 changes
@contractspec/bundle.library
Layer: bundles · 2 changes
@contractspec/bundle.workspace
Layer: bundles · 5 changes
@contractspec/integration.builder-telegram
Layer: integrations · 2 changes
@contractspec/integration.builder-voice
Layer: integrations · 2 changes
@contractspec/integration.builder-whatsapp
Layer: integrations · 2 changes
@contractspec/integration.harness-runtime
Layer: integrations · 3 changes
@contractspec/integration.provider.claude-code
Layer: integrations · 2 changes
@contractspec/integration.provider.codex
Layer: integrations · 2 changes
@contractspec/integration.provider.copilot
Layer: integrations · 2 changes
@contractspec/integration.provider.gemini
Layer: integrations · 2 changes
@contractspec/integration.provider.local-model
Layer: integrations · 2 changes
@contractspec/integration.provider.stt
Layer: integrations · 2 changes
@contractspec/integration.runtime
Layer: integrations · 2 changes
@contractspec/integration.runtime.hybrid
Layer: integrations · 2 changes
@contractspec/integration.runtime.local
Layer: integrations · 2 changes
@contractspec/integration.runtime.managed
Layer: integrations · 2 changes
@contractspec/lib.builder-runtime
Layer: libs · 2 changes
@contractspec/lib.builder-spec
Layer: libs · 2 changes
@contractspec/lib.contracts-integrations
Layer: libs · 2 changes
@contractspec/lib.contracts-runtime-client-react
Layer: libs · 5 changes
@contractspec/lib.contracts-runtime-server-graphql
Layer: libs · 5 changes
@contractspec/lib.contracts-runtime-server-mcp
Layer: libs · 5 changes
@contractspec/lib.contracts-runtime-server-rest
Layer: libs · 5 changes
@contractspec/lib.contracts-spec
Layer: libs · 5 changes
@contractspec/lib.design-system
Layer: libs · 2 changes
@contractspec/lib.error
Layer: libs · 5 changes
@contractspec/lib.harness
Layer: libs · 3 changes
@contractspec/lib.identity-rbac
Layer: libs · 3 changes
@contractspec/lib.jobs
Layer: libs · 5 changes
@contractspec/lib.knowledge
Layer: libs · 5 changes
@contractspec/lib.mobile-control
Layer: libs · 2 changes
@contractspec/lib.notification
Layer: libs · 5 changes
@contractspec/lib.personalization
Layer: libs · 3 changes
@contractspec/lib.presentation-runtime-core
Layer: libs · 5 changes
@contractspec/lib.presentation-runtime-react
Layer: libs · 5 changes
@contractspec/lib.presentation-runtime-react-native
Layer: libs · 5 changes
@contractspec/lib.provider-runtime
Layer: libs · 2 changes
@contractspec/lib.provider-spec
Layer: libs · 2 changes
@contractspec/lib.translation-runtime
Layer: libs · 4 changes
@contractspec/lib.ui-kit
Layer: libs · 4 changes
@contractspec/lib.ui-kit-core
Layer: libs · 4 changes
@contractspec/lib.ui-kit-web
Layer: libs · 4 changes
@contractspec/module.builder-workbench
Layer: modules · 2 changes
@contractspec/module.mobile-review
Layer: modules · 2 changes
@contractspec/module.notifications
Layer: modules · 5 changes
@contractspec/module.workspace
Layer: modules · 2 changes