Capability contract

Newer is allowed only when required behavior remains.

An application may run on a newer Arcane Core. Version alone never substitutes for a missing protocol, feature, capability, or method.

Admission checks the complete declared contract

  • Target

    The requested target appears in every selected or bundled app descriptor.

  • Core floor

    The host Core meets the highest minimum declared by the SDK runtime and complete app closure.

  • Protocol

    requirements.arcaneProtocol matches the host protocol generation.

  • Features

    Every declared feature is advertised by the host.

  • Capabilities

    Every requested capability is available to the app boundary.

  • Methods

    Every declared method exists with compatible meaning.

Example

app minimum 0.8.12host Core 0.9.0Allowed only if every declared contract remains

A higher semantic version does not override one missing method. Conversely, an exact version equality requirement would reject safe non-breaking Core upgrades unnecessarily.

Payload selection and host compatibility are separate

The portable target can assemble a non-executable payload from the installed SDK without an Arcane OS checkout. That result establishes the selected payload, not the behavior of a future composed host. A real host must still provide the required protocol, version floor, features, capabilities, methods, services, bridge, and lifecycle. Windows x64 and macOS ARM64/x64 use SDK-owned providers with application-selected services and require host archives matching the installed numeric SDK release. Mac host compilation and platform execution remain separate from its delivered composition source. Linux and Android retain their explicit checkout-backed providers; explicit Windows checkout overrides remain supported.

See the portable packaging contract, Core runtime, and browser client for the responsibilities at each boundary.

Breaking changes must become visible

A host must stop advertising an old protocol, feature, capability, or method when its meaning or guarantee changes incompatibly. Change the protocol generation or contract identifier so admission fails before provider build or launch.

Keep compatibility and release verification distinct

Compatibility

Can this host provide every behavior declared by the selected app and its bundled app dependencies?

Release verification

Does the explicitly selected artifact satisfy its descriptor, package contract and complete file inventory?

Newer Core versions are accepted when the required contracts remain available. Explicit artifact verification describes the selected output; it does not establish browser behavior, native installation or production readiness.