Capabilities and Adapter Architecture

Status: implemented capability architecture; platform behavior is environment-dependent.

A capability is work requested after the Core host, scope, evaluation, rendering, and action boundaries are understood. An adapter performs its library- or environment-specific work without moving rendering, application policy, or page ownership into Core. Platform selection and packaging are separate in Platforms and Packaging.

One capability, explicit mediation

HTML capability declaration
  -> Core resolves owner, scope, and explicit operation
  -> registered adapter performs capability-specific work
  -> safe result may use *response
  -> owner cleans up its instance or subscription

Registration metadata makes a capability, adapter name, owner kind, operations, aliases, and subscriptions discoverable. It is not a general plugin framework. Controlled .call reaches registered public operations only; it rejects statements, global traversal, assignment, and private/prototype paths.

Backend selection does not erase differences

The usual adapter order is project bridge, selected native bridge, browser implementation, then explicit unsupported result. Tauri and Capacitor are platform-selected alternatives, not backends that probe one another.

Only unavailable or explicitly unhandled work may continue to the next backend. Once a native operation starts, success, cancellation, permission denial, or operational failure stops selection. This prevents duplicate side effects and does not pretend that browser and native permission behavior is identical.

The initial Tauri scope is filesystem, clipboard, notification, and device info. Windows use requires platform-specific device validation; this is an environment boundary, not a gap in the capability architecture. No *tauri directive exists.

External-library adapters remain specific

MapLibre, ECharts, Dexie, ProseMirror, CodeMirror, and Yjs/provider adapters are reference implementations, not one common library vocabulary. Each keeps its own native state, public operations, subscription cleanup, and result normalization. Detailed names and APIs belong to their directive reference and architecture record.

Evidence

Status: implemented with environment-dependent native boundaries.

Evidence: public adapter reference, docs/spec/external-capability-adapter-architecture.md, dist/adapters/, test/external-capability-adapter.test.js, and test/external-capability-routing.test.js.