发布与分发

插件做完了，怎么交到用户手里？分发的最小单位是一个 .tgz 包（解开即插件根），有三条路可走。

包结构

<id>-<version>.tgz 解开后:
├── plugin.json          # manifest(必需)
├── package.json         # node 插件:type:module + 依赖清单
├── dist/                # node 插件:后端构建产物(entry 指向这里)
├── ui/dist/             # 前端构建产物(有 UI 时)
└── node_modules/…       # 仅原生依赖需要随包;纯 JS 依赖建议打进 dist

打包前把 manifest 的入口切到构建产物（entry: "dist/server.js"）——devEntry 只在源码开发时用，随包无意义。

三条分发路径

① 目录拷贝(内网/手动)

最朴素的一条：把插件目录（或解开的 tgz）放进用户机器的 ~/xinghan/plugins/<id>/，重启应用即生效。适合内网环境与团队内部工具 —— 产品文档的离线与内网安装写了用户侧的完整操作。

② 本地包安装

应用内市场页支持从本地 .tgz 安装（宿主解到临时区、校验、原子落位）。给用户发一个包文件，比让他们手动拷目录更不容易出错。

③ 上架市场

正式的分发面。市场按 catalog.json 列出插件，客户端下载 .tgz 后按 SHA-256 校验字节、解到同盘 staging、原子 rename 进安装目录 —— 半个包永远不会出现在用户机器上。

manifest 的 market 字段决定你在市场卡片上的样子：

"market": {
  "category": "效率",
  "tags": ["timer", "focus"],
  "featured": false
}

description 是卡片副标题 —— 一句话说清插件给用户带来什么，别写实现细节。

市场投稿的具体流程（提交、审核、更新）以市场页指引为准；写作本页时第三方投稿通道在逐步开放中。

版本与更新

• 宿主对账（reload/重启应用）时按磁盘内容重启插件 —— version 用语义化版本（0.2.1）标记你的每次发布,市场靠它判断可更新；
• 配置结构变了要自己兼容老数据：字段插件的 cell 值、文件插件的文档、自动化节点的 node.Data 都可能是老版本写的 —— 读入时迁移（version 字段 + migrate()，见文件类型指南的做法）；
• 卸载必须无害：这是贡献点设计一以贯之的承诺（字段退回基础类型、文件回归内建编辑器、表视图显示占位）。你的插件数据格式也要配合 —— summaryPath 之类的”降级快照”别偷懒不填。

发布前自查清单

• plugin.json 的 id 是正式 reverse-DNS（不是 dev. 前缀）
• entry/ui 指向构建产物，本地删掉源码目录后仍能跑
• capabilities 只声明真用到的（授权面 = 用户对你的信任面）
• 多语言文案两种语言都填了（LocalizedText 缺语言会回退，但体验差）
• 卸载后打开曾用它编辑的文件/字段/视图，确认降级显示正常
• description 与 market 元数据从用户视角写