Plugin architecture
A VibeX plugin is an installable, toggleable, configurable product unit. One package is one user-visible capability: stable identity, one-line summary, content tree, root config, and lifecycle. App, Agent, Host, and Runtime are integration targets inside the package. Settings → Plugins shows name, summary, publisher, version, and the enable switch.
Changes to platform source, Tauri commands, or Application Core belong under Platform architecture. When the public SDK lacks a Host capability, add a generic capability and SDK export first, then consume it from the plugin. Core may know contribution kinds and Host slots. Special cases keyed by plugin ID or file format are debt.
Trust model
Install or enable means Full Trust. Worker, App, declared Runtimes, filesystem, process, and network use the same local rights as the Host. Separate processes and App frames handle hot reload, crash isolation, and dispose.
v4 public manifests default packageClass to full-trust. The product UI omits per-capability grant dialogs. Integrity depends on a deterministic digest, candidate rollback, revision-conflict handling, and resource cleanup. The permissions array remains as compatibility metadata for older v4 packages. New packages omit it.
Isolated execution is declared by a v5 manifest: manifestVersion 5, packageClass isolated, schema at packages/plugin-contract/schemas/plugin.v5-isolated.json in the Host repository. Isolated Worker author APIs match Full Trust. The Host applies OS policy at spawn: sandbox-exec on macOS, bwrap or Landlock on Linux, AppContainer on Windows. When that primitive is absent, spawn fails with plugin_class_unsupported. v4 plugin.json rejects unknown top-level fields; Isolated fields belong on the v5 manifest.
Identity and compatibility
Identity is Publisher plus Plugin ID. Display name, folder name, and similar contents remain presentation. Packages with the same ID and different publishers keep separate grants and data. engines.vibex and engines.pluginSdk declare the compatible range. Current matrix: Host 0.1.3, protocol 1.1, SDK 1.0.0.
A linked development plugin follows the author-chosen source directory. After the source changes, the Host revalidates package identity and every contribution, then forms a new digest and candidate generation. The Host keeps that directory.
UI contract
/plugins keeps the settings sidebar with a single-column catalog. A row opens /plugins/:pluginId. The Content tab shows the README and Host-validated contents/. The Config tab renders config.schema and atomically writes root config.json. Generation, Runtime locks, and handler lists belong in doctor and developer tools.
Completion
- A user can enable the package and finish the promised operation on Content or Config.
- Manifest, SDK, CLI validation, Host parsing, and UI consumption agree on every integration.
- After a linked install, the real Host path works. A harness covers in-process contracts. File tabs, preview processes, Runtimes, and remote observation are accepted on a running Host.
- The README states runtime requirements, offline and network behavior, troubleshooting, third-party licenses, and config retention after uninstall.

