Overview

The Xilancer plugin system follows a strict three-layer architecture that keeps core and plugins fully decoupled.

Architecture

core/                 Laravel application. Calls plugin_*() helpers at seam points.
                      Never imports plugin classes directly.

plugins/framework/    Zero-dependency engine: hooks, slots, registries,
                      plugin discovery, boot ordering.

plugins/<slug>/       Individual plugins. Depend ONLY on PluginsFramework/*.

Key invariant: Plugins never import App\*, Modules\*, or other plugin namespaces. Core talks to plugins only through hooks, slots, and registry seams.

Plugin Lifecycle

1. Discovery — PluginManager scans plugins/*/plugin.json, validates manifests
2. Activation — Writes "slug": true to plugins/statuses.json (inactive by default)
3. Autoload — PSR-4 namespaces registered on Composer class loader
4. Boot — Entry class instantiated with PluginContext, boot() called in dependency order
5. Runtime — Core calls plugin seams via guarded helpers
6. Asset Wiring — Routes, views, migrations, config auto-loaded by PluginBridgeServiceProvider

Architectural Invariants

1. Exception isolation — Plugin boot errors never break other plugins or core
2. No core imports — Plugins only use PluginsFramework\* and PHP builtins
3. Scalar-only payloads — Actions receive IDs, strings, arrays — never models
4. Data filter safety — plugin_filter_model_data() reasserts allow-lists after plugin enrichment
5. Priority ordering — Lower priority runs first (default: 10, FIFO within same priority)
6. Activation state external — plugins/statuses.json survives core updates
7. Dependency isolation — Missing/unmet dependencies isolate only the affected plugin

Last updated: September 2026