scripts/capability_resolver.py is your plugin-capability registry and resolver. It provides the runtime half of crickets' enhances: soft-composition. It aggregates the capabilities: keys from installed plugins into a per-host registry. You use it to answer the question, "is this capability available, optionally at a version range?" It uses only the standard library. It never imports plugin code. It handles missing or corrupt files by degrading gracefully.

capability_available is your boolean surface. Use this primary interface when you only need True or False.

This function never raises an exception. It returns False on any internal error. This implements LC-4. Unavailable is your safe default.

capability_resolve provides your richer return form. Use this when you need to log or branch on the reason.

{
    "available": bool,
    "provider":  str | None,   # plugin slug
    "version":   str | None,   # provider's declared version
    "reason":    str,          # one of the four reason codes above
}

This takes the same parameters as capability_available. It never raises an exception.

build_registry is your low-level builder. It returns the raw capability-to-provider map. The root parameter overrides your home directory. Tests use this with a temp directory instead of your live ~. It returns {} on any I/O error.

ProviderEntry is a frozen dataclass:

The resolver aggregates two host state directories independently. It then merges them. Claude Code entries win when both claim the same capability.

Both paths are optional. A missing or corrupt file at any step returns an empty partial registry. The merger then silently skips the absent host. The Antigravity path contributes nothing on a machine with only Claude Code. The reverse is also true.

The following rules apply when both hosts declare a provider for the same capability:

1. Installed provider wins over not-installed. An enabled Claude Code plugin beats a declared-but-not-installed Antigravity sidecar.
2. Claude Code wins over Antigravity when both are installed. You expect the two to be identical in co-installed setups. CC takes priority as your tie-breaker.
3. First declarant wins within each host. The first plugin appearing in the manifest order wins if two plugins on the same host declare the same capability.

python3 scripts/capability_resolver.py <capability>
python3 scripts/capability_resolver.py <capability> <version-range>

This is your entry point wired by the agentm capability shim (Task 3). The importable module is your primary contract. The CLI gives your shell callers a convenience shim.

scripts/capability_version_match.py implements your version range evaluation. It uses only the standard library. The public API is a single function:

satisfies(installed_version: str | None, range_str: str) -> bool

It returns True when installed_version satisfies the constraint expressed in range_str. It returns False on any malformed input, a None version, or a compound specifier. It never raises an exception. This implements your LC-4 graceful degrade.

~= X.Y expands to >= X.Y AND < (X+1). This means "any release of the same major version starting at X.Y or later". For example:

This strictly follows PEP 440's compatible release clause.

The script zero-pads versions with fewer components before comparison. It treats 1.2 as 1.2.0. It then compares them component-wise as integers.

satisfies() returns False and never raises an exception for:

• None installed version — provider's version is undeclared in its manifest.
• Malformed version string — cannot be parsed as dot-separated integers.
• Compound specifier — range strings containing , (PEP 440 a, b multi-constraint form). The resolver acts as a single-check, not a solver. It rejects compound specifiers entirely.

capability_resolve uses the "version-mismatch" reason code when satisfies() returns False for an installed provider.

• CI gates — the test gate (scripts/test_capability_resolver.py, 39 tests) runs in check-all.sh.
• Auto-orchestration — the runtime that will consume capability_available to gate enhances-declared skill dispatch.
• AgentM HLD — V5 unbundling — the decision that established plugins as the soft-composition surface.