Plugin Builder

Plugin Builder is a workspace tab opened from any New tab (+) menu or the command palette as Plugin Builder. It creates local custom-view drafts from plain-language prompts. In v1 the AI provider returns a structured draft spec, and Wrengle generates the plugin manifest and local files that run on this device after you approve Apply changes.

The Plugin Builder workspace keeps chat and the generated preview or review state visible together. Build progress appears as concise chat status cards, and installed-plugin lifecycle actions live in the project header instead of a permanent controls rail. The header keeps Open and History visible while less common actions stay in the overflow menu, including Reset app state for stateful installed apps. You can describe a new plugin, ask for changes to the current plugin, or submit a replacement prompt from chat while inspecting the generated preview. A replacement prompt creates the next preview, then discards the previous active draft.

What it can build

The builder can draft two local custom-view shapes:

• Static custom views: plugin-owned screens that display self-contained local UI.
• Offline feature apps: plugin-owned screens that display self-contained local UI and store their own plugin-scoped JSON state through Wrengle.

Builder-created offline apps can use window.wrengle.state.get, window.wrengle.state.set, and window.wrengle.state.delete for plugin-scoped local JSON state. Builder drafts declare expected state keys and generated code is checked against that draft contract before Apply. Installed app state remains scoped to the plugin and installed app calls are limited to the declared keys. They do not receive state.list or state.clear; reset is a Wrengle-owned action from Plugin Builder.

Offline feature apps cannot read or write Wrengle notes, projects, blocks, meetings, workflows, files, or settings. They cannot use external network access, secrets, shell commands, or generated WASM actions.

Workspace-aware Builder plugins remain future work. 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. Future workspace-aware Builder work may include generated views that read bounded workspace data or request app-mediated write proposals, but those capabilities are not part of the current Builder release. If write proposals return in a future Builder release, nothing changes until you approve the proposal in Wrengle.

Plugin Builder asks the AI provider for a structured draft spec, then Wrengle generates the plugin manifest and local files under app data. Normal generation uses one structured draft-spec request with an embedded internal planning brief: the provider is instructed to infer requirements, self-answer safe defaults, apply the Wrengle Plugin Builder contract, outline a compact spec and plan, and then return the final JSON view spec. That planning stays inside the one generation request and does not add a user approval step. Platform checks and preview run behind the scenes before you review the generated preview. The content applied to this device must match the checked fingerprint shown during review, and installation or replacement happens only after you choose Apply changes. Applying a custom-view plugin opens the generated plugin view as a workspace tab; later you can reopen it from the command palette as Open <view label>, shown with the AI-built plugin name as attribution.

For supported static custom-view create prompts with clear static/sample/mock UI intent, Plugin Builder can recover from malformed provider JSON, invalid draft specs, or generated static HTML that local policy blocks before files are written. The unusable provider output is discarded and replaced with a safe local starter draft that still has to pass checks and smoke preview before Apply changes is enabled. Recovery is intentionally limited to static custom-view creates; unsupported prompts, network/API/remote-service prompts, live/real/actual/production data requests, workspace data prompts, edit drafts, provider connection/auth/rate-limit failures, and local write, metadata, or fingerprint failures still stop with Needs attention.

If the AI provider returns malformed draft data, Wrengle tries one internal repair. For supported static custom-view create prompts with clear static/sample/mock UI intent, a failed repair can recover into a safe starter draft. When safe static recovery does not apply, no draft is created and no plugin change is applied. Provider, network, and configuration failures do not create a draft; the builder keeps your prompt in place and shows local retry guidance so you can build again or simplify the request.

Work on a plugin over time

Installed Builder-created plugins open in Plugin Builder as focused local project workspaces. Use the header Open button to open the installed view, use History to review approved prompt history and rollback from older approved entries, or open the actions menu for Edit current version, Reset app state for stateful installed apps, enable or disable, and delete. Describe the change in chat and Plugin Builder automatically builds the draft, runs checks, runs smoke preview, and prepares the generated preview. The installed plugin is unchanged until you choose Apply changes. For stateful apps, edit-preview state is temporary; preview interactions test the draft only, and applying an edit preserves installed app state. If the preview is close but not right, submit another chat prompt or choose Refine prompt to return to the same request with your last prompt pre-filled, then generate another preview.

Plugin Builder keeps builder conversations and approved prompt history locally on this device. The selected plugin's Prompt history opens a prompt-first approved timeline so you can read how the plugin changed over time. The history shows approved installed versions only; failed checks, failed smoke previews, and abandoned drafts do not become rollback points. Rolling back restores an older approved version after confirmation. Edit and rollback actions are available only while the installed plugin is enabled. If unfinished draft work exists for the selected plugin, Plugin Builder shows an inline recovery prompt to resume or discard it. Older drafts created before source tracking show a rebuild prompt instead of direct resume.

Resetting app state removes the selected offline app's local saved data only; it does not remove plugin files, prompt history, or conversations. Deleting a Builder-created app removes its managed plugin files, approved prompt history, rollback points, linked Builder conversations, and installed app state.

When automatic checks or preview preparation need attention, Plugin Builder keeps the draft in review, shows Needs attention, and lets you choose Try again to rerun the same request, or Refine prompt to adjust the request first. It does not expose separate manual check or smoke-preview actions.

Review before applying

Review the Plugin Builder access summary before choosing Apply changes:

For offline feature apps, state keys are declared by the Builder draft and generated code is checked against those keys before Apply. Installed app state is plugin-scoped local JSON state managed by Wrengle, and installed app calls are limited to the declared keys. Regenerating or refining the draft requires approval again before installing.

Checks and preview run locally inside Plugin Builder. Generated plugin runtimes and views must not use external network calls, unmanaged secrets, raw filesystem access, shell commands, keychain access, Tauri IPC, parent-DOM access, plugin-defined OAuth, or connector install flows.

Generated views have no network, secrets, shell, filesystem, or Tauri IPC access.

Smoke preview also requires custom views to be self-contained and visibly renderable before they can be applied. Hidden-only markup, placeholder-only content, canvas or blob-backed visuals, empty or non-renderable SVGs, non-renderable raster data URLs, and other runtime-dependent previews stay in review with attention guidance instead of being installed. Static generated visuals should use inline/data SVG with real geometry or scanner-recognized non-interlaced PNG data images; other raster data URLs are treated conservatively.

Privacy

Your current chat prompt and Plugin Builder draft context are sent to Wrengle's configured AI provider so it can generate the draft. Builder conversation records are stored locally on this device and prior local chat history is not sent as provider chat messages. Normal draft generation uses one structured draft-spec request with an embedded planning brief; if the provider returns malformed draft data, Wrengle may make one internal repair request. When you create an edit draft from the current approved version, the structured draft-spec request also includes the current approved plugin behavior summary and custom view HTML, plus your requested change, so the edited draft can preserve existing behavior. Workspace content is not sent for Builder-created offline apps. Prompts that need workspace reads or writes are blocked before generation rather than converted into fixture-backed previews.

Preview and checks happen locally on this device. Plugin Builder manages the plugins it creates from a focused project workspace: describe a new plugin or a change to the current version, review the generated preview after automatic checks and smoke preview finish, then choose Apply changes when it looks right.

The same workspace can open the installed view from the header, and its header History action opens prompt-first approved history with rollback from older approved entries after confirmation. Its actions menu can enable or disable the plugin, edit the current version, Reset app state for stateful installed apps, or delete installed Builder-created plugins.

Broader developer plugin controls live under Settings → Plugins → Developer; permission, key, and plugin-state controls live under Management. Settings also keeps My plugins as a secondary place to enable, disable, or delete installed Builder-created plugins. Diagnostics stay local unless you choose to share them.

Current limits

Builder-created plugins are local to this device in v1. There is no marketplace, publishing, ratings, payments, moderation, remote discovery, connector distribution, remote install, external plugin network access, plugin-defined OAuth, or connector install flow in v1.

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.

AI-built drafts are offline in the MVP. Prompts that require recent notes, project data, note writes, block writes, external network access, credentials, secrets, or unsupported platforms are blocked before generation. When possible, Plugin Builder suggests a prompt that stays inside local offline custom-view or offline feature-app scope.