Module Boundary

Module Boundary

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

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

Current Decision

LibModule is the official home for module authoring APIs, runtime ownership, module commands, examples and module lifecycle behavior.

EasyLibrary no longer owns a core module manager. It keeps only the host bridge needed to:

• detect package-backed or standalone LibModule;
• wire command backend registration;
• expose provider data in doctor, support reports, /plugins and /version;
• expose a disabled provider when no visible LibModule runtime exists.

Provider Modes

modules:
  provider: auto

Mode	Meaning
auto	Use visible and ready LibModule; otherwise expose disabled module runtime.
core	Keep module runtime unavailable from EasyLibrary. It no longer means old core module manager.
libmodule-experimental	Require external LibModule and report loudly if it cannot be activated.

Expected summaries:

Module provider: package-backed / LibModule external module runtime
Module provider: standalone / LibModule external module runtime
Module provider: disabled / No module runtime loaded

Authoring

New modules should use the LibModule repository:

• LibModule README
• LibModule authoring API
• LibModule examples

Do not import EasyLibrary bridge classes for module authoring. Classes under imperazim\library\libmodule are host integration details.

Diagnostics

When LibModule is loaded, module diagnostics are available through:

/modules
/easymodule
/easylibrary doctor
/easylibrary report create
/plugins
/version

When LibModule is absent, module commands are not advertised as bundled EasyLibrary features. General server summaries only show module information when a visible official LibModule runtime exists.

See Module Smoke Matrix, Public API Contract and Compatibility Policy for validation and API rules.