Module plugins 

Content-plugin install / uninstall / list commands.

Install is gated by a native confirmation dialog (mirroring set_hooks): the user must explicitly approve installing a plugin, with its provenance shown. A content plugin’s pack is merged into the active profile and the exact additions are recorded in the registry (merge-and-track), so uninstall removes precisely what was added. The registry persists to plugins.json; the merged content persists in the profile as usual.

Structs

DialogBusyGuard 🔒

InstallOutcome

Result of an install, surfaced to the renderer. hints_added / routines_added are the content merge effect (zero for a detector).

Enums

Prepared 🔒

A validated plugin awaiting consent + apply. Holds enough to show the confirmation dialog and then apply the right install path.

Constants

DIALOG_MAX_CAPABILITIES_SHOWN 🔒

Most capabilities shown in full in the dialog before truncating, so a long (or padded) import list can’t push the safety text off-screen.

KEY_FINGERPRINT_CHARS 🔒

Number of leading characters of the base64 signing key shown as a short visual fingerprint in the dialog, so a returning user can recognise a familiar author and spot a substituted one.

MAIN_WINDOW_LABEL 🔒

Plugin IPC is restricted to the main settings window, like content packs.

MAX_MANIFEST_BYTES 🔒

Hard cap on a plugin manifest we’ll read+parse. A content plugin embeds its pack, so this matches the content-pack cap.

PLUGIN_DIALOG_ALLOW 🔒

PLUGIN_DIALOG_CANCEL 🔒

Functions

apply_detector_install 🔒

Persist a validated detector’s module to disk and register it (granted capabilities + detect config travel in the record). Split out so it’s unit-testable without a WebviewWindow/dialog. The module bytes are written first; only on success is the registry updated and persisted, so a failed write leaves no dangling record.

apply_export_install 🔒

Register a validated export adapter (declarative — no module, no content merge). The export config travels in the record for the delivery path. Split out so it’s unit-testable without a WebviewWindow/dialog.

apply_install 🔒

Merge a validated content plugin into the active profile, record the additions in the registry, and persist both. Split out so it’s unit-testable without a WebviewWindow/dialog. Mirrors the content-pack apply_pack write sequence (merge into a clone, rebuild the derived caches, store, upsert the active profile, persist).

apply_uninstall 🔒

Remove added content from the active profile and persist. The registry entry is dropped by the caller; this only touches settings. Split out for unit testing. Returns MergeSummary repurposed as removal counts.

confirm_install 🔒

ensure_main_window 🔒

format_install_summary 🔒

install_plugin

Install a plugin from path: read (size-capped), validate (parse, schema, signature, and — for detectors — decode + sandbox link check), confirm via a native dialog, then apply. Content plugins merge their pack into the active profile; detector plugins persist their module and register their granted capabilities. Returns a summary of the effect.

list_plugins

List installed plugins for the Settings UI.

read_manifest_text 🔒

Read a plugin manifest file with the size cap, mapping I/O errors to user-facing strings. Pure (filesystem only), so the read + error-mapping is testable without a Tauri window.

sanitize_for_dialog 🔒

Same control-character / bidi sanitisation as the hooks dialog, so a hostile manifest can’t spoof or scramble the consent prompt.

uninstall_by_id 🔒

Drop the registry record for id and remove its tracked content from the active profile, persisting both. Errors if id isn’t installed. Split from the command wrapper so it’s testable against a real Scheduler.

uninstall_plugin

Uninstall the plugin id: remove exactly the content it added from the active profile and drop its registry record. No-op-safe if the user already deleted some of that content by hand. Returns what was removed.