Client internals (class loading & config assembly)

The plugin architecture and lifecycle contract (pipeline and insertion points, scan roots, dual-track routing, enable/disable and mutual exclusion, dependency gates) and the security red lines each live in their own knowledge card — this page no longer repeats them:

Topic	Card
Pipeline & insertion points · scan roots · lifecycle · dual-track · enable/disable · dependency gates	Runtime architecture & lifecycle
What the 12 type values do, and how to choose	Type overview & selection
Security red lines · runtime environment · private dependencies	Runtime environment & red lines
Every card	Plugin Development Docs

This page covers only how the client wires a plugin up: Python class loading and config assembly.

---

1. Python class loading

For asr / mt / tts / middleware / assistant / interpretation / tool:

1. Parse entrypoint as relative/path.py:ClassName (without a colon, ClassName = "Plugin")
2. importlib loads the module from that file
3. The class must subclass BasePlugin
4. cls(manifest) → initialize(config)
5. The instance is cached; shutdown() is called on unload

Data types (glossary / i18n / theme) skip this entirely — they are mounted as data only. Full entrypoint rules: Layout & mod.json.

For external (non-built-in) plugins, initialize() runs on a background thread and the host waits for it to settle before it is really needed — so blocking for a few seconds there does not freeze the UI, but it is still the wrong place to start a local service (see Local-service engine contract).

---

2. Config assembly

Case	What the host does	Details
Ordinary fields	Renders a generic form from config_schema (inline on the hub card, or as its own settings tab)	config_schema declarative form
Custom UX (get a key / test connection / dual base URLs)	Loads the plugin's ui_extensions.settings_view QML first; it is not auto-generated from the schema	Custom settings view
Persistence	Stored in QSettings plugins_config/<id>; Python reads self._config, changes arrive via update_config	Config & private data

---

3. Security model

No sandbox: Python plugins run in the same process and with the same privileges as the host. Data types (theme / glossary / i18n) are low risk; audit script plugins before installing. The full red lines (no runtime pip, privacy, no cross-plugin config writes, …) are in Runtime environment & red lines.