Summary
run_wasm sends PluginInput { version: 1, skill } (plugin.rs:373) to every WASM plugin, and the doc comment on PluginInput::version says 'so a plugin can refuse a shape it does not know' (plugin.rs:345), but the host never inspects or requires anything about the plugin's declared support for that version — there is no version field on PluginOutput, no documented meaning for future values of version, and no test exercising version mismatch behavior.
Scope
- Severity (reporter's assessment): low
- Area:
arch
- Code:
packages/core/src/plugin.rs:341-390
- Reproduced empirically: yes
Minimal reproduction
grep -n "version" packages/core/src/plugin.rs shows exactly one write site (version: 1 at plugin.rs:373) and zero read sites on the response side (PluginOutput, plugin.rs:349-353, has no version field); no test in plugin.rs's #[cfg(test)] mod tests (plugin.rs:467-830) constructs a plugin that reports an unsupported version or asserts any host-side reaction to one.
Expected
For 'a versioned contract for the plugin API' (part of the project's stated extensibility roadmap) to mean anything, the host should document what changes are and are not allowed within a given version, and either the wire format should carry a supported-version range the plugin can check, or the host should bump version and provide a migration/compatibility note whenever PluginInput's shape changes.
Sources
- No external source — direct reading of plugin.rs's own doc comment, which states an intent ('so a plugin can refuse a shape it does not know') the code does not yet fully back up on the response side
Notes
Low severity because nothing is broken today (there is exactly one version in use and no known plugin ecosystem yet), but it is the concrete gap the prompt's extensibility question is pointing at: there is no versioned contract enforced end-to-end, only a field that exists for future use.
Filed as part of a systematic pre-release audit. Triage and de-duplication pending.
Summary
run_wasmsendsPluginInput { version: 1, skill }(plugin.rs:373) to every WASM plugin, and the doc comment onPluginInput::versionsays 'so a plugin can refuse a shape it does not know' (plugin.rs:345), but the host never inspects or requires anything about the plugin's declared support for that version — there is no version field onPluginOutput, no documented meaning for future values ofversion, and no test exercising version mismatch behavior.Scope
archpackages/core/src/plugin.rs:341-390Minimal reproduction
grep -n "version" packages/core/src/plugin.rsshows exactly one write site (version: 1at plugin.rs:373) and zero read sites on the response side (PluginOutput, plugin.rs:349-353, has no version field); no test in plugin.rs's#[cfg(test)] mod tests(plugin.rs:467-830) constructs a plugin that reports an unsupported version or asserts any host-side reaction to one.Expected
For 'a versioned contract for the plugin API' (part of the project's stated extensibility roadmap) to mean anything, the host should document what changes are and are not allowed within a given
version, and either the wire format should carry a supported-version range the plugin can check, or the host should bumpversionand provide a migration/compatibility note wheneverPluginInput's shape changes.Sources
Notes
Low severity because nothing is broken today (there is exactly one version in use and no known plugin ecosystem yet), but it is the concrete gap the prompt's extensibility question is pointing at: there is no versioned contract enforced end-to-end, only a field that exists for future use.
Filed as part of a systematic pre-release audit. Triage and de-duplication pending.