The CLI checks project inputs, builds the package and verifies its archive. Its output records desktopTested: false; those checks do not establish behavior in the installed desktop application. Keep compatibility status pending until the required manual qualification has evidence for the exact plugin archive, Lomi version and platform.
Qualification steps
Section titled “Qualification steps”Use a separate OS account or an explicitly qualified disposable application profile. Do not use the source repository or node_modules during the trial.
- Record the Lomi version, binary hash, OS and architecture, plugin version and ZIP SHA-256.
- Import the extracted package and confirm its metadata appears before code is enabled.
- Approve the exact revision through the normal trust flow. Review every declared command, view, fill and theme.
- Check the plugin’s behavior with and without a workspace, across workspace switching and application restart. Check state persistence and singleton behavior where declared.
- Exercise keyboard access, focus, resizing, appearance, docking and any platform-specific behavior the plugin claims to support.
- For document views, verify Save, Discard, Cancel and save failures during view close, plugin disable and application quit.
- Import a changed revision, confirm renewed trust approval and the required restart. Check missing-plugin and incompatible-state behavior.
- Check disable, uninstall and safe mode. Check offline operation when the plugin claims it works without a network.
For a theme-only plugin, select the theme in Settings > Themes without enabling executable code. Record failures and unsupported platforms as such. Do not claim broad compatibility from a single platform trial.