Feature
Define how Rust plugins extend modulex beyond the builtins, so feature families (repo caretaking, calendar, email, on-call, system health, …) can ship as disciplined, independently-tested crates without bloating modulex-core.
Proposed shape
modulex-plugin-<name> crates in this workspace: each exports pub fn register(registry: &mut StepRegistry) plus its step handlers, MCP tool specs, and (optionally) store migrations.
- Feature-gated linkage:
modulex-cli / modulex-mcp grow cargo features (plugin-git, plugin-calendar, …; a full meta-feature) so a lean build is possible and each plugin's deps stay out of the default graph (the existing web feature is the precedent).
- Tool-surface extension:
tools.rs dispatch becomes registry-driven so plugins can contribute MCP tools (today's match-based dispatch only covers builtins).
- Store extension: a per-plugin schema-version row in
meta (e.g. schema:<plugin>) so plugins own their tables and migrations without touching core's user_version.
- Leash: plugins declare programs via
required_programs() (feeds the declared-default exec grant) and hosts via a parallel required_hosts() for the net axis; nothing escapes ExecGate / the leashed fetcher.
- Non-Rust extension stays as-is: the subprocess plugin protocol (
modulex-plugin/1) and in-process Python registration.
Acceptance
Development discipline
Rust-first, jujutsu-style (no panics in lib code, RFC-1574 doc comments, lower-level tests over e2e). Follow Foundation contributor rules + the rust-tdd skill: TDD, regression tests, 80% coverage floor, README per crate, exec/net leashed, generation counters not wall-clock, credentials as references only.
Feature
Define how Rust plugins extend modulex beyond the builtins, so feature families (repo caretaking, calendar, email, on-call, system health, …) can ship as disciplined, independently-tested crates without bloating
modulex-core.Proposed shape
modulex-plugin-<name>crates in this workspace: each exportspub fn register(registry: &mut StepRegistry)plus its step handlers, MCP tool specs, and (optionally) store migrations.modulex-cli/modulex-mcpgrow cargo features (plugin-git,plugin-calendar, …; afullmeta-feature) so a lean build is possible and each plugin's deps stay out of the default graph (the existingwebfeature is the precedent).tools.rsdispatch becomes registry-driven so plugins can contribute MCP tools (today's match-based dispatch only covers builtins).meta(e.g.schema:<plugin>) so plugins own their tables and migrations without touching core'suser_version.required_programs()(feeds the declared-default exec grant) and hosts via a parallelrequired_hosts()for the net axis; nothing escapesExecGate/ the leashed fetcher.modulex-plugin/1) and in-process Python registration.Acceptance
steps_list/tools/listreflect plugin registrations dynamically--no-default-features, default,full)Development discipline
Rust-first, jujutsu-style (no panics in lib code, RFC-1574 doc comments, lower-level tests over e2e). Follow Foundation contributor rules + the rust-tdd skill: TDD, regression tests, 80% coverage floor, README per crate, exec/net leashed, generation counters not wall-clock, credentials as references only.