ZeroClaw proposes checking whether a plugin can load before declaring it installed

ZeroClaw's plugin proposals target a misleading success condition: a manifest and a WASM file can exist while the host cannot load the component. PR #10746 would check loading before committing an install. Its dependent follow-up #10752 adds explicit verification for plugins already on disk, including ones left behind by a host upgrade. The initiating report describes an experimental WIT contract that had drifted between plugin and host.

The facts

- Issue #10505 reports a component being discovered but registering no tools after a vendored WIT definition omitted a host logging variant. - The install proposal would compile and instantiate through the host's existing verification path and show the wasmtime cause chain on failure. - An explicit --no-verify option would downgrade refusal to a warning; it would not make the component compatible. - Channel verification deliberately stops before configure(), so a plugin is not rejected merely because its settings are not filled in. - The follow-up proposes plugin info load verdicts and plugin list --verify; the ordinary list remains a cheap discovery view without a loading guarantee. - Memory-capability plugins receive a compile check but lack a dedicated instantiate-world check in this proposal.

Why it matters

Plugin ecosystems need a distinction between inventory and readiness. If a setup command says installed and a list command repeats the name, operators reasonably expect the tool to exist. Surfacing compatibility failure only as a startup warning transfers debugging work to the user and makes automated health checks optimistic. The proposed verification is valuable precisely because it does not claim to change the ABI, fix an incompatible plugin or relax its egress policy. It makes the existing boundary visible sooner.

Current

Inspected on 2026-09-12. The ZeroClaw release baseline is v0.8.5 published 2026-09-05T07:31:19Z. The main source was open (not merged) when captured. Proposals, merged mainline changes and packaged releases are different availability states; the linked release baseline does not imply that open proposals have shipped.

Evidence

Primary evidence: zeroclaw-labs/zeroclaw PR #10746 (https://github.com/zeroclaw-labs/zeroclaw/pull/10746). Supporting context: zeroclaw-labs/zeroclaw PR #10752 (https://github.com/zeroclaw-labs/zeroclaw/pull/10752); zeroclaw-labs/zeroclaw issue #10505 (https://github.com/zeroclaw-labs/zeroclaw/issues/10505). Sources were read directly through public pages or GitHub API bodies. Contributor test results are attributed claims, not independently reproduced results.

Operator take

A reviewer can assess the design with a disposable host configuration and a known-good fixture, then substitute an incompatible component and compare plain listing with explicit verification. Retain the exact error and rebuild against the host's current WIT rather than treating --no-verify as a repair. The dependent proposal includes later notes correcting unknown-name exit behavior and stable ordering, while an older scope paragraph still says those paths are unchanged. That internal inconsistency should be resolved against the final diff before scripts rely on the details; this brief does not present the contradictory paragraph as settled behavior.

Caveat

Both proposals were open in the captured snapshot. The issue describes v0.8.4-era WIT skew, while the current release baseline is v0.8.5; it is context for the proposed guard, not proof that every current installation is broken. Contributor validation is not an independent cross-platform test, and successful loading alone would not certify plugin safety.