OAS v0.20.0

OAS v0.20.0

OAS v0.20.0 is a breaking pre-1.0 release. The framework release includes
@oas-framework/oas@0.20.0, @oas-framework/pi@0.20.0, and OAS Desktop
0.20.0.

This release finalizes capability materialization and config templates. It
replaces the earlier, unadopted transitional v2 package shape without changing
lockfileVersion: 2.

Revised lockfile v2

The final v2 lock separates package provenance from installed capability
identity.

• packages records the source, exact commit, selected package root, payload
  integrity, and package dependencies.
• capabilities records each materialized artifact, its provider package,
  source path, artifact integrity, and executable trust.

A package is now a transport and update unit. Each exported capability is an
installed, activatable, and trustable unit. OAS materializes it under
.agents/capabilities/installed/<capability-id>/.

Every newly authored package must give each capability a dedicated,
self-contained root. Declared resources and symlinks must stay inside that
root. The package root is not kept as an installed package store.

Config templates remain local policy

Canonical package manifests use configTemplates. Their template files live
under config-templates/.

oas install does not apply a template. Adoption is explicit through
oas init --package or oas config adopt. The adopted file is an ordinary,
editable oas-config.yaml.

Each scope has at most one active config and one adopted base. OAS records the
base under .agents/config-templates/adopted/. The oas config diff, sync,
sync --reset, and adopt commands use that base for three-way plans. Package
updates do not overwrite local config edits.

Migration and trust

Existing valid v1 locks from 0.18 remain supported. Migration is explicit and
converts a scope directly to the final revised v2 shape.

Migration is atomic for each scope. If a mixed scope contains entries that must
be retained, OAS holds the whole scope unchanged. It does not partly rewrite
the lock. Executable trust never transfers silently to a materialized
capability.

The earlier transitional lockfileVersion: 2 shape is unsupported. It was not
adopted as a release contract, so this release provides no migration for it.
Back up the scope and reacquire its package state through supported CLI paths.
Do not hand-edit the lock.

See Distribution packages for the lock, adoption, and
migration details.

Desktop compatibility

Desktop API remains version 1. Desktop 0.20 accepts released CLI versions in
>=0.18.0 <0.21.0. This range includes the matching 0.20 kernel.
Prerelease versions are not accepted.

Required release order

The framework and package releases have a strict dependency order.

1. Release the v0.20.0 kernel, Pi adapter, and Desktop first.
2. After that consumer contract is available, revise and test all six official
   package repositories. They are oas-okf, oas-aweb, oas-jira,
   oas-linear, oas-authoring, and oas-dev. Tag immutable package revisions
   in dependency order. Release leaf packages first and oas.dev last.
3. Only after all six immutable package tags exist, update the kernel catalog.
   Cut a framework patch if the catalog change requires one.

Do not retag an existing package release. The revised package versions do not
become catalog defaults until the catalog follow-up ships.

Install or update

npm install -g @oas-framework/oas@0.20.0
pi install npm:@oas-framework/pi@0.20.0

Keep the kernel, Pi adapter, and Desktop on matching release versions.