Module Boundary

Module Boundary

This page summarizes the EasyLibrary 3.0-dev module boundary decision.

The versioned source document is docs/module-boundary.md.

Current Decision

Modules stay in the EasyLibrary core for now.

LibModule is still a valid future idea, and the repository is reserved at git@github.com:ImperaZim/LibModule.git. It should not become an official package/runtime before the module contract is smaller, better tested and less coupled to core boot behavior.

Why

The current module runtime owns more than authoring helpers:

• discovery from owner plugin plugin.yml;
• module.yml manifest loading;
• dependency and load-order resolution;
• service and capability registry;
• PMMP plugin enable/disable synchronization;
• command, listener, event, task, async job, component handle and cleanup tracking;
• /easymodule, /modules, /version, doctor and report-bundle output.

Moving all of that into a separate repo too early would make boot behavior and diagnostics more fragile.

3.0-dev Plan

Step	Status	Scope
OP-29A	Done	Boundary audit, docs and lightweight tests
OP-29B	Done	Shared module command runner plus native /easymodule fallback without rich LibCommand
OP-29C	Done	Component coupling isolated behind an internal registry/handle adapter
OP-29D	Next	Stable read-only module summary
OP-29E	Pending	Module smoke matrix

Stability

The module authoring surface remains @experimental in 3.0-dev. Plugin authors can test it, but it may still change before stable 3.0.0.

addComponent() remains available for compatibility with owner plugins that use PluginToolkit, but lifecycle cleanup now tracks a module component handle instead of storing PluginToolkit directly.

See Public API Contract and Compatibility Policy for the broader API rules.