Plugin loading mechanism documented
Why it matters
When the plugin loading mechanism is undocumented, a developer who has built a working plugin cannot install it. They do not know whether to place files in a plugins/ directory, add an entry to a config file, or call a registration function. ISO 25010 maintainability.modularity requires that the extension point be clearly defined; an undocumented loading mechanism makes the extension point inaccessible despite technically existing. The barrier affects plugin users as much as plugin authors — a correctly built plugin that cannot be installed provides no value.
Severity rationale
High because an undocumented plugin loading mechanism makes the plugin system functionally inaccessible: correctly built plugins cannot be installed by developers who cannot find the loading path.
Remediation
Document the full loading flow in src/plugins/README.md or docs/plugins.md, covering file placement, naming conventions, configuration entries, and activation sequence. Include a working import pattern.
// src/plugins/loader.ts — dynamic plugin loading
const plugins = await import(`./plugins/${name}/index.ts`);
Also document whether plugins can be hot-loaded after startup or require a restart.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Plugin / Extension Architecture Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · maintainability.modularity — Modularity — documented loading mechanism enables consistent plugin integration without host source reading
Taxons
History
- 2026-04-18·v1.0.0·Initial import from plugin-extension-architecture·automated