v0.7.7

变更

• 审批台账落盘（approvals.json，0600、原子替换）：每会话的放宽额度、本桥创建的会话所有权、尚未还清的放宽欠账都跨重启保留；启动时把上一个进程留下的放宽收回。
• history 补上期限：新增 historyBudgetMs（默认 30000 ms，钳制 100–120000），读不到就以 -32005 结束，不再无限等待；关闭事件流也改成有界（最多等 1 秒），Host 卡住不会再把答案一起拖住。
• 文档：中英 README 逐节对齐；docs/release.md 重写为可执行的手册，并新增 Release 正文模板（本正文即按该骨架写）。

说明

• 等待仍是分片循环：单次 HTTP 响应活不过五分钟（Node fetch 的 300 s headersTimeout，实测 303.9 s 报 fetch failed），片长由 maxWaitSliceMs 控制（默认 120000，上限 240000）。CLI 与 MCP 工具已自动续等，自己写客户端要自己切片。
• 审批任务停在待批时会立刻返回：approvals.mode=delegate 下，轮次若因等你回答而停下，dsh_ask/dsh_wait 返回 status:"waiting-approval" 与 pendingApproval，而不是死等到 deadlineMs。
• 已知边界：① token 对桥创建的子会话可读（同机同用户），delegate 防的是误操作与提示注入，不防同用户进程自我批准；② 闸门只拦工具参数里的 sandbox_permissions，configure 改预设被禁止，但"创建会话时调用方自选预设"不受闸门约束；③ 放宽额度按会话，重启不再清零，新建会话仍重新计三次。

验证

项	结果
单测（十套件）	methods 76 · mcp-format 19 · registry 8 · pending 36 · approvals 11 · approval-state 8 · wait 6 · abort 7 · client 6 · status 6 = 182 例
真宿主集成	test/host.test.mjs 1 例
端到端 / 边界	test/e2e.mjs 14 例、test/edge.mjs 24 例（最近一次运行 2026-11-05）
版本一致性	check:version → version ok: 0.7.7
打包完整性	check:package → 32 files, 485.2 KB unpacked, 172.3 KB packed
CI	合入提交 27c09df 的 test run #42220725409 双绿（Node 22.x / 24.x）

本机沙箱限制：abort 套件里一条用例需要 spawn 子进程，在 workspace-write 下被以 EPERM 拒绝，因此本机 npm test 退出码为 1（170 通过 / 该例环境性失败）；同一提交的 CI 在无此限制的环境下双绿，故以 CI 为发布依据。这是环境边界，不是代码失败。

安装

dsh plugin add @punchact/dsh-rpc-agent@0.7.7

v0.7.6

v0.7.6

从 npm 上现存的 0.5.3 起算，这一版把 0.5.4 → 0.7.6 四个版本一起交付。

变更

0.5.4 · 长调用不再被单次 HTTP 请求的寿命卡死

• 等待预算按 120 秒切片循环，片长默认 120 s、硬上限 240 s；dsh.discover 回报 maxWaitSliceMs，被钳制时另报 maxWaitSliceMsRequested。
• 截止不再只靠中止：读流与既有截止赛跑，超时立刻收成本次结果，不等宿主交还控制权。
• 清理有界：事件流的 return() 最多等 1 秒，答案不依赖清理是否完成。

0.6.0 · 调用方断开时中止，并把非失败结局与错误分开计

• res.on("close") → 中止本次调用；轮次照旧继续，桥只是不再空等。
• MCP 的 notifications/cancelled 真的会中止在途调用。
• /status 新增 calls.outcomes: { timeouts, cancelledByClient }；被中止的调用不再计入 errors。

0.7.0–0.7.6 · 无人值守会话撞上审批墙时，桥能回绝，也能把决定交回派发方

• 三档 approvals.mode：off（默认）/ deny（桥直接回绝升权）/ delegate（派发方 agent 回答）。
• 两个新方法：dsh.approvals.pending（长轮询 ≤120 s）与 dsh.approvals.resolve。
• 轮次停在待批时立刻返回 status: "waiting-approval" 与 pendingApproval，而不是把调用方拖到超时。
• allow-once 只在被批准的那次调用期间放宽预设，调用结束（或下游拒绝、或 5 分钟兜底到期）即恢复；同一会话同一时刻只允许一条待批。
• 按两轮独立审计收窄：决策包递归脱敏并带 untrusted 标记、所有权只认桥创建的会话、改预设走所有权与模式校验、闸门任何异常都降级放行。

说明

• approvals.mode 默认仍是 off：不开就与旧版行为一致，升级不会改变任何现有会话的行为。
• 已知边界（本轮不修）：子会话与桥同用户，能读到 ~/.dsh/dsh-rpc/token，因此 delegate 挡不住「拿到 token 的子代理自己批准自己」。默认 off 时不触发；开启前请确保子代理可信。
• 3 次升权额度与所有权记录仍在内存，宿主重启后清零。

验证

• 单元/契约：172 例通过（methods 74、mcp-format 19、pending 36、approvals 11、registry 8、wait 6、abort 6/7、client 6、status 6）+ 宿主集成 1 例 + catalogue ok。唯一未通过的是 abort 套件里那条需要 child_process.spawn 的用例，在本机沙箱里报 EPERM，CI 上通过。
• 打包：31 files, 432.3 KB unpacked, 153.8 KB packed。
• 真宿主端到端（本机 profile）：allow-once、reject、到期、取消、preset 上报五条路径全部跑通；批准后命令确实按新预设执行，拒绝/到期/取消时命令确实未执行。
• CI：main 的 run 42214271524 双绿（Node 22.x / 24.x）。

安装

dsh plugin add @punchact/dsh-rpc-agent

或在 profile 里 install_bundle("@punchact/dsh-rpc-agent@0.7.6")。MCP 侧接法见 README 的「接进 MCP 客户端」一节。

v0.5.3

变更

• dsh.discover 现在返回 config（defaultTimeoutMs、maxWaitSliceMs 等），MCP 层的默认预算与提示文案从这里读，不再各自复制一份。

说明

0.5.1 与 0.5.2 都没有发布到 npm，这一版把三段改动一并带上：

• PR #9：MCP 渲染三处（句柄不再打印 turn ?、completed 不再重复打印 reason、错误不再 dump 已经说过的字段）；红队审计提出的 reason 判据与两处测试守门；以及 prompt 丢失 model/reasoningEffort 参数——它此前只读 sessionId/text/mode，静默落回会话默认模型。
• PR #10：等待改成分片循环。Node 内建 fetch 的 300 秒 headersTimeout 会掐死任何"静默五分钟才回响应"的请求（实测 303.9 秒报 fetch failed），这与推荐的 timeout_ms: 600000 直接冲突。
• PR #11：dsh.discover 此前只回 plugin/version/protocol/transport/methods，没有 config——于是 0.5.2 里"默认值只有一个来源"在实现上并不成立，客户端读到 undefined 就退回写死的 600000。现在由测试守着这条契约。

验证

• 单元与集成：methods 68、mcp-format 18、wait 3、registry 8、client 6、status 6、host 1、catalog.smoke 14 项全过
• check:version → version ok: 0.5.3；check:package → 27 files、340.4 KB unpacked
• 现网分片证据：waitForTurn 对真桥，片长 3000 ms、预算 9000 ms → slices: 3、waitedMs: 9015、wallClockMs: 9015；dsh-rpc wait --timeout 20000 准时 20.0 秒返回
• CI：PR #11 的 run 42156700937 双绿；合并后 main 的 run 42157124395 双绿
• 未验证项：片长 240 秒的单次 wait 在超大会话（19008 条事件）上跑过一次 13 分钟未返回，原因未查明

安装

dsh plugin add @punchact/dsh-rpc-agent

v0.4.4

变更

• 发布流水线（.github/workflows/release.yml）：发布 job 不再向 setup-node 传 registry-url；toolchain 步骤打印 node / npm 版本并检测 OIDC 请求端点是否可用；publish 步骤改为仅在存在 NPM_TOKEN 时写入 ~/.npmrc
• 版本号 0.4.3 → 0.4.4（package.json、lib/version.mjs）
• CHANGELOG.md 增补 0.4.4 段

说明

本版没有运行时改动，只改发布流水线与版本号。

背景：由 GitHub Release 触发的发布连续两次以 npm error code ENEEDAUTH 失败。根因既不在令牌，也不在 npm 侧的信任关系条目：setup-node 收到 registry-url 后会写入一行

//registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN}

仓库没有配置 NPM_TOKEN 时，该行展开为空令牌，npm 判定"凭证存在但不可用"并直接拒绝，根本不会进入 OIDC 交换。移除 registry-url 后，本版由 Trusted Publishing（OIDC）发布成功，首次带上 SLSA provenance。

验证

• 干跑（workflow_dispatch + dry_run=true）：verify 全绿；发布 job 输出 node v24.22.1, npm 11.19.1 与 OIDC: request endpoint present — id-token: write is in effect，唯一报错是版本已存在（You cannot publish over the previously published versions: 0.4.3），即认证已经通过
• 正式发布（release 事件）：verify 与 publish 两个 job 均为 success；日志含 no NPM_TOKEN secret configured — relying on Trusted Publishing (OIDC) 与 + @punchact/dsh-rpc-agent@0.4.4
• 注册表核对：latest = 0.4.4，25 个文件，unpacked 264843 B，shasum 9b897d15219884a98eb753c93eb0e5e975fee9af
• provenance：GET https://registry.npmjs.org/-/npm/v1/attestations/@punchact%2Fdsh-rpc-agent@0.4.4 → 200，predicate 含 npm publish/v0.1 与 https://slsa.dev/provenance/v1
• 本地套件：单元测试 41、客户端 6、状态页 6、真宿主集成 1、方法目录冒烟 1，全部通过；node scripts/check-package.mjs 25 个文件

安装

dsh plugin add @punchact/dsh-rpc-agent

v0.4.3

变更

• docs/design.md 不再出现开发早期的包名，只保留"改过一次包名"这件事本身的描述
• 测试夹具的示例路径改用中性的 /home/dev/...
• 仓库历史一并重建：早期提交里写死本机绝对路径的那几行、以及早期包名，已从历史中抹去

说明

这一版没有任何运行时变更。发版是为了让 npm 上的 latest 指向不含这些字样的产物。

验证

• npm run check:version → version ok: 0.4.3
• 单元测试 41 项、客户端 6 项、状态页 6 项、真宿主集成 1 项、冒烟检查 1 项，全部通过
• node scripts/check-package.mjs → 25 个文件、258.0 KB unpacked、91.6 KB packed
• 全新 clone 复核：12 个可达提交中 andy / C:\Users / 插件项目路径 0 命中