dominds 1.19.3 → 1.20.1

package/README.md

@@ -295,6 +295,7 @@ Result: fewer bad side effects, higher plan fidelity, and more first‑try succe
 - **[FBR](docs/fbr.md)** — Fresh Boots Reasoning (`freshBootsReasoning`) design and enhancements
 - **[Context Health](docs/context-health.md)** — Measuring/maintaining context quality
 - **[Diligence Push](docs/diligence-push.md)** — Auto-continue (diligence) mechanism
+- **[Idle Reminder Wake](docs/idle-reminder-wake.md)** — Runtime wakeups from owner-managed reminder events
 - **[Showing-by-Doing](docs/showing-by-doing.md)** — A dialog-creation prelude that makes Tellask feel real
 - **[Design](docs/design.md)** — Architecture and key abstractions
 - **[Roadmap](docs/roadmap.md)** — Major-version plan and evolution

package/dist/access-control.js

@@ -312,12 +312,12 @@ function getAccessDeniedMessage(operation, targetPath, language = 'en') {
         lines.push('');
         if (language === 'zh') {
             lines.push(`- 说明：\`*.tsk/\` 是封装差遣牒。通用文件工具无法读/写/列目录/删除其中内容（硬编码无条件拒绝）。`);
-            lines.push(`- 提示：写入/更新请使用函数工具 \`change_mind\`（顶层：\`change_mind({\"selector\":\"goals|constraints|progress\",\"content\":\"...\"})\`；额外章节：\`change_mind({\"category\":\"<category>\",\"selector\":\"<selector>\",\"content\":\"...\"})\`）。`);
+            lines.push(`- 提示：少量追加请使用 \`mind_more\`（默认 progress：\`mind_more({\"items\":[\"...\"]})\`）；整章替换请使用 \`change_mind\`（顶层：\`change_mind({\"selector\":\"goals|constraints|progress\",\"content\":\"...\"})\`；额外章节：\`change_mind({\"category\":\"<category>\",\"selector\":\"<selector>\",\"content\":\"...\"})\`）。`);
             lines.push(`- 提示：读取额外章节请使用函数工具 \`recall_taskdoc\`：\`recall_taskdoc({\"category\":\"<category>\",\"selector\":\"<selector>\"})\`。`);
         }
         else {
             lines.push(`- Note: \`*.tsk/\` is an encapsulated Taskdoc. It is hard-denied for all general file tools.`);
-            lines.push(`- Hint: For updates, use the function tool \`change_mind\` (top-level: \`change_mind({\"selector\":\"goals|constraints|progress\",\"content\":\"...\"})\`; extra sections: \`change_mind({\"category\":\"<category>\",\"selector\":\"<selector>\",\"content\":\"...\"})\`).`);
+            lines.push(`- Hint: For small append-only updates, use \`mind_more\` (defaults to progress: \`mind_more({\"items\":[\"...\"]})\`); for full-section replacements, use \`change_mind\` (top-level: \`change_mind({\"selector\":\"goals|constraints|progress\",\"content\":\"...\"})\`; extra sections: \`change_mind({\"category\":\"<category>\",\"selector\":\"<selector>\",\"content\":\"...\"})\`).`);
             lines.push(`- Hint: To read extra sections, use \`recall_taskdoc({\"category\":\"<category>\",\"selector\":\"<selector>\"})\`.`);
         }
     }

package/dist/dialog.d.ts

@@ -21,6 +21,11 @@ import { ChatMessage, FuncResultMsg, TellaskCarryoverMsg, TellaskResultMsg } fro
 import type { ToolResultImageIngest, UserImageIngest } from './llm/gen';
 import type { JsonValue } from './tool';
 import { Reminder, ReminderOptions, ReminderOwner } from './tool';
+export declare class InvalidReminderIndexError extends Error {
+    readonly index: number;
+    readonly total: number;
+    constructor(index: number, total: number);
+}
 type NewCourseHookResult = {
     kind: 'continue';
     prompt: DialogRuntimePrompt;
@@ -357,7 +362,7 @@ export declare abstract class Dialog {
     /**
      * Start a new course - clears conversational noise, Q4H, and increments course counter.
      * Queues a new-course prompt for the driver to consume on the next drive cycle.
-     * This is the single entry point for mental clarity operations (clear_mind, change_mind).
+     * This is the single entry point for mental clarity operations that start a new course.
      */
     startNewCourse(newCoursePrompt: string, options?: {
         runControl?: DialogRunControlSpec;

package/dist/dialog.js

@@ -1,6 +1,6 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.DialogStore = exports.MainDialog = exports.SideDialog = exports.Dialog = exports.DialogID = void 0;
+exports.DialogStore = exports.MainDialog = exports.SideDialog = exports.Dialog = exports.DialogID = exports.InvalidReminderIndexError = void 0;
 exports.buildSideDialogAskerStack = buildSideDialogAskerStack;
 const id_1 = require("@longrun-ai/kernel/utils/id");
 const time_1 = require("@longrun-ai/kernel/utils/time");
@@ -14,6 +14,15 @@ const work_language_1 = require("./runtime/work-language");
 const shared_reminders_1 = require("./shared-reminders");
 const tool_1 = require("./tool");
 const id_2 = require("./utils/id");
+class InvalidReminderIndexError extends Error {
+    constructor(index, total) {
+        super(`Reminder target index ${index} is stale; current reminder count is ${total}`);
+        this.name = 'InvalidReminderIndexError';
+        this.index = index;
+        this.total = total;
+    }
+}
+exports.InvalidReminderIndexError = InvalidReminderIndexError;
 class DialogID {
     constructor(selfId, rootId) {
         this.selfId = selfId;
@@ -423,7 +432,7 @@ class Dialog {
     }
     deleteReminder(index) {
         if (index < 0 || index >= this.reminders.length) {
-            throw new Error(`Reminder index ${index} does not exist. Available reminders: 0-${this.reminders.length - 1}`);
+            throw new InvalidReminderIndexError(index, this.reminders.length);
         }
         const deleted = this.reminders.splice(index, 1)[0];
         this.touchReminders();
@@ -431,7 +440,7 @@ class Dialog {
     }
     updateReminder(index, content, meta, options) {
         if (index < 0 || index >= this.reminders.length) {
-            throw new Error(`Reminder index ${index} does not exist. Available reminders: 0-${this.reminders.length - 1}`);
+            throw new InvalidReminderIndexError(index, this.reminders.length);
         }
         const oldReminder = this.reminders[index];
         const updatedReminder = (0, tool_1.materializeReminder)({
@@ -1035,7 +1044,7 @@ class Dialog {
     /**
      * Start a new course - clears conversational noise, Q4H, and increments course counter.
      * Queues a new-course prompt for the driver to consume on the next drive cycle.
-     * This is the single entry point for mental clarity operations (clear_mind, change_mind).
+     * This is the single entry point for mental clarity operations that start a new course.
      */
     async startNewCourse(newCoursePrompt, options) {
         const trimmedPrompt = newCoursePrompt.trim();

package/dist/docs/context-health.md

@@ -25,7 +25,11 @@ Dominds already has:
     (UI-visible and rendered as a normal user instruction).
   - In **critical**, enforce stability via a **countdown remediation** (max 5 turns):
     - Each turn injects a **recorded role=user prompt** (UI-visible as a user prompt) that instructs
-      the agent to curate reminders (`update_reminder`/`add_reminder`) and then `clear_mind`.
+      Main Dialogs to first record current-dialog discussion details that are not yet documented but the
+      next course needs to know into the appropriate Taskdoc sections, then curate continuation-package
+      reminders (`update_reminder`/`add_reminder`) and `clear_mind`. Side Dialogs are instructed not to
+      maintain Taskdoc or draft update proposals; they maintain sufficiently detailed continuation-package
+      reminders instead, with no technical length limit, then `clear_mind`.
     - The prompt includes a countdown signal (how many reminders remain before auto-`clear_mind`).
     - When the countdown reaches 0, Dominds **automatically** executes `clear_mind` (no Q4H; no
       suspension) to keep long-running autonomy stable.
@@ -135,10 +139,16 @@ Rules:
 - Do not let the agent branch on subjective self-assessment such as “clear-headed” vs “muddled”.
 - When the current course is not under `caution` / `critical` remediation, prefer compressing into
   one structured continuation-package reminder.
-- When the system has put the current course into `caution` / `critical` remediation, prioritize
-  preserving volatile information even via multiple rough reminders; in the current course, only
-  preserve info and `clear_mind`. Once the system actually starts the next course, the first step
-  is to review, merge, and delete redundancy.
+- When the system has put the current course into `caution` / `critical` remediation, the driver splits
+  prompts by dialog scope:
+  - Main Dialog: first fill Taskdoc with current-dialog discussion details that are not yet documented
+    but the next course needs to know; then preserve details still not covered by Taskdoc but easy to
+    lose during resume.
+  - Side Dialog: do not maintain Taskdoc and do not draft Taskdoc update proposals; directly maintain
+    sufficiently detailed continuation-package reminders. Reminder length has no technical limit, so
+    prefer being complete.
+  - Multiple rough bridge reminders are acceptable. Once the system actually starts the next course,
+    the first step is to review, merge, and delete redundancy.
 - Do not duplicate Taskdoc content except for a short bridge when strictly needed.
 - Do not paste long raw logs/tool outputs into the continuation package.
 
@@ -157,7 +167,10 @@ Current behavior:
 - On entering `caution`, Dominds inserts the prompt once (entry injection).
 - While still `caution`, Dominds reinserts the prompt on a cadence (default: every **10**
   generations; configurable per model).
-- Each inserted prompt requires the agent to **curate reminders** (at least one call):
+- Each inserted prompt is split by the program according to dialog scope, so the agent does not decide
+  whether it is in the Main Dialog or a Side Dialog:
+  - Main Dialog: update Taskdoc first with `mind_more` / `change_mind`, then curate reminders (at least one call)
+  - Side Dialog: do not maintain Taskdoc and do not draft Taskdoc update proposals; directly curate sufficiently detailed reminders (at least one call)
   - `update_reminder` (preferred) / `add_reminder`
   - Default to one structured continuation-package reminder; if the current course is already under remediation and one structured reminder cannot be produced directly from already observed facts, rough multi-reminder carry-over is acceptable
   - Then `clear_mind` when it becomes scannable/actionable
@@ -167,9 +180,13 @@ Current behavior:
 When `level === 'critical'`, the driver enters a **countdown remediation** (max **5** turns):
 
 - On each turn, the driver records a **role=user prompt** (persisted as a user message) that is
-  visible in the UI as a user prompt. This prompt tells the agent to:
-  - curate reminders via `update_reminder` / `add_reminder`, preferably into a continuation-package reminder but allowing rough multi-reminder carry-over when the current course is already under remediation and a single structured reminder cannot be produced directly from already observed facts, and
-  - then call `clear_mind` to start a new course.
+  visible in the UI as a user prompt. The prompt is scope-specific:
+  - Main Dialog prompt: first write undocumented discussion details that the next course needs to know
+    into the appropriate Taskdoc sections with `mind_more` / `change_mind`, then curate reminders via
+    `update_reminder` / `add_reminder`, and call `clear_mind`.
+  - Side Dialog prompt: do not maintain Taskdoc and do not draft Taskdoc update proposals; directly
+    maintain sufficiently detailed continuation-package reminders with no technical length limit, then
+    call `clear_mind`.
 - The prompt includes a countdown: after **N** turns the system will automatically clear.
 - When the countdown reaches 0, the driver **automatically calls** `clear_mind` (with empty args; no
   requirement on `reminder_content`), starting a new course without suspending.
@@ -234,9 +251,18 @@ Additional constraints:
 - v3 remediation:
   - `caution`: driver inserts a persisted role=user prompt (UI-visible user instruction).
     On entering `caution` it inserts once; while still `caution` it reinserts on a cadence (default: every
-    10 generations; configurable per model). Each time, the agent must call at least one of
-    `update_reminder` / `add_reminder` and preserve a continuation package. A single structured reminder is preferred when the current course is not under remediation pressure; during remediation, multiple rough reminders are acceptable if they can be written directly from already observed facts without further reading/analysis. In the new course the agent should reconcile them first, then `clear_mind` when ready.
+    10 generations; configurable per model). Each time, the agent must first record undocumented
+    discussion details the next course needs to know into Taskdoc, then call at least one of
+    `update_reminder` / `add_reminder` and preserve a continuation package. In a Side Dialog, the
+    prompt says not to maintain Taskdoc or draft Taskdoc update proposals; instead, maintain sufficiently
+    detailed continuation-package reminders directly.
+    A single structured reminder is preferred when the current course is not under remediation pressure;
+    during remediation, multiple rough reminders are acceptable if they can be written directly from
+    already observed facts without further reading/analysis. In the new course the agent should
+    reconcile them first, then `clear_mind` when ready.
   - `critical`: driver runs a countdown remediation (max 5 turns) using **recorded role=user prompts**.
-    Each prompt includes a countdown and instructs reminder curation + `clear_mind`. When the countdown
-    reaches 0, the driver auto-executes `clear_mind` and starts a new course (no Q4H, no suspension).
+    Each prompt includes a countdown. Main Dialog prompts instruct Taskdoc update, reminder curation,
+    then `clear_mind`; Side Dialog prompts instruct detailed reminder curation only, then `clear_mind`.
+    When the countdown reaches 0, the driver auto-executes `clear_mind` and starts a new course (no Q4H,
+    no suspension).
 - UI shows context health with green/yellow/red (and “unknown” handling when usage is unavailable).

package/dist/docs/context-health.zh.md

@@ -19,7 +19,7 @@ Dominds 已具备以下功能：
 - 当对话上下文"过大"时，执行简短的、可执行的、可回归测试的 **v3 恢复**工作流：
   - 在 **caution（警告）** 级别，记录一条自动插入的 **role=user prompt** 作为正常的、持久化的用户消息（UI 可见并渲染为正常的用户指令）。
   - 在 **critical（严重）** 级别，通过**倒计时恢复**（最多 5 轮）强制执行稳定性：
-    - 每轮注入一条**记录的角色为 user 的 prompt**（UI 可见为用户 prompt），指示智能体整理提醒项（`update_reminder`/`add_reminder`），然后执行 `clear_mind`。
+    - 每轮注入一条**记录的角色为 user 的 prompt**（UI 可见为用户 prompt）。主线对话提示智能体先把当前对话历史中尚未落实到文档、且下一程需要知会的讨论细节落到差遣牒合适章节，再整理接续包提醒项（`update_reminder`/`add_reminder`），然后执行 `clear_mind`；支线对话提示智能体不要维护差遣牒、也不要整理更新提案，只维护足够详尽的接续包提醒项（长度无技术限制），然后执行 `clear_mind`。
     - prompt 包含倒计时信号（在进行自动 `clear_mind` 之前还剩多少轮）。
     - 当倒计时归零时，Dominds **自动**执行 `clear_mind`（无需 Q4H；无需暂停）以保持长期运行的自主性。
 
@@ -112,7 +112,10 @@ Dominds 计算比率：
 - 普通提醒项保持简短且少量。
 - 不允许智能体靠主观感觉判断自己“头脑清楚”还是“已经发乱”；这两种说法没有可靠、可审计的客观判据。
 - 机制性分流规则只有一个：看**系统是否已将当前程置于上下文健康处置态**。若当前没有 `caution/critical` 处置指令，则默认优先压缩成一个结构化接续包提醒项。
-- 一旦系统已将当前程置于 `caution/critical` 处置态，当前程的目标就切换为“保住易丢信息并尽快 `clear_mind`”，此时允许多条粗略提醒项过桥；系统真正开启新一程后，第一步再复核、合并并删除冗余。
+- 一旦系统已将当前程置于 `caution/critical` 处置态，驱动程序按对话范围分流提示：
+  - 主线对话：先把当前对话历史中尚未落实到文档、且下一程需要知会的讨论细节写入差遣牒合适章节；随后只把差遣牒仍未覆盖、但恢复工作容易丢的细节放入接续包。
+  - 支线对话：不要维护差遣牒，也不要整理差遣牒更新提案；直接维护足够详尽的接续包提醒项，提醒项长度没有技术限制，宁可完整一些。
+  - 此时允许多条粗略提醒项过桥；系统真正开启新一程后，第一步再复核、合并并删除冗余。
 - 除非确有必要，不要重复差遣牒已覆盖的内容。
 - 不要把长原始日志/大段 tool output 直接塞进接续包。
 
@@ -126,7 +129,9 @@ Dominds 计算比率：
 
 - 进入 `caution` 时，Dominds 插入一次提示（入口注入）。
 - 保持在 `caution` 状态时，Dominds 按节奏重新插入（默认：每 **10** 次生成；可按模型配置）。
-- 每次插入的提示都要求智能体**整理提醒项**（至少一次调用）：
+- 每次插入的提示都由程序按范围分流，不要求智能体自己判断主线/支线：
+  - 主线对话：先使用 `mind_more` / `change_mind` 补齐差遣牒，再整理提醒项（至少一次调用）
+  - 支线对话：不维护差遣牒，也不整理差遣牒更新提案；直接整理足够详尽的提醒项（至少一次调用）
   - `update_reminder`（首选）/ `add_reminder`
   - 在提醒项内维护接续包草稿
   - 当可扫描/可操作时执行 `clear_mind`
@@ -135,14 +140,16 @@ Dominds 计算比率：
 
 当 `level === 'critical'` 时，驱动程序进入**倒计时恢复**（最多 **5** 轮）：
 
-- 每轮，驱动程序记录一条 **role=user prompt**（持久化为用户消息），在 UI 中作为用户 prompt 可见。此提示告诉智能体：
-  - 通过 `update_reminder` / `add_reminder` 整理提醒项（尽力而为的接续包），然后调用 `clear_mind` 开始新一程。
+- 每轮，驱动程序记录一条 **role=user prompt**（持久化为用户消息），在 UI 中作为用户 prompt 可见。提示按范围分开：
+  - 主线对话提示：先用 `mind_more` / `change_mind` 把未落文档、且下一程需要知会的讨论细节写入差遣牒合适章节，再通过 `update_reminder` / `add_reminder` 整理提醒项并调用 `clear_mind`。
+  - 支线对话提示：不要维护差遣牒，也不要整理差遣牒更新提案；直接维护足够详尽的接续包提醒项，提醒项长度没有技术限制，然后调用 `clear_mind`。
 - 提示包含倒计时：经过 **N** 轮后系统将自动清空。
 - 当倒计时归零时，驱动程序**自动调用** `clear_mind`（带空参数；不要求 `reminder_content`），开始新一程且无需暂停。
 
 理由：
 
 - `caution` 已经在提醒项中尽力推动接续包草稿的编写。
+- 告急提示仍要求主线先补差遣牒；支线则以详尽提醒项保存讨论细节，避免维护人提案在上下文吃紧时额外增加心智负担。
 - 在 `critical` 状态下，我们更倾向于保持对话长期运行而无需人工干预。
 
 ## UI（Webapp）预期
@@ -193,6 +200,6 @@ Dominds 计算比率：
   - 未配置时 `optimal_max_tokens` 默认为 `100_000`。
   - 未配置时 `critical_max_tokens` 默认为 `floor(modelContextLimitTokens * 0.9)`。
 - v3 恢复：
-  - `caution`：驱动程序插入持久化的 role=user prompt（UI 可见的用户指令）。进入 `caution` 时插入一次；保持在 `caution` 状态时按节奏重新插入（默认：每 10 次生成；可按模型配置）。每次智能体必须至少调用 `update_reminder` / `add_reminder` 之一并维护接续包草稿，然后在就绪时执行 `clear_mind`。
-  - `critical`：驱动程序使用**记录的角色为 user 的 prompt** 运行倒计时恢复（最多 5 轮）。每次提示包含倒计时并指示提醒整理 + `clear_mind`。当倒计时归零时，驱动程序自动执行 `clear_mind` 并开始新一程（无 Q4H，无暂停）。
+  - `caution`：驱动程序插入持久化的 role=user prompt（UI 可见的用户指令）。进入 `caution` 时插入一次；保持在 `caution` 状态时按节奏重新插入（默认：每 10 次生成；可按模型配置）。主线提示要求先把未落文档、且下一程需要知会的讨论细节补进差遣牒，再至少调用 `update_reminder` / `add_reminder` 之一维护接续包草稿；支线提示要求不要维护差遣牒/更新提案，直接维护足够详尽的接续包提醒项；然后在就绪时执行 `clear_mind`。
+  - `critical`：驱动程序使用**记录的角色为 user 的 prompt** 运行倒计时恢复（最多 5 轮）。每次提示包含倒计时；主线提示指示先补差遣牒，再整理提醒项并 `clear_mind`；支线提示指示只维护详尽提醒项并 `clear_mind`。当倒计时归零时，驱动程序自动执行 `clear_mind` 并开始新一程（无 Q4H，无暂停）。
 - UI 显示上下文健康状态：绿色/黄色/红色（以及使用情况不可用时的"未知"处理）。

package/dist/docs/idle-reminder-wake.md

@@ -0,0 +1,227 @@
+# Idle Reminder Wake Design
+
+Chinese version: [中文版](./idle-reminder-wake.zh.md)
+
+This document defines a driver-level background coroutine mechanism: after a dialog enters `idle_waiting_user`, the runtime may wait for wake-worthy events from reminder owners. If an event arrives while the dialog is still idle, the runtime packages the event into a system-notice `role=user` message and continues driving the dialog.
+
+This is a design document. It defines semantics, owner interfaces, cancellation, and the current implementation target; it does not prescribe the final code split.
+
+---
+
+## Background
+
+Reminder owners already own the meaning of their reminders. For example, the `shell_cmd` daemon reminder can discover that a daemon has exited during the next reminder update and turn the reminder into a terminal snapshot.
+
+The missing link is idle-time wakeup. If a daemon exits while the dialog is idle, Dominds currently notices only when the dialog is opened, reminders are displayed, or a later drive happens. From the user's perspective, the long-running command has completed, but the dialog does not automatically wake up or explain that the process exited.
+
+The `shell_cmd` tool should not directly drive dialogs to solve this. The driver is the only component that should decide whether a dialog continues running. A reminder owner should only explain when one of its reminders has produced an environment event worth waking the model for.
+
+---
+
+## Goals
+
+- Start a cancelable background await task only after the dialog truly enters `idle_waiting_user`.
+- Let reminder owners expose wake-worthy events such as daemon exit.
+- After an event arrives, briefly aggregate nearby events before forming one runtime `role=user` system notice.
+- If the dialog is still idle after aggregation, continue through the normal driver path.
+- Cancel the existing idle await task whenever any new drive starts.
+- Preserve owner metadata encapsulation: framework code routes by owner but does not reinterpret owner meta.
+- Guarantee idempotence: the same environment event must not insert duplicate system notices.
+
+## Non-Goals
+
+- Do not treat every reminder content change as a wake signal.
+- Do not let reminder owners call `driveDialogStream` directly.
+- Do not represent the idle await task as an `activeRun`, because the UI must not see environment waiting as proceeding.
+- Do not auto-wake blocked, stopped, dead, completed, or archived dialogs.
+- Do not wake on every daemon stdout/stderr growth; the current scenario only covers daemon lifecycle exit.
+
+---
+
+## Core Decisions
+
+### 1. The driver owns the idle wake lifecycle
+
+After `driveDialogStreamCore` finally sets display state to `idle_waiting_user`, the outer driver starts a dialog-scoped idle wake task.
+
+The task:
+
+- does not hold the dialog mutex
+- does not create an active run
+- does not change display state
+- only waits for owner-provided wake events
+- is canceled before a new drive begins
+
+This keeps "waiting for an environment event" separate from "actively working" and avoids confusing user-visible run-control semantics.
+
+### 2. Reminder owners only report wake events
+
+`ReminderOwner` gains an optional interface:
+
+```ts
+export type ReminderWakeEvent = Readonly<{
+  eventId: string;
+  reminderId: string;
+  content: string;
+  updatedContent?: string;
+  updatedMeta?: JsonValue;
+}>;
+
+export interface ReminderOwner {
+  readonly name: string;
+  updateReminder(dlg: Dialog, reminder: Reminder): Promise<ReminderUpdateResult>;
+  renderReminder(dlg: Dialog, reminder: Reminder): Promise<ChatMessage>;
+
+  waitForReminderWakeEvent?(
+    dlg: Dialog,
+    reminders: readonly Reminder[],
+    signal: AbortSignal,
+  ): Promise<ReminderWakeEvent | readonly ReminderWakeEvent[] | null>;
+}
+```
+
+`content` is owner-formatted system-notice text and must start with `【系统提示】` or `[System notice]`. It is not real user input, but because providers commonly lack a dedicated environment role, it is persisted through the runtime prompt path as a `role=user` message.
+
+`eventId` is a stable idempotence key in the owner's domain. The owner must be able to record, in reminder meta or owner-owned state, that the event has already been delivered.
+
+### 3. The first event opens a short aggregation window
+
+The driver should not drive immediately after the first wake event. It should:
+
+1. await the first wake event
+2. open an aggregation window of about 500 ms
+3. collect other wake events that arrive in the same idle wake task
+4. stably sort and deduplicate the events
+5. package them into one runtime prompt
+
+This prevents several daemons that exit close together from causing several consecutive drive rounds. The user and model see one combined environment-status message instead of fragmented notices.
+
+### 4. Wake must re-check fresh state
+
+After the aggregation window, the driver must re-read persistence and verify:
+
+- the dialog still exists and is running
+- display state is still `idle_waiting_user`
+- execution marker is not dead and not an interrupted state requiring human resume
+- no pending Q4H exists
+- no blocking pending sideDialog exists
+- no active run exists
+
+Only then may the driver continue with the wake prompt. Otherwise the wake is dropped, while owner idempotence/state updates may still be retained.
+
+### 5. Any drive cancels the idle wake task
+
+Before any new drive begins, runtime must cancel the dialog's existing idle wake task. This includes:
+
+- user messages
+- manual Continue / Resume All
+- Q4H-answer resume
+- sideDialog-response resume
+- Diligence Push / other runtime auto-drive
+- the wake drive from this mechanism
+
+After cancellation, the old task must not produce side effects even if one of its promises resolves.
+
+---
+
+## Wake Message Format
+
+Owner event `content` should state facts without inventing a user request.
+
+Daemon exit example:
+
+```text
+【系统提示】
+后台进程已退出。这是 runtime 环境事件，不是新的用户指令。
+
+- PID: 12345
+- 命令: pnpm run build
+- 退出状态: code 0, signal null
+
+请根据当前任务上下文判断是否需要查看最终 stdout/stderr 或向用户汇报结果；不要只回复“收到”。
+```
+
+When the driver aggregates multiple events, it should preserve each factual block and add a shared prefix:
+
+```text
+【系统提示】
+以下是对话空闲期间发生的 runtime 环境事件。这些事件不是新的用户指令。
+
+1. 后台进程已退出 ...
+2. 后台进程已退出 ...
+
+请结合当前任务上下文继续推进；若这些事件不影响当前工作，不要发送占位式确认。
+```
+
+---
+
+## Current Target: Shell Daemon Exit
+
+`shellCmdReminderOwner` implements `waitForReminderWakeEvent`.
+
+Semantics:
+
+- It only watches daemon reminders owned by this owner.
+- It only emits a wake event when a daemon transitions from running to exited/gone.
+- stdout/stderr growth does not emit a wake event.
+- If reminder meta already marks the corresponding exit event as delivered, it returns `null`.
+- When the event arrives, the owner also provides terminal reminder `updatedContent` / `updatedMeta`, and the driver persists them before delivering the wake prompt.
+
+Required meta additions:
+
+- `originRootId`: needed to restore the origin dialog.
+- `originDialogId`: existing field; continues to mean self id.
+- `exitWakeEventId`: stable event id, for example `shellCmd:daemonExited:<pid>:<startTime>`.
+- `exitWakeNotifiedAt`: timestamp when runtime accepted and delivered the event.
+
+If the daemon runner can provide an awaitable exit signal, use that as the primary path. If the current implementation can only use local IPC status checks, polling must stay encapsulated inside the owner; the driver must not gain daemon-specific scanning logic.
+
+---
+
+## Cancellation And Concurrency
+
+There is at most one idle wake task per dialog.
+
+Suggested runtime state:
+
+```ts
+type IdleReminderWakeTask = Readonly<{
+  dialogKey: string;
+  controller: AbortController;
+  startedAt: string;
+}>;
+```
+
+The first preflight step of a new drive cancels the old task. Cancellation is idempotent.
+
+After an idle wake task resolves, it must also verify that it is still the current task. If it has been replaced or canceled, it returns without side effects.
+
+---
+
+## Crash Recovery
+
+The idle wake task itself is not persisted. After backend restart, Dominds does not recover in-flight waiting promises.
+
+The first normal driver/display/reminder update after restart still corrects reminder terminal state. If restart-time proactive waking is needed, Dominds can add bootstrap logic that reinstalls idle wake tasks for running idle dialogs. That capability is not required for the current mechanism to be complete.
+
+---
+
+## Observability And Error Handling
+
+Owner wait interfaces are loud by default:
+
+- Non-cancel errors should be structured logs with `rootId`, `selfId`, `ownerName`, `reminderId`, and `eventId` when available.
+- Owners must not swallow unreasonable states, such as the same event id mapping to conflicting content.
+- If the driver finds that an aggregated wake can no longer revive the dialog, it should record debug/warn diagnostics, but it must not surface the dropped wake as a user-visible message.
+
+---
+
+## Implementation Order
+
+1. Add `ReminderWakeEvent` and optional `ReminderOwner.waitForReminderWakeEvent?` types.
+2. Add driver-side idle wake task management: start/cancel/race/500 ms aggregation/fresh state checks.
+3. Cancel the dialog's idle wake task in every drive preflight.
+4. Start an idle wake task after the driver finally lands on `idle_waiting_user`.
+5. Implement daemon-exit wake events in `shellCmdReminderOwner`.
+6. Add `originRootId` and wake idempotence fields to daemon reminder meta.
+7. Add tests: single daemon exit wake, multiple daemon exits aggregated within 500 ms, user message cancellation, blocked dialogs not waking, and idempotence.