dsh-notify-me 1.10.6 → 1.12.0

package/CHANGELOG.md

@@ -2,19 +2,60 @@
 
 All notable changes to **dsh-notify-me** are documented here.
 
-## [1.10.6] — 2026-10-21
+## [1.12.0] — 2026-10-21
 
-### 修复
+### 新增
 
-- **提醒方式选「页面浮层」时，窗口在后台就等于没有提醒**：浮层卡片画在页面里，窗口被别的应用挡住（或最小化）时它既看不见、又会在 12 秒后自己收起，于是只剩下提示音，屏幕上什么都没有。现在浮层通道在页面离开前台时会额外发一条系统通知——那是唯一能追到「人在别处」的手段；窗口回到前台则不加，屏幕上还是一张卡片，不重复。系统通知仍受通知权限约束，未授权时保持原样（只有卡片）。
+- **人走开但窗口没走也算离开**（来自 [#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
+
+### 移除
+
+- **「提醒方式」二选一整段删掉**：系统通知成了唯一通道，设置页不再有「通知类型」分段选择器。页面浮层当独立通道的用途是「窗口在哪块屏，卡片就在哪块屏」，可它只在 DSH 窗口处于前台时看得见——需要提醒的时刻恰恰是窗口在后台。选了浮层、切走之后，后台只剩提示音和标题标记，等于没提醒；1.10.6 想在后台补发系统通知，又违背了你选的通道。两个方向都不成立，所以直接去掉这个选项。
+- `channel` / `overlay` / `toast` 三个配置键失效。旧配置里的值在下次读配置时删掉，其余设置不受影响（`overlayCorner` 保留）。
+- `window.__dshNotifyMe.debug()` 里的 `channel`、`toast` 被去掉，`overlay` 改名为 `card`，只报告桌面端审批卡片（`enabled` / `corner` / `cards`）。
+
+### 保留
+
+- **桌面端审批卡片**：`dsh-app://` 注册不了 Service Worker，系统通知带不了「同意 / 拒绝」，所以审批类提醒仍在窗口角落画一张可点击的卡片（12 秒回收，同一条审批不叠第二张）。位置改由「提醒方式 → 审批通知上直接裁决」下面的「审批卡片位置」决定，与已删除的通道无关。
+- 1.10.5 的「窗口失焦也算后台」与 1.10.7 的行为原样保留。
 
 ### 测试
 
-- 冒烟新增断言：浮层通道在页面隐藏时发出系统通知且仍画卡片；开关关闭后不再发；页面可见时行为不变。
+- 冒烟删掉浮层通道用例（`overlayChannel`、`settingsOverlayRow`），换成 `cardLayer`（卡片只给审批、四角位置、卡片上的审批按钮能裁决）与 `settingsAlertSetup`（设置页没有通道分段选择器、审批卡片位置子行在、旧配置的 `channel` 被清掉）。
+
+## [1.10.7] — 2026-10-21
+
+### 撤销
+
+- **1.10.6 的「浮层通道在后台补发系统通知」整条撤销**。它把「选浮层」变成了「浮层 + 后台时又弹系统通知」，等于绕过了用户明确选定的通道——用户的反馈是「我选的不是浮层提醒吗，为什么弹系统通知」。现在恢复 1.10.5 的行为：选了浮层就只画页面卡片，窗口被挡住时后台只有提示音和标题标记，系统通知一条都不发。想要后台可见的提醒，请把「通知类型」切到「系统通知」。
+
+### 说明
+
+- 1.10.5 的「窗口失焦也算后台」保留不动：它决定的是「要不要提醒」，与「用哪个通道提醒」无关。
 
 ## [1.10.5] — 2026-10-21
 

package/README.en.md

@@ -24,11 +24,11 @@
 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 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, or your own webhook.
-- **When you do not watch the primary display:** switch the alert channel to the in-page overlay — it follows the DSH window onto whichever screen you are looking at (system notifications only ever appear on the primary display).
 
-> Keep the page or desktop app running; backgrounding / minimizing is fine. System notifications require permission. Approval buttons need a Service Worker capable Web environment (such as `http://127.0.0.1` or `https`); Desktop notifications have no buttons — turn on the in-page overlay to decide from there instead (see [Secondary displays and the overlay](#secondary-displays-and-the-overlay)).
+> 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).
 
@@ -38,16 +38,12 @@ A notification plugin for DSH Web / Desktop, so you can keep full access off wit
 
 *Plain notification example · Windows / Edge · no approval buttons.* [View full size](https://raw.githubusercontent.com/chromoany/dsh-notify-me/main/docs/screenshots/notify-toast.png)
 
-![Three overlay cards in the bottom-right corner of the DSH page: question, approval request with Approve / Reject, and reply finished](https://raw.githubusercontent.com/chromoany/dsh-notify-me/main/docs/screenshots/overlay-en.png)
-
-*In-page overlay · the real plugin rendered on a demo page · for when system notifications cannot reach the secondary display; cards appear on whichever display the DSH window is on.* [View full size](https://raw.githubusercontent.com/chromoany/dsh-notify-me/main/docs/screenshots/overlay-en.png)
-
 <details>
 <summary>See the settings interface</summary>
 
 ![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, v1.10.2 defaults) without the DSH navigation sidebar. Alert type is a segmented control, and row explanations live in a hover tooltip that appears when the pointer rests on a title, which is why only the titles show here.
+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
@@ -74,17 +70,17 @@ The Electron application manages the `desktop` profile. Do not change the Web co
 ## First-use check
 
 1. Click once in the DSH page and allow notifications when prompted. If you previously declined, allow them in the browser's site settings. The operating system must also allow notifications from the browser / DSH Desktop.
-2. Open **Settings → Notify me**. Confirm that the section and plugin version at its foot appear, and leave the master switch, the alert type on system notifications, and sound enabled.
+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
 ```
 
@@ -106,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.
 
@@ -121,32 +117,15 @@ Open **Settings → Notify me**. The page runs as how you get told, when to aler
 ### How you get told
 
 - **Enable reminders**: master switch — off means no toasts, no sounds, and the tab title is left alone;
-- **Alert type (pick one)**: one segmented control — system notifications on the left, in-page overlay on the right; whichever you pick is the only channel used;
-  - **System notifications** (default): native toasts landing in the Windows / macOS notification center; needs notification permission;
-  - **In-page overlay**: cards drawn in the page corner, on whichever display the window sits on — system notifications only land on the primary display. No permission needed, and the Desktop shell can Approve / Reject right on the card. With the overlay chosen, a Corner row appears; open it to pick one of four positions. See [Secondary displays and the overlay](#secondary-displays-and-the-overlay);
 - **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). You can also switch the channel to the in-page overlay and decide there.
-
-### Secondary displays and the overlay
-
-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.
-
-The **in-page overlay** skips the notification center and draws the card inside the DSH page instead: wherever the window is, the card is there too.
-
-- **Position** — with the in-page overlay chosen, a Corner row appears showing 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;
-- **No notification permission needed** — it works when permission was never granted, and on the Desktop shell where buttonless toasts are all the OS channel can do;
-- **Approval cards carry Approve / Reject** — the same decision as Allow once / Reject on the approval card, and they work on the Desktop too (no Service Worker involved). Clicking the card body opens its conversation;
-- **Lifetime** — "needs you" and "reply finished" cards retire after 5s each, an approval card with buttons after 12s (system toasts use the same two numbers); a card or its close button retires one earlier. At most 4 cards stack at once;
-- **Relation to system notifications** — it is one or the other. Both used to be switchable at once, which meant every alert arrived twice and the pair covered each other; 1.10.0 made it a single choice, and 1.10.2 turns that into one segmented row. An old config with the overlay on migrates to it.
-- **System notification while the window is in the background** (on by default, since 1.10.6) — the card is drawn inside the page, so a window behind another app or minimized shows nothing and leaves only the sound. With this on, an alert arriving while the page is away is also raised as a system notification; back in front, the card is the only copy again. Turn it off to keep the overlay strictly in-page.
-
-The overlay only knows which screen the window is on, not which screen you are looking at. If the window stays on the primary display while you watch another one, it stays invisible — same as a toast.
+- **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 underneath 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.
 
@@ -201,9 +180,7 @@ The last block inside Advanced. The page protocol is detected automatically to t
 
 ## How it alerts
 
-- **Alert channel (pick one — the two never run together)**:
-  - **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)
-  - **In-page overlay** — an alert card drawn in the corner of the DSH page, on whatever display the window is on, optionally with Approve / Reject buttons; see [Secondary displays and the overlay](#secondary-displays-and-the-overlay)
+- **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)
 - **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
@@ -235,7 +212,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
 
@@ -250,19 +227,17 @@ 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)
-  channel: "toast",          // alert channel: 'toast' system notification | 'overlay' in-page card, pick one
+  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
-  overlay: false,             // legacy mirror kept in sync with channel (old configs migrate through it)
-  overlayCorner: "bottom-right", // overlay anchor: 'top-right' | 'bottom-right' | 'top-left' | 'bottom-left'
-  overlayAwayToast: true,     // overlay channel: also raise a system notification while the page is away (the only cross-channel exception)
   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"
@@ -299,7 +274,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.
 
@@ -324,7 +299,7 @@ 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. Use the in-page overlay for that — it follows the DSH window to its display.
+- 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**, 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).
@@ -340,7 +315,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
 ```
@@ -357,6 +332,7 @@ 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).
+- [@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,11 +24,11 @@
 DSH Web / Desktop 的通知插件，让你敢不开完整访问，也不必一直守着页面。
 
 - **需要你操作时**：审批、方案确认、提问，用通知、提示音和标题标记提醒。
-- **后台回复完成时**：及时回来查看结果，点击通知可回到对应对话。
+- **后台回复完成时**：及时回来查看结果，点击通知可回到对应对话；提醒时机可选「仅后台 / 仅当前对话静默 / 总是提醒」。
+- **人走开但窗口没走**：窗口留在最前台、人却离开座位，超过 3 分钟没有输入也算离开，该提醒的照常提醒；收到的那条通知不会在你回来之前自己消失。
 - **离开电脑时**：可选转发到 Discord、Bark、Gotify 或自己的 Webhook。
-- **不看主屏时**：把「通知类型」切成「浮层提醒」，卡片就跟着 DSH 窗口出现在你正看着的那块屏（系统通知只会出现在主屏）。
 
-> 页面或桌面应用需保持运行，后台 / 最小化可以。系统通知需要通知权限；审批按钮在支持 Service Worker 的 Web 环境（如 `http://127.0.0.1` 或 `https`）由通知提供，桌面端的通知没有按钮——把「通知类型」选成「浮层提醒」后可在浮层上直接裁决（见[副屏与浮层提醒](#副屏与浮层提醒)）。
+> 页面或桌面应用需保持运行，后台 / 最小化可以。系统通知需要通知权限。审批按钮靠 Service Worker 才能进通知：Web 端（`http://127.0.0.1` 或 `https`）有，桌面端 `dsh-app://` 页面注册不了，通知上没有按钮，点通知回到对话里裁决。
 
 > 🔎 想找这个插件？可以搜：`dsh-notify-me`、**消息提醒**、**可操作提醒**、**桌面通知**、**需要你操作**、**回复完成提醒**、**后台完成提醒**、**外部通知**、**Discord / Bark / Gotify 推送**（npm 关键词已含以上中英文词）。
 
@@ -38,16 +38,12 @@ DSH Web / Desktop 的通知插件，让你敢不开完整访问，也不必一
 
 *普通通知示例 · Windows / Edge · 不含审批按钮。* [查看原图](https://raw.githubusercontent.com/chromoany/dsh-notify-me/main/docs/screenshots/notify-toast.png)
 
-![DSH 页面右下角的三张浮层提醒：提问、审批请求（带「同意 / 拒绝」按钮）、回复完成](https://raw.githubusercontent.com/chromoany/dsh-notify-me/main/docs/screenshots/overlay-zh.png)
-
-*页面浮层提醒 · 真实插件在独立演示页里渲染 · 系统通知画不到副屏时用它，卡片落在 DSH 窗口所在的那块屏。* [查看原图](https://raw.githubusercontent.com/chromoany/dsh-notify-me/main/docs/screenshots/overlay-zh.png)
-
 <details>
 <summary>展开设置界面预览</summary>
 
 ![通知提醒设置页：页眉、提醒方式、什么时候提醒、试一试与折叠的高级设置](https://raw.githubusercontent.com/chromoany/dsh-notify-me/main/docs/screenshots/settings-zh.png)
 
-只截插件自己的面板（真实组件、v1.10.2 默认配置），不带 DSH 左侧导航栏；「通知类型」是分段选择器，每行说明在鼠标停在标题文字上时才出现，所以这里只看到标题。
+只截插件自己的面板（真实组件，与宿主同款深色主题），不带 DSH 左侧导航栏；每行说明在鼠标停在标题文字上时才出现，所以这里只看到标题。
 </details>
 
 ## 安装
@@ -74,7 +70,7 @@ dsh plugin --profile web add dsh-notify-me
 ## 首次验证
 
 1. 在 DSH 页面上点击一次，按提示允许通知；若此前拒绝过，在浏览器站点设置中允许通知。操作系统也需要允许对应浏览器 / DSH Desktop 显示通知。
-2. 打开 **设置 → 通知提醒**，确认出现该分区及底部插件版本号，保持「启用提醒」「提示音」开启，通知类型先留「系统通知」。
+2. 打开 **设置 → 通知提醒**，确认出现该分区及底部插件版本号，保持「启用提醒」「提示音」开启。
 3. 点击设置页的「测试『回复完成』」按钮：应出现一条测试通知，并按当前音效设置播放声音。这个本地测试不会转发到外部通知端点，也不受「窗口在前台时也提醒」开关限制。
 
 Web 用户可再测试审批按钮。桌面端拿不到 Service Worker，这条测试会在窗口角落画一张带「同意 / 拒绝」的卡片（1.10.4 起；之前的版本这里只发普通通知）。
@@ -102,11 +98,11 @@ dsh-notify-me 把「监督」和「守在屏幕前」解耦：只在真的出现
 | 事件 | 默认行为 |
 | --- | --- |
 | 🔔 需要你操作 | 页面可见也提醒；当前对话只留标题标记 |
-| ✅ 回复完成 | 页面隐藏 / 后台时提醒 |
+| ✅ 回复完成 | 页面隐藏 / 后台时提醒（可选「仅当前对话静默」或「总是提醒」） |
 
-**需要你操作**包括审批请求、方案待确认（plan review）和提问（`ask_user_question`）。审批带「同意 / 拒绝」：Web 走带按钮的系统通知，桌面端（注册不了 Service Worker）改画在窗口角落的卡片上。
+**需要你操作**包括审批请求、方案待确认（plan review）和提问（`ask_user_question`）。审批带「同意 / 拒绝」的按钮只在 Web 端有（需要 Service Worker）；桌面端注册不了，通知上没有按钮，点通知回到对话里裁决。
 
-**回复完成**也覆盖后台会话；完成但还没看时，标题带 `✅ 回复完成 ·` 标记，打开对应会话即撤。标题标记不受「窗口在前台时也提醒」开关限制。
+**回复完成**也覆盖后台会话；完成但还没看时，标题带 `✅ 回复完成 ·` 标记，打开对应会话即撤。标题标记不受提醒策略限制。
 
 > **后台**子代理（subagent）子会话的等待与完成默认**不提醒**：DSH 把每个子代理子会话列成独立会话，但它们是所属主对话那一轮里的步骤，提醒只会是噪音。你当前打开的那个子代理会话不算在内，照常提醒。设置页「子代理会话不提醒」可关掉这个静音。
 
@@ -117,32 +113,15 @@ dsh-notify-me 把「监督」和「守在屏幕前」解耦：只在真的出现
 ### 提醒方式
 
 - **启用提醒** 总开关：关闭后不弹通知、不响提示音，也不改标签页标题；
-- **通知类型（二选一）**：一行分段选择器，左边「系统通知」、右边「浮层提醒」，点哪个就只走哪个；
-  - **系统通知**（默认）：进 Windows / macOS 通知中心，需要通知权限；
-  - **页面浮层**：在 DSH 页面角落画提醒卡片，窗口在哪块屏它就在哪块屏——系统通知只会画在主屏，主屏不看时用它；不需要通知权限，桌面端也能在卡片上直接「同意 / 拒绝」。选中后卡片里会多出「浮层位置」子行，点开可选四个角落，见[副屏与浮层提醒](#副屏与浮层提醒)；
 - **提示音 / 音量**：开关直接切；音量滑块收在该行里，点一下标题（▸ 变成 ▾）展开。具体播什么由「高级设置 → 音效来源」决定；
-- **审批通知上直接裁决**（默认开）：审批带「同意 / 拒绝」，点一下即完成裁决，不用切回页面。Web 走带按钮的系统通知；桌面端 `dsh-app://` 注册不了 Service Worker，于是把按钮画在窗口角落的卡片上（12 秒自动收起，同一条审批不叠第二张卡）。也可以把「通知类型」换成「页面浮层」，改在浮层卡片上裁决。
-
-### 副屏与浮层提醒
-
-Windows 的系统通知横幅固定画在主屏上，系统没有设置项、浏览器也没有 API 能把它挪到别的显示器。主屏不看、DSH 停在副屏时，通知就等于没发。
-
-「页面浮层提醒」绕开系统通知中心，直接在 DSH 页面里画一张卡片：窗口在哪块屏，卡片就出现在哪块屏。
-
-- **位置**：选中「浮层提醒」后，「浮层位置」子行出现，行上直接显示当前值（默认右下）；点它（▸ 变 ▾）再选右上 / 右下 / 左上 / 左下，改完立刻生效；
-- **不需要通知权限**：通知权限没给、或桌面端弹不出带按钮的通知时，浮层照常工作；
-- **审批卡片带「同意 / 拒绝」**：与审批卡片的「允许一次 / 拒绝」等价，桌面端也能用（不依赖 Service Worker）；点卡片正文则切回对应对话；
-- **停留时间**：普通提醒 5 秒自动收起，带「同意 / 拒绝」的审批卡片 12 秒（系统通知用同一套数字）；也可以点卡片或右上角叉提前关掉。最多同时叠 4 张；
-- **与系统通知的关系**：二选一。以前两个开关可以同开，结果同一条提醒弹两遍、还互相挡住；1.10.0 起改成单选，1.10.2 起做成一行分段选择器。老配置里开着浮层的，升级后自动落到浮层。
-- **窗口在后台时补发系统通知**（默认开，1.10.6 起）：浮层画在页面里，窗口被别的应用挡住或最小化时看不见，等于只剩声音；开着这一项，页面离开前台时额外发一条系统通知，窗口回到前台还是只有卡片。不需要这份兜底就关掉它。
-
-浮层只知道窗口在哪块屏，不知道你人在看哪块屏。窗口留在主屏、人却盯着副屏时，它同样看不见。
+- **审批通知上直接裁决**（默认开）：审批带「同意 / 拒绝」，点一下即完成裁决，不用切回页面。Web 走带按钮的系统通知；桌面端 `dsh-app://` 注册不了 Service Worker，通知上没有按钮，点通知回到对话里裁决。设置页那行下面会如实说明当前环境能不能给按钮。
 
 ### 什么时候提醒
 
-- **窗口在前台时也提醒「需要你」**（默认开）：窗口在前台也提醒；关掉后只有窗口转到后台才提醒——切到别的应用、被别的窗口遮住、最小化都算后台；
-- **当前对话不弹通知**（默认开）：等待就发生在你正看着的对话里时只留标签页标记，免得挡住审批卡片；窗口转到后台后照常提醒，若你已处理掉就作废；
-- **窗口在前台时也提醒「回复完成」**（默认关）：默认只在窗口转到后台时提醒，避免打扰（桌面端窗口被遮住也算后台，1.10.5 起不再要求最小化）；
+- **窗口在前台时也提醒「需要你」**（默认开）：窗口在前台也提醒；关掉后只有窗口转到后台才提醒——切到别的应用、被别的窗口遮住、最小化都算后台。窗口一直留在前台但人离开座位（默认 3 分钟没有任何键鼠输入）同样算后台；`idleMinutes: 0` 退回只看窗口；
+- **当前对话不弹通知**（默认开）：等待就发生在你正看着的对话里时只留标签页标记，免得打断眼前的操作；人离开（窗口转到后台或闲置超时）后照常提醒，若你已处理掉就作废；
+- **「回复完成」什么时候提醒**（默认「仅后台」）：三选一。「仅后台」＝原来的规则，不在看页面才提醒；「仅当前对话静默」＝屏幕上那条静默，别的对话完成照常提醒，多开对话时有用；「总是提醒」＝从不静默。老配置里的「窗口在前台时也提醒『回复完成』」开关自动迁移到这一项；
+- **通知自动消失**（默认「离开时保留」）：三选一。「离开时保留」＝只有你在看页面时才几秒后关闭，人不在时收到的那条留在通知中心等你回来；「总是关闭」＝旧行为；「从不关闭」＝普通通知一直留着，等你点掉。带「同意 / 拒绝」的审批通知仍按 12 秒走，同样不会在人不在时被撤掉；
 - **子代理会话不提醒**（默认开）：跳过后台子代理（subagent）会话——它们是主对话那一轮的步骤，完成由主对话自己的提醒覆盖；你当前打开的那个子代理会话照常提醒；
 - **点击通知回到对应对话**（默认开）：点通知切到提醒所属的对话；浏览器里同时把窗口带到前台；桌面端不稳定——有时窗口会上前，有时只切对话（见[桌面端怎么抬窗的](#桌面端怎么抬窗的)）；多个标签页同时开着时只调起一个（优先当前可见的那个）；关掉后点通知不做任何事。
 
@@ -197,9 +176,7 @@ Windows 的系统通知横幅固定画在主屏上，系统没有设置项、浏
 
 ## 提醒渠道
 
-- **提醒渠道（二选一，不同时出现）**：
-  - **系统通知**：经浏览器弹出的系统通知，进 Windows 通知中心或 macOS 通知中心（点击回到提醒所属的对话；支持快捷裁决的 Web 环境可点审批按钮直接裁决，桌面端无按钮）
-  - **页面浮层**：画在 DSH 页面角落的提醒卡片，落在窗口所在的那块屏，可带「同意 / 拒绝」按钮；见[副屏与浮层提醒](#副屏与浮层提醒)
+- **系统通知**：经浏览器弹出的系统通知，进 Windows 通知中心或 macOS 通知中心（点击回到提醒所属的对话；支持快捷裁决的 Web 环境可点审批按钮直接裁决，桌面端没有按钮）
 - **提示音**：默认是 WebAudio 合成音（「需要你」与「完成」使用不同音型）；可在设置里为两类提醒分别换成自定义音频文件，或改成让操作系统播放它自己的通知音
 - **标签页标题标记**：有待处理事项时，标题前出现 `🔔 需要你 · …` / `🔔 Action needed · …`；后台会话**完成但还没看**时出现 `✅ 回复完成 · …` / `✅ Reply finished · …`，打开对应会话（或它再次开跑）即消失。两种标记可同时出现，「需要你」在前；宿主改写标题后标记基于新标题重建
 - **外部通知**（可选，默认关）：按设置里配的推送目标，把同一条提醒转发到 Discord Webhook / Bark / Gotify / 自定义 Webhook——临时离开电脑时，手机上的推送渠道照样收到
@@ -231,7 +208,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/`），与宿主无关。
 
 ## 控制台高级配置
 
@@ -246,19 +223,17 @@ 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）会话不提醒（当前打开的照常）
-  channel: "toast",          // 通知类型：'toast' 系统通知 | 'overlay' 页面浮层，二选一
   sound: true,                // 提示音开关（含「系统通知音」模式）
   soundDone: "synth",         // 「完成」音效来源：'synth' 内置 | 'custom' 自定义文件 | 'system' 系统通知音
   soundAttention: "synth",    // 「需要你」音效来源，取值同上
   volume: 0.5,                // 音量 0~1
   autoFocus: true,            // 点通知回到提醒所属的对话
   quickActions: true,         // 审批通知上的「同意 / 拒绝」按钮
-  overlay: false,             // 兼容字段，跟随 channel 同步（老配置靠它迁移）
-  overlayCorner: "bottom-right", // 浮层位置：'top-right' | 'bottom-right' | 'top-left' | 'bottom-left'
-  overlayAwayToast: true,     // 浮层通道下，页面在后台时额外发一条系统通知（唯一跨通道例外）
   externalEnabled: false,     // 外部通知转发主开关（默认关：不填端点就什么都不发）
   externalAttention: true,    // 转发「需要你」（触发规则跟本地提醒完全一致）
   externalDone: true,         // 转发「回复完成」
@@ -295,9 +270,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 秒），到点自动撤；没来得及点就回页面里裁决，对话里的审批一直等着你。
 
 ### 桌面端怎么抬窗的
 
@@ -318,7 +293,7 @@ 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` 字段会说明原因，其余功能不受影响。
@@ -326,7 +301,7 @@ DSH Desktop 是一层 Electron 壳，页面跑在 `dsh-app://app` 下：DOM 的
 - 配置存在浏览器 `localStorage`：换浏览器/设备或清除站点数据后会回到默认值（设置页可一键恢复默认）。
 - `≥ 0.1.6`（含 `0.2.0-rc.2`、`0.2.1-rc.2`）的「回复完成」提醒正文只有会话名，不再附带回复摘要——宿主快照已不再提供 `nodes`；提醒本身照常触发。
 - 标题标记由宿主与插件共同写 `document.title`：宿主重算标题时标记可能被覆盖，直到下一次提醒事件重新写成。
-- 「当前对话不弹通知」按 `document.hidden` 判定：窗口被别的应用完全盖住时仍算「页面可见」，此时当前对话的等待照样静默。
+- 「当前对话不弹通知」按「窗口是否在前台」判定：窗口被别的应用盖住、切到别的应用、最小化都算后台，此时当前对话的等待照常提醒；窗口回到前台再静默。
 - 外部通知转发受浏览器跨域（CORS）限制：端点不放行时自动降级为「送出但不可确认」（no-cors），如实标为「已送出不可确认」；Discord Webhook 官方放行跨域，可直接确认送达。HTTP 错误如实记失败、不重试。转发在本地提醒决定要发之后才触发，所以被「当前对话不弹通知」等规则静音的提醒也不会外发。
 
 - **设置左侧导航行图标靠 DOM 补丁**：外壳按分区 id 硬编码图标且 `settings.section` 没有图标字段，插件只能在面板渲染后把那一行的 `<svg>` 换成铃铛。命中依赖宿主当前的面板结构（`data-shortcut-modal="settings"` + 导航按钮里的标签 `<span>`）；如果 DSH 改了这套结构，补丁会静默失效、显示回默认齿轮，其他功能不受影响。
@@ -336,7 +311,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               # 预览发布包
 ```
@@ -353,6 +328,7 @@ 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）。
+- [@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 图只显示维护者，贡献者以上面的致谢署名。