dominds 1.19.3 → 1.20.2

package/dist/tools/os.js

@@ -311,9 +311,18 @@ function buildShellCmdReminderMeta(previousMeta, daemon, options) {
     if (previousMeta.originDialogId !== undefined) {
         nextMeta['originDialogId'] = previousMeta.originDialogId;
     }
+    if (previousMeta.originRootId !== undefined) {
+        nextMeta['originRootId'] = previousMeta.originRootId;
+    }
     if (daemon.processGroupId !== undefined) {
         nextMeta['processGroupId'] = daemon.processGroupId;
     }
+    if (previousMeta.exitWakeEventId !== undefined) {
+        nextMeta['exitWakeEventId'] = previousMeta.exitWakeEventId;
+    }
+    if (previousMeta.exitWakeNotifiedAt !== undefined) {
+        nextMeta['exitWakeNotifiedAt'] = previousMeta.exitWakeNotifiedAt;
+    }
     if (options?.completed) {
         nextMeta['completed'] = true;
     }
@@ -400,6 +409,141 @@ function stripDaemonLifecyclePhaseSummary(content) {
     }
     return normalized.slice(separatorIndex + 2);
 }
+function buildShellCmdExitWakeEventId(meta) {
+    return `shellCmd:daemonExited:${String(meta.pid)}:${meta.startTime}`;
+}
+function buildShellCmdExitWakeMeta(meta, eventId, notifiedAt) {
+    return {
+        ...meta,
+        exitWakeEventId: eventId,
+        exitWakeNotifiedAt: notifiedAt,
+    };
+}
+function assertShellCmdExitWakeNotPreviouslyDelivered(meta, eventId) {
+    if (meta.exitWakeEventId !== undefined && meta.exitWakeEventId !== eventId) {
+        throw new Error(`shell_cmd daemon wake invariant violation: conflicting exit wake event id for pid ${String(meta.pid)}`);
+    }
+    if (meta.exitWakeNotifiedAt !== undefined) {
+        throw new Error(`shell_cmd daemon wake invariant violation: exit wake event already delivered for pid ${String(meta.pid)}`);
+    }
+}
+function assertShellCmdExitWakeDeliveryFieldsConsistent(meta, eventId) {
+    if (meta.exitWakeNotifiedAt !== undefined && meta.exitWakeEventId === undefined) {
+        throw new Error(`shell_cmd daemon wake invariant violation: exit wake notified timestamp without event id for pid ${String(meta.pid)}`);
+    }
+    if (meta.exitWakeEventId !== undefined && meta.exitWakeEventId !== eventId) {
+        throw new Error(`shell_cmd daemon wake invariant violation: delivered event id mismatch for pid ${String(meta.pid)}`);
+    }
+}
+function formatShellCmdDaemonExitWakeContent(args) {
+    const prefix = (0, driver_messages_1.formatSystemNoticePrefix)(args.language);
+    const status = args.exitCode !== undefined || args.exitSignal !== undefined
+        ? `code ${String(args.exitCode ?? 'null')}, signal ${String(args.exitSignal ?? 'null')}`
+        : args.language === 'zh'
+            ? '未知（runner 已不可用）'
+            : 'unknown (runner unavailable)';
+    return args.language === 'zh'
+        ? `${prefix}
+后台进程已退出。这是 runtime 环境事件，不是新的用户指令。
+
+- PID: ${String(args.pid)}
+- 命令: ${args.command}
+- 退出状态: ${status}
+
+请根据当前任务上下文判断是否需要查看最终 stdout/stderr 或向用户汇报结果；不要只回复“收到”。`
+        : `${prefix}
+A background process has exited. This is a runtime environment event, not a new user instruction.
+
+- PID: ${String(args.pid)}
+- Command: ${args.command}
+- Exit status: ${status}
+
+Decide from the current task context whether you need to inspect final stdout/stderr or report the result to the user; do not reply with a standalone acknowledgement.`;
+}
+function abortableDelay(ms, signal) {
+    return new Promise((resolve) => {
+        if (signal.aborted) {
+            resolve();
+            return;
+        }
+        let timeout;
+        let settled = false;
+        const finish = () => {
+            if (settled)
+                return;
+            settled = true;
+            clearTimeout(timeout);
+            signal.removeEventListener('abort', onAbort);
+            resolve();
+        };
+        const onAbort = () => {
+            finish();
+        };
+        timeout = setTimeout(finish, ms);
+        signal.addEventListener('abort', onAbort, { once: true });
+    });
+}
+async function waitForShellCmdReminderWakeEvent(reminder, signal) {
+    const eventId = buildShellCmdExitWakeEventId(reminder.meta);
+    assertShellCmdExitWakeDeliveryFieldsConsistent(reminder.meta, eventId);
+    if (reminder.meta.completed === true) {
+        return null;
+    }
+    if (reminder.meta.exitWakeNotifiedAt !== undefined) {
+        return null;
+    }
+    while (!signal.aborted) {
+        const resolved = await resolveDaemonFromMeta(reminder.meta);
+        const notifiedAt = (0, time_1.formatUnifiedTimestamp)(new Date());
+        const language = (0, work_language_1.getWorkLanguage)();
+        if (resolved.kind === 'gone') {
+            const isTrackedDaemon = reminder.meta.runnerEndpoint !== undefined || reminder.meta.runnerPid !== undefined;
+            if (!isTrackedDaemon)
+                return null;
+            assertShellCmdExitWakeNotPreviouslyDelivered(reminder.meta, eventId);
+            const updatedMeta = buildShellCmdExitWakeMeta(buildShellCmdFinalizedMeta(reminder.meta, notifiedAt), eventId, notifiedAt);
+            const updatedContent = formatExitedDaemonReminderContent(reminder.meta.initialCommandLine, reminder.meta.pid, language, stripDaemonLifecyclePhaseSummary(reminder.content));
+            return {
+                eventId,
+                reminderId: reminder.id,
+                content: formatShellCmdDaemonExitWakeContent({
+                    command: reminder.meta.initialCommandLine,
+                    pid: reminder.meta.pid,
+                    language,
+                }),
+                updatedContent,
+                updatedMeta,
+            };
+        }
+        if (resolved.kind === 'error') {
+            throw new Error(resolved.errorText);
+        }
+        const daemon = resolved.daemon;
+        if (!daemon.isRunning) {
+            assertShellCmdExitWakeNotPreviouslyDelivered(reminder.meta, eventId);
+            const updatedContent = formatExitedDaemonReminderContent(daemon.command, reminder.meta.pid, language, formatRunnerBackedDaemonStatusDetails(daemon, language));
+            const completedMeta = buildShellCmdReminderMeta(reminder.meta, daemon, {
+                completed: true,
+                lastUpdated: notifiedAt,
+            });
+            return {
+                eventId,
+                reminderId: reminder.id,
+                content: formatShellCmdDaemonExitWakeContent({
+                    command: daemon.command,
+                    pid: reminder.meta.pid,
+                    exitCode: daemon.exitCode,
+                    exitSignal: daemon.exitSignal,
+                    language,
+                }),
+                updatedContent,
+                updatedMeta: buildShellCmdExitWakeMeta(completedMeta, eventId, notifiedAt),
+            };
+        }
+        await abortableDelay(1000, signal);
+    }
+    return null;
+}
 function getOsToolMessages(language) {
     if (language === 'zh') {
         return {
@@ -1162,6 +1306,59 @@ exports.shellCmdReminderOwner = {
             }),
         };
     },
+    async waitForReminderWakeEvent(_dlg, reminders, signal) {
+        const candidates = reminders.filter(isShellCmdReminder);
+        if (candidates.length === 0)
+            return null;
+        const controller = new AbortController();
+        const onAbort = () => {
+            controller.abort();
+        };
+        signal.addEventListener('abort', onAbort, { once: true });
+        if (signal.aborted) {
+            controller.abort();
+        }
+        const pending = candidates.map((reminder) => waitForShellCmdReminderWakeEvent(reminder, controller.signal));
+        return await new Promise((resolve, reject) => {
+            let settled = false;
+            let remaining = pending.length;
+            const cleanup = () => {
+                signal.removeEventListener('abort', onAbort);
+                controller.abort();
+            };
+            const finish = (event) => {
+                if (settled)
+                    return;
+                settled = true;
+                cleanup();
+                resolve(event);
+            };
+            const settleEmpty = () => {
+                if (settled)
+                    return;
+                remaining -= 1;
+                if (remaining === 0)
+                    finish(null);
+            };
+            for (const promise of pending) {
+                void promise
+                    .then((event) => {
+                    if (event !== null) {
+                        finish(event);
+                        return;
+                    }
+                    settleEmpty();
+                })
+                    .catch((error) => {
+                    if (settled)
+                        return;
+                    settled = true;
+                    cleanup();
+                    reject(error instanceof Error ? error : new Error(String(error)));
+                });
+            }
+        });
+    },
     async renderReminder(dlg, reminder) {
         const language = (0, work_language_1.getWorkLanguage)();
         const prefix = (0, driver_messages_1.formatSystemNoticePrefix)(language);
@@ -1309,6 +1506,7 @@ exports.shellCmdTool = {
                 shell: initialMessage.shell,
                 startTime: initialMessage.startTime,
                 originDialogId: dlg.id.selfId,
+                originRootId: dlg.id.rootId,
             };
             if (initialMessage.processGroupId !== undefined) {
                 reminderSeedMeta.processGroupId = initialMessage.processGroupId;

package/dist/tools/prompts/control/en/errors.md

@@ -93,9 +93,9 @@ A: `dialog` reminders are only for the current dialog's working set. `personal`
 
 A: Use `personal` only for responsibility-related reminders that you should keep seeing in all later dialogs you lead. Everything else should default to `dialog`.
 
-### Q: Does change_mind reset dialog rounds?
+### Q: Do mind_more / change_mind reset dialog rounds?
 
-A: No. `change_mind` only updates taskdoc content, it doesn't reset dialog rounds.
+A: No. `mind_more` / `change_mind` only update Taskdoc content; they do not reset dialog rounds.
 
 ### Q: Are taskdoc updates immediately visible to all teammates?
 

package/dist/tools/prompts/control/en/index.md

@@ -27,7 +27,7 @@
 control is Dominds' **dialog control toolset** for managing dialog state, reminders, taskdocs, and inter-dialog reply closure semantics:
 
 - **Reminder management**: Two reminder scopes. Default to dialog-local working set; use `personal` only for responsibility-linked notes that you should keep seeing in all later dialogs you lead
-- **Taskdoc operations**: Update task contracts (goals/constraints/progress); within Taskdoc, `progress` is the team-shared, quasi-real-time, scannable task bulletin board
+- **Taskdoc operations**: Append to or replace task contract sections (goals/constraints/progress); within Taskdoc, `progress` is the team-shared, quasi-real-time, scannable task bulletin board
 - **Context maintenance**: Reduce cognitive load without losing key resume state
 - **Reply routing**: Separate `tellaskBack`, `replyTellask*`, and plain text by responsibility in Side Dialog / ask-back flows
 

package/dist/tools/prompts/control/en/principles.md

@@ -40,7 +40,7 @@ Default to `dialog`. Use `personal` only when you should keep seeing that note i
 - `personal` reminders stay visible in all later dialogs you lead
 - Can be added, modified, or deleted at any time
 - Should stay compact, scannable, and directly actionable by default
-- Before `clear_mind`, default to a structured continuation-package reminder; if the current course is already under system remediation, rough multi-reminder carry-over is acceptable
+- Before `clear_mind`, the Main Dialog first records undocumented discussion details the next course needs to know into Taskdoc, then creates a structured continuation-package reminder; a Side Dialog directly maintains sufficiently detailed continuation-package reminders. If the current course is already under system remediation, Side Dialog reminder length has no technical limit and rough multi-reminder carry-over is acceptable
 
 **Difference from memory:**
 | Feature | dialog reminder | personal reminder | personal memory |
@@ -73,20 +73,23 @@ Taskdoc is a **task contract** and the task's **team-shared source of current tr
 
 **Update Rules:**
 
-- Each `change_mind` call replaces entire chapter
+- `mind_more` appends small entries; `change_mind` replaces a full section
 - Does not reset dialog rounds
 - Changes visible to all teammates
 - When writing `progress`, assume teammates will skim it to synchronize on the current task truth rather than read your private process log
+- Do not keep blindly calling `mind_more` until `progress` becomes a chronology; when the bulletin board starts accumulating duplicates, stale entries, or noisy history, use `change_mind` to condense it around facts that are still effective now
+- Detailed investigations, long logs, full plans, acceptance records, and expanded rationale belong in formal rtws documentation; Taskdoc should keep only the key point, current conclusion, next step, and a location pointer such as path/section/command
 
 ## Tool Overview
 
-| Tool            | Function                                    |
-| --------------- | ------------------------------------------- |
-| add_reminder    | Add reminder                                |
-| delete_reminder | Delete reminder                             |
-| update_reminder | Update reminder content                     |
-| change_mind     | Update taskdoc (goals/constraints/progress) |
-| recall_taskdoc  | Read taskdoc chapter                        |
+| Tool            | Function                                             |
+| --------------- | ---------------------------------------------------- |
+| add_reminder    | Add reminder                                         |
+| delete_reminder | Delete reminder                                      |
+| update_reminder | Update reminder content                              |
+| mind_more       | Append entries to Taskdoc (defaults to progress)     |
+| change_mind     | Replace Taskdoc section (goals/constraints/progress) |
+| recall_taskdoc  | Read taskdoc chapter                                 |
 
 ## Inter-dialog Reply Routing
 
@@ -127,9 +130,11 @@ Taskdoc is a **task contract** and the task's **team-shared source of current tr
 
 - Keep concise: reminders are often 1-3 items; prefer `update_reminder` to compress/merge
 - Separate carriers: information that must synchronize the team's current effective state, key decisions, next steps, or still-active blockers belongs in `progress`, the quasi-real-time task bulletin board; reminders keep local resume details
-- Team-facing: keep `progress` scannable and centered on what is still effective now; do not let it degrade into a personal log, raw chronology, scratchpad, or stale history pile
-- Collapse before clearing: default to a structured continuation-package reminder; if the current course is already under system remediation, rough multi-reminder carry-over is acceptable but must be reconciled first in the new course
+- Team-facing: keep `progress` scannable and centered on what is still effective now; do not let it degrade into a personal log, raw chronology, scratchpad, or stale history pile. Use `mind_more` for small additions and `change_mind` when cleanup/reordering/compression is needed
+- Condense when needed: `mind_more` is not the default bookkeeping move. If one topic already has several phase notes, prefer `change_mind` to merge them into the current summary; put the detailed expansion in formal rtws documentation and keep a document pointer in Taskdoc
+- Collapse before clearing: the Main Dialog first records undocumented discussion details the next course needs to know into the appropriate Taskdoc sections, then creates a structured continuation-package reminder; a Side Dialog must not maintain Taskdoc or draft Taskdoc update proposals, and should directly maintain sufficiently detailed continuation-package reminders. If the current course is already under system remediation, rough multi-reminder carry-over is acceptable but must be reconciled first in the new course
 - Avoid raw-material dumps: do not paste long logs or large tool outputs into reminders
+- Documentation layering: Taskdoc says “what the team should sync on / do next now”; formal rtws documentation carries “why, how, detailed evidence, and the full process”. When Taskdoc references formal rtws documentation, use a stable path/section name/relevant command instead of copying the full content
 
 ### 4. What Belongs in `progress`
 
@@ -138,16 +143,18 @@ Taskdoc is a **task contract** and the task's **team-shared source of current tr
   - blockers that are confirmed and still active
   - the next step the team should currently align on
   - completed stage closures and remaining gaps
+  - a short summary of content already written to formal rtws documentation, plus a pointer to that document
 - Poor fits for `progress`:
   - “I just read file X”
   - “I might try a small idea next”
   - scratch notes only useful to the current speaker
   - historical traces whose current validity is unclear
+  - detailed expansions, long logs, full plans, or acceptance-record text that belongs in formal rtws documentation
 
 ## Limitations and Notes
 
 1. `dialog` reminders end with the dialog; `personal` reminders stay visible in all later dialogs you lead
-2. Taskdoc updates use full section replacement, ensure to merge existing content
-3. `change_mind` does not reset dialog rounds
-4. A continuation-package reminder should keep only details not already covered by Taskdoc but easy to lose during resume
+2. Use `mind_more` for small Taskdoc additions; use `change_mind` for full-section replacement and merge existing content first. Do not treat `mind_more` as a chronology tool; when cleanup, stale-entry removal, or same-topic consolidation is needed, use `change_mind`
+3. `mind_more` / `change_mind` do not reset dialog rounds
+4. A continuation-package reminder should keep only details still not covered by Taskdoc but easy to lose during resume; in the Main Dialog, undocumented discussion details from current dialog history that the next course needs to know should be written to the appropriate Taskdoc sections first; in a Side Dialog under caution/critical remediation, maintain sufficiently detailed continuation-package reminders only
 5. Do not turn `personal` reminders into a long-term fact dump; move durable knowledge into `personal_memory`

package/dist/tools/prompts/control/en/scenarios.md

@@ -117,15 +117,23 @@ replyTellaskBack({
 
 ### Scenario Description
 
-Announce the current effective state, key decisions, next step, and still-active blockers to the whole team rather than writing a private chronology.
+Announce the current effective state, key decisions, next step, and still-active blockers to the whole team rather than writing a private chronology. If details have been organized into formal rtws documentation, `progress` should keep only the summary and document pointer.
 
 ### Example
 
 ```typescript
+// Small additions that are still effective now
+mind_more({
+  items: [
+    '- Next: verify control / team_mgmt manuals and tests are aligned (details: <doc-path>#<section>)',
+  ],
+});
+
+// Full-section replacement when cleanup, reordering, same-topic consolidation, or chronology compression is needed
 change_mind({
   selector: 'progress',
   content:
-    '## Progress\n\n### Current Effective State\n- The memory-carrier boundary cleanup is complete; next we strengthen the Taskdoc bulletin-board semantics\n\n### Decisions In Effect\n- `personal_memory` is no longer treated as a short-term junk drawer\n- `team_memory` now carries only long-lived team conventions and invariants\n\n### Next Step\n- Add stronger `progress` bulletin-board guidance in control / team_mgmt manuals\n\n### Still-Active Blockers\n- None',
+    '## Progress\n\n### Current Effective State\n- The memory-carrier boundary cleanup is complete; next we strengthen the Taskdoc bulletin-board semantics; details: <doc-path>#<section>\n\n### Decisions In Effect\n- `personal_memory` is no longer treated as a short-term junk drawer\n- `team_memory` now carries only long-lived team conventions and invariants\n\n### Next Step\n- Add stronger `progress` bulletin-board guidance in control / team_mgmt manuals\n\n### Still-Active Blockers\n- None',
 });
 ```
 
@@ -187,7 +195,7 @@ recall_taskdoc({
 
 ### Scenario Description
 
-Maintain taskdoc integrity and consistency, and keep `progress` as a team-scannable current-truth snapshot.
+Maintain taskdoc integrity and consistency, and keep `progress` as a team-scannable current-truth snapshot; put detailed expansion in formal rtws documentation and keep only the summary plus location pointer in Taskdoc.
 
 ### Example
 
@@ -196,6 +204,6 @@ Maintain taskdoc integrity and consistency, and keep `progress` as a team-scanna
 change_mind({
   selector: 'progress',
   content:
-    '## Progress\n\n### Current Effective State\n- The boundary wording has been propagated into handbook sources and tests\n\n### Decisions In Effect\n- role assets / personal_memory / team_memory / Taskdoc-progress / reminders now have separated responsibilities\n\n### Next Step\n- Re-verify control manual wording, Taskdoc display text, and boundary tests\n\n### Still-Active Blockers\n- None',
+    '## Progress\n\n### Current Effective State\n- The boundary wording has been propagated into handbook sources and tests; details: <doc-path>#<section>\n\n### Decisions In Effect\n- role assets / personal_memory / team_memory / Taskdoc-progress / reminders now have separated responsibilities\n\n### Next Step\n- Re-verify control manual wording, Taskdoc display text, and boundary tests\n\n### Still-Active Blockers\n- None',
 });
 ```

package/dist/tools/prompts/control/en/tools.md

@@ -45,7 +45,7 @@ Add reminder.
 Use when:
 
 - Adding a new temporary working-set item
-- Creating continuation-package notes before `clear_mind`; rough bridge notes are acceptable when context is already degraded
+- Before `clear_mind`, the Main Dialog first records undocumented discussion details the next course needs to know into Taskdoc, then creates continuation-package notes; a Side Dialog directly maintains sufficiently detailed continuation-package reminders. When the current course is already under caution/critical remediation, Side Dialog reminder length has no technical limit and rough bridge notes are acceptable
 
 **Parameters:**
 
@@ -160,7 +160,37 @@ updated_at: <update timestamp>
 - Changes visible to all teammates
 - Constraint rule: `constraints` must include only task-specific hard requirements; do not repeat global rules. If a duplicate is found, delete it and inform the user
 
-### 6. recall_taskdoc
+### 6. mind_more
+
+Append entries to a Taskdoc section; defaults to `progress`, reducing full-section replacement pressure.
+
+**Parameters:**
+
+- `items` (required): Entries to append; each item must be a non-empty string
+- `sep` (optional): Separator between existing content and new content, and between entries. Defaults to `\n`
+- `selector` (optional): Chapter selector. Defaults to `progress`; use `goals` / `constraints` / `progress`
+- `category` (optional): Extra section directory; with `selector`, targets `<category>/<selector>.md`
+
+**Example:**
+
+```typescript
+mind_more({
+  items: [
+    '- Next: review verification results (details: <doc-path>#<section>)',
+    '- Blocker: API acceptance criteria pending',
+  ],
+});
+```
+
+**Characteristics:**
+
+- Append-only: it does not deduplicate, rewrite, or compress old content
+- Good for adding one or two still-effective states, decisions, next steps, or blockers to `progress`
+- Not for appending every investigation step, long log, full plan, or acceptance record as a chronology; those details belong in formal rtws documentation, while Taskdoc keeps the summary and document pointer
+- If stale entries must be removed, reordered, or compressed, use `change_mind` for a full-section replacement
+- When one topic already has several phase notes, prefer `change_mind` to merge them into a concise current announcement instead of continuing to call `mind_more`
+
+### 7. recall_taskdoc
 
 Read taskdoc chapter.
 
@@ -230,11 +260,21 @@ update_reminder({
 
 ### Update Taskdoc Progress
 
+```typescript
+mind_more({
+  items: [
+    '- Next: strengthen the bulletin-board semantics of Taskdoc `progress` (details: <doc-path>#<section>)',
+  ],
+});
+```
+
+### Replace Taskdoc Progress
+
 ```typescript
 change_mind({
   selector: 'progress',
   content:
-    '## Progress\n\n### Current Effective State\n- The handbook boundary split is now agreed: role assets / personal long-lived experience / Taskdoc-progress / reminders\n\n### Decisions In Effect\n- `persona / knowhow / pitfalls` no longer absorb daily member experience\n- `personal_memory` is reserved for one member\\'s reusable long-lived experience\n\n### Next Step\n- Strengthen the bulletin-board semantics of Taskdoc `progress`\n\n### Still-Active Blockers\n- None',
+    '## Progress\n\n### Current Effective State\n- The handbook boundary split is now agreed: role assets / personal long-lived experience / Taskdoc-progress / reminders; details: <doc-path>#<section>\n\n### Decisions In Effect\n- `persona / knowhow / pitfalls` no longer absorb daily member experience\n- `personal_memory` is reserved for one member\\'s reusable long-lived experience\n\n### Next Step\n- Strengthen the bulletin-board semantics of Taskdoc `progress`\n\n### Still-Active Blockers\n- None',
 });
 ```
 
@@ -274,6 +314,6 @@ message: <error message>
 
 - Normal reminders should stay concise, fresh, and directly actionable; often 1-3 items total
 - For a continuation package, use structured notes by default: next step, key pointers, run/verify, easy-to-lose volatile details
-- If the current course is already under caution/critical remediation, rough multi-reminder bridge notes are acceptable; in the current course only preserve info + `clear_mind`, and reconcile them as the first step only after the system actually starts the new course
-- Keep only details not already covered by Taskdoc; do not repeat team-shared status. If the team needs “where we are now / which decisions are in effect / what is next / which blockers still hold”, write it back to Taskdoc `progress`
+- If the current course is already under caution/critical remediation: the Main Dialog first records undocumented discussion details the next course needs to know into the appropriate Taskdoc sections, then keeps necessary continuation-package reminders; a Side Dialog must not maintain Taskdoc or draft Taskdoc update proposals, and should directly maintain sufficiently detailed continuation-package reminders with no technical length limit. Rough multi-reminder bridge notes are acceptable and should be reconciled as the first step only after the system actually starts the new course
+- Keep only details still not covered by Taskdoc; do not repeat team-shared status. If the team needs “where we are now / which decisions are in effect / what is next / which blockers still hold”, write it back to Taskdoc `progress`
 - Do not paste long logs, large tool outputs, or raw material into reminders

package/dist/tools/prompts/control/zh/errors.md

@@ -93,9 +93,9 @@ A: `dialog` 提醒只用于当前对话的工作集。`personal` 提醒会在所
 
 A: 只有当这条提醒与你的持续职责相关，且在所有由你主理的后续对话里也应该继续被看到时，才用 `personal`。其它情况默认都用 `dialog`。
 
-### Q: change_mind 会重置对话轮次吗？
+### Q: mind_more / change_mind 会重置对话轮次吗？
 
-A: 不会。`change_mind` 仅更新差遣牒内容，不重置对话轮次。
+A: 不会。`mind_more` / `change_mind` 仅更新差遣牒内容，不重置对话轮次。
 
 ### Q: 差遣牒更新后立即对所有队友可见吗？
 

package/dist/tools/prompts/control/zh/index.md

@@ -27,7 +27,7 @@
 control 是 Dominds 的**对话控制工具集**，用于管理对话状态、提醒、差遣牒，以及跨对话回复收口语义：
 
 - **提醒管理**：提醒分 `dialog` / `personal` 两个 scope；默认保持对话内工作集，只有职责相关且在所有由你主理的后续对话里也应继续看到的提醒才用 `personal`
-- **差遣牒操作**：更新任务契约（goals/constraints/progress）；其中 `progress` 是全队共享、准实时、可扫读的任务公告牌
+- **差遣牒操作**：追加或替换任务契约章节（goals/constraints/progress）；其中 `progress` 是全队共享、准实时、可扫读的任务公告牌
 - **上下文维护**：在不丢关键恢复线索的前提下降低认知负载
 - **回复路由**：在支线/回问语境下，区分 `tellaskBack`、`replyTellask*` 与普通文本的职责边界
 

package/dist/tools/prompts/control/zh/principles.md

@@ -40,7 +40,7 @@
 - `personal` 提醒会在所有由你主理的后续对话里继续可见
 - 可随时添加、修改、删除
 - 默认应保持少量、可扫读、可直接指导下一步
-- 准备 `clear_mind` 时，默认优先压缩成结构化接续包提醒项；若当前程已被系统置于吃紧/告急处置态，也可先保留多条粗略提醒项过桥
+- 准备 `clear_mind` 时，主线对话先把应由下一程知会的未落文档讨论细节补进差遣牒，再压缩成结构化接续包提醒项；支线对话直接维护足够详尽的接续包提醒项。若当前程已被系统置于吃紧/告急处置态，支线提醒项长度没有技术限制，也可先保留多条粗略提醒项过桥
 
 **与 memory 的区别：**
 | 特性 | dialog reminder | personal reminder | personal memory |
@@ -73,20 +73,23 @@
 
 **更新规则：**
 
-- 每次调用 `change_mind` 会替换整个章节
+- `mind_more` 用于少量追加条目；`change_mind` 用于整章替换
 - 不重置对话轮次
 - 变更对所有队友可见
 - 写入 `progress` 时，应默认假设全队成员会用它快速同步“当前任务真相”，而不是阅读你的个人过程记录
+- 不要无脑连续使用 `mind_more` 把 `progress` 写成流水账；当公告牌开始堆积、重复或含过期信息时，用 `change_mind` 按当前仍有效的事实压缩整理
+- 细节展开、调查过程、长日志、方案全文和验收记录应落进 rtws 正式文档；差遣牒只保留要点、当前结论、下一步，以及指向正式文档的路径/章节/命令等定位 pointer
 
 ## 工具概览
 
-| 工具            | 功能                                     |
-| --------------- | ---------------------------------------- |
-| add_reminder    | 添加提醒                                 |
-| delete_reminder | 删除提醒                                 |
-| update_reminder | 更新提醒内容                             |
-| change_mind     | 更新差遣牒（goals/constraints/progress） |
-| recall_taskdoc  | 读取差遣牒章节                           |
+| 工具            | 功能                                         |
+| --------------- | -------------------------------------------- |
+| add_reminder    | 添加提醒                                     |
+| delete_reminder | 删除提醒                                     |
+| update_reminder | 更新提醒内容                                 |
+| mind_more       | 向差遣牒追加条目（默认 progress）            |
+| change_mind     | 整章替换差遣牒（goals/constraints/progress） |
+| recall_taskdoc  | 读取差遣牒章节                               |
 
 ## 跨对话回复路由
 
@@ -127,9 +130,11 @@
 
 - 保持简洁：默认提醒项常见 1–3 条，优先 `update_reminder` 压缩/合并
 - 区分载体：需要向全队同步的当前有效状态、关键决策、下一步与仍成立阻塞，写入 `progress` 这一准实时任务公告牌；提醒项只留个人/当前对话恢复所需细节
-- 面向全队：`progress` 应保持可扫读、以“当前仍有效”为准，不要退化成个人日志、流水账、临时便签或历史残影堆积
-- 换程前收束：默认优先整理成结构化接续包提醒项；若系统已把当前程切到吃紧/告急处置态，则先保留多条粗略提醒项过桥也可以；当前程只做保信息 + `clear_mind`，系统真正开启新一程后第一步再收敛
+- 面向全队：`progress` 应保持可扫读、以“当前仍有效”为准，不要退化成个人日志、流水账、临时便签或历史残影堆积；少量新增用 `mind_more`，需要清旧/重排/压缩时用 `change_mind`
+- 按需整理：`mind_more` 不是默认记账动作。若同一主题已有多条阶段性记录，优先用 `change_mind` 合并成当前摘要；把细节放进 rtws 正式文档，并在差遣牒里保留文档定位 pointer
+- 换程前收束：主线对话先把尚未落实到文档、且下一程需要知会的讨论细节写入差遣牒合适章节，再整理结构化接续包提醒项；支线对话不要维护差遣牒，也不要整理差遣牒更新提案，直接维护足够详尽的接续包提醒项。若系统已把当前程切到吃紧/告急处置态，则先保留多条粗略提醒项过桥也可以；当前程只做落文档/保信息 + `clear_mind`（支线只做保信息 + `clear_mind`），系统真正开启新一程后第一步再收敛
 - 拒绝原料堆积：不要把长日志/大段 tool output 直接塞进提醒项
+- 文档分层：差遣牒写“现在应如何同步/推进”，正式文档写“为什么、怎么做、详细证据和完整过程”。差遣牒需要引用正式文档时，写稳定路径/章节名/相关命令，而不是复制整段内容
 
 ### 4. `progress` 内容取舍
 
@@ -138,16 +143,18 @@
   - 当前已确认、仍成立的 blocker
   - 当前全队应共识的下一步
   - 当前阶段性闭环与尚未闭环的 gap
+  - 已落正式文档的关键内容摘要，以及定位该文档的 pointer
 - 不适合写进 `progress`：
   - “我刚刚看了什么文件”
   - “我准备先试一个小想法”
   - 只对当前说话者自己有用的临时便签
   - 无法判断是否仍然有效的历史痕迹
+  - 可在 rtws 正式文档中承载的细节展开、长日志、完整方案或验收记录全文
 
 ## 限制与注意事项
 
 1. `dialog` 提醒会随对话结束而结束；`personal` 提醒会在所有由你主理的后续对话里继续可见
-2. 差遣牒更新使用整段替换，请确保合并已有内容
-3. `change_mind` 不重置对话轮次
-4. 接续包提醒项只保留差遣牒未覆盖、但恢复工作容易丢的细节
+2. 差遣牒少量新增可用 `mind_more` 追加；整段替换用 `change_mind`，请确保合并已有内容。不要把 `mind_more` 当流水账工具；需要整理、去旧、合并同主题记录时直接 `change_mind`
+3. `mind_more` / `change_mind` 不重置对话轮次
+4. 接续包提醒项只保留差遣牒仍未覆盖、但恢复工作容易丢的细节；主线对话应先把当前对话历史中应由下一程知会的未落文档讨论细节写入差遣牒合适章节；支线对话在吃紧/告急时只维护足够详尽的接续包提醒项
 5. 不要把 `personal` 提醒堆成长期事实仓库；耐久知识应迁到 `personal_memory`

package/dist/tools/prompts/control/zh/scenarios.md

@@ -116,15 +116,21 @@ replyTellaskBack({
 
 ### 场景描述
 
-把当前有效状态、关键决策、下一步与仍成立阻塞公告给全队，而不是写个人流水账。
+把当前有效状态、关键决策、下一步与仍成立阻塞公告给全队，而不是写个人流水账。若细节已整理到 rtws 正式文档，`progress` 只写摘要和文档定位 pointer。
 
 ### 示例
 
 ```typescript
+// 少量新增当前仍有效的公告条目
+mind_more({
+  items: ['- 下一步：复核 control / team_mgmt 手册与测试是否对齐（详见 <文档路径>#<章节>）'],
+});
+
+// 需要清理旧项、重排、同主题合并或压缩流水账时，整章替换
 change_mind({
   selector: 'progress',
   content:
-    '## Progress\n\n### 当前有效状态\n- 已完成三类记忆载体边界收口，准备补 Taskdoc 公告牌属性\n\n### 已生效决策\n- `personal_memory` 不再作为短期杂物柜\n- `team_memory` 只承接团队长期共识与不变量\n\n### 下一步\n- 在 control / team_mgmt 手册中补强 `progress` 的公告牌语义\n\n### 仍成立阻塞\n- 无',
+    '## Progress\n\n### 当前有效状态\n- 已完成三类记忆载体边界收口，准备补 Taskdoc 公告牌属性；细节见 <文档路径>#<章节>\n\n### 已生效决策\n- `personal_memory` 不再作为短期杂物柜\n- `team_memory` 只承接团队长期共识与不变量\n\n### 下一步\n- 在 control / team_mgmt 手册中补强 `progress` 的公告牌语义\n\n### 仍成立阻塞\n- 无',
 });
 ```
 
@@ -186,7 +192,7 @@ recall_taskdoc({
 
 ### 场景描述
 
-维护差遣牒的完整性和一致性，并确保 `progress` 始终是可供全队扫读的当前真相快照。
+维护差遣牒的完整性和一致性，并确保 `progress` 始终是可供全队扫读的当前真相快照；细节展开放入 rtws 正式文档，差遣牒只保留摘要和定位 pointer。
 
 ### 示例
 
@@ -195,6 +201,6 @@ recall_taskdoc({
 change_mind({
   selector: 'progress',
   content:
-    '## Progress\n\n### 当前有效状态\n- 边界口径已统一到手册源头与测试\n\n### 已生效决策\n- 角色级资产 / personal_memory / team_memory / Taskdoc-progress / reminders 的职责已经切开\n\n### 下一步\n- 复验 control 手册、Taskdoc 展示文案与边界测试\n\n### 仍成立阻塞\n- 无',
+    '## Progress\n\n### 当前有效状态\n- 边界口径已统一到手册源头与测试；细节见 <文档路径>#<章节>\n\n### 已生效决策\n- 角色级资产 / personal_memory / team_memory / Taskdoc-progress / reminders 的职责已经切开\n\n### 下一步\n- 复验 control 手册、Taskdoc 展示文案与边界测试\n\n### 仍成立阻塞\n- 无',
 });
 ```