[epic] 统一 Plugin 中心 (Dify 式) — 源库/模板/工具收进单一入口 #25

Activity

1. 1012839419a-alt commented on Aug 31, 2026

   

   1012839419a-alt

   on Aug 31, 2026

   Collaborator

   More actions

   Architecture handoff after PR #87

   The unified Dify-style marketplace remains the correct product entry, but it is not yet a VS Code-style extension architecture. The current repository already has PluginInstallation, Dify metadata intake, capability catalogs, platform-rendered declarative UI, and locked/project-derived node definitions. Those are useful foundations, not a complete extension runtime.

   Delta to a convenient VS Code-like model

   Still missing as first-class contracts:

   1. Immutable plugin package + versioned manifest — identity, engine/API compatibility, contribution points, dependencies, declared permissions, integrity/signature, and migration metadata.
   2. Contribution registry — deterministic registration of nodes, sources, tools, triggers, notification channels, templates, commands, settings schemas, and credential schemas without importing plugin implementation into product code.
   3. Lifecycle state machine — install, validate, enable, activate, deactivate, disable, upgrade, rollback, uninstall; package state must remain separate from workspace/project instances.
   4. Isolated extension host + stable RPC — plugin code runs outside the API/web process with time, memory, network, filesystem, and secret-grant boundaries; RPC is version-negotiated and observable.
   5. Activation events and lazy loading — activate only for declared events/capabilities, not at application boot.
   6. Permission grants and provenance — declared capability is not authorization; grants are scoped, revocable, auditable, and secrets remain ephemeral execution grants.
   7. SDK/tooling — scaffold, manifest validation, contract tests, local host, package/sign/publish, compatibility checks, and upgrade/rollback fixtures.

   Recommended sequencing

   • P0: freeze manifest v1 + contribution-point schema + compatibility rules; project existing catalogs into that registry.
   • P1: implement installation lifecycle, validation, enable/disable, version pinning, and rollback while keeping UI platform-rendered per ADR-0015.
   • P2: add an isolated extension host and narrow RPC for the first real external Tool/Source executor; preserve fail-closed readiness and grant checks.
   • P3: publish SDK/CLI and registry workflow; only then call third-party plugins generally extensible.

   Key invariant: marketplace/catalog answers “what can be installed”; installation answers “what is enabled here”; runtime host answers “what code may execute now”; business pages own installed instances and run evidence. Do not collapse these into one Plugin record.

   PR #87 does not implement this delta. Keep it as follow-up architecture/work under this epic rather than widening the integration PR.