Plugin development

Plugin manifest

Every plugin ships a manifest.json declaring its identity, the runtime it needs, and what it contributes — one or more actions, views, or importers:

{
  "id": "org.example.my-discovery-algorithm",
  "name": "My Discovery Algorithm",
  "version": "0.1.0",
  "runtime": "wasm",
  "contributes": {
    "actions": [
      {
        "id": "discover",
        "label": "Discover → My algorithm",
        "input": ["event-log"],
        "output": "process-model",
        "parameters": [
          { "id": "noiseThreshold", "type": "number", "default": 0.2 }
        ]
      }
    ]
  }
}

The host data contract

Actions don't receive raw file contents. They receive a handle to query the input artifact through a small host API — host.sql() for tabular/event data, and typed accessors for object-centric data — so the same plugin code works whether the artifact lives in the browser's storage or, later, on a Promenade Compute engine. See the API reference for the full surface.

Sandboxing

Plugins run inside a sandboxed iframe with no direct DOM or network access to the host page. Views communicate with the host via postMessage, following the same handshake the built-in views use — this is deliberate: a plugin author debugging their own view is exercising the identical code path the core application depends on.

Packaging and loading

For local development, point Promenade's plugin registry at your plugin's build output directory and it's picked up on refresh. For distribution, plugins are listed in the dev/production registry the same way built-in plugins are — there's no separate "external plugin" install flow with a reduced feature set.

Where to start

The repository'splugins/ directory has the full set of built-in plugins as working examples, spanning all three runtimes — a good starting point is a small, single-action Wasm plugin before attempting a full discovery algorithm or a custom view.