1. 定义一个明确的用户结果

说明安装后会发生什么、Bundle 为 DSH 增加什么、目标 Profile 是哪个，以及用户下一步可以做什么。不要把无关仓库仅仅标记成 Plugin。

2. 声明 Bundle patch

package manifest 必须指向实际包含在分发内容中的 patch。

{
  "name": "your-package",
  "version": "1.0.0",
  "dsh": { "bundle": { "patch": "cordis.patch.yml" } }
}

3. 让分发内容可审计

  • 把 manifest 和 patch 提交到源码仓库。
  • 发布与安装命令中版本一致的 package。
  • 确保 npm tarball 或 Git commit 同时包含这两个文件。
  • 避免隐藏下载和生命周期脚本；无法避免时明确写入文档。
  • 把 package 关联到规范的源码仓库。

4. 记录完整生命周期

  • 前置条件与支持的 Harness 基线。
  • 目标 Profile 和固定版本的安装命令。
  • 明确的验证步骤。
  • 更新和移除命令。
  • 网络、文件系统、凭据、shell、原生构建和外部运行时事实。
  • 已知限制和移除后可能残留的数据。

5. 发布证据，而不是承诺

可复现的 package、不可变 commit 和清楚的生命周期能帮助用户做决定。流行度和笼统的安全声明不能替代这些事实。DSHub 会把新发现的 package 留在公开索引之外，直到有记录的审查确认用途、兼容性、限制和操作。

查看 Registry schema →