Plugins

When a workflow needs behavior beyond configuration, a plugin can combine shared records and services into a report, reviewed operation or business workspace. Explore the bundled examples and industry recipes to choose a pattern before implementing your extension.

Runtime plugins declare their tools, triggers, required capabilities and permissions. Registration begins in review; enablement makes approved capabilities available to a workspace. Modules describe the pages, navigation and configuration that present a capability. The extension overview explains how these pieces fit together.

Build beyond the default workflows

A plugin can be part of an App with custom records, its own lifecycle and a dedicated interface. Use the existing module, entity and domain service paths to implement those capabilities; the runtime manifest alone does not create them. App design explains the choices, and custom work shows how a native queue can retain authoritative state without copying it into a task.

Source-built Apps can change the whole operating experience. The current isolated plugin hosts expose bounded capabilities; adding a new execution capability requires a host implementation and verification. AI authoring distinguishes source development today from the planned in-app builder.

Manifest shape

Required: pluginKey, name, description. Optional: version, author, homepage, required capabilities, permissions, config schema, MCP server URL, tools, triggers.

Each tool declares toolName, label, description, input schema, impact (read, internal_write, external_action), whether confirmation is required, and an autonomy level (prohibited, always_ask, ask_until_trusted, standing_permission, autonomous).

What still applies

Plugin tools flow through the autonomy policy engine. Mutating tools still stage into action_queue. MCP tools discovered from an external server must be registered as plugin_tools before use; they do not bypass Accelerate governance. Isolate execution (QuickJS) is the host for untrusted plugin code, with measured bounds. A plugin does not get a raw database handle.

What not to do

Do not treat a plugin as a way to skip approval. Do not document a plugin as autonomous if its policy is always_ask. Do not load plugin code from the extensions/ JSON directory; that directory is data.

Document the plugin before release

Every plugin needs an operator guide covering setup, configuration, permissions, costs, a worked example, disabling, recovery and verified limitations. Bundled plugins keep plugins/<id>/README.md and a public docsUrl in their manifest. npm run verify:extensions rejects missing guides and documentation links. Runtime/MCP submissions supply the same documentation in their review packet; the current runtime registry does not enforce a documentation field.

Follow the plugin documentation contract. A reviewer must follow the task against the current implementation; structural checks cannot establish that the guide is accurate. See the Collections guide for a business workspace and the Radar guide for its daily review workspace, source-backed relationship context, model budgets and current release limits.

Consistent workspace interfaces

Plugin screens should inherit the workspace appearance through the shared admin components and field styles. Use AdminButton, AdminSurface, AdminTable, AdminDialog, AdminStatusMessage and admin-field instead of copying control colors, corners or focus treatments. Keep labels, error recovery and keyboard behavior consistent with the core workspace. Read-only views use useAdminQuery and AdminReadBody so loading, retry and cached data follow the same lifecycle.

Theme choices change presentation without changing permissions or business behavior. Verify plugin screens in light and dark themes, at mobile and desktop widths, and with keyboard and reduced-motion preferences before release.