长任务完成通知 + 多渠道推送

让 Agent 跑一个半小时的任务，然后去吃饭——回来发现它在第 3 分钟就卡在了一个审批弹窗上。这是远程/挂机使用 DSH 时最普遍的糟糕体验：任务完成了没人告诉你，任务卡住了也没人告诉你。

需求信号

• #5208：要系统级通知卡片，最好卡片里就能直接审批。
• #6712：浏览器声音 + notification 提醒任务完成。
• #2335（5 赞同）：上下文被占满时没有任何提醒，任务无声无息地停掉。

缺口在哪

索引层 notification 主题的仓库有 349 个，但 ≥100★ 的只有 1 个（还是沾边的 dsh-cost-meter 290★）；专注通知的 THEWOLFWALKER/dsh-notifier 95★、omdsh-dev/dsh-notification 83★，都只覆盖单一通道。dsh-im（1,274★）做的是 IM 机器人双向接入，不是通知推送。结论：有对手，没有赢家。

建议形态

Host service 为主：监听会话与轮次事件（任务完成、审批请求、错误中断、上下文将满），把事件路由到可配置的推送通道——飞书/微信（Server酱）/Bark/Telegram/webhook；附一个 Client 设置卡片管理通道与开关。

实现要点

• 事件源：官方事件系统文档 docs/user/develop/framework/events.md，以及子系统文档 session-telemetry.md。DSH 自带 webhook runtime，先评估能否直接复用再自建。
• 审批通知做成「可点击深链回会话」：通知的价值不在告知，在把用户拉回正确的上下文。
• 每个通道独立失败重试与降级；通知插件自己挂掉却静默，比没有通知更坏。
• 设置页走官方 cookbook：adding-a-settings-card.md。

最小可行版本

一个通道（webhook）+ 三类事件（完成/审批/错误）。一周以内。

风险与边界

通知内容可能包含会话摘要等敏感信息，外发到第三方通道前要明示并默认脱敏。这是审核时会重点看的权限面。

FAQ

浏览器自带的 Notification API 不够吗？

只覆盖「人坐在浏览器前」的场景。挂机与远程场景需要离开浏览器的通道，这正是空缺所在。