社区插件生态：从图片、视频与画布看未来能力市场

独立社区索引已经收集视觉理解、图片生成、网页评审、交互式 UI 生成和 OpenPencil 画布等方向。这些项目成熟度不一，却提供了重要信号：用户不满足于聊天和代码，他们希望 Agent 直接参与设计、内容、研究和空间化思考。

对 FDE 交付平台，这些能力更有价值。不同客户可能需要视频审片、营销素材、业务画布、数据看板或专业文档。平台不应该把它们全部做成 Core 页面，而应让领域 Pack 声明任务与成果类型，让 Renderer/Tool/Knowledge contribution 进入宿主 slot。

研究社区的正确目标，是形成 capability taxonomy 和 interaction pattern：这个插件解决什么工作、输入输出是什么、是否有副作用、需要哪些权限、产物如何被验收，而不是把项目清单直接变成安装市场。

第一步确认来源和维护者；第二步固定 artifact 与完整依赖闭包；第三步检查 install scripts 和宿主权限；第四步读取 capability/permission 声明；第五步在隔离环境做 hostile fixture；第六步验证卸载、升级和 previous-good rollback；第七步检查输出是否能进入 Lumi 的 Artifact、Evidence 和 Acceptance。

社区目录、star 数和 README 演示只能用于发现。一个能生成漂亮图片的插件，仍可能把 API key 写进日志、执行任意脚本、读取整个用户目录或在升级时破坏配置。企业市场必须让风险和能力一样可见。

Control Center 最初应是只读：显示来源、版本、闭包 digest、声明能力、批准权限、实际 enforcement、健康和升级可用性。Mutation 必须晚于治理模型。

图片/视频生成通常属于有成本、有凭据、有外部副作用的 Tool Provider；它的输出应成为 ArtifactRevision，并记录模型、参数、来源与费用。Artifact Renderer 只负责展示已存在的内容，权限更低。Knowledge Source 负责索引和读取，必须有 owner 与 citation 语义。无限画布更接近 Workspace View，需要宿主导航、选择状态和保存协议。

这些类别的生命周期、权限和验收完全不同。若市场只提供一个“安装插件”按钮，平台无法做最小授权。企业协议应先要求 ExtensionDefinition 声明 kind、capability、side-effect class、UI slot 与 data boundary，再由不同 Provider 实现。

对于无名初一类客户，主题、内容策略和业务流程留在 Customer Pack/Overlay；图片生成或审片能力若跨客户通用，则提升为 Official Pack 或 approved Provider。边界不是按客户名字划，而是按可复用合同与数据责任划。

阶段一是研究目录：只读展示，平台不安装。阶段二是 curated registry：官方或审核扩展，exact pin、签名、权限 diff、健康和回滚齐全。阶段三是合作伙伴提交：标准化验收与人工审核。阶段四才可能允许 Agent 生成候选扩展，但生成、审查、签名、安装、激活必须分离。

node:vm 或浏览器弹窗不能成为不可信插件的企业安全边界。动态代码至少要在独立进程或容器中运行，禁止任意 DOM 注入，UI 只走声明式 slot；临时 session 信任也不能自动晋升为正式 Pack。

这条路线看似保守，却能保护生态。没有信任分层的开放市场最终会让优秀开发者和企业用户一起承担事故成本。