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, but it should not be created before the module runtime 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 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	Next	Coupling to imperazim\components\plugin
OP-29D	Pending	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.

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