dsh-notify-me 1.11.0 → 1.13.0

package/CHANGELOG.md

@@ -2,6 +2,58 @@
 
 All notable changes to **dsh-notify-me** are documented here.
 
+## [1.13.0] — 2026-10-23
+
+### 新增
+
+- **外部推送新增三种国内常用目标**（来自 [#17](https://github.com/chromoany/dsh-notify-me/issues/17) 的安卓端诉求）：`feishu`（飞书群机器人）、`serverchan`（Server酱 Turbo 与 Server酱³ 同一套 `…/send/<SendKey>.send` 地址 + `title`/`desp` 表单）、`wxpusher`（`appToken` + 接收者 UID，端点固定，没有可填错的 URL）。三种都走官方接口，浏览器页面能直连确认送达——飞书返回 `Access-Control-Allow-Origin: *`，Server酱与 WxPusher 回显页面 Origin。
+- **失败自动重试与失败记录**：明显临时的失败（网络中断、HTTP 5xx、429）按 `externalRetryDelays`（默认 2 秒 / 6 秒，带 ±25% 抖动）退避重试；其它错误立即停。重试仍失败的投递写进「失败记录」（最多 10 条，只留标题与正文摘要、事件类型与主机名，不留完整端点），设置页可查看与清空。
+- **每个目标可单独启停、并显示最近一次投递状态**：目标行右侧显示「上次成功 / 上次已送出（不可确认）/ 上次失败 + 原因 + 时间」，旁边一个独立开关（`enabled: false`）——某个端点临时不可用就单独关掉它，不必关掉整类事件。
+- **出站签名**：自定义目标填了签名密钥时，请求带 `X-DSH-Notify-Signature`（对请求体做 HMAC-SHA256，`sha256=<hex>`）与 `X-DSH-Notify-Timestamp`；飞书目标填了密钥时按官方算法在请求体里带 `timestamp`（秒）/ `sign`（`base64(HMAC(key = timestamp + "\n" + secret, data = ""))`）。
+- **消息模板**：飞书 / Server酱 / WxPusher / 自定义目标可填模板，占位符 `{{title}}` `{{body}}` `{{event}}` `{{time}}` `{{session}}`；留空是「标题 + 换行 + 正文」。
+- 服务端返回的失败原因如实写进状态：飞书/Server酱/WxPusher 的 `code` 判成功（WxPusher 为 `1000`），失败带上 `error` / `message` / `info` / `msg`。
+
+### 说明
+
+- **钉钉群机器人没有做成目标类型**：实测其接口不返回任何 CORS 头，且只接受 `application/json`——浏览器页面既读不到响应，也无法在 no-cors 下发出合规请求。文档与设置页提示：自建一个中转，用「自定义 Webhook」指向它。
+- **PushDeer / ntfy 同样没有做**：PushDeer 官方安卓客户端已停止维护、接口无 CORS 头；ntfy 自建在安卓上依赖常连保活、默认 `priority` 低于 4 不弹横幅。需要时仍可用自定义目标接自建 ntfy。
+
+### 测试
+
+- 冒烟新增：4 种目标各发一次并逐个校验报文形状（飞书 text + 签名、Server酱 form 编码、WxPusher token/uids、自定义模板与 HMAC 头）；网络错误/5xx 重试到耗尽进失败记录、4xx 不重试、第二次成功只记 `sent`；目标级 `enabled:false` 被裁剪；设置页的类型专属字段、目标启停开关、状态文案、失败记录展示与清空。
+
+### 文档
+
+- README 中英：外部推送整节重写（目标类型、可靠性、状态、签名、模板、钉钉为何不支持），控制台示例补 `externalRetryDelays` 与目标字段形状，已知限制口径同步；致谢加上 [@yuexian7](https://github.com/yuexian7) 与 #17。
+
+## [1.12.0] — 2026-10-21
+
+### 新增
+
+- **人走开但窗口没走也算离开**（来自 [#16](https://github.com/chromoany/dsh-notify-me/pull/16)，[@shrekcg](https://github.com/shrekcg)）：`idleMinutes`（默认 3 分钟，`0` 关掉）内没有任何键鼠输入，就把「窗口在前台」按离开处理——「需要你」照常提醒、「回复完成」按离开规则提醒、`autoDismiss: "present"` 也不再撤掉那条通知。此前只认窗口失焦 / 页面隐藏，人坐在桌前离开座位时一切都还是「你在看」。
+- **闲置到期会补发被压下的审批**（维护者补的）：`currentHiddenOnly` 把当前对话的等待只留标题标记时，原先只有失焦 / 页面隐藏事件才会补发；现在闲置定时器到期即补发，人离开但窗口没动也能收到。一次性触发，队列清空后不重复。
+- **「回复完成」提醒时机三选一**（#16）：`donePolicy` —— `"background"`（默认，旧行为）/ `"smart"`（屏幕上那条静默，别的对话完成照常提醒）/ `"always"`（从不静默），设置页「什么时候提醒」里换成下拉。
+- **通知自动消失三选一**（#16）：`autoDismiss` —— `"present"`（默认，只有你在页面时才计时关闭，离开时收到的留在通知中心）/ `"always"`（旧行为）/ `"never"`（普通通知等你点掉）。带「同意 / 拒绝」的审批通知仍按 12 秒走。
+
+### 移除
+
+- **页内审批卡片整条删掉**：1.11.0 删掉「浮层通道」后，桌面端还留着一张兜底卡片（`dsh-app://` 注册不了 Service Worker，审批按钮画在窗口角落）。结果是审批提醒**同时**弹系统通知和页内卡片——与「只留通知」的目标冲突，而且卡片只在窗口前台时看得见，需要提醒的时刻恰恰不在。现在 `drawOverlayCard` / `showFallbackApprovalCard` / `.dnm-ov-*` 样式 / 「审批卡片位置」设置子行 / `overlayCorner` 配置键 / `debug().card` 全部删除。桌面端的审批提醒就是普通系统通知，点通知回到对话里裁决。
+- 老配置里的 `overlayCorner` 在下次读配置时删掉，其余设置不受影响。
+- `window.__dshNotifyMe.debug()` 去掉 `card`；`doneHiddenOnly` 换成 `donePolicy` / `idleMinutes` / `autoDismiss` / `away`（`doneHiddenOnly` 作为读写别名保留，旧脚本仍能写）。
+
+### 迁移
+
+- 旧配置 `doneHiddenOnly: false` → `donePolicy: "always"`，其余 → `"background"`；写回时两者仍互相同步。
+- `idleMinutes` 默认 3；写 `0` 退回只看窗口失焦 / 页面隐藏。
+
+### 测试
+
+- 冒烟删掉 `cardLayer` / `desktopFallbackCard`，新增 `awayWhileFocusedAndIdle`、`idleFlushesQuieted`、`donePolicyScopes`、`autoDismissPolicy`；设置页用例改为断言「审批卡片位置」子行与旧通道选项都已消失、三档下拉落盘正确、旧配置仍能加载。
+
+### 文档
+
+- README 中英：设置清单换成三档下拉、补闲置判定与通知自收、删「副屏与审批卡片」整节、控制台示例同步、致谢加上 [@shrekcg](https://github.com/shrekcg) 与 #16。
+
 ## [1.11.0] — 2026-10-21
 
 ### 移除

package/README.en.md

@@ -24,13 +24,13 @@
 A notification plugin for DSH Web / Desktop, so you can keep full access off without watching the page all day.
 
 - **When input is needed:** approval, plan review, and questions trigger notifications, sound, and a title marker.
-- **When a background reply finishes:** return to the result; click the notification to open its conversation.
-- **When you leave your computer:** optionally forward alerts to Discord, Bark, Gotify, or your own webhook.
-- **When you do not watch the primary display:** system notifications only ever appear on the primary display; the Desktop approval card is drawn in the page and follows the DSH window onto whichever screen it is on (see [Secondary displays and the approval card](#secondary-displays-and-the-approval-card)).
+- **When a background reply finishes:** return to the result; click the notification to open its conversation. Pick "background only", "quiet for the open one", or "always".
+- **When you walk off but the window stays in front:** over 3 minutes without input counts as away, and the alert still fires; a toast you have not seen is not closed on a timer before you return.
+- **When you leave your computer:** optionally forward alerts to Discord, Bark, Gotify, Feishu group bots, ServerChan, WxPusher, or your own webhook.
 
-> Keep the page or desktop app running; backgrounding / minimizing is fine. System notifications require permission. Approval buttons need a Service Worker: Web (`http://127.0.0.1` or `https`) has one, the Desktop `dsh-app://` pages cannot register one, so their notifications carry no buttons and approvals are decided on a card in the window corner instead.
+> Keep the page or desktop app running; backgrounding / minimizing is fine. System notifications require permission. Approval buttons need a Service Worker: Web (`http://127.0.0.1` or `https`) has one, the Desktop `dsh-app://` pages cannot register one, so their notifications carry no buttons — click the notification to decide in the conversation.
 
-> 🔎 Looking for it? Search `dsh-notify-me`, **message alerts**, **notification**, **desktop notification**, **reminder**, **approval alert**, **external notifications**, **Discord / Bark / Gotify push** or **可操作提醒 / 消息提醒 / 桌面通知 / 需要你操作** (npm keywords include both English and Chinese terms).
+> 🔎 Looking for it? Search `dsh-notify-me`, **message alerts**, **notification**, **desktop notification**, **reminder**, **approval alert**, **external notifications**, **Android push**, **Discord / Bark / Gotify / Feishu / ServerChan / WxPusher push** or **可操作提醒 / 消息提醒 / 桌面通知 / 需要你操作** (npm keywords include both English and Chinese terms).
 
 ## UI Preview
 
@@ -43,7 +43,7 @@ A notification plugin for DSH Web / Desktop, so you can keep full access off wit
 
 ![The Notify me settings page: header, how you get told, when to alert, try it, and the collapsed Advanced block](https://raw.githubusercontent.com/chromoany/dsh-notify-me/main/docs/screenshots/settings-en.png)
 
-Just the plugin panel (the real component, captured before 1.11.0) without the DSH navigation sidebar. Row explanations live in a hover tooltip that appears when the pointer rests on a title, which is why only the titles show here. 1.11.0 removed the "alert type" row at the top; the rest is unchanged.
+Just the plugin panel (the real component, on the same dark theme as the host) without the DSH navigation sidebar. Row explanations live in a hover tooltip that appears when the pointer rests on a title, which is why only the titles show here.
 </details>
 
 ## Installation
@@ -73,14 +73,14 @@ The Electron application manages the `desktop` profile. Do not change the Web co
 2. Open **Settings → Notify me**. Confirm that the section and plugin version at its foot appear, and leave the master switch and sound enabled.
 3. Click **Test "reply finished"** on the settings page. A test notification should appear and sound according to your cue settings. This local test does not forward to external endpoints and ignores the "while the window is in front" toggle.
 
-Web users can also test approval buttons. On Desktop the shell cannot register a Service Worker, so this test draws an in-page card with Approve / Reject in the window corner (since 1.10.4; earlier versions sent a plain notification).
+Web users can also test approval buttons. On Desktop the shell cannot register a Service Worker, so this test sends a plain notification without buttons — click it to open the conversation.
 
 **Optional console check** — in environments with DevTools, you can also run:
 
 ```js
 window.__dshNotifyMe.test("done")        // "reply finished" sample
 window.__dshNotifyMe.test("attention")   // "needs your input" sample
-window.__dshNotifyMe.test("approval")    // Approve / Reject with an active Web bridge; an in-page card on Desktop
+window.__dshNotifyMe.test("approval")    // Approve / Reject with an active Web bridge; a plain notification on Desktop
 window.__dshNotifyMe.debug()             // the bridge field reports the button channel: "active" = buttons work
 ```
 
@@ -102,11 +102,11 @@ dsh-notify-me decouples **supervision** from **sitting in front of the screen**:
 | Event | Default behavior |
 | --- | --- |
 | 🔔 Input needed | Alerts even in the foreground; the conversation on screen keeps only a title marker |
-| ✅ Reply finished | Alerts while the page is hidden / backgrounded |
+| ✅ Reply finished | Alerts while the page is hidden / backgrounded (or "quiet for the open one" / "always") |
 
-**Input needed** covers approval requests, plan review, and questions (`ask_user_question`). Approvals carry Approve / Reject: on Web as a system notification with buttons, on Desktop (which cannot register a Service Worker) as a card drawn in the window corner.
+**Input needed** covers approval requests, plan review, and questions (`ask_user_question`). The Approve / Reject buttons only exist on Web (they need a Service Worker); the Desktop cannot register one, so its notifications carry no buttons — click the notification to decide in the conversation.
 
-**Reply finished** also covers background sessions. A finished but unread session keeps the `✅ Reply finished ·` title marker until opened. Title markers are independent of the "while the window is in front" toggles.
+**Reply finished** also covers background sessions. A finished but unread session keeps the `✅ Reply finished ·` title marker until opened. Title markers are independent of the alert policy.
 
 > **Background** subagent child sessions are **not** alerted about by default: DSH lists each of them as its own session, but they are steps inside the parent conversation's turn, so an alert for them is only noise. The subagent session you have open is not part of this and alerts as usual. Settings → "Ignore subagent sessions" turns the mute off.
 
@@ -118,26 +118,14 @@ Open **Settings → Notify me**. The page runs as how you get told, when to aler
 
 - **Enable reminders**: master switch — off means no toasts, no sounds, and the tab title is left alone;
 - **Sound / Volume**: the switch is direct; the slider folds into that row — click the title (▸ turns into ▾) to reveal it. What it plays comes from Advanced → Alert sound;
-- **Decide approvals from the toast** (on by default): approvals carry Approve / Reject that settle the request in place. On Web that is a system notification with buttons; on Desktop `dsh-app://` cannot register a Service Worker, so the buttons are drawn on a card in the window corner (auto-dismissed after 12 s, one card per approval). Its corner comes from the Corner sub-row underneath — see [Secondary displays and the approval card](#secondary-displays-and-the-approval-card).
-
-### Secondary displays and the approval card
-
-Windows draws system notification banners on the primary display only. There is no setting in Windows and no API in the browser to aim one at another monitor, so with DSH parked on a second screen and the primary display unwatched, a toast is as good as not sent. That part is out of reach — the only thing that can show up on the other screen comes from inside the page.
-
-One thing does: the Desktop approval card. It is drawn in the DSH page, so it appears on whichever display the window sits on, and it carries Approve / Reject (Desktop toasts have no buttons).
-
-- **Position** — the Corner sub-row under "Decide approvals from the toast" shows the current value (bottom right by default); click it open (▸ turns into ▾), then pick top right / bottom right / top left / bottom left. Changes apply immediately;
-- **Approvals only** — plain "needs you" and "reply finished" alerts never draw a card; they are system notifications only;
-- **Lifetime** — an approval card retires after 12 s; clicking the card body opens its conversation. At most 4 cards stack at once;
-- **No notification permission needed** — this path touches no Service Worker and needs no permission.
-
-> 1.11.0 removed the "alert type" choice. The in-page overlay used to work as a standalone channel, but it is only visible while the DSH window is in front — and the moment an alert matters is exactly when the window is in the background. With the overlay chosen, backgrounding left only the sound and the tab marker, which is no alert at all.
+- **Decide approvals from the toast** (on by default): approvals carry Approve / Reject that settle the request in place. On Web that is a system notification with buttons; on Desktop `dsh-app://` cannot register a Service Worker, so the notification carries no buttons — click it to decide in the conversation. The line under the Try-it block states whether buttons are possible here.
 
 ### When to alert
 
-- **Also alert "needs you" while the window is in front** (on): turn it off to hear only once the window goes to the background — another app focused, the window covered, or minimized all count;
-- **Stay quiet for the conversation on screen** (on): a wait belonging to the conversation you are looking at keeps only the tab marker so the approval card stays readable; moving the window to the background restores alerts;
-- **Also alert "reply finished" while the window is in front** (off): by default only background finishes alert (a covered Desktop window counts as background since 1.10.5, not only a minimized one);
+- **Also alert "needs you" while the window is in front** (on): turn it off to hear only once the window goes to the background — another app focused, the window covered, or minimized all count. A window left in front while nobody touches it (3 minutes without input by default) also counts as background; `idleMinutes: 0` restores the window-only rule;
+- **Stay quiet for the conversation on screen** (on): a wait belonging to the conversation you are looking at keeps only the tab marker, so it does not interrupt what you are doing; moving the window to the background or going idle restores alerts;
+- **When "reply finished" alerts** (default "background only"): three choices. "Background only" is the old rule — alert when you are not watching the page; "quiet for the open one" stays silent only for the conversation on screen while any other conversation still alerts (useful with several open); "always" never suppresses. An old profile's "also alert reply finished while in front" switch migrates to this setting;
+- **Dismiss the toast automatically** (default "keep while away"): three choices. "Keep while away" only closes a toast a few seconds later while you are at the page, so one that arrived while you were away is still in the notification centre when you come back; "always close" is the old tidy-up; "never close" leaves plain toasts up until you dismiss one. Approvals keep their 12 s rule and are likewise not withdrawn while you are away;
 - **Ignore subagent sessions** (on): skip background sessions spawned by a subagent — the parent conversation covers them; the one you have open still alerts;
 - **Click a toast to open that conversation** (on): the click switches to the conversation that raised it; in a browser it also brings the window forward, while on the Desktop shell it is flaky — sometimes the window comes forward, sometimes only the conversation switches (see [How the Desktop window gets raised](#how-the-desktop-window-gets-raised)); with several tabs open only one is raised, and off means a click does nothing.
 
@@ -164,12 +152,17 @@ Choose a built-in cue, custom audio file, or system notification sound independe
 
 ### External push
 
-Off by default. Supports Discord Webhook / Bark / Gotify / custom webhooks. Alert text is sent to the addresses you enter; use trusted endpoints.
+Off by default. Supports Discord Webhook / Bark / Gotify / Feishu group bots / ServerChan (Turbo and ServerChan³) / WxPusher / custom webhooks. Alert text is sent to the addresses you enter; use trusted endpoints.
 
 <details>
-<summary>Target URLs, forwarding switches, and test messages</summary>
+<summary>Target URLs, forwarding switches, test messages, and the failure log</summary>
 
-- **External notifications** (default off) — forward each alert to your own push endpoints as well, so it reaches you away from the machine: **Discord Webhook** / **Bark** / **Gotify** / **custom webhook**, any number of targets, each with a type and URL (Discord takes the webhook URL; Bark `https://api.day.app/<device key>`; Gotify `https://<server>/message?token=<app token>`; a custom endpoint receives one POST of JSON: `{source, event, title, body, sessionId, time}`). "Forward 'needs you'" and "Forward 'reply finished'" switch independently; **Send test notification** sends one test message to every target (not limited by those two switches, and never pretending to be a real alert). Forwarding follows exactly the same trigger rules as local alerts ("stay quiet for the conversation on screen" and friends apply to it too); the alert text is sent as-is to the addresses you fill in, so **only use endpoints you trust**;
+- **External notifications** (default off) — forward each alert to your own push endpoints as well, so it reaches you away from the machine: **Discord Webhook** / **Bark** / **Gotify** / **Feishu group bot** / **ServerChan** / **WxPusher** / **custom webhook**, any number of targets, each of which can be enabled or disabled on its own (Discord takes the webhook URL; Bark `https://api.day.app/<device key>`; Gotify `https://<server>/message?token=<app token>`; Feishu the group-bot webhook plus an optional verification secret; ServerChan the full `…/send/<SendKey>.send` URL; WxPusher the appToken and the receiver UID; a custom endpoint receives one POST of JSON: `{source, event, title, body, text, sessionId, time}`). "Forward 'needs you'" and "Forward 'reply finished'" switch independently; **Send test notification** sends one test message to every target (not limited by those two switches, and never pretending to be a real alert). Forwarding follows exactly the same trigger rules as local alerts ("stay quiet for the conversation on screen" and friends apply to it too); the alert text is sent as-is to the addresses you fill in, so **only use endpoints you trust**;
+- **Reliable delivery** — failures that look transient (network error, 5xx, 429) are retried after 2 s and 6 s; anything else stops at once. A delivery that still fails is recorded in the failure log (10 entries at most — title and body snippet plus host only, never the full endpoint), which the settings page shows and can clear;
+- **Per-target state** — the right end of each target row shows how its last delivery went (last delivery ok / sent-unverified / failed with the reason) next to a switch of its own, so an endpoint that is temporarily down can be turned off alone instead of muting a whole alert kind;
+- **Signing** — a custom target with a secret sends `X-DSH-Notify-Signature` (HMAC-SHA256 over the body, `sha256=<hex>`); a Feishu target with a secret carries `timestamp` / `sign` in the body per Feishu's own algorithm;
+- **Message template** (optional) — Feishu / ServerChan / WxPusher / custom targets accept a template with `{{title}}` `{{body}}` `{{event}}` `{{time}}` `{{session}}`; empty means "title, newline, body";
+- **DingTalk is not supported** — its robot endpoint answers no CORS header at all and only accepts `application/json`, so a page can neither read the reply nor send a conforming request (under no-cors the content type is restricted to the safelisted ones). To reach DingTalk, relay it through a machine you control and point a custom webhook at that.
 
 </details>
 
@@ -193,10 +186,9 @@ The last block inside Advanced. The page protocol is detected automatically to t
 ## How it alerts
 
 - **System notification** — a toast through the browser into the Windows action center / macOS Notification Center (clicking it opens the conversation it came from; supported Web environments offer approval buttons, Desktop does not)
-- **Desktop approval card** — `dsh-app://` cannot put Approve / Reject on a toast, so approval alerts also drop a clickable card in the window corner; see [Secondary displays and the approval card](#secondary-displays-and-the-approval-card)
 - **Sound** — WebAudio beeps by default (distinct patterns for "needs you" vs "done"); each kind can instead play a picked audio file, or hand the sound over to the operating system's own notification sound
 - **Tab title marker** — while something is waiting on you, the tab title is prefixed with `🔔 Action needed · …` / `🔔 需要你 · …`; while a background session is **finished but unread**, with `✅ Reply finished · …` / `✅ 回复完成 · …`, gone once you open that session (or it starts running again). Both kinds can be up together, "needs you" first; a host title change is rebased under the markers
-- **External notifications** (optional, default off) — the same alert is also forwarded to the push targets you configure: Discord Webhook / Bark / Gotify / custom webhook — so the push channel on your phone picks it up while you step away from the machine
+- **External notifications** (optional, default off) — the same alert is also forwarded to the push targets you configure: Discord Webhook / Bark / Gotify / Feishu group bot / ServerChan / WxPusher / custom webhook — so the push channel on your phone picks it up while you step away from the machine
 
 This is a **browser-layer** plugin: the DSH page must stay open (minimized or backgrounded is fine — that's exactly the "away" state it watches for).
 
@@ -225,7 +217,7 @@ Two traps are worth remembering: a package listed in `dsh.client.inject` that a
 
 </details>
 
-`1.9.0` neither widens nor narrows that range: the settings page is plain React rendering over the existing CSS variables (every colour carries a fallback) and adds no host API. The overlay, title markers and window raising still go through the 1.7 / 1.8 paths, so **plugin entries stay compatible from 0.1.1-rc.2 through 0.2.1-rc.2**, and stepping back to an older host needs no config change. The only new surface is visual: the bell in the page header is the plugin's own SVG (`docs/brand/`).
+`1.9.0` neither widens nor narrows that range: the settings page is plain React rendering over the existing CSS variables (every colour carries a fallback) and adds no host API. The alerts, title markers and window raising still go through the 1.7 / 1.8 paths, so **plugin entries stay compatible from 0.1.1-rc.2 through 0.2.1-rc.2**, and stepping back to an older host needs no config change. The only new surface is visual: the bell in the page header is the plugin's own SVG (`docs/brand/`).
 
 ## Advanced: console configuration
 
@@ -240,22 +232,28 @@ window.__dshNotifyMe.setConfig({
   enabled: true,           // false = disable all reminders (master switch)
   language: "auto",        // 'auto' follow the UI | 'zh' | 'en'
   attentionHiddenOnly: false, // true = don't alert "needs you" while the page is visible
-  currentHiddenOnly: true,    // true = waits in the conversation on screen keep only the tab marker (replayed once backgrounded)
-  doneHiddenOnly: true,       // false = also alert "reply finished" while visible
+  currentHiddenOnly: true,    // true = waits in the conversation on screen keep only the tab marker (replayed once away)
+  donePolicy: "background",   // "reply finished" policy: 'background' only when away | 'smart' quiet only for the open one | 'always' always alert
+  idleMinutes: 3,             // minutes without pointer/keyboard input before a focused page counts as away (0 = off)
+  autoDismiss: "present",     // toast self-dismiss: 'present' keep while away | 'always' always close | 'never' never close
   ignoreSubagent: true,       // true = never alert for background subagent sessions (the open one is exempt)
-  quickActions: true,         // Approve / Reject on approval alerts
+  quickActions: true,         // Approve / Reject buttons on approval toasts
   sound: true,                // cue toggle (also governs the "system notification sound" mode)
   soundDone: "synth",         // "reply finished" cue source: 'synth' built-in | 'custom' picked file | 'system' OS sound
   soundAttention: "synth",    // "needs you" cue source, same values
   volume: 0.5,                // 0..1
   autoFocus: true,            // clicking a toast opens the conversation it came from
-  quickActions: true,         // Approve / Reject buttons on approval toasts
-  overlayCorner: "bottom-right", // Desktop approval card anchor: 'top-right' | 'bottom-right' | 'top-left' | 'bottom-left'
   externalEnabled: false,     // external-notification forwarding master switch (default off: no endpoint, nothing is sent)
   externalAttention: true,    // forward "needs you" (exactly the same trigger rules as local alerts)
   externalDone: true,         // forward "reply finished"
-  externalTargets: []         // push targets: [{id, type:'discord'|'bark'|'gotify'|'custom', url}]
+  externalRetryDelays: [2000, 6000], // backoff for retryable failures (ms, with jitter; [] = send once)
+  externalTargets: []         // push targets, see the shape below
 })
+// Target shape: {id, type, url, secret?, token?, uid?, template?, enabled?}
+// type: 'discord' | 'bark' | 'gotify' | 'feishu' | 'serverchan' | 'wxpusher' | 'custom'
+// token/uid only for wxpusher (its URL is fixed to the official endpoint); secret signs Feishu bodies
+// and custom HMAC headers; template is optional ({{title}} {{body}} {{event}} {{time}} {{session}});
+// enabled:false disables that one target
 window.__dshNotifyMe.resetConfig()                // restore defaults (also drops any picked audio files)
 window.__dshNotifyMe.decide("approval:3", "allowed-once")  // programmatic decision: "allowed-once" | "rejected"
 window.__dshNotifyMe.testExternal()               // explicit outbound test to valid targets; resolves {sent, unverified, failed, statuses}
@@ -287,7 +285,7 @@ The reminder core stays dependency-free and self-contained: notification copy re
 
 ### Quick decisions, and how they reach the agent
 
-Action buttons (`actions`) belong to persistent notifications shown through `ServiceWorkerRegistration.showNotification()`; passing `actions` to the `new Notification()` constructor throws a `TypeError`. That is a browser rule no plugin can route around, so the bundle holds two jobs in the same bytes: the page half registers the reminder factory as it always did, and the very same file is registered as a Service Worker whose only task is relaying which button was clicked back to the page. The decision itself happens in the page, through the same `PendingApproval.answer('allowed-once' | 'rejected')` the approval card uses — which is why "Approve" is exactly "Allow once" and nothing broader. The "raise a window and switch its conversation" part of a body click is scheduled on the worker half too: `client.focus()` raises exactly one window (a visible one first) and routes the conversation switch to that window alone, so several open DSH tabs never fight over focus or all switch at once.
+Action buttons (`actions`) belong to persistent notifications shown through `ServiceWorkerRegistration.showNotification()`; passing `actions` to the `new Notification()` constructor throws a `TypeError`. That is a browser rule no plugin can route around, so the bundle holds two jobs in the same bytes: the page half registers the reminder factory as it always did, and the very same file is registered as a Service Worker whose only task is relaying which button was clicked back to the page. The decision itself happens in the page, through the same `PendingApproval.answer('allowed-once' | 'rejected')` the conversation's approval prompt uses — which is why "Approve" is exactly "Allow once" and nothing broader. The "raise a window and switch its conversation" part of a body click is scheduled on the worker half too: `client.focus()` raises exactly one window (a visible one first) and routes the conversation switch to that window alone, so several open DSH tabs never fight over focus or all switch at once.
 
 Every button toast is booked against its interaction key, so it can only decide the request it was raised for. Once the page answers that request or a newer one replaces it, clicking the leftover buttons decides nothing and just closes the notification. Button toasts stay 12s (plain ones 5s) and retire on their own, so an approval left undecided there still waits for you in the page.
 
@@ -312,14 +310,14 @@ There is no page-side fallback either: the shell preload only exposes `dshDeskto
 - The first sound/toast of each page load needs one user click on the page first (browser autoplay + permission policy).
 - Toasts are only produced once the notification permission is granted; declining means sound + title marker only.
 - On the Desktop shell (DSH Desktop 0.2.1-rc.2 / Windows) a toast click does not reliably bring the window forward: sometimes it does, sometimes only the conversation switches. The plugin's `dsh://open` deep link on its own failed 3/3 in isolation (see [How the Desktop window gets raised](#how-the-desktop-window-gets-raised)), so when it does come forward it is most likely the OS/Chromium activating the app on the notification click itself ([discussions #10446](https://github.com/deepseek-ai/deepseek-harness/discussions/10446)).
-- System notification banners are drawn on the primary display only: Windows has no setting and Chromium no API to aim one at another monitor, so on a multi-monitor setup the second screen never receives them. The one thing that does reach another display is the Desktop approval card, drawn in the page and carried by the window; for plain alerts across screens, forward them to your phone with external notifications.
-- Quick-decision buttons need a Service Worker: they work on `http://127.0.0.1` and `https`, not on plain `http://192.168.x.x`-style LAN addresses, and some browsers or desktop hosts never render notification buttons. **The Desktop (`dsh-app://`) is tested and cannot register a Service Worker**, so buttons never render there and approval toasts fall back to their buttonless form. The `bridge` field of `window.__dshNotifyMe.debug()` says why; everything else keeps working.
+- System notification banners are drawn on the primary display only: Windows has no setting and Chromium no API to aim one at another monitor, so on a multi-monitor setup the second screen never receives them. Forwarding to your phone with external notifications is the only route across screens (since 1.12.0 the page no longer draws an approval card).
+- Quick-decision buttons need a Service Worker: they work on `http://127.0.0.1` and `https`, not on plain `http://192.168.x.x`-style LAN addresses, and some browsers or desktop hosts never render notification buttons. **The Desktop (`dsh-app://`) is tested and cannot register a Service Worker** (the shell does not grant the `allowServiceWorkers` privilege), so buttons never render there and approval toasts fall back to their buttonless form. The `bridge` field of `window.__dshNotifyMe.debug()` says why; everything else keeps working.
 - macOS: in the browser, alerts, sounds, the title marker and toast-click navigation carry no OS assumptions and work as on Windows. Two caveats: DSH Desktop (Electron) notifications require the app to be code-signed — unsigned builds simply emit no notification — and whether the official macOS build satisfies that is untested; and notification buttons on the macOS desktop host are likewise untested (the Windows desktop host is tested and renders none, see the line above), falling back to the buttonless form above.
 - Config lives in browser `localStorage`: switching browsers/devices or clearing site data returns to defaults (one-click restore in the Settings page).
 - On `>= 0.1.6` (including `0.2.0-rc.2`, `0.2.1-rc.2`) the "reply finished" toast body carries only the session label, no assistant snippet: host snapshots no longer expose `nodes`. The alert itself still fires.
 - The title marker is written into `document.title` alongside the host: when the host recomputes the title it can overwrite the marker until the next alert event rewrites it.
-- "Stay quiet for the conversation on screen" is judged by `document.hidden`: a window fully covered by other apps still counts as visible, so waits in the current conversation stay quiet there too.
-- External notification forwarding is subject to browser CORS rules: an endpoint that does not allow cross-origin requests falls back to a "sent but unverifiable" delivery (no-cors) and is reported honestly as such; Discord webhooks do allow cross-origin, so delivery to them is confirmed. HTTP errors are recorded as failures and never blindly retried. Forwarding runs only after the local alert has decided to fire, so anything the rules silence is never sent out.
+- "Stay quiet for the conversation on screen" is judged by whether the window has focus: a window covered by another app, a switched-away app, or a minimized one all count as background, so waits in the current conversation alert there too; once the window is back in front, or you touch the keyboard / mouse again (no longer idle), it goes quiet again.
+- External notification forwarding is subject to browser CORS rules: an endpoint that does not allow cross-origin requests falls back to a "sent but unverifiable" delivery (no-cors) and is reported honestly as such; Discord, Feishu, ServerChan, and WxPusher all allow cross-origin, so delivery to them is confirmed. DingTalk allows no CORS header at all and only accepts `application/json`, so a page cannot post to it — hence no DingTalk target type (relay it through your own box and use a custom webhook). A failure that looks transient (network error, 5xx, 429) is retried on the backoff; a delivery that still fails lands in the failure log, and anything else stops at once. Forwarding runs only after the local alert has decided to fire, so anything the rules silence is never sent out.
 
 - **The settings sidebar glyph relies on a DOM patch**: the shell hard-codes icons per section id and `settings.section` exposes no icon field, so the plugin can only swap the `<svg>` in its own row after the panel renders. It depends on the current panel structure (`data-shortcut-modal="settings"` plus a label `<span>` inside each nav button); if DSH changes that markup the patch silently stops working and the default gear shows instead — nothing else is affected.
 
@@ -328,7 +326,7 @@ There is no page-side fallback either: the shell preload only exposes `dshDeskto
 ```powershell
 node --check lib\client.js
 node --check lib\index.js
-node smoke\smoke-test.cjs        # offline state-machine test: three host generations + master switch + zh/en cases + the quick-decision bridge (worker half included)
+node smoke\smoke-test.cjs        # offline state-machine test: three host generations + master switch + zh/en cases + the quick-decision bridge (worker half included) + idle detection and toast self-dismiss
 node smoke\cordis-host-test.mjs  # real-cordis end-to-end (skips when no local DSH installation is found)
 npm pack --dry-run               # preview the published tarball
 ```
@@ -345,6 +343,8 @@ Contributors (by handle; the link points at the PR / issue they worked on):
 - [@Wh1stle05](https://github.com/Wh1stle05) — [#10](https://github.com/chromoany/dsh-notify-me/pull/10): the per-kind alert sound source (built-in synth / picked audio file / system notification sound, chosen independently for "needs you" and "reply done"), with its settings UI, fallback chain, tests and docs; the two refinements — a "system" preview sending a real test notification instead of doing nothing, and the fake React holding hook state by index across renders — come from the same PR.
 - [@yanzhaohui1999](https://github.com/yanzhaohui1999) — [#13](https://github.com/chromoany/dsh-notify-me/issues/13) / [#14](https://github.com/chromoany/dsh-notify-me/pull/14): the 482-session idle-page CPU report (pinning `currentSessionId()` rescanning the whole table per row, 5.9%~6.5% of CPU) and the fix (derive the on-screen session once per list change), with a red-then-green regression assertion — a 4-row and a 40-row list change must cost the same (upstream reported 7 vs 43, 5 vs 5 after).
 - [@RiZhiZhaoYi](https://github.com/RiZhiZhaoYi) — [#12](https://github.com/chromoany/dsh-notify-me/issues/12): the external-notification forwarding suggestion (Discord Webhook / Bark / Gotify / custom webhook) and its use case (1.7.0).
+- [@yuexian7](https://github.com/yuexian7) — [#17](https://github.com/chromoany/dsh-notify-me/issues/17): the ask for alerts on an Android phone — Discord is awkward in mainland China and Bark has no Android app, so a self-hosted relay was the only option; 1.13.0's Feishu / ServerChan / WxPusher targets, retries, and failure log came out of it.
+- [@shrekcg](https://github.com/shrekcg) — [#16](https://github.com/chromoany/dsh-notify-me/pull/16): counting "in front but walked away" as away (`idleMinutes`, 3 minutes by default), deciding "reply finished" alerts by which conversation finished (`donePolicy`, three choices), the three-way toast self-dismiss policy (`autoDismiss`), with matching smoke cases and old-config migration; when it landed in 1.12.0 the maintainer added the idle-expiry replay for suppressed approvals, removed the leftover in-page approval card, and brought docs and version up to date.
 
 Attribution policy: external PRs are landed as maintainer commits — the original commit is not reused and no Co-authored-by trailer is added, so GitHub's contributors graph lists the maintainer only and contributors are credited above.
 

package/README.md

@@ -24,13 +24,13 @@
 DSH Web / Desktop 的通知插件，让你敢不开完整访问，也不必一直守着页面。
 
 - **需要你操作时**：审批、方案确认、提问，用通知、提示音和标题标记提醒。
-- **后台回复完成时**：及时回来查看结果，点击通知可回到对应对话。
-- **离开电脑时**：可选转发到 Discord、Bark、Gotify 或自己的 Webhook。
-- **不看主屏时**：系统通知只会画在主屏，副屏看不到；桌面端的审批卡片画在页面里，跟着 DSH 窗口走到哪块屏（见[副屏与审批卡片](#副屏与审批卡片)）。
+- **后台回复完成时**：及时回来查看结果，点击通知可回到对应对话；提醒时机可选「仅后台 / 仅当前对话静默 / 总是提醒」。
+- **人走开但窗口没走**：窗口留在最前台、人却离开座位，超过 3 分钟没有输入也算离开，该提醒的照常提醒；收到的那条通知不会在你回来之前自己消失。
+- **离开电脑时**：可选转发到 Discord、Bark、Gotify、飞书群机器人、Server酱、WxPusher 或自己的 Webhook。
 
-> 页面或桌面应用需保持运行，后台 / 最小化可以。系统通知需要通知权限。审批按钮靠 Service Worker 才能进通知：Web 端（`http://127.0.0.1` 或 `https`）有，桌面端 `dsh-app://` 页面注册不了，通知上没有按钮，审批改在窗口角落的卡片上裁决。
+> 页面或桌面应用需保持运行，后台 / 最小化可以。系统通知需要通知权限。审批按钮靠 Service Worker 才能进通知：Web 端（`http://127.0.0.1` 或 `https`）有，桌面端 `dsh-app://` 页面注册不了，通知上没有按钮，点通知回到对话里裁决。
 
-> 🔎 想找这个插件？可以搜：`dsh-notify-me`、**消息提醒**、**可操作提醒**、**桌面通知**、**需要你操作**、**回复完成提醒**、**后台完成提醒**、**外部通知**、**Discord / Bark / Gotify 推送**（npm 关键词已含以上中英文词）。
+> 🔎 想找这个插件？可以搜：`dsh-notify-me`、**消息提醒**、**可操作提醒**、**桌面通知**、**需要你操作**、**回复完成提醒**、**后台完成提醒**、**外部通知**、**安卓推送**、**Discord / Bark / Gotify / 飞书 / Server酱 / WxPusher 推送**（npm 关键词已含以上中英文词）。
 
 ## 效果预览
 
@@ -43,7 +43,7 @@ DSH Web / Desktop 的通知插件，让你敢不开完整访问，也不必一
 
 ![通知提醒设置页：页眉、提醒方式、什么时候提醒、试一试与折叠的高级设置](https://raw.githubusercontent.com/chromoany/dsh-notify-me/main/docs/screenshots/settings-zh.png)
 
-只截插件自己的面板（真实组件，1.11.0 之前的截图），不带 DSH 左侧导航栏；每行说明在鼠标停在标题文字上时才出现，所以这里只看到标题。1.11.0 删掉了最上面的「通知类型」一行，其余行没变。
+只截插件自己的面板（真实组件，与宿主同款深色主题），不带 DSH 左侧导航栏；每行说明在鼠标停在标题文字上时才出现，所以这里只看到标题。
 </details>
 
 ## 安装
@@ -73,14 +73,14 @@ dsh plugin --profile web add dsh-notify-me
 2. 打开 **设置 → 通知提醒**，确认出现该分区及底部插件版本号，保持「启用提醒」「提示音」开启。
 3. 点击设置页的「测试『回复完成』」按钮：应出现一条测试通知，并按当前音效设置播放声音。这个本地测试不会转发到外部通知端点，也不受「窗口在前台时也提醒」开关限制。
 
-Web 用户可再测试审批按钮。桌面端拿不到 Service Worker，这条测试会在窗口角落画一张带「同意 / 拒绝」的卡片（1.10.4 起；之前的版本这里只发普通通知）。
+Web 用户可再测审批按钮，通知上会带「同意 / 拒绝」。桌面端拿不到 Service Worker，这条测试只发一条普通通知；真实审批的提醒同理——只弹通知，点它回到对话里裁决。
 
 **控制台验证（可选）** — 支持 DevTools 的环境也可执行：
 
 ```js
 window.__dshNotifyMe.test("done")        // 「完成」示例
 window.__dshNotifyMe.test("attention")   // 「需要你」示例
-window.__dshNotifyMe.test("approval")    // 桥可用时带「同意 / 拒绝」按钮；桌面端画在窗口角落的卡片上
+window.__dshNotifyMe.test("approval")    // 桥可用时带「同意 / 拒绝」按钮；否则只发普通通知（桌面端即如此）
 window.__dshNotifyMe.debug()             // 桥接状态看 bridge 字段，active = 按钮可用
 ```
 
@@ -98,11 +98,11 @@ dsh-notify-me 把「监督」和「守在屏幕前」解耦：只在真的出现
 | 事件 | 默认行为 |
 | --- | --- |
 | 🔔 需要你操作 | 页面可见也提醒；当前对话只留标题标记 |
-| ✅ 回复完成 | 页面隐藏 / 后台时提醒 |
+| ✅ 回复完成 | 页面隐藏 / 后台时提醒（可选「仅当前对话静默」或「总是提醒」） |
 
-**需要你操作**包括审批请求、方案待确认（plan review）和提问（`ask_user_question`）。审批带「同意 / 拒绝」：Web 走带按钮的系统通知，桌面端（注册不了 Service Worker）改画在窗口角落的卡片上。
+**需要你操作**包括审批请求、方案待确认（plan review）和提问（`ask_user_question`）。审批带「同意 / 拒绝」的按钮只在 Web 端有（需要 Service Worker）；桌面端注册不了，通知上没有按钮，点通知回到对话里裁决。
 
-**回复完成**也覆盖后台会话；完成但还没看时，标题带 `✅ 回复完成 ·` 标记，打开对应会话即撤。标题标记不受「窗口在前台时也提醒」开关限制。
+**回复完成**也覆盖后台会话；完成但还没看时，标题带 `✅ 回复完成 ·` 标记，打开对应会话即撤。标题标记不受提醒策略限制。
 
 > **后台**子代理（subagent）子会话的等待与完成默认**不提醒**：DSH 把每个子代理子会话列成独立会话，但它们是所属主对话那一轮里的步骤，提醒只会是噪音。你当前打开的那个子代理会话不算在内，照常提醒。设置页「子代理会话不提醒」可关掉这个静音。
 
@@ -114,26 +114,14 @@ dsh-notify-me 把「监督」和「守在屏幕前」解耦：只在真的出现
 
 - **启用提醒** 总开关：关闭后不弹通知、不响提示音，也不改标签页标题；
 - **提示音 / 音量**：开关直接切；音量滑块收在该行里，点一下标题（▸ 变成 ▾）展开。具体播什么由「高级设置 → 音效来源」决定；
-- **审批通知上直接裁决**（默认开）：审批带「同意 / 拒绝」，点一下即完成裁决，不用切回页面。Web 走带按钮的系统通知；桌面端 `dsh-app://` 注册不了 Service Worker，于是把按钮画在窗口角落的卡片上（12 秒自动收起，同一条审批不叠第二张卡）。卡片位置由它下面的子行「审批卡片位置」控制，见[副屏与审批卡片](#副屏与审批卡片)。
-
-### 副屏与审批卡片
-
-Windows 的系统通知横幅固定画在主屏上，系统没有设置项、浏览器也没有 API 能把它挪到别的显示器。主屏不看、DSH 停在副屏时，通知就等于没发。这一条改不掉——真要在副屏看见，只能靠页面里的东西。
-
-页面里还剩一种：桌面端的审批卡片。它画在 DSH 页面里，窗口在哪块屏就出现在哪块屏，卡片上能直接「同意 / 拒绝」（桌面端通知带不了按钮）。
-
-- **位置**：「审批通知上直接裁决」下面的「审批卡片位置」子行，行上直接显示当前值（默认右下）；点它（▸ 变 ▾）再选右上 / 右下 / 左上 / 左下，改完立刻生效；
-- **只给审批**：普通提醒与「回复完成」不画卡片，它们只有系统通知；
-- **停留时间**：审批卡片 12 秒自动收起；点卡片正文切回对应对话。最多同时叠 4 张；
-- **不用通知权限**：这条路径不碰 Service Worker，也不依赖通知权限。
-
-> 1.11.0 删掉了「通知类型」二选一。页面浮层曾经能当独立通道用，但它只在 DSH 窗口处于前台时看得见——需要提醒的时刻恰恰是窗口在后台。选浮层、切走之后后台只剩提示音和标题标记，等于没提醒。
+- **审批通知上直接裁决**（默认开）：审批带「同意 / 拒绝」，点一下即完成裁决，不用切回页面。Web 走带按钮的系统通知；桌面端 `dsh-app://` 注册不了 Service Worker，通知上没有按钮，点通知回到对话里裁决。设置页「试一试」下面那行会如实说明当前环境能不能给按钮。
 
 ### 什么时候提醒
 
-- **窗口在前台时也提醒「需要你」**（默认开）：窗口在前台也提醒；关掉后只有窗口转到后台才提醒——切到别的应用、被别的窗口遮住、最小化都算后台；
-- **当前对话不弹通知**（默认开）：等待就发生在你正看着的对话里时只留标签页标记，免得挡住审批卡片；窗口转到后台后照常提醒，若你已处理掉就作废；
-- **窗口在前台时也提醒「回复完成」**（默认关）：默认只在窗口转到后台时提醒，避免打扰（桌面端窗口被遮住也算后台，1.10.5 起不再要求最小化）；
+- **窗口在前台时也提醒「需要你」**（默认开）：窗口在前台也提醒；关掉后只有窗口转到后台才提醒——切到别的应用、被别的窗口遮住、最小化都算后台。窗口一直留在前台但人离开座位（默认 3 分钟没有任何键鼠输入）同样算后台；`idleMinutes: 0` 退回只看窗口；
+- **当前对话不弹通知**（默认开）：等待就发生在你正看着的对话里时只留标签页标记，免得打断眼前的操作；人离开（窗口转到后台或闲置超时）后照常提醒，若你已处理掉就作废；
+- **「回复完成」什么时候提醒**（默认「仅后台」）：三选一。「仅后台」＝原来的规则，不在看页面才提醒；「仅当前对话静默」＝屏幕上那条静默，别的对话完成照常提醒，多开对话时有用；「总是提醒」＝从不静默。老配置里的「窗口在前台时也提醒『回复完成』」开关自动迁移到这一项；
+- **通知自动消失**（默认「离开时保留」）：三选一。「离开时保留」＝只有你在看页面时才几秒后关闭，人不在时收到的那条留在通知中心等你回来；「总是关闭」＝旧行为；「从不关闭」＝普通通知一直留着，等你点掉。带「同意 / 拒绝」的审批通知仍按 12 秒走，同样不会在人不在时被撤掉；
 - **子代理会话不提醒**（默认开）：跳过后台子代理（subagent）会话——它们是主对话那一轮的步骤，完成由主对话自己的提醒覆盖；你当前打开的那个子代理会话照常提醒；
 - **点击通知回到对应对话**（默认开）：点通知切到提醒所属的对话；浏览器里同时把窗口带到前台；桌面端不稳定——有时窗口会上前，有时只切对话（见[桌面端怎么抬窗的](#桌面端怎么抬窗的)）；多个标签页同时开着时只调起一个（优先当前可见的那个）；关掉后点通知不做任何事。
 
@@ -160,12 +148,17 @@ Windows 的系统通知横幅固定画在主屏上，系统没有设置项、浏
 
 ### 外部推送
 
-默认关闭。支持 Discord Webhook / Bark / Gotify / 自定义 Webhook；提醒正文会发往你填写的地址，只使用可信端点。
+默认关闭。支持 Discord Webhook / Bark / Gotify / 飞书群机器人 / Server酱（Turbo 与 Server酱³）/ WxPusher / 自定义 Webhook；提醒正文会发往你填写的地址，只使用可信端点。
 
 <details>
-<summary>目标地址、转发开关与发送测试</summary>
+<summary>目标地址、转发开关、发送测试与失败记录</summary>
 
-- **外部通知**（默认关）：把提醒同时转发到你自己的推送端点，人不在电脑前也能收到——支持 **Discord Webhook** / **Bark** / **Gotify** / **自定义 Webhook**，可加多个目标，每个选类型填地址（Discord 填 Webhook 地址；Bark 填 `https://api.day.app/<设备密钥>`；Gotify 填 `https://<服务器>/message?token=<应用令牌>`；自定义端点收一条 POST JSON：`{source, event, title, body, sessionId, time}`）；「转发「需要你」」「转发「回复完成」」各自独立开关；**发送测试通知**往所有目标发一条测试消息（不受这两类开关限制，也不会冒充真提醒）。转发跟本地提醒走同一套触发规则（「当前对话不弹通知」等开关同样管它）；提醒正文会原样发往你填的地址，**只填你自己信任的端点**；
+- **外部通知**（默认关）：把提醒同时转发到你自己的推送端点，人不在电脑前也能收到——支持 **Discord Webhook** / **Bark** / **Gotify** / **飞书群机器人** / **Server酱** / **WxPusher** / **自定义 Webhook**，可加多个目标，每个目标可单独启用/停用（Discord 填 Webhook 地址；Bark 填 `https://api.day.app/<设备密钥>`；Gotify 填 `https://<服务器>/message?token=<应用令牌>`；飞书填群机器人 Webhook，可选填签名校验密钥；Server酱 填 `…/send/<SendKey>.send` 完整地址；WxPusher 填 appToken 与接收者 UID；自定义端点收一条 POST JSON：`{source, event, title, body, text, sessionId, time}`）；「转发「需要你」」「转发「回复完成」」各自独立开关；**发送测试通知**往所有目标发一条测试消息（不受这两类开关限制，也不会冒充真提醒）。转发跟本地提醒走同一套触发规则（「当前对话不弹通知」等开关同样管它）；提醒正文会原样发往你填的地址，**只填你自己信任的端点**；
+- **可靠投递**：明显是临时故障的失败（网络中断、5xx、429）按 2 秒 / 6 秒自动重试两次，其它错误立即停；重试仍失败会把这一条记进「失败记录」（最多 10 条，只留标题与正文摘要和主机名，不留完整端点），设置页能一眼看到并清空；
+- **每个目标的状态**：目标行右侧显示它最近一次投递的结果（上次成功 / 上次已送出但不可确认 / 上次失败 + 原因），并各自带一个启停开关——某个端点临时不可用就单独关掉它，不用关掉整类事件；
+- **签名**：自定义目标填了签名密钥时，请求带 `X-DSH-Notify-Signature`（对请求体做 HMAC-SHA256，`sha256=<hex>`）；飞书填了签名密钥时按官方算法在请求体里带 `timestamp` / `sign`；
+- **消息模板**（可选）：飞书 / Server酱 / WxPusher / 自定义目标可填模板，占位符 `{{title}}` `{{body}}` `{{event}}` `{{time}}` `{{session}}`，留空默认是「标题 + 换行 + 正文」；
+- **钉钉不在支持列表里**：钉钉群机器人接口不返回任何 CORS 头，且只接受 `application/json`——浏览器页面既读不到响应，也无法发出符合要求的请求（no-cors 下 Content-Type 会被限制成 safelisted 类型）。要用钉钉，请在自己能控制的机器上搭一个中转，再把「自定义 Webhook」指向它。
 
 </details>
 
@@ -189,10 +182,9 @@ Windows 的系统通知横幅固定画在主屏上，系统没有设置项、浏
 ## 提醒渠道
 
 - **系统通知**：经浏览器弹出的系统通知，进 Windows 通知中心或 macOS 通知中心（点击回到提醒所属的对话；支持快捷裁决的 Web 环境可点审批按钮直接裁决，桌面端没有按钮）
-- **桌面端审批卡片**：`dsh-app://` 下系统通知带不了「同意 / 拒绝」，审批类提醒额外在窗口角落画一张可点卡片；见[副屏与审批卡片](#副屏与审批卡片)
 - **提示音**：默认是 WebAudio 合成音（「需要你」与「完成」使用不同音型）；可在设置里为两类提醒分别换成自定义音频文件，或改成让操作系统播放它自己的通知音
 - **标签页标题标记**：有待处理事项时，标题前出现 `🔔 需要你 · …` / `🔔 Action needed · …`；后台会话**完成但还没看**时出现 `✅ 回复完成 · …` / `✅ Reply finished · …`，打开对应会话（或它再次开跑）即消失。两种标记可同时出现，「需要你」在前；宿主改写标题后标记基于新标题重建
-- **外部通知**（可选，默认关）：按设置里配的推送目标，把同一条提醒转发到 Discord Webhook / Bark / Gotify / 自定义 Webhook——临时离开电脑时，手机上的推送渠道照样收到
+- **外部通知**（可选，默认关）：按设置里配的推送目标，把同一条提醒转发到 Discord Webhook / Bark / Gotify / 飞书群机器人 / Server酱 / WxPusher / 自定义 Webhook——临时离开电脑时，手机上的推送渠道照样收到
 
 本插件是**浏览器层**实现：DSH 页面需保持打开（最小化/后台即可——那正是它监听的「离开」状态）。
 
@@ -221,7 +213,7 @@ Windows 的系统通知横幅固定画在主屏上，系统没有设置项、浏
 
 </details>
 
-`1.9.0` 的界面重排没有放宽也没有收紧这个范围：设置页是纯 React 渲染 + 既有 CSS 变量（每个色值都带 fallback），没有引入任何新的宿主 API；浮层、标题标记、抬窗仍走 1.7 / 1.8 那几条路径。**0.1.1-rc.2 到 0.2.1-rc.2 的插件条目照旧兼容**，换回旧宿主也不需要改配置。新增的只有界面元素——设置页页眉的铃铛是插件自己画的 SVG（`docs/brand/`），与宿主无关。
+`1.9.0` 的界面重排没有放宽也没有收紧这个范围：设置页是纯 React 渲染 + 既有 CSS 变量（每个色值都带 fallback），没有引入任何新的宿主 API；提醒、标题标记、抬窗仍走 1.7 / 1.8 那几条路径。**0.1.1-rc.2 到 0.2.1-rc.2 的插件条目照旧兼容**，换回旧宿主也不需要改配置。新增的只有界面元素——设置页页眉的铃铛是插件自己画的 SVG（`docs/brand/`），与宿主无关。
 
 ## 控制台高级配置
 
@@ -236,8 +228,10 @@ window.__dshNotifyMe.setConfig({
   enabled: true,           // false = 关闭所有提醒（主开关）
   language: "auto",        // 'auto' 跟随界面 | 'zh' 简体中文 | 'en' English
   attentionHiddenOnly: false, // true = 页面可见时「需要你」不提醒
-  currentHiddenOnly: true,    // true = 当前对话的等待只留标题标记（转后台补发）
-  doneHiddenOnly: true,       // false = 页面可见时「完成」也提醒
+  currentHiddenOnly: true,    // true = 当前对话的等待只留标题标记（人离开后补发）
+  donePolicy: "background",   // 「回复完成」策略：'background' 仅后台 | 'smart' 仅当前对话静默 | 'always' 总是提醒
+  idleMinutes: 3,             // 超过多少分钟没有键鼠输入算「离开」（0 = 关掉闲置判定）
+  autoDismiss: "present",     // 通知自动消失：'present' 离开时保留 | 'always' 总是关闭 | 'never' 从不关闭
   ignoreSubagent: true,       // true = 后台子代理（subagent）会话不提醒（当前打开的照常）
   sound: true,                // 提示音开关（含「系统通知音」模式）
   soundDone: "synth",         // 「完成」音效来源：'synth' 内置 | 'custom' 自定义文件 | 'system' 系统通知音
@@ -245,12 +239,16 @@ window.__dshNotifyMe.setConfig({
   volume: 0.5,                // 音量 0~1
   autoFocus: true,            // 点通知回到提醒所属的对话
   quickActions: true,         // 审批通知上的「同意 / 拒绝」按钮
-  overlayCorner: "bottom-right", // 桌面端审批卡片位置：'top-right' | 'bottom-right' | 'top-left' | 'bottom-left'
   externalEnabled: false,     // 外部通知转发主开关（默认关：不填端点就什么都不发）
   externalAttention: true,    // 转发「需要你」（触发规则跟本地提醒完全一致）
   externalDone: true,         // 转发「回复完成」
-  externalTargets: []         // 推送目标：[{id, type:'discord'|'bark'|'gotify'|'custom', url}]
+  externalRetryDelays: [2000, 6000], // 可重试失败的退避间隔（毫秒，带抖动；[] = 只发一次）
+  externalTargets: []         // 推送目标，见下方字段说明
 })
+// 目标的形状：{id, type, url, secret?, token?, uid?, template?, enabled?}
+// type: 'discord' | 'bark' | 'gotify' | 'feishu' | 'serverchan' | 'wxpusher' | 'custom'
+// token/uid 只用于 wxpusher（url 固定为官方端点）；secret 用于飞书签名与自定义 HMAC 签名；
+// template 可选，占位符 {{title}} {{body}} {{event}} {{time}} {{session}}；enabled:false 单独停用该目标
 window.__dshNotifyMe.resetConfig()                // 恢复默认（同时清掉已选的自定义音效文件）
 window.__dshNotifyMe.decide("approval:3", "allowed-once")  // 程序化裁决："allowed-once" | "rejected"
 window.__dshNotifyMe.testExternal()               // 显式外发测试：向有效目标发送，返回 {sent, unverified, failed, statuses}
@@ -282,9 +280,9 @@ window.__dshNotifyMe.testExternal()               // 显式外发测试：向有
 
 ### 快捷裁决怎么走通的
 
-通知按钮（`actions`）只属于 Service Worker 弹的持久通知，往 `new Notification()` 里传 `actions` 会直接抛 `TypeError`——这是绕不开的浏览器限制。所以 bundle 一份文件干两件事：页面里照常注册提醒工厂，同一份字节再注册成一个只干转信的 Service Worker，把「点了哪个按钮」（同意 / 拒绝 / 点正文）带回页面。真正的裁决发生在页面里，调的是审批卡片自己用的 `PendingApproval.answer('allowed-once' | 'rejected')`，所以「同意」就是「允许一次」，不多放行任何东西。点正文的「调窗口 + 切对话」同样归 worker 这半侧调度：它用 `client.focus()` 只调起一个窗口（优先当前可见的），并只让那个窗口切对话——多个 DSH 标签页不会互相抢焦点或一起乱切。
+通知按钮（`actions`）只属于 Service Worker 弹的持久通知，往 `new Notification()` 里传 `actions` 会直接抛 `TypeError`——这是绕不开的浏览器限制。所以 bundle 一份文件干两件事：页面里照常注册提醒工厂，同一份字节再注册成一个只干转信的 Service Worker，把「点了哪个按钮」（同意 / 拒绝 / 点正文）带回页面。真正的裁决发生在页面里，调的是对话里审批「允许一次 / 拒绝」用的同一个 `PendingApproval.answer('allowed-once' | 'rejected')`，所以「同意」就是「允许一次」，不多放行任何东西。点正文的「调窗口 + 切对话」同样归 worker 这半侧调度：它用 `client.focus()` 只调起一个窗口（优先当前可见的），并只让那个窗口切对话——多个 DSH 标签页不会互相抢焦点或一起乱切。
 
-每条按钮通知按交互 key 记账，一次只认领一条等待；请求被页面里答掉、或被新请求顶替之后，残留通知上的按钮再点也不会误裁，只是安静地关掉。带按钮的通知停留 12 秒（普通通知 5 秒），到点自动撤；没来得及点就回页面里裁决，卡片一直等着你。
+每条按钮通知按交互 key 记账，一次只认领一条等待；请求被页面里答掉、或被新请求顶替之后，残留通知上的按钮再点也不会误裁，只是安静地关掉。带按钮的通知停留 12 秒（普通通知 5 秒），到点自动撤；没来得及点就回页面里裁决，对话里的审批一直等着你。
 
 ### 桌面端怎么抬窗的
 
@@ -305,16 +303,16 @@ DSH Desktop 是一层 Electron 壳，页面跑在 `dsh-app://app` 下：DOM 的
 - 页面必须开着才会提醒（后台标签/最小化可以；关标签页即失效——浏览器层方案固有限制）。
 - 通知经由浏览器弹出，需允许浏览器通知权限，且勿扰模式不能屏蔽它。
 - 桌面端（DSH Desktop 0.2.1-rc.2 / Windows）点通知后窗口不一定上前台：有时会，有时只切对话。插件发的 `dsh://open` 深链单独复测 3/3 无效（详见[桌面端怎么抬窗的](#桌面端怎么抬窗的)），能抬的时候多半是系统/Chromium 在通知激活时自己把窗口带起来了（[discussions #10446](https://github.com/deepseek-ai/deepseek-harness/discussions/10446)）。
-- 系统通知横幅只画在主屏：Windows 没有设置项、Chromium 没有 API 能把它指到别的显示器（多屏时副屏收不到系统通知）。页面里唯一还会出现在副屏的是桌面端的审批卡片，它跟着 DSH 窗口走；普通提醒要跨屏，只能靠外部推送转到手机。
+- 系统通知横幅只画在主屏：Windows 没有设置项、Chromium 没有 API 能把它指到别的显示器（多屏时副屏收不到系统通知）。要跨屏提醒只能靠外部推送转到手机（1.12.0 起页面里不再画审批卡片）。
 - 每次页面加载后第一次出声/弹通知前，需在页面上点击过一次（浏览器自动播放与权限策略）。
 - 未授权通知权限时只有提示音与标题标记。
-- 快捷裁决按钮要 Service Worker：`http://127.0.0.1`、`https` 可用，`http://192.168.x.x` 这类局域网地址不行；**桌面端（`dsh-app://`）已实测无法注册 Service Worker**，按钮渲染不了，审批通知退回无按钮样式。浏览器或桌面宿主不渲染通知按钮时，`window.__dshNotifyMe.debug()` 的 `bridge` 字段会说明原因，其余功能不受影响。
+- 快捷裁决按钮要 Service Worker：`http://127.0.0.1`、`https` 可用，`http://192.168.x.x` 这类局域网地址不行；**桌面端（`dsh-app://`）已实测无法注册 Service Worker**（宿主未开放 `allowServiceWorkers` 特权），按钮渲染不了，审批通知退回无按钮样式。浏览器或桌面宿主不渲染通知按钮时，`window.__dshNotifyMe.debug()` 的 `bridge` 字段会说明原因，其余功能不受影响。
 - macOS：浏览器里提醒、提示音、标题标记、点通知跳转都没有平台假设，照常工作；但 DSH Desktop（Electron）的系统通知要求应用已签名，未签名的通知直接发不出去，官方 macOS 版是否满足这一前提未实测；审批按钮在 macOS 桌面宿主上的渲染同样未实测（Windows 桌面端已实测不渲染，见上条），不渲染时自动退回无按钮通知。
 - 配置存在浏览器 `localStorage`：换浏览器/设备或清除站点数据后会回到默认值（设置页可一键恢复默认）。
 - `≥ 0.1.6`（含 `0.2.0-rc.2`、`0.2.1-rc.2`）的「回复完成」提醒正文只有会话名，不再附带回复摘要——宿主快照已不再提供 `nodes`；提醒本身照常触发。
 - 标题标记由宿主与插件共同写 `document.title`：宿主重算标题时标记可能被覆盖，直到下一次提醒事件重新写成。
-- 「当前对话不弹通知」按「窗口是否在前台」判定：窗口被别的应用盖住、切到别的应用、最小化都算后台，此时当前对话的等待照常提醒；窗口回到前台再静默。
-- 外部通知转发受浏览器跨域（CORS）限制：端点不放行时自动降级为「送出但不可确认」（no-cors），如实标为「已送出不可确认」；Discord Webhook 官方放行跨域，可直接确认送达。HTTP 错误如实记失败、不重试。转发在本地提醒决定要发之后才触发，所以被「当前对话不弹通知」等规则静音的提醒也不会外发。
+- 「当前对话不弹通知」按「窗口是否在前台」判定：窗口被别的应用盖住、切到别的应用、最小化都算后台，此时当前对话的等待照常提醒；窗口回到前台、或重新有键鼠输入（不再闲置）之后，再恢复静默。
+- 外部通知转发受浏览器跨域（CORS）限制：端点不放行时自动降级为「送出但不可确认」（no-cors），如实标为「已送出不可确认」；Discord、飞书、Server酱、WxPusher 都放行跨域，可直接确认送达。钉钉不放行任何 CORS 头、又只收 `application/json`，页面发不出去，所以没有做成目标类型（自建中转 + 自定义目标才行）。明显临时的失败（网络中断、5xx、429）会按退避重试，重试仍失败进失败记录；其余错误立即停、不重试。转发在本地提醒决定要发之后才触发，所以被「当前对话不弹通知」等规则静音的提醒也不会外发。
 
 - **设置左侧导航行图标靠 DOM 补丁**：外壳按分区 id 硬编码图标且 `settings.section` 没有图标字段，插件只能在面板渲染后把那一行的 `<svg>` 换成铃铛。命中依赖宿主当前的面板结构（`data-shortcut-modal="settings"` + 导航按钮里的标签 `<span>`）；如果 DSH 改了这套结构，补丁会静默失效、显示回默认齿轮，其他功能不受影响。
 
@@ -323,7 +321,7 @@ DSH Desktop 是一层 Electron 壳，页面跑在 `dsh-app://app` 下：DOM 的
 ```powershell
 node --check lib\client.js
 node --check lib\index.js
-node smoke\smoke-test.cjs        # 离线状态机冒烟测试：三代宿主 + 主开关 + 中英语言用例 + 快捷裁决桥（Service Worker 半侧一并跑）+ 桌面审批卡片
+node smoke\smoke-test.cjs        # 离线状态机冒烟测试：三代宿主 + 主开关 + 中英语言用例 + 快捷裁决桥（Service Worker 半侧一并跑）+ 闲置判定与通知自收
 node smoke\cordis-host-test.mjs  # 真 cordis 端到端（找不到本机 DSH 时自动跳过）
 npm pack --dry-run               # 预览发布包
 ```
@@ -340,6 +338,8 @@ npm pack --dry-run               # 预览发布包
 - [@Wh1stle05](https://github.com/Wh1stle05) — [#10](https://github.com/chromoany/dsh-notify-me/pull/10)：「音效来源」功能（内置合成音 / 自定义音频文件 / 系统通知音，「需要你」与「回复完成」各自独立选），含设置页交互、回落链与测试、文档；「系统通知音」试听改发测试通知、假 React 按索引跨渲染保持 hook 状态这两处修正同样出自该 PR。
 - [@yanzhaohui1999](https://github.com/yanzhaohui1999) — [#13](https://github.com/chromoany/dsh-notify-me/issues/13) / [#14](https://github.com/chromoany/dsh-notify-me/pull/14)：482 个会话下空闲页面烧 CPU 的性能报告（定位到 `currentSessionId()` 每行重扫全表，实测占 CPU 5.9%~6.5%）与修复（一次列表变化只推导一次「当前会话」），并带先红后绿的回归断言——4 行与 40 行的列表变化代价必须相等（上游报 7 vs 43，修后 5 vs 5）。
 - [@RiZhiZhaoYi](https://github.com/RiZhiZhaoYi) — [#12](https://github.com/chromoany/dsh-notify-me/issues/12)：外部通知转发（Discord Webhook / Bark / Gotify / 自定义 Webhook）的功能建议与使用场景（1.7.0）。
+- [@yuexian7](https://github.com/yuexian7) — [#17](https://github.com/chromoany/dsh-notify-me/issues/17)：安卓端收消息的诉求——Discord 在国内不便、Bark 没有安卓端，只能自己搭后台中转；1.13.0 的飞书 / Server酱 / WxPusher 三种目标、自动重试与失败记录都是据此做的。
+- [@shrekcg](https://github.com/shrekcg) — [#16](https://github.com/chromoany/dsh-notify-me/pull/16)：把「人在前台但离开了」并入离开判定（`idleMinutes`，默认 3 分钟）、「回复完成」按哪个对话完成决定是否提醒（`donePolicy` 三选一）、通知自动消失的三档策略（`autoDismiss`），并带上对应冒烟用例与旧配置迁移；1.12.0 落地时维护者补了闲置到期补发被压下的审批、删掉残留的页内审批卡片、补齐文档与版本。
 
 署名口径：本仓库收编外部 PR 时以维护者提交落地——不沿用原 commit、不挂 Co-authored-by，GitHub 的 contributors 图只显示维护者，贡献者以上面的致谢署名。