OAS v0.21.2

OAS v0.21.2

OAS v0.21.2 is a corrective release for the v0.21 line. There are no new
features and no lock, manifest, or CLI-surface changes: the single correction
below, and the tests that pin it.

Package payload is no longer discovered as a deployment scope

At a config scope declaring team:, bare oas install reconciles the whole
workspace: it walks downward for descendant scopes, restores each one, and
validates that every config-referenced installed capability is supplied by a
visible locked package. The walk recognized a scope by the presence of an
oas-config.yaml (or an oas-lock.json) — and a member repository that
publishes an OAS package carries oas-config.yaml files that are not scopes
at all: the config templates the package exports, declared through
configTemplates and living under config-templates/ per the v0.20 contract.

A template deliberately binds a layer to the capability its own package
supplies, on the assumption that the adopting deployment installs that package
first. Reconciled as if it were live, it therefore failed by construction:

Failures by scope:
  <workspace>/oas-jira/oas-package/config-templates/default: oas.jira — referenced by
    capabilities.layers.tasks but supplied by no visible locked package
  <workspace>/oas-linear/oas-package/config-templates/default: oas.linear — referenced by
    capabilities.layers.tasks but supplied by no visible locked package

One healthy workspace failed reconciliation for every package it develops, and
the failures named directories no operator could act on. Templates that happened
to resolve against the surrounding chain passed only by accident — the same
walk had been treating all of them as live deployments.

Scope discovery now excludes package payload. A directory holding an
oas-package.json is a package root, and every path beneath it is content
the package exports, never a scope: it is not reconciled, not validated, and
never acquires anything. The rule is the manifest, not the literal
config-templates/ path — custom payload roots exist and one repository may
ship several packages at different paths, and all of them are covered.

Because the test is a containing ancestor, a repository that ships a package
and is itself a deployment scope is unaffected: an oas-config.yaml at a
repository root whose manifest sits in a subdirectory (the framework repo's own
shape) has no oas-package.json ancestor and stays a scope exactly as before.

The same walk backs oas migrate --official --recursive's descendant discovery,
so the exclusion applies there too — a lock stranded inside a payload is no
longer planned as a migration scope.

Genuine failures are untouched. A real member scope referencing a capability no
visible locked package supplies still reports the same message, at the same
scope, with the same nonzero exit.

Compatibility

• No lockfile, manifest, config, or CLI-surface changes. v0.21.x locks,
  artifacts, and approvals are unaffected; nothing needs reacquiring.
• Workspaces holding no package payload see no change. Workspaces that develop
  packages stop reporting failures for directories that were never scopes.

OAS v0.21.1

OAS v0.21.1

OAS v0.21.1 is a corrective release for the v0.21.0 line. There are no new
features and no lock, manifest, or CLI-surface changes: the single correction
below, and the tests that pin it.

Artifact provenance is judged scope-exactly

A deployment chain may legitimately hold the SAME package identity at two
scopes with different source spellings — for example a laptop scope that
acquired oas.okf directly (locked catalog:oas.okf) under a workspace scope
that received the same package through another package's dependency closure
(locked catalog:oas.okf@v2.0.0). Each scope is internally consistent: every
materialized artifact's .oas-installation.json agrees with the lock beside
it.

oas doctor resolved the lock rows for that comparison from the MERGED chain,
where each identity resolves closest-scope-first. Running it at the inner scope
therefore compared the outer scope's artifacts against the inner scope's rows —
rows they were never projected from — and reported the healthy pair as

ERROR: capability oas.okf: materialized capability oas.okf: .oas-installation.json
"source" is "catalog:oas.okf" but the lock records "catalog:oas.okf@v2.0.0" [invalid-lock]

Both doctor renderings (human and --json) now resolve those rows
scope-exactly, the way oas list and oas trust already did: an artifact under
<scope>/.agents/capabilities/installed is judged against <scope>/oas-lock.json
and nothing else — the same discipline v0.20.1 established for doctor's orphan
check. Each package row is also reported with its own scope's source, path, and
commit rather than the nearest scope's.

Trust evaluation carried the same confusion and is corrected identically. When
the closest scope locks a capability it has not materialized, the artifact that
actually activates comes from an outer scope; capabilityTrust compared that
artifact's integrity and provenance against the inner row, so a capability its
own scope had approved resolved as untrusted. Trust now reads the row from the
artifact's own scope.

What is compared is unchanged — source-string equality within the correct scope
— and both directions still fail closed: an artifact that genuinely disagrees
with its own scope's lock is still invalid-lock, and an artifact whose own
scope does not lock it is untrusted even when another scope in the chain locks
that capability id.

Compatibility

• No lockfile, manifest, config, or CLI-surface changes. v0.21.0 locks,
  artifacts, and approvals are unaffected; nothing needs reacquiring.
• Diagnostics only become more precise: chains that never held one package id
  at two scopes see no change.

OAS v0.21.0

OAS v0.21.0

OAS v0.21.0 changes where the official package catalog comes from. The catalog
is now read from the OAS repository at resolution time instead of only from the
copy bundled inside the installed kernel.

The catalog is read from the OAS repo

The source of truth is package-catalog.json on main in
OAS-Framework/oas. A catalog-consuming
command fetches it, validates its shape, and caches it.

Why. The catalog is an identity map — official short id → repository, ref
and package root. Before this release it could only change by publishing a new
kernel, so a newly published official package (or a corrected entry) reached
deployments a release late, and the strict "release the kernel, then the
packages, then a catalog patch" ordering was a recurring tax. Reading the
catalog from main decouples publishing a package from cutting a kernel.

Resolution order.

1. OAS_PACKAGE_CATALOG — an explicit local file. It replaces the catalog
   entirely: no fetch, no cache write, unchanged failure behavior for a broken
   file. This is the hermetic escape hatch for tests and pinned environments.
2. The remote catalog, with a short bounded timeout, validated before use and
   cached on success.
3. The cached last successful copy — the normal source for every read that did
   not just fetch, and the fallback when a fetch fails or the payload is
   invalid. When a command attempted a refresh and fell back, one line goes to
   stderr naming the cache age.
4. The package-catalog.json bundled in the npm package, as the last-resort
   seed for a host that has never reached the network.

The bundled catalog stays in the published package. It is the seed, not the
source of truth.

Remote payloads are untrusted input. A catalog entry's url, ref and
path end up in a git clone argv and on the filesystem, so a remote payload —
and the cache, which only ever holds remote-derived content — is validated entry
by entry: a valid package id, an https://-only url (no file:, ssh:,
git: or scp-like spellings), a plain option-free ref, a canonical relative
path, and unknown keys dropped. One bad entry disqualifies the payload, which
becomes a fetch failure. Redirects are followed only to https GitHub hosts,
and the body cap is enforced in bytes. An OAS_PACKAGE_CATALOG override file
is exempt from these tightenings: it is operator-controlled and local, and
keeps the pre-release semantics exactly, file:// urls included.

Reproducibility is unchanged

Locks pin exact commits. The catalog supplies identity and discovery only: it
advances no lock, changes no installed bytes, and grants no executable trust.
The same oas-lock.json restores the same commits whether the catalog came from
the network, the cache, or the bundle.

Restores stay offline. A bare oas install restore of an existing lock — and
the recursive workspace reconciliation — never attempts a catalog fetch, because
the lock already names what to restore. Only new work resolves the catalog:
oas install <catalog-id>, oas update <package>, oas migrate, and the
oas init forms that resolve a fundamental layer or --package. An install
whose source names its own transport (./dir, git:host/org/repo,
https://…) is not a catalog lookup and performs no fetch, and oas doctor
never fetches — diagnostics stay off the network.

Cache and offline behavior

The cache lives at ~/.oas/package-catalog.cache.json (under $OAS_HOME_DIR
when set). It stores the payload with its fetch timestamp and is replaced
atomically: an exclusively created temp file with an unguessable random name,
0600 always, fsynced, then renamed — so a name planted in advance cannot be
followed. The containing directory is created 0700 when the kernel creates it;
a directory that already exists keeps the permissions the host gave it. A cache
that is missing, corrupt, or fails entry validation is treated as absent, never
as a failure, and a cache that cannot be written never fails the command (it is
reported as catalog.cacheError in oas doctor --json).

Offline hosts keep working: the cache answers, with a single stderr line such as

oas: official package catalog unreachable (timed out after 4000ms) — using the cached copy from 26h ago (~/.oas/package-catalog.cache.json)

--json output is unaffected: warnings never enter the envelope on stdout.

Set OAS_CATALOG_FETCH=off on an air-gapped host to switch the remote attempt
off entirely and resolve straight to the cache and then the seed. Its messages
say the fetch was disabled — they never claim the remote was unreachable,
because nothing was contacted.

Doctor reports catalog provenance — without fetching

oas doctor names the catalog source this host is actually serving —
override, remote, cache or bundled — with the URL or file path, the
cache location, and the cache age when a cached copy is being served. The same
data is available structurally as catalog in oas doctor --json, which also
carries refreshedThisRun, refreshedBy, fetchDisabled and cacheError.

Doctor performs no fetch: diagnostics stay off the network, so a broken
network cannot make the diagnostic hang, and doctor never changes the state it
is diagnosing. Its lines therefore never claim the remote "was unreachable" —
they report what is stored and name the acquiring commands that do refresh it.
A broken OAS_PACKAGE_CATALOG override is reported as broken rather than
rendered as a healthy override.

Desktop compatibility

Desktop API remains version 1: the surface Desktop probes and drives
(version --json, spawn --json, okf harvest --json) is unchanged by this
release, and the desktop server reads no catalog of its own — it only classifies
catalog: lock sources as strings, which this change does not touch.

The accepted CLI band in packages/desktop/cli-locator.mjs is widened to
>=0.18.0 <0.22.0 so it admits the kernel published by this same tag (Desktop
and the kernel publish in lockstep, and a band excluding its own kernel would
ship an app degraded to observation-only). DESKTOP_API stays 1; only the
upper bound moves, and the band-edge tests pin the new edges.

Security posture

The fetched URL is a constant compiled into the kernel. It is never taken from
configuration, a lock, the catalog itself, or a command-line argument, so no
input can turn the kernel into a fetch proxy for another address. The only
override, OAS_PACKAGE_CATALOG, names a local file exactly as before.

See Distribution packages for the full contract and
the package engine contract for the
provenance and fetch-classification tables.

OAS v0.20.1

OAS v0.20.1

OAS v0.20.1 is a corrective release for the v0.20.0 capability-materialization
line. The framework release includes @oas-framework/oas@0.20.1,
@oas-framework/pi@0.20.1, and OAS Desktop 0.20.1. There are no new features;
the changes are the three corrections below and the hardening they forced.

Doctor recognizes revised-v2 capability locks

oas doctor no longer reports installed capabilities from a canonical
revised-v2 lock as orphans. The orphan check is scope-exact: a capability row
is judged against the lock of the scope that installed it, reading the
revised-v2 capabilities table directly instead of inferring provenance from
package rows. Legacy v1 locks keep their previous diagnostic behavior.

Own-property config handling and __proto__ rejection

Config parsing and diagnostics no longer consult inherited Object.prototype
properties anywhere: key dispatch, capability binding, command-owner lookup,
and shape validation are own-property. YAML keys named __proto__ are refused
with the typed failure unsafe-config-key. Internal engine annotations
(underscore keys such as _capabilityLock) are stripped from every manifest
and soul reader, so on-disk files cannot impersonate engine state.

Configless oas use states the real problem

Running oas use in a scope with no config chain now fails with the typed
error E_NO_CONFIG and prints a deterministic remedy — initialize the scope
with oas init --raw --dir <dir> — instead of the misleading acquired: none
report. OAS does not author adopter policy: the remedy initializes an empty
config; adopting a package profile remains an explicit separate step.

Config writes fail closed

Text that would change the shape of a written config is now refused with
typed failures instead of being written:

• unsafe-config-value — values containing line breaks (including U+2028,
  U+2029, and U+0085, which earlier releases wrote and then silently dropped
  on read), embedded " #" (which opens a trailing comment), empty values,
  and leading YAML structure indicators.
• unsafe-config-key — keys and --soul/--type names carrying :, #,
  or __proto__.

This includes the scaffolded name: line: oas init, and the first
oas use/oas type add in a fresh scope, now refuse to run in a directory
whose basename cannot be stored as one YAML scalar — for example a name
beginning with @, #, or a flow bracket, or containing " #" or a line
break. The refusal names the offending basename and writes nothing. This is a
deliberate behavior change: earlier releases wrote such names verbatim, and a
basename containing a line break could inject top-level config blocks.

Untrusted text (directory names, $HOME) is never used as a regex
replacement string, so names containing $&-style sequences are stored and
reported literally.

Desktop parity with the kernel

The OAS Desktop deployment reader now reads revised-v2 capability locks (it
previously rejected them) and matches the kernel's judgments: it refuses
every lock shape the kernel refuses (path canonical form, source grammar,
duplicate dependencies), and its legacy-v1 artifact digest now counts .git
and nested lock files exactly as the kernel does — a payload planted in a
v1-locked artifact after locking is integrity drift in the app, not an
invisible exclusion.

Compatibility

• New typed failures: E_NO_CONFIG (configless oas use),
  unsafe-config-key, unsafe-config-value. Scripts matching error text
  should match the typed codes.
• oas init and first-write commands refuse directory basenames that cannot
  be stored as one YAML scalar (see above).
• No lockfile, manifest, or CLI-surface changes otherwise; v0.20.0 locks and
  configs are unaffected.

See the package engine contract for
the typed-failure table.

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.

OAS v0.19.4

OAS v0.19.4

Release-pipeline follow-up for the documentation refresh.

• Makes Desktop server tests independent of a repository-owned deployment lock
  by constructing their capability-agent deployment explicitly.
• Allocates ephemeral loopback ports instead of choosing a collision-prone
  pseudo-random development port.
• Keeps live-checkout parity diagnostics tolerant of deployment-local package
  skew while retaining the unconditional isolated parity proof.

No runtime contract changes from v0.19.2.

OAS v0.19.2

OAS v0.19.2

Official package catalog and migration activation patch.

The kernel now bundles immutable catalog entries for:

• oas.okf@v1.4.1
• oas.aweb@v1.8.0
• oas.authoring@v1.0.0
• oas.jira@v1.0.0
• oas.linear@v1.0.0
• oas.dev@v1.0.0, which exports oas.review@1.2.0

Each catalog entry selects the repository's contained oas-package/ payload.
Short-id installs now prefer these distribution packages over the legacy bundled
capability marketplace. Existing v1 locks and installed artifacts remain
supported until the user explicitly runs the guided migration:

oas migrate --official --recursive --dry-run --dir <team-root>
oas migrate --official --recursive --dir <team-root>

This patch also preserves the v0.19.1 marketplace compatibility bridge for
npm-hoisted aweb skills.

Install matching versions:

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

OAS v0.19.1

OAS v0.19.1

Corrective patch for the v0.19.0 marketplace compatibility bridge.

• Restores npm-hoisted aweb skills for existing v1 oas.aweb installations.
  Marketplace declarations still anchor at their declaring capability first;
  when npm hoists a declared dependency, OAS resolves the equivalent path under
  the installed kernel root with the same realpath containment checks.
• Keeps valid older installed+locked marketplace capabilities usable across a
  kernel upgrade while still failing closed when the installed copy and lock
  disagree.
• Preserves framework-author oas.authoring skill composition from the
  published kernel layout.

The official package catalog and default migration redirects are not included
in this corrective patch; they follow after the independently tagged official
packages complete their published-kernel probes.

Install matching kernel and Pi adapter versions:

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

OAS v0.19.0

OAS v0.19.0

One release built from one tag: @oas-framework/oas@0.19.0,
@oas-framework/pi@0.19.0, and OAS Desktop 0.19.0 in this GitHub Release.

This release introduces distribution packages, exact OAS-managed instance
curricula, canonical primary-checkout instance homes, and the package/profile
setup flow needed for independently published official capabilities.

Distribution packages

An OAS package is now the acquisition, integrity, update, and review unit above
independently targetable capabilities. A Git repository may contain ordinary
development content and one or more package payloads; the selected payload path
is part of the source and lock contract.

# Git/catalog sources default to the contained oas-package/ directory.
oas install https://github.com/example/project.git@v1.0.0

# Select another contained directory, or the repository root explicitly.
oas install 'https://github.com/example/project.git@v1.0.0#dist/oas'
oas install 'https://github.com/example/root-package.git@v1.0.0#.'

# A local path always names the exact package root.
oas install ../project/oas-package

Lock v2 records source, exact commit, selected path, integrity, dependency
closure, exported capabilities, and per-capability executable approvals. Bare
oas install restores the exact locked graph; it never advances a branch,
catalog selector, package path, or dependency closure. Updating remains
explicit:

oas update <package-id>

Acquisition installs and hashes only the selected payload subtree. Repository
CI, documentation, owner souls, sibling packages, and source-control metadata
are not installed. If root .git metadata later appears inside a managed
artifact, it is treated as source drift and invalidates trust rather than being
an approval-invisible exclusion.

Package config profiles and workspace setup

Packages may ship complete reference oas-config.yaml profiles. Adoption is
explicit and produces an editable local snapshot:

oas init --package <package-source> [--config <profile>] --dir <workspace>
oas install --dir <workspace>

The first command acquires and exact-locks the full package closure, validates
the selected profile against its capability providers, and writes the snapshot.
The second command reconciles the team boundary and nested repository locks.
Package updates never rewrite an adopted config; normal targeting, exclusions,
settings, and closer repository overrides remain authoritative.

Missing host commands and runtime packages remain a separate consent decision.
Human and JSON plans show every ordered argv step before anything executes.
Spawn verifies required runtime packages but never installs them.

Exact OAS-managed instance curriculum

For each soul, the scoped config cascade now determines the complete
OAS-managed skill and instruction set. Active capability resources are
enumerated before scaffolding, copied into the canonical instance tree, and
asserted against the expected composition. Missing, untrusted, duplicate, or
uncontained active resources fail closed instead of producing a half-configured
agent.

Canonical instance resources are:

<instance-home>/.agents/skills/
<instance-home>/.claude/skills -> ../.agents/skills
<instance-home>/AGENTS.md
<instance-home>/CLAUDE.md -> AGENTS.md

Runtime posture is deliberately provider-specific and recorded in
instance.json:

• Pi suppresses ambient skills, context files, and prompt templates while
  preserving operator-configured extensions.
• Claude Code preserves the operator's native user/repository settings,
  skills, plugins, MCP, hooks, and memory; OAS adds its canonical composed
  resources without exclusion flags.

The guarantee is exact OAS-managed composition, not identical ambient behavior
across providers.

Canonical instance homes and the home/work boundary

Instance homes now live under the soul-owning repository's primary checkout,
even when spawn is invoked from a linked worktree or from an agent's work/.
Unresolvable placement fails closed before creating anything.

Every runtime and lifecycle hook receives the absolute OAS_INSTANCE_HOME.
Generated instructions distinguish the two operational surfaces:

• instance home contains instructions, task, soul reference, provenance,
  selected skills, and episodic state; OAS lifecycle and active-capability
  commands run there;
• <instance-home>/work is the repository or workspace view where permitted
  reading, editing, Git, builds, tests, and commits happen.

OAS performs resolved-path containment checks and rechecks the created home
before writing credentials or running hooks. The deployment agents directory
must still be operator-owned and not writable by untrusted local processes.

Required hooks, runtime requirements, and safe rollback

Capability spawn hooks may declare required: true. A required hook that cannot
establish its contract fails the spawn. If compensation cannot finish, OAS
retains a versioned quarantine containing the credential and original cleanup
metadata; oas retire retries and verifies outstanding cleanup before deleting
the home. --force remains the explicit operator escape hatch.

Requirement consent now supports runtime-scoped Pi packages and Claude plugins,
including multi-step marketplace registration plans. JSON and human output show
the same exact ordered steps.

Existing 0.18 capability installations

Upgrading the kernel does not force a capability migration. Existing valid
v1 locks, installed official capability artifacts, config activation, and trust
continue to work in 0.19.0.

The guided command is included:

oas migrate --official --recursive --dry-run --dir <team-root>
oas migrate --official --recursive --dir <team-root>

It remains held until the official package catalog and immutable package tags
are published. That catalog/default redirect ships in the planned 0.19.1
follow-up. Until then, oas doctor explains that the legacy capabilities remain
supported. Migration preserves config files and capability IDs, leaves custom,
owned, and path capabilities untouched, and never transfers executable trust
silently.

Legacy kernel-marketplace capabilities may still reference framework-hoisted
resources. Those paths now anchor at the declaring capability's canonical
marketplace directory and remain contained by the installed kernel. Valid older
installed+locked capabilities continue working across a kernel upgrade.

OAS Desktop

Desktop accepts the matching 0.19 CLI through Desktop CLI API v1
(>=0.18.0 <0.20.0) instead of rejecting its own release and degrading to
observation-only mode. Compatibility and recovery copy are derived from one
runtime contract rather than repeated literals.

Desktop also includes the accumulated 0.18.x post-release work: cluster-aware
agent navigation, persistent editor-style terminal groups, Quick Open for souls,
runtime-scoped model suggestions, improved spawn readiness handoff, and the
existing editable shortcut system.

Downloads

Platform	Artifacts
macOS arm64 (Apple Silicon)	DMG + ZIP
macOS x64 (Intel)	DMG + ZIP
Linux x64	AppImage + DEB

macOS artifacts are ad-hoc signed, not Developer ID signed or notarized. First
launch may require right-click → Open, or Open Anyway in System Settings.
Verify assets with SHA256SUMS.txt and the GitHub build-provenance attestations.
Windows and Linux arm64 are not supported in this release.

Install or update

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

The kernel, Pi adapter, and Desktop publish from the same tag and should stay on
matching versions. Official OAS capability packages are published separately
after released-kernel consumer probes; this release does not claim that their
catalog entries are live yet.

OAS v0.18.6

OAS v0.18.6

One public release, built from one tag: @oas-framework/oas@0.18.6,
@oas-framework/pi@0.18.6, and OAS Desktop 0.18.6 (attached to this
GitHub Release).

This release adds explicit spawn-time agent relations, cluster-first Desktop
navigation, and user-editable Desktop keyboard shortcuts. Desktop CLI API v1
remains the compatibility boundary (>=0.18.0 <0.19.0), but related spawns
require the new 0.18.6 CLI.

New: explicit agent relations

A new instance can declare what it is to an existing instance:

oas spawn <agent> --relation child|sibling|parent --relative-to <instance>

• child works for and nests under the anchor;
• sibling joins the anchor as a peer;
• parent oversees the anchor and takes its previous lineage position;
• no relation flags means unrelated and top-level.

--parent <instance> remains supported as child-relation shorthand.
Same-named instances can exist in different agent roots, so
--relative-root <agents-root> can qualify an anchor. Ambiguous or shadowed
lineage fails closed with E_RELATIVE_AMBIGUOUS rather than linking or acting
on the wrong instance. Attached agents remain children of the verified owner
of their shared work tree.

Retiring an instance repairs ordinary parent and sibling links that point to
it. OAS intentionally keeps this as sparse current-state metadata rather than
a lineage database: concurrent parent spawns against one anchor are
last-writer-wins, and a multi-instance retirement repair is sequential rather
than a crash-atomic transaction.

Desktop: cluster-first agent surfaces

The Active overview and permanent instance sidebar now group related agents as
clusters built from parent and sibling links. Independent instances remain in
a quieter separate strip. Duplicate instance names across repositories remain
distinct throughout grouping, filtering, collapse state, terminal routing,
Brain actions, and privileged instance-addressed API calls.

The Spawn surface now uses one accessible modal with purpose, task, relation,
anchor, runtime, and model controls. Relation controls stay visible but fail
closed when the installed CLI predates 0.18.6; unrelated spawning remains
available across the existing Desktop API v1 compatibility range.

Desktop: editable keyboard shortcuts

Desktop actions now use a central keybinding engine with persisted user
overrides and explicit unbinding. Open the shortcuts editor with Mod+,.
The editor covers app, stage, tab, sidebar, terminal typography, and
view-local actions, with live shortcut labels and conflict warnings.

Terminal shortcut interception happens before PTY writes for an explicit
action allowlist. View-local shortcuts remain confined to their focused
surface, and spawn-modal controls keep ownership of their keys.

Downloads

Platform	Artifacts
macOS arm64 (Apple Silicon)	DMG + ZIP
macOS x64 (Intel)	DMG + ZIP
Linux x64	AppImage + DEB

The macOS artifacts are ad-hoc signed — not Developer ID signed and not
notarized. First launch may still require right-click → Open (or Open
Anyway in System Settings → Privacy & Security).

Verify downloads with SHA256SUMS.txt; GitHub build-provenance attestations
are published for all assets.

Windows and Linux arm64 are not supported in 0.18.x.

Install / update

npm install -g @oas-framework/oas@0.18.6

The pi bridge @oas-framework/pi publishes in lockstep. Desktop downloads are
the assets on this release; the full install/support guide is
docs/desktop.md.