Repository navigation

Releases

dsh-notify 0.6.0 Latest

Latest

having5548 released this 17 Oct 05:54

v0.6.0

7bd9ce7

dsh-notify 0.6.0

前台后台都会响提示音了。 之前提示音只在 DSH 有焦点时播放，窗口切到后台就只剩一个静音的系统通知。

改了什么

每条通知现在在两种状态下都响，但只响一次：

状态	谁发声
焦点在 DSH	页面内的 `<audio>` 播放自带的 `notify.wav`（与之前一致）
焦点不在 DSH	页面保持安静，由系统原生通知发声

之所以不两边同时响，是为了避免同一条通知响两遍。

为什么不干脆让页面一直播？ 浏览器会限流后台标签页的播放，后台标签页里的 Audio.play() 并不可靠——这正是把后台的声音交给系统通知的原因。

平台细节

Windows：dsh-toast.ps1 现在往 toast XML 里写显式的
<audio src="ms-winsoundevent:Notification.Default" loop="false"/>，
不再依赖「没有 <audio> 元素时系统用默认音」这种隐式行为；
关闭「提示音」时写 <audio silent="true"/>。
macOS：osascript 的 display notification 加上 sound name "default"；
关闭「提示音」时省略该子句（不写就是静音）。

兜底

如果「系统通知」通道被关掉，后台会退回页面内发声（尽力而为，可能被浏览器限流）。

客户端在请求原生通知时带上 sound 字段；服务端未收到时默认按开启处理，旧客户端不受影响。

回归测试

新增三组断言，覆盖全部三条路径：

前台：不请求原生通知，页面内放音一次
后台：请求一次原生通知且 sound: true，页面内不放音
后台 + 系统通知关闭：退回页面内放音

测试里有个坑值得记：插件是在 focus/blur 事件回调里读 document.hasFocus() 的，
所以测试必须真的派发这些事件，光改一个布尔变量不生效。

安装

# 从 npm
dsh plugin --profile desktop add @having5548/dsh-notify

# 或从本页附件
dsh plugin --profile desktop add having5548-dsh-notify-0.6.0.tgz

安装后重启 DSH 生效。

新版桌面端的 profile 名是 desktop；旧版 Web 是 web。

环境

DSH ≥ 0.1.7-rc.2（已在 0.1.7-rc.2 / 0.2.0-rc.2 上核对）
Windows 10+ / macOS

完整改动

见 7bd9ce7。

Assets

having5548-dsh-notify-0.6.0.tgz — 插件安装包
SHA256：6AA6C5B81672AE7D90E3D41CECE4C4B5C68BBF7241C93FBDD2A0A9AA55872161

Assets 3

dsh-notify 0.5.0

having5548 released this 30 Sep 10:10

v0.5.0

6ea8f7c

dsh-notify 0.5.0

适配 DSH 0.2.0-rc.2 + 两项降噪优化。

如果你在用 0.4.0 且一切正常，这一版没有必须升级的理由——它不会修掉你遇到的任何故障，只是让通知更安静、更省资源。在 DSH 0.1.7 / 0.2.0 上都可用。

先说兼容性：这次没有 API 漂移

对当前打包版 DSH（0.2.0-rc.2，Electron 构建）逐项核对，插件用到的客户端接口全部健在：

接口	状态
`ctx.uiSession.sessionStatus` / `adapter.current`	✅
`ctx.configForms.get(entryId)`	✅
`ctx.jobs.state` + `watchRows`	✅
`settings.section` 槽位	✅
`ctx.on('session/event')` / `webServer.register`	✅
`ctx.settingsScope`	✅ 仍然不存在（0.1.7 起就已移除）

也确认了 dsh.client.platform 仍必须是 "web"——新版桌面端是 Electron 外壳，渲染的是同一套 Web 客户端。

优化一：子代理会话静音 🤖

DSH 会给每个子代理分配独立会话（客户端 SessionSummary.origin、服务端 session.header.origin 都是 'subagent'），而它们每一轮都会发 turn/end。

后果是：一次 fan-out 工作流（并行子代理、workflow 编排）能瞬间刷出几十条「新会话已创建」和「任务完成」，把真正属于你的任务通知淹掉。

本版在两侧都做了过滤：

服务端在 broadcast 之前就拦掉子代理的 turn/end（连流量都不产生）
客户端的「新会话」与 turn-end 两条路径各自独立过滤

审批 / 待回答类通知不过滤。 子代理同样可能请求授权，漏掉一次授权的代价远大于多一条通知。

优化二：任务订阅有界 📉

ctx.jobs 的任务名册是按会话订阅的（ctx.jobs.watchRows），每个订阅在服务端是一条常开的 job.list 流。

之前的实现给会话列表里的每个会话都开一条——本机上就是 45 条流，其中绝大多数永远不会再有任务。

现在只订阅「可能还有任务在跑」的会话：

当前会话
正在运行的会话（任务只可能在运行期被创建）
12 小时内活跃过的会话（兜住「轮次已结束但任务还在跑」）
名册里当前仍有任务的会话（任务比会话活动活得更久时继续盯着）

订阅会在会话列表变化、以及切换当前会话时重算。

回归测试扩充

tools/smoke-client.mjs 新增覆盖：

子代理会话不产生「新会话」通知
子代理的 turn/end 不产生通知（普通会话的仍通知）
48 小时未活动的会话不会被 watchRows
切换当前会话时立即补上它的订阅

node tools/smoke-client.mjs

安装

# 从 npm
dsh plugin --profile desktop add @having5548/dsh-notify

# 或从本页附件
dsh plugin --profile desktop add having5548-dsh-notify-0.5.0.tgz

新版桌面端的 profile 名是 desktop（旧版 Web 是 web）。可以先用 dsh plugin --help 确认。

安装后重启 DSH 生效。

环境

DSH ≥ 0.1.7-rc.2（已在 0.1.7-rc.2 与 0.2.0-rc.2 上核对）
Windows 10+ / macOS

完整改动

见 6ea8f7c。

Assets

having5548-dsh-notify-0.5.0.tgz — 插件安装包
SHA256：141FFCDF47A98188AEB2177F7CE0C024B16401695B4707BED6C6B5B54A4CD20B

Assets 3

dsh-notify 0.4.0

having5548 released this 26 Sep 05:47

v0.4.0

c6341b1

dsh-notify 0.4.0

⚠️ 本版为 DSH 0.1.7 适配版。 如果你的 DSH 是 0.1.5 或更早，请留在 0.3.2；如果已经升到 0.1.7+，那么 0.3.x 装上后插件完全不会加载，必须用本版。

症状：插件静默停在 pending

升级 DSH 后，Web 端启动会报：

Failed to load plugins
web boot: 1 entry did not activate
@having5548/dsh-notify: pending (waiting for service: settingsScope)

cordis 会一直挂起一个插件，直到它 inject 的每个服务都存在。0.1.7 把 settingsScope 删掉了，于是插件永远等下去——整个插件不加载，而且没有任何报错，连通知都发不出来。

DSH 0.1.5 → 0.1.7 变了什么

用途	0.3.x（0.1.5 写法）	0.4.0（0.1.7 写法）
设置读写	`ctx.settingsScope.bind({namespace})`	`ctx.configForms.get('dsh-notify')`
待审批 / 待回答	`uiSession.pendingInteractions`	`uiSession.sessionStatus` → `pendingInteraction`
后台任务	`sessions.list.jobsBySession`	`ctx.jobs.state.rows`（+ 按会话 `watchRows`）
当前会话	`sessions.list.current`	`uiSession.adapter.current.getSnapshot().key`
服务端设置	`ctx.settings.register(ns, schema)`	导出 `Config` schema，`apply(ctx, config)` 直接读

session/event、webServer.register、settings.section 槽位都没有变。

本版最重要的改动：不再硬依赖可选服务

光换服务名只解决这一次。真正的病根是硬 inject——任何一个服务被改名或移除，插件就整体静默死亡，而界面上只有一个 pending。

所以本版把 inject 收窄到只剩骨架服务：

var inject = ['sessions', 'slots']

configForms / uiSession / jobs / locale 全部改为 ctx.get() 惰性解析，缺哪个就只关掉对应功能并在控制台留一条 warn。宁可少一个功能，也不能整个插件不加载。

后台任务的行为变化

0.1.7 的任务名册是按会话订阅的（引用计数），不再能被动读取。本版会跟随会话列表，为每个列出的会话调用 ctx.jobs.watchRows()，并在会话移出列表时释放订阅。

新增回归测试

tools/smoke-client.mjs —— 打桩跑，无需浏览器：

node tools/smoke-client.mjs

覆盖 sessionStatus / jobs / configForms / 优雅降级共 9 组断言。这类 bug 没有它根本看不见（插件静默 pending、零报错）。每次 DSH 升级后请先跑它。

该目录不在 files 字段内，不会进入 npm 包。

安装

# 从 npm
dsh plugin --profile web add @having5548/dsh-notify

# 或从本页附件
dsh plugin --profile web add having5548-dsh-notify-0.4.0.tgz

安装后重启 DSH Web GUI 生效。

环境

DSH ≥ 0.1.7-rc.2（0.1.5 及更早请用 0.3.2）
Windows 10+ / macOS

Assets

having5548-dsh-notify-0.4.0.tgz — 插件安装包
SHA256：0BC7AB229E95AADC2CF2952EC56162E4E38B2FE5A17F3F91C474F9BCAB8160CE

Assets 3

dsh-notify 0.3.2

having5548 released this 26 Sep 00:25

v0.3.2

5264499

⚠️ 本版只适用于 DSH ≤ 0.1.5。 在 DSH 0.1.7+ 上，本版的 inject 仍依赖已被移除的 settingsScope 服务，插件会永远停在 pending、完全不加载。请改用 0.4.0。

dsh-notify 0.3.2

⚠️ 装过 0.3.1 的（GitHub Release 或 npm）请务必升级到本版。 0.3.1 的包名改造只做了一半，装完后插件在 DSH 启动时直接加载失败——不是静默降级，是起不来。

0.3.1 坏在哪

0.3.1 把包名从 dsh-notify 改成了 @having5548/dsh-notify（为的是避开 npm 上同名的第三方包 Pasumao/dsh-plugin-notify），但只改了 package.json 的 name。DSH 还会把这个包名用在另外两处模块解析上，它们当时都还是裸名：

位置	0.3.1 的值	正确值
`cordis.patch.yml` 里 insert 的 `name`	`dsh-notify`	`@having5548/dsh-notify`
`lib/client.js` 的 `__ModuleLoader__.load({ id })`	`dsh-notify`	`@having5548/dsh-notify`

前者是插件的模块说明符，必须能被 require.resolve 解析；
后者是客户端 bundle 注册的 id，DSH 侧会校验，不匹配会抛 bundle ... loaded without registering "<id>"。

从 profile 目录实测：

dsh-notify              ->  MODULE_NOT_FOUND
@having5548/dsh-notify  ->  OK

本版修复

cordis.patch.yml：name 改为 '@having5548/dsh-notify'
lib/client.js：__ModuleLoader__ 的 id 改为 '@having5548/dsh-notify'
补上 npm 元数据：repository / homepage / bugs，以及 publishConfig.access: public（作用域包默认 restricted，不加会发布失败）
版本号 0.3.1 → 0.3.2。pnpm pack 的产物名由包名派生，作用域包会输出 having5548-dsh-notify-<版本>.tgz，README 的安装示例同步更新

故意保持不变的内部标识

settings 命名空间、locale 命名空间、/dsh-notify/* 路由、settings.section 的 id 全部仍是 dsh-notify —— 改了会重置你已有的通知设置。服务端导出的插件名也仍然是 dsh-notify（官方 dshmarket 的包名是 dshmarket、导出名却是 dsh-market，可见这里没有强制一致的要求）。

安装

# 从 npm（推荐，作用域名不会被别人占用）
dsh plugin --profile web add @having5548/dsh-notify

# 或从本页附件
dsh plugin --profile web add having5548-dsh-notify-0.3.2.tgz

安装后重启 DSH Web GUI 生效（重启会中断当前会话，先保存手头任务）。

环境

Windows 10+ / macOS，DSH Web GUI（dsh web）
全部所用 API 已在 dsh 0.1.5-rc.2 上逐条核对

完整改动

见 5264499 与 9a15962。

Assets

having5548-dsh-notify-0.3.2.tgz — 插件安装包
SHA256：B9B1FE81CAD60A2784BB38E500005772B257BF05208B62942371EE5ED9371967

Assets 3

dsh-notify 0.3.1

having5548 released this 12 Sep 11:48

v0.3.1

25e72fa

⚠️ 本版有缺陷，请改用 0.3.2。
本版的包名改造只做了一半：cordis.patch.yml 的 specifier 与客户端模块 id 仍是裸名 dsh-notify，装完后插件会在 DSH 启动时加载失败。npm 上对应的 @having5548/dsh-notify@0.3.1 同样受影响。

dsh-notify 0.3.1

DeepSeek Harness 通知插件 — 新会话 / 待审批 / 待回答 / 任务完成 / 任务中断 / 后台任务，一个都不错过。

⚠️ 如果你在用 0.2.x，这次升级是必须的

0.2.x 的「批准 / 拒绝」按钮和「待回答 / 计划审阅」通知，在当前 DSH 上是静默失效的：

客户端读的是 SessionSnapshot.pending 和会话列表行的 pendingInteraction 字段；
这两个字段在当前 DSH 客户端 API 里都已经不存在了。

后果是：审批通知照弹，但按钮点了没有任何反应（内部轮询 6 秒后悄悄放弃），而且「待回答 / 计划审阅」两类通知从来不触发。因为每一步都吞掉了异常，界面上看不出任何报错。

本版把这条链路整体迁移到官方事实源 ctx.uiSession.pendingInteractions —— 也就是 DSH 自己的审批面板和侧边栏角标用的同一个数据源。

修复

「批准 / 拒绝」真正可用 — 直接调用 PendingApproval.answer('allowed-once' | 'rejected')，不需要先打开会话、不需要轮询。请求已被其它界面应答时会明确报错，不再静默失败。
「待回答 / 计划审阅」通知恢复 — 由 pendingInteractions 的 kind: 'question' / 'plan-review' 驱动，通知正文带上第一个问题的内容。
待办解决后 Toast 自动撤下 — 你在审批面板里处理掉之后，右上角那条通知会自己消失，不用手动关。
消除重复通知 — 服务端 SSE 不再广播 approval/asked。客户端本地已经有权威事实源，两条路径并存会让同一次审批弹出两条通知（tag 不同，服务端那层 800ms 去重拦不住）。
不再硬依赖 uiSession — 改用 ctx.inject 延迟接线。万一该服务缺席或形状变化，只损失审批/问答这一类通知，其余功能照常，而不是整个插件不加载。
修正通知日志在失焦时的通道标注（此前会误标成「应用内+系统」）。

变更

移除 wscript + dsh-activate.vbs + dsh-notify:// 自定义协议激活链路。
原生通知现在只负责提醒：不注册自定义协议、不创建 .lnk、不调用脚本宿主、不做点击回调 / 一键审批 / 带回前台。这是为了避开 360 / 火绒这类安全软件对「脚本宿主 + 自定义协议」组合的误报。待审批请回到 DSH 界面，在应用内通知或审批面板里处理。

安装

dsh plugin --profile web add dsh-notify-0.3.1.tgz

安装后重启 DSH Web GUI 生效（重启会中断当前会话，先保存手头任务）。

环境

Windows 10+ / macOS，DSH Web GUI（dsh web）
全部所用 API 已在 dsh 0.1.5-rc.2 上逐条核对：ctx.settings.register、ctx.on('session/event')、turn/end 的 reason.kind、ctx.sessions.list 快照结构、ctx.uiSession.pendingInteractions、ctx.slots 的 settings.section、ctx.settingsScope.bind、ctx.locale
原生通道：Windows 走 PowerShell 5.1 + 内置 WinRT（只写 HKCU 的 AUMID，无需管理员）；macOS 走系统自带 osascript

完整改动

协议与内部实现细节见 25e72fa。

Assets

dsh-notify-0.3.1.tgz — 插件安装包（dsh plugin add 直接用这个）
SHA256(dsh-notify-0.3.1.tgz) = 40863E9FB985D241B67A8ED184C7E4852F15B6B3574EB90A283BEA9FDDFB4C0D

Assets 3

dsh-notify 0.6.0

dsh-notify 0.6.0

改了什么

平台细节

兜底

回归测试

安装

环境

完整改动

Uh oh!

dsh-notify 0.5.0

dsh-notify 0.5.0

先说兼容性：这次没有 API 漂移

优化一：子代理会话静音 🤖

优化二：任务订阅有界 📉

回归测试扩充

安装

环境

完整改动

Uh oh!

dsh-notify 0.4.0

dsh-notify 0.4.0

症状：插件静默停在 pending

DSH 0.1.5 → 0.1.7 变了什么

本版最重要的改动：不再硬依赖可选服务

后台任务的行为变化

新增回归测试

安装

环境

Uh oh!

dsh-notify 0.3.2

dsh-notify 0.3.2

0.3.1 坏在哪

本版修复

故意保持不变的内部标识

安装

环境

完整改动

Uh oh!

dsh-notify 0.3.1

dsh-notify 0.3.1

⚠️ 如果你在用 0.2.x，这次升级是必须的

修复

变更

安装

环境

完整改动

Uh oh!