dsh-plugin-publish
用一条命令在 GitHub 上发布或更新 DSH 插件：验证清单和捆绑包标识符，创建或复用仓库，将目录树作为一次提交上传，遵循 .gitignore，并设置必需的主题而不删除你已有的主题。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:Gty2408/dsh-plugin-publish#2346a2a23c4d3bae529ea738baf42c18e72d8f28Plugin Publish 以 dsh-plugin-publish 发布，当前版本为 0.3.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
一条命令把 DSH 插件发布到 GitHub。产出一个公开仓库，任何其他机器都能从它安装这个插件。
npx dsh-plugin-publish ./my-plugin --token <token> --yes
dsh-plugin topic（保留你已有的 topic）。Published: https://github.com/you/my-plugin
Install it on another machine with:
dsh plugin --profile desktop add github:you/my-plugin
(resolves through git; that machine needs git installed)
dsh plugin --profile desktop add https://codeload.github.com/you/my-plugin/tar.gz/HEAD
(fetched over HTTPS; no git needed)
两条命令都打印，因为哪条能用取决于目标机器：github: 形式通过 git 解析，codeload 链接走 HTTPS 直接下载。另外还会给一条钉住具体提交的命令，用来安装"确定是这一版"而不是"跟着 HEAD 走"。
再跑一次就行。 第二次发布把新提交的父节点指向分支当前的 HEAD，是一次快进（fast-forward），不需要 --force：
npx dsh-plugin-publish ./my-plugin --yes
repo : exists https://github.com/you/my-plugin
commit : 3f9a1c2d (12 files)
topics : dsh-plugin, dsh, deepseek-harness, cordis
上传采用"整个目录树即仓库内容"的语义：本地删掉的文件，远端也会删掉。所以发布即镜像，不会留下你早已删除的旧文件。
仓库的 description 也会跟着 package.json 更新 —— 改了描述再发一次就会同步到仓库页面。
每一项检查的存在，都是因为 DSH 加载器会因此失败，而且失败点往往是静默或令人困惑的：
| 检查 | 没有它会怎样 |
|---|---|
声明了 dsh.bundle | dsh plugin add 根本无法安装这个包 |
| patch 文件真实存在 | 组合包层没有东西可应用 |
patch 行的 name 与包名一致 | 模块永远找不到 |
浏览器半注册的 id 与包名一致 | 浏览器半永远不加载，且没有任何报错 |
| 没有疑似凭据的文件 | 推到公开仓库的 token，推送那一刻就已泄露 |
最后两条最危险：插件看起来装好了，就是什么都不做。以上全部在任何网络请求之前运行，所以一个坏掉的 manifest 不可能把仓库发布到一半。
关于
id和name：patch 行的id是行标识，name才是要加载的模块，两者语义不同、可以不同。本工具因此比对name，不是id。
作为 DSH 插件安装 —— 在 harness 内增加 /publish-plugin 命令：
dsh plugin --profile desktop add github:Gty2408/dsh-plugin-publish
然后在任意会话里：
/publish-plugin # 校验工作区里的插件
/publish-plugin --push # 校验后发布
/publish-plugin ./my-plugin --push --repo custom-name
token 从 ~/.dsh/.github-token（一个带 repo 权限的 classic token）或插件的 token 配置读取。
作为独立 CLI，供 harness 之外使用：
npx dsh-plugin-publish --help
| 方式 | 何时用 |
|---|---|
| 设备码流程（默认） | 交互式。打印一个短码，你在浏览器里授权。无需粘贴 token。 |
--token | 非交互，或 github.com 不通但 api.github.com 可用时。 |
设备码流程访问 github.com，而 API 调用访问 api.github.com。这两个域名的可达性可能不同 —— 在某网络上实测，api.github.com 约 185 ms 就响应，而 github.com 连接 22 秒后失败 —— 这就是保留 token 这条路的原因。
scrubSecrets 会移除 classic 与 fine-grained 两种 token 形状，以及 URL 里夹带的 token，然后才显示或记录。--force。.gitignore。 构建产物、编辑器状态、本地数据不会因为恰好放在源码旁边就被推到公开仓库。node test/run.mjs
测试套件是密闭的：无网络、无凭据、无账号。推送路径的每个分支 —— 空仓库的播种、blob/tree/commit/ref 序列、409 情形、错误传播、重试行为、topic 合并、.gitignore 匹配 —— 都跑在一个说同样 REST 接口的假 GitHub 上。hermetic.test.mjs 通过扫描其他测试文件来强制这一性质：不允许读凭据，不允许未 mock 的调用。
这是刻意的。早期版本每次运行都会发布到真实仓库来证明流程可用；由于 repo 权限不能删仓库，每次运行都留下一个用户必须手工清理的产物。一个会写真实账号的测试不是测试，是带了断言的副作用。
真实网络路径由一个不属于测试套件的脚本单独、刻意地检查一次：
node test/live-verify.mjs --i-know-this-creates-a-repo
没有那个标志它会拒绝运行，并复用同一个固定仓库名，所以反复运行不会累积产物；结束时打印清理链接。
repo 权限不能删除仓库 —— 那需要 delete_repo。所以本工具从不提供清理功能，删除是手工步骤。--force 会覆盖分支。不带它时，已有提交的分支不会被强行改写（GitHub 会以非快进拒绝，本工具会报告该错误）。.gitignore。MIT