Plugin foundation

The plugin foundation lets first-party features add data and selected interface surfaces without placing every feature's code in the case editor. The checked build has one official plugin, tea.health. The manifest defines which plugin IDs and surfaces the build knows about. An operator can withhold a manifest plugin from a deployment with TEA_PLUGINS_DISABLED, while a user's effective enablement determines whether its UI appears.

Add a registered surfaceCopy Anchor Link

The manifest in lib/plugins/manifest.ts lists the health plugin's ID, version, description and surfaces. A plugin registers browser UI in typed slots. Current live registries cover an element badge, an element panel and a settings section. Health uses these for its node badge, evidence panel and settings. lib/plugins/bootstrap.ts imports the plugin's registration module at the client boundary. A registration must name a known plugin and a surface declared by its manifest entry. The editor then filters registered components by effective plugin enablement.

The slot types also name case panels and canvas decorators as extension points, but the current registry has no live instance for those future surfaces. Do not assume that declaring one in a manifest makes it render. Server features such as machine routes and plugin-owned tables are separate from browser slots.

Store plugin stateCopy Anchor Link

PluginState supports organisation, team and user scoped enablement and settings. A disabled higher scope wins over a lower scope; this build writes only user scoped state. PluginData stores namespaced extension data related to a case or element. The health plugin uses that data for the derived claim score, while its append-only evidence lives in a dedicated plugin table. Access to plugin data and to health routes is still checked against case permissions; a namespace is not an alternative authorisation system. Before adding a new official plugin, register its identity and permitted surfaces, add any needed UI registration, and use the shared enablement and data services. The manifest and slot types define the current extension contract.

Limits and code locationCopy Anchor Link

This is an official, compiled-in plugin mechanism. It is not runtime loading of arbitrary external packages. UI registration is build-time, and the checked release has no marketplace flow. The manifest is lib/plugins/manifest.ts; slot contracts and registry are in lib/plugins/slots/; per-user state and data are managed by lib/services/plugin-enablement-service.ts and lib/services/plugin-data-service.ts.