Skip to content

Plugin Inventory

pawaca edited this page Aug 30, 2026 · 1 revision

Plugin Inventory

Upstream plugin state projection and composition viewer — why Edge's settings page shows no plugin list.

No dedicated upstream documentation page. Packages: @deepseek-ai/dsh-host-plugin-inventory + @deepseek-ai/dsh-cordis-host-runner

What Upstream Provides

Two packages work together to expose the runtime plugin graph to the browser:

  • dsh-host-plugin-inventory — a read-only Typert Remote projection of the current cordis Loader plugin state. Exposes a pluginInventory/list endpoint that returns every loaded package, its version, trust level, and active status.
    • dsh-cordis-host-runner — the dynamic package definition registry that manages host-half sandbox lifecycle and invoke handlers for model-mounted dual-half packages. Provides the runtime that the inventory reads from.

The client plugin dsh-client-ui-agent-preset (included in Edge's 33-plugin bundle) consumes this data to render the preset composition viewer and plugin list in the settings page.

Current Edge State

Not implemented. Neither package is installed. The effects are:

  • The settings page plugin list section is empty — the client calls pluginInventory/list via Typert Remote but the server has no provider, so the gateway returns an error.
    • Edge hardcodes a single preset 'dsh-edge' in edge-api.ts. The agentPresets.list handler returns one preset with trust: 'system', authorable: false, hasDocument: false.
    • The agentPresets.read handler generates a synthetic YAML description of the Edge composition from runtime state (installed plugins, deployment profile, model config).

Why Not Installed

Edge uses static assembly instead of dynamic loading. All plugins are pre-built at deploy time by assemble-standalone-web.mjs, verified against expected-boot-graph.json, and served as Cloudflare Assets. There is no cordis Loader, no runtime package discovery, and no per-session preset switching. The plugin inventory service has nothing to read from because the loading infrastructure it depends on doesn't exist.

This is a deliberate architectural choice: static assembly eliminates cold-start plugin resolution, keeps the bundle deterministic, and avoids dynamic import() which is restricted in Workers.

Architecture Summary

Component Status Edge Approach
dsh-host-plugin-inventory 🚫 Not installed No loader to read from
dsh-cordis-host-runner 🚫 Not installed No dynamic packages
dsh-client-ui-agent-preset ✅ In bundle Shows hardcoded 'dsh-edge' preset
agentPresets API ⚠️ Hardcoded Single preset, no YAML files

Key observation: The plugin inventory gap is a consequence of Edge's static assembly model — not a missing feature to fix. Installing the inventory service requires the dynamic loader infrastructure, which conflicts with Edge's deterministic bundle approach. The path forward is not to add dynamic loading, but to provide a static inventory projection that reports the build-time plugin list.

TODO

Evaluate static plugin inventory projection. A lightweight adapter could read the build-time plugin list (from expected-boot-graph.json or the assembled manifest) and expose it as a Typert Remote endpoint, so the settings page shows the current composition without needing the full dynamic loader. This would satisfy the pluginInventory/list client call without changing the static assembly model. All plans.

Relationship to Agent Presets (#43). If Edge ever supports multiple presets (different tool sets per session), the inventory and loader infrastructure would need to be reconsidered. See #43 for the preset system spike.

English

中文

Clone this wiki locally