Local developer folders
Plugins are discovered from configured local paths, validated from plugin.toml, and treated as trusted local code.
Plugins
Local plugins are a developer preview.
Wrengle can load trusted local WASM action plugins, sandboxed plugin views, AI-built offline custom views and feature apps, and manifest-declared UI contributions across palette, slash, context, keybinding, status, settings, and panel surfaces. Declarations are not grants: actions use local app-install grants, first-use consent, and user-approved write proposals. Distribution, marketplace installation, and long-term compatibility promises are not in v1.
// local WASM actions · sandboxed views · UI contributions · local grants
Current runtime
What exists today.
The plugin surface is intentionally local and explicit while adoption evidence is gathered; marketplace distribution is not available.
Beta
WASM actions
A WASM action plugin must provide plugin.wasm and export run_action for the current action runtime.
Custom plugin views
Single-file HTML plugin views can render in sandboxed iframe tabs, settings pages, and docked panels.
Manifest UI contributions
Plugins can declare palette commands, slash-menu items, context menus, keybindings, status-bar items, settings pages, and docked panels that appear after reload.
Consent, secrets, and writes
Declarations are not grants. Local app-install grants gate host APIs, secret aliases, scoped state, and app-mediated write proposals before notes or blocks change.
Typed local creator
The in-app plugin creator previews ids, templates, SDK scaffolds, and exact requested capability grants before generating a local action or view plugin folder.
Plugin Builder
Users can open a workspace tab from any New tab (+) menu or the Plugin Builder command. Plugin Builder creates local offline custom views and stateful offline feature apps. It does not create networked plugins, workspace readers, workspace writers, marketplace listings, or generated WASM tools in this release. Offline feature apps can store their own plugin-scoped JSON state through Wrengle, but Builder-created apps cannot read or write Wrengle notes, projects, blocks, meetings, workflows, files, or settings and cannot use external network access, secrets, or shell commands. Open and History stay visible in the header; edit, enable or disable, reset app state for stateful installed apps, and delete stay in the actions menu. Resetting app state removes only local saved data; deleting a Builder-created app removes its managed plugin files, approved prompt history, rollback points, linked Builder conversations, and installed app state. For stateful edits, edit-preview state is temporary; preview interactions test the draft only, and applying an edit preserves installed app state. Workspace-aware generated Builder plugins are future work, and prompts that need recent notes, project data, note writes, block writes, external APIs, credentials, or secrets are blocked instead of being turned into fixture-backed previews.
Developer docs
Pick the plugin path you need.
WASM actions, creator scaffolds, plugin views, and manifest UI contributions are different local workflows. Start with the guide that matches the contribution you are building.
Build a WASM action
Use the manifest, action contract, local grants, scoped state and secrets, build command, and smoke command for local WASM action plugins.
Open docsUse the SDK and creator
Generate creator templates, import wrengle-plugin-sdk, handle host errors, and route note or block writes through proposals.
Open docsCreate a plugin view
Declare a view, ship one self-contained HTML file per view entry, and use the bridge protocol for theme and selection messages.
Open docsDeclare UI contributions
Add palette, slash-menu, context-menu, keybinding, status-bar, settings-page, and docked-panel entries with explicit host-command targets.
Open docsTry JSON Compare
Load the no-build reference view plugin, open it as Open Compare JSON, and run the smoke checklist.
Open docsBuild in Plugin Builder
Use the Plugin Builder flow for static custom views and stateful offline feature apps with plugin-scoped JSON state, including unsupported-prompt blocking before generation, one-shot structured draft generation, minimal chat-and-preview project workspaces, header/actions-menu lifecycle controls, automatic checks, smoke preview before Apply, Refine prompt iteration, Needs attention retry handling, explicit apply approval, Builder-created app management, state reset, command-palette attribution, limits, current-draft recovery, and rebuild-only recovery for older source-less drafts. Workspace-aware generated plugins remain future work.
Open docs