# Plugin manifests declare Plugin SDK compatibility

The historical `block_core` compatibility field predates the standalone
Plugin SDK and is ambiguous: CMS core and the plugin-facing SDK have separate
release cycles. Interpreting the same constraint against both versions can
select an artifact that the host cannot load or reject one that is compatible.

Decision: `[compatibility]` gains an optional `plugin_sdk` string containing a
semantic-version constraint for the plugin-facing SDK/ABI, for example
`plugin_sdk = ">=0.3.7"`. Manifest parsing preserves the value verbatim;
registry and host resolvers own constraint validation and matching.

An omitted or empty value is undeclared compatibility, not a wildcard.
Automated resolution against a host SDK version must fail closed, except for
an explicitly bounded migration policy for releases published before this
field existed. `block_core` remains a separate historical constraint and is
not reinterpreted as the CMS application's own version.

Consequences:

- Plugins can state the actual SDK/ABI range they require.
- CMS core can evolve independently of the public Plugin SDK.
- New releases must declare `plugin_sdk` to participate in automatic
  SDK-compatible selection.

Keywords: plugin.mod, compatibility, plugin_sdk, PluginSDK, ABI, semantic
version, plugin resolver, fail closed