一键发布 KNLCXY/dsh-release

dsh-release

给 DeepSeek Harness 一个 release 工具：一次调用把发布走完，并用 sha256 证明三处一致。

仓库：<https://github.com/KNLCXY/dsh-release> · 尚未发布到 npm（见下面「安装」）

release({ action: "prepare", repo: "…/repo/dsh-websift" }) ← 先看计划，什么都不改
release({ action: "apply", repo: "…/repo/dsh-websift", bump: "patch" })

它解决什么

发布一个包要经过这么多步，每一步都能单独出错：

版本同步 → 测试 → npm pack → 提交 + 打 tag + 推送 → GitHub Release + 传附件 → npm 发布 → 核验

而且 发布不可逆，npm 的 publish 又返回 202 Accepted（异步受理）—— 光看命令退出码根本不知道到底上线了没有。已经踩过的坑就在眼前：npm publish 明明成功，registry 上却还是旧版本。

这个工具的两条硬规矩：

1. 默认只出计划。 action: "prepare" 不改任何文件、不写任何远端，只把「要发什么、有什么风险、下一步敲什么」摆出来。真正动手必须显式 action: "apply"。
2. 只在 registry 上真的查到、且哈希对得上时才说「发出去了」。 报告里的每一行都有出处：
npm 下载回来的 tarball 算 sha256 和本地比，GitHub Release 附件的 digest 和本地比。

在这台机器上尤其有用

它面对的是一台 PATH 里没有 node、也没有 npm 的机器：

| 需要 | 它怎么解决 |
| git | PATH → ~/.dsh/profiles//node_modules/@dsh-ops/…/ucrt64/bin/git.exe → 常见安装位置，逐个探活 |
| npm | 本机 npm → 从 registry 下载一份 npm CLI 缓存到 ~/.dsh/storages/release/npm/（自带的 tar.gz 解包器） |
| node（给 npm test 里的脚本用） | 造一个 node.cmd 垫片，用 ELECTRON_RUN_AS_NODE=1 <DSH 的 Electron> 当 Node |
| GitHub 令牌 | 插件配置 → GITHUB_TOKEN/GH_TOKEN → dsh-github 的存储 → git credential fill |

所以这台机器上不需要预先装任何东西。

安装

从 GitHub（当前唯一的发布渠道）
dsh plugin --profile desktop add github:KNLCXY/dsh-release

或者本机源码目录
dsh plugin --profile desktop add file:/path/to/dsh-release

尚未发布到 npm。 这个生态里已经有 dsh-release- 一大堆同类工具（发布自检、证据、门禁……），其中一个仓库名和功能描述都和这里高度重合。所以先只留 GitHub —— 名字留着，不急着往拥挤的
npm 命名空间里再塞一个。真要 npm i 的时候，release({action:"apply"}) 一条命令就能发。

改完源码要 bump package.json 的 version 再重新 add（pnpm 是按版本号判断是否复制的），并且重启 DSH 才会加载宿主半。

工具：release

| 参数 | 说明 |
| action | prepare（默认）/ apply / setup-ci / verify |
| repo | 仓库目录，默认=当前会话工作目录 |
| version / bump | 目标版本；bump 取 patch/minor/major |
| channel | auto（默认）/ token / stage / ci |
| prerelease | auto（默认）/ true / false |
| changelog_entry | apply 时插进 CHANGELOG.md 顶部的本版说明 |
| notes / name / message | Release 正文、标题、提交信息 |
| install / profile | 发布后把产物装进某个 DSH profile |
| github / tag / skip_tests | 关掉某一步 |

apply 的顺序固定：

版本同步 → 测试 → npm pack → git commit/tag/push → GitHub Release → npm 发布 → 核验 → (可选) 装进 profile

任一步失败就停下，报告里说明卡在哪一步、原始错误是什么。

三条 npm 通道

npm 正在淘汰「长期免验证码的令牌」：账号类操作从 2026-08 起要交互式 2FA，
直接发布预计 2027-01 起也会失去（7-31 公告）。

| 通道 | 什么时候用 | 怎么走 |
| token | 现在最省事 | 本机 ~/.npmrc 里有可用凭证，直接 npm publish |
| stage | 令牌不能直接发之后 | npm stage publish 送进暂存区，你在网页用 2FA 批准才公开 |
| ci | 想彻底不碰令牌 | 打 tag → GitHub Actions 用 OIDC 换一张一次性凭证发布 |

channel 默认 auto：仓库里已经有 OIDC workflow 就走 ci（本地不再 publish，避免两边抢同一个版本号）；否则有可用凭证走 token；都没有就退回 stage。

配置 OIDC（一次的事）

release({ action: "setup-ci", repo: "…/repo/dsh-websift" })

会生成一份 .github/workflows/release.yml（含 id-token: write，并把 runner 自带的 npm 升到 trusted publishing 要求的 ≥ 11.5.1），然后告诉你 npm 侧要敲的命令：

npm trust github <包名> --file release.yml --repo <owner>/<repo> --allow-publish

⚠️ 这一步必须交互式 2FA：bypass 2FA 的令牌从 2026-08 起做不了 trusted publishing 配置（实测 npm trust list dsh-websift 直接 403）。网页入口： https://www.npmjs.com/package/<包名>/access → Trusted Publishing。
workflow 文件名必须一字不差（含 release.yml 这个扩展名），否则 OIDC 校验会失败。

配好之后 channel 自动选 ci：本地只推 tag，npm 由 CI 发。

发布口径

沿用既定规矩：0.x 一律预发布（GitHub Release 标 prerelease，不算 Latest），1.x 起算正式版。
可用 prerelease: "true"/"false" 覆盖。

配置

运行时配置写在 ~/.dsh/storages/release/settings.json，优先级高于 cordis.patch.yml 里的出厂默认：

{
"gitPath": "",
"npmCli": "",
"npmVersion": "",
"githubToken": "",
"profile": "",
"access": "public",
"verifyTimeoutMs": 240000
}

GET http://127.0.0.1:<GUI 端口>/_release/settings 可以看到当前探到的 git 与存储位置。

开发

本机没有 node/npm，用 DSH 自带的 Electron 当 Node 跑：

export ELECTRON_RUN_AS_NODE=1
EXE="C:/Users/Administrator/Desktop/DeepSeek Harness/DeepSeek Harness.exe"

"$EXE" test/test-semver.mjs # 版本号 "$EXE" test/test-policy.mjs # 口径 / tag / 通道选择 "$EXE" test/test-pack.mjs # npm pack 输出解析（npm 12 是对象、老版是数组） "$EXE" test/test-plan.mjs # 计划卡片排版 "$EXE" test/test-fixture.mjs # 真临时 git 仓库上跑 prepare / setup-ci（离线，假 npm） "$EXE" test/diag-env.mjs # 需要联网：npm 自举 + 真 pack

test-fixture.mjs 用 test/stub-npm-cli.js 顶替 npm，所以除了一次只读的 registry 查询之外全程离线。

和同类工具的关系

DSH 生态里「发布工具」不算少。2026-10-24 查过一圈，比较接近的有：

| 项目 | 它做什么 | 和这里的区别 |
| JOJO-Adam/dsh-release | 描述同样是「一条命令走完 check/bump/test/push/publish/verify/install」 | 名字和定位高度重合，各写各的 |
| dsh-publish-plugin（npm） | 一键发到 npm + GitHub，fail-closed | 同样默认不执行；发布流程重叠 |
| dsh-testkit（npm） | 真宿主发布门禁：装进真 DSH 跑生命周期 | 它验运行时行为，这里比字节 |
| dsh-release-proof | 「多源可复现发布证据」 | 最接近这里的哈希核验那块 |
| dsh-release-guardian / -guard / -sentinel / -selfcheck / -evidence / -infringement-audit | 各类发布风险检查、合规审计 | 覆盖 prepare 的一部分 |

这里的两条差异（没有逐行读过别人的源码，所以只敢说是「没看到」而不是「没有」）：

1. 三处字节一致：npm tarball 的 sha256、GitHub Release 附件的 digest、本地 npm pack 的产物，两两相等才算成功。任一不一致就报失败并写出两个哈希。
2. 令牌迁移：token / staged / OIDC 三通道按仓库现状自动选，setup-ci 直接生成 id-token: write 的 workflow —— 应对 npm 2027-01 起停掉 bypass-2FA 令牌直接发布。

另外它是在一台没有 node、没有 npm、git 在插件包里的机器上长出来的，所以 lib/proc.js 里那套工具链自举（找 git、下 npm、造 node 垫片）对同类环境可能也有用。

已知限制

- 只在 Windows 上实测过；代码里对 POSIX 做了分支，但没跑过。
- ci 通道是生成 workflow + 给出 npm 侧命令，那一步需要人做 2FA，工具不能替你点。
- npm test 依赖 package.json 的 test 脚本；没有就跳过并如实标注。
- 不处理 monorepo / workspaces，一次只发一个 package.json 所在的目录。
- 不会自动写 CHANGELOG 内容，只做「有没有这个版本的段落」的检查；要自动插段落得显式传 changelog_entry。

License

MIT