dominds 1.17.6 → 1.17.7

package/dist/minds/system-prompt-parts.js

@@ -162,7 +162,7 @@ function getMemoryPromptCopy(ctx) {
             temporaryInfoLine: '你的聊天记录与工具输出是临时信息：会快速累积、很快过时，并增加你的认知负担。在同一轮对话中，除了 `clear_mind` 以外你无法真正丢弃这些历史。',
             clearMindLine: '`clear_mind` 会开启新一程对话（保留差遣牒、提醒项与记忆层），从而卸掉这部分认知负载并继续推进。因此你必须先把关键信息提炼到高价值载体：',
             taskdocContractLine: '- 差遣牒（`*.tsk/`）：全队共享的任务契约（goals/constraints/progress）；不是个人笔记，保持足够短，每轮都应可通读。',
-            taskdocSemanticsLine: '- 章节语义约定：`progress` 是全队共享的里程碑公告牌，用来记录关键决策、当前状态与下一步；不是流水账，也不是个人工作记录。`goals` / `constraints` 是较稳定的任务契约；每次更新都必须保留仍然有效的他人条目。',
+            taskdocSemanticsLine: '- 章节语义约定：`progress` 是全队共享、准实时、可扫读的任务公告牌，用来记录当前有效状态、关键决策、下一步与仍成立阻塞；不是流水账，也不是个人工作记录。`goals` / `constraints` 是较稳定的任务契约；每次更新都必须保留仍然有效的他人条目。',
             taskdocSectionReplaceLine: `- 更新差遣牒的任意分段时：每次调用会替换该分段全文；你必须先对照“上下文中注入的当前内容”做合并/压缩；禁止覆盖/抹掉他人条目；自己负责维护的条目必须标注责任人（例如 \`- [owner:@${ctx.agentId}] ...\` 或用 \`### @${ctx.agentId}\` 分块）。`,
             progressLine: '- 更新 `progress` 时：它必须始终是可供全队扫读的完整当前快照，而不是只追加自己这一轮的零散笔记。',
             injectedTaskdocLine: '- 重要：差遣牒内容会被系统以内联形式注入到上下文中（本轮生成视角下即为最新；注入内容不包括全局约束）。需要回顾时请直接基于上下文里的差遣牒内容回顾与决策，不要试图用通用文件工具读取 `*.tsk/` 下的文件（会被拒绝）。',
@@ -186,7 +186,7 @@ function getMemoryPromptCopy(ctx) {
         temporaryInfoLine: 'Dialog history and tool outputs are temporary: they accumulate quickly, become stale, and increase cognitive load. Within a course, you cannot truly drop that history except via `clear_mind`.',
         clearMindLine: '`clear_mind` starts a new course while preserving Taskdoc, reminders, and memory layers. Therefore, before clearing, distill key information into durable layers:',
         taskdocContractLine: '- Taskdoc (`*.tsk/`): the team-shared task contract (goals/constraints/progress). It is not a personal notebook; keep it small enough to read every course.',
-        taskdocSemanticsLine: '- Section semantics: `progress` is the team’s shared milestone bulletin board for key decisions, current status, and next steps; it is not a raw log or personal work record. `goals` / `constraints` are the more stable task contract; every update must preserve still-valid entries from others.',
+        taskdocSemanticsLine: '- Section semantics: `progress` is the team-shared, quasi-real-time, scannable task bulletin board for current effective state, key decisions, next steps, and still-active blockers; it is not a raw log or personal work record. `goals` / `constraints` are the more stable task contract; every update must preserve still-valid entries from others.',
         taskdocSectionReplaceLine: `- When updating any Taskdoc section: each call replaces the entire section; always start from the current injected content and merge/compress; do not overwrite other contributors; add an explicit owner tag for entries you maintain (e.g., \`- [owner:@${ctx.agentId}] ...\` or a \`### @${ctx.agentId}\` block).`,
         progressLine: '- When updating `progress`, keep it as a complete, team-scannable current snapshot instead of appending only your own latest notes.',
         injectedTaskdocLine: '- Important: the Taskdoc content is injected inline into the context (the latest as of this generation; injected content excludes global constraints). Review the injected Taskdoc instead of trying to read files under `*.tsk/` via general file tools (they will be rejected).',

package/dist/server/websocket-handler.d.ts

@@ -3,6 +3,11 @@ import { type LanguageCode } from '@longrun-ai/kernel/types/language';
 import type { Server } from 'http';
 import { WebSocket, WebSocketServer } from 'ws';
 import type { AuthConfig } from './auth';
+export declare function shouldQueueUserSupplementAtGenerationBoundary(args: {
+    latestGenerating: boolean;
+    inMemoryGenerating: boolean;
+    isLocked: boolean;
+}): boolean;
 /**
  * Handle incoming WebSocket messages
  */

package/dist/server/websocket-handler.js

@@ -1,5 +1,6 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.shouldQueueUserSupplementAtGenerationBoundary = shouldQueueUserSupplementAtGenerationBoundary;
 exports.handleWebSocketMessage = handleWebSocketMessage;
 exports.setupWebSocketServer = setupWebSocketServer;
 exports.cleanupEventSystems = cleanupEventSystems;
@@ -209,12 +210,22 @@ function syncDialogLanguagePreference(dialog, language, options) {
     }
     dialog.resetCourseLanguageNotice();
 }
-async function queueUserSupplementAtGenerationBoundary(dialog, prompt) {
-    const latest = await persistence_1.DialogPersistence.loadDialogLatest(dialog.id, 'running');
-    if (latest?.generating !== true) {
+function shouldQueueUserSupplementAtGenerationBoundary(args) {
+    if (!args.isLocked) {
         return false;
     }
-    if (!dialog.isLocked()) {
+    return args.latestGenerating || args.inMemoryGenerating;
+}
+async function queueUserSupplementAtGenerationBoundary(dialog, prompt) {
+    const latest = await persistence_1.DialogPersistence.loadDialogLatest(dialog.id, 'running');
+    const inMemoryGenerating = dialog.hasActiveGeneration;
+    // Live UX can observe generating_start before latest.yaml flips generating=true, so boundary
+    // queuing must honor either persisted or in-memory generation state.
+    if (!shouldQueueUserSupplementAtGenerationBoundary({
+        latestGenerating: latest?.generating === true,
+        inMemoryGenerating,
+        isLocked: dialog.isLocked(),
+    })) {
         return false;
     }
     const queued = dialog.queueUserPromptAtGenerationBoundary({
@@ -237,6 +248,8 @@ async function queueUserSupplementAtGenerationBoundary(dialog, prompt) {
         selfId: dialog.id.selfId,
         msgId: queued.msgId,
         incomingMsgId: prompt.msgId,
+        latestGenerating: latest?.generating === true,
+        inMemoryGenerating,
     });
     return true;
 }

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

@@ -87,7 +87,7 @@
 
 ### Q: What's the difference between dialog reminders, personal reminders, and memory?
 
-A: `dialog` reminders are only for the current dialog. `personal` reminders stay visible in all later dialogs you lead, but still belong to the active working set rather than long-term knowledge. `personal_memory` is for durable facts and reusable knowledge saved to disk.
+A: `dialog` reminders are only for the current dialog's working set. `personal` reminders stay visible in all later dialogs you lead, but still belong to the working set rather than long-term knowledge. `personal_memory` is for durable facts and reusable knowledge saved to disk; if the information should synchronize the team's current effective state, key decisions, next step, or still-active blockers, write it to Taskdoc `progress` instead of a reminder.
 
 ### Q: How do I choose `personal` vs `dialog`?
 

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)
+- **Taskdoc operations**: Update task contracts (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 sideline / ask-back flows
 
@@ -69,4 +69,4 @@ Taskdoc is a **task contract** containing:
 
 - **goals**: Task objectives
 - **constraints**: Constraints
-- **progress**: Progress status
+- **progress**: A quasi-real-time team task bulletin board / current effective-state snapshot for team-wide sync

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

@@ -63,19 +63,20 @@ Default to `dialog`. Use `personal` only when you should keep seeing that note i
 
 ### 2. Taskdoc
 
-Taskdoc is a **task contract** defining goals, constraints, and progress.
+Taskdoc is a **task contract** and the task's **team-shared source of current truth** during execution; within it, `progress` acts as a **quasi-real-time team task bulletin board / current effective-state snapshot**.
 
 **Structure:**
 
 - **goals.md**: Task objectives
 - **constraints.md**: Constraints
-- **progress.md**: Progress status
+- **progress.md**: The current effective state, key decisions, next steps, and still-active blockers for team-wide sync
 
 **Update Rules:**
 
 - Each `change_mind` call replaces entire chapter
 - 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
 
 ## Tool Overview
 
@@ -118,15 +119,29 @@ Taskdoc is a **task contract** defining goals, constraints, and progress.
 
 - **Goal changes**: When task objectives change
 - **Constraint adjustments**: When constraints need adjustment
-- **Progress updates**: When task status has significant progress
+- **Progress updates**: When the team needs the current effective state, key decisions, next steps, or still-active blockers synchronized
 
 ### 3. Update Strategy
 
 - Keep concise: reminders are often 1-3 items; prefer `update_reminder` to compress/merge
-- Separate carriers: shared decisions/status belong in Taskdoc; reminders keep local resume details
+- 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
 - Avoid raw-material dumps: do not paste long logs or large tool outputs into reminders
 
+### 4. What Belongs in `progress`
+
+- Good fits for `progress`:
+  - key decisions already in effect
+  - blockers that are confirmed and still active
+  - the next step the team should currently align on
+  - completed stage closures and remaining gaps
+- 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
+
 ## Limitations and Notes
 
 1. `dialog` reminders end with the dialog; `personal` reminders stay visible in all later dialogs you lead

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

@@ -11,18 +11,18 @@
 - Failure Branch
 - Completion Criteria
 
-## Scenario 1: Task Progress Tracking
+## Scenario 1: Reminder Working Set Tracking
 
 ### Scenario Description
 
-Use reminders to track current task progress.
+Use reminders for the current dialog's working set: next steps, blockers, and volatile details that are not meant to become the team's Taskdoc bulletin board.
 
 ### Example
 
 ```typescript
-// Add task reminder
+// Add a dialog-scoped working-set reminder
 add_reminder({
-  content: 'Current task: Creating i18n manual [In Progress]',
+  content: 'Next step: verify the control manual wording against Taskdoc progress semantics',
 });
 
 // Add a personal reminder only because this is a responsibility-linked cue
@@ -32,13 +32,13 @@ add_reminder({
   scope: 'personal',
 });
 
-// Update after task completion
+// Update after the local working-set detail changes
 update_reminder({
   reminder_id: 'abc123de',
-  content: 'Completed: Creating i18n manual [Done]',
+  content: 'Blocker cleared: control manual wording now aligned with Taskdoc progress semantics',
 });
 
-// Delete completed reminder
+// Delete the reminder once it is no longer needed
 delete_reminder({
   reminder_id: 'abc123de',
 });
@@ -46,8 +46,9 @@ delete_reminder({
 
 ### Key Points
 
-- Default to `dialog` for current-task progress and temporary blockers
+- Default to `dialog` for local next steps, temporary blockers, and volatile bridge details
 - Use `personal` only when you should still see the note in all later dialogs you lead
+- If the information should synchronize the whole team's current effective state, put it in Taskdoc `progress` instead
 - If the note is durable knowledge rather than an active working-set cue, move it to `personal_memory` instead
 
 ## Scenario 2: Sideline is complete, and the assignment header requires replyTellask
@@ -115,7 +116,7 @@ replyTellaskBack({
 
 ### Scenario Description
 
-Update task progress to taskdoc.
+Announce the current effective state, key decisions, next step, and still-active blockers to the whole team rather than writing a private chronology.
 
 ### Example
 
@@ -123,7 +124,7 @@ Update task progress to taskdoc.
 change_mind({
   selector: 'progress',
   content:
-    '## Progress\n\n### Completed\n- [x] Create ws_mod manual\n- [x] Create team_mgmt manual\n- [x] Create personal_memory manual\n\n### In Progress\n- [ ] Create control manual [50%]\n\n### Pending Improvements\n- [ ] Write tool descriptions',
+    '## 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',
 });
 ```
 
@@ -185,15 +186,15 @@ recall_taskdoc({
 
 ### Scenario Description
 
-Maintain taskdoc integrity and consistency.
+Maintain taskdoc integrity and consistency, and keep `progress` as a team-scannable current-truth snapshot.
 
 ### Example
 
 ```typescript
-// Update progress (keep goals and progress consistent)
+// Update progress (keep goals / constraints / progress consistent)
 change_mind({
   selector: 'progress',
   content:
-    '## Progress\n\n### Completed\n- [x] Create ws_mod manual [100%]\n- [x] Create team_mgmt manual [100%]\n- [x] Create personal_memory manual [100%]\n\n### In Progress\n- [ ] Create control manual [60%]\n\n### Next Steps\n- Complete control manual\n- Create os manual',
+    '## 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',
 });
 ```

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

@@ -234,7 +234,7 @@ update_reminder({
 change_mind({
   selector: 'progress',
   content:
-    '## Progress\n\n### Completed\n- [x] Create ws_mod manual\n- [x] Create team_mgmt manual\n\n### In Progress\n- [ ] Create personal_memory manual [80%]\n\n### Not Started\n- [ ] Create control manual',
+    '## 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',
 });
 ```
 
@@ -275,5 +275,5 @@ 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
+- 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`
 - Do not paste long logs, large tool outputs, or raw material into reminders

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

@@ -87,7 +87,7 @@
 
 ### Q: `dialog` 提醒、`personal` 提醒和 memory 有什么区别？
 
-A: `dialog` 提醒只用于当前对话。`personal` 提醒会在所有由你主理的后续对话里继续可见，但仍属于当前工作集提示，不是长期知识库。`personal_memory` 用于保存持久稳定事实和可复用知识。
+A: `dialog` 提醒只用于当前对话的工作集。`personal` 提醒会在所有由你主理的后续对话里继续可见，但仍属于工作集提示，不是长期知识库。`personal_memory` 用于保存持久稳定事实和可复用知识；如果信息需要向全队同步当前有效状态、关键决策、下一步或仍成立阻塞，应写入 Taskdoc `progress`，而不是提醒项。
 
 ### Q: `personal` 和 `dialog` 怎么选？
 

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

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

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

@@ -63,19 +63,20 @@
 
 ### 2. 差遣牒
 
-差遣牒是**任务契约**，定义任务的 goals、constraints 和 progress。
+差遣牒是**任务契约**，也是任务执行期的**全队共享真相载体**；其中 `progress` 承担的是**准实时全队任务公告牌 / 当前有效状态快照**职责。
 
 **结构：**
 
 - **goals.md**：任务目标
 - **constraints.md**：约束条件
-- **progress.md**：进度状态
+- **progress.md**：面向全队同步的当前有效状态、关键决策、下一步与仍成立阻塞
 
 **更新规则：**
 
 - 每次调用 `change_mind` 会替换整个章节
 - 不重置对话轮次
 - 变更对所有队友可见
+- 写入 `progress` 时，应默认假设全队成员会用它快速同步“当前任务真相”，而不是阅读你的个人过程记录
 
 ## 工具概览
 
@@ -118,15 +119,29 @@
 
 - **目标变更**：当任务目标发生变化时
 - **约束调整**：当约束条件需要调整时
-- **进度更新**：当任务状态有重要进展时
+- **进度更新**：当需要向全队同步当前有效状态、关键决策、下一步或仍成立阻塞时
 
 ### 3. 更新策略
 
 - 保持简洁：默认提醒项常见 1–3 条，优先 `update_reminder` 压缩/合并
-- 区分载体：团队共享决策/状态写入差遣牒，提醒项只留本地恢复所需细节
+- 区分载体：需要向全队同步的当前有效状态、关键决策、下一步与仍成立阻塞，写入 `progress` 这一准实时任务公告牌；提醒项只留个人/当前对话恢复所需细节
+- 面向全队：`progress` 应保持可扫读、以“当前仍有效”为准，不要退化成个人日志、流水账、临时便签或历史残影堆积
 - 换程前收束：默认优先整理成结构化接续包提醒项；若系统已把当前程切到吃紧/告急处置态，则先保留多条粗略提醒项过桥也可以；当前程只做保信息 + `clear_mind`，系统真正开启新一程后第一步再收敛
 - 拒绝原料堆积：不要把长日志/大段 tool output 直接塞进提醒项
 
+### 4. `progress` 内容取舍
+
+- 适合写进 `progress`：
+  - 当前已经生效的关键决策
+  - 当前已确认、仍成立的 blocker
+  - 当前全队应共识的下一步
+  - 当前阶段性闭环与尚未闭环的 gap
+- 不适合写进 `progress`：
+  - “我刚刚看了什么文件”
+  - “我准备先试一个小想法”
+  - 只对当前说话者自己有用的临时便签
+  - 无法判断是否仍然有效的历史痕迹
+
 ## 限制与注意事项
 
 1. `dialog` 提醒会随对话结束而结束；`personal` 提醒会在所有由你主理的后续对话里继续可见

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

@@ -11,18 +11,18 @@
 - 失败分支处理
 - 完成判据
 
-## 场景 1：任务进度跟踪
+## 场景 1：提醒项工作集跟踪
 
 ### 场景描述
 
-使用提醒跟踪当前任务进度。
+使用 reminders 承接当前对话的工作集：下一步、临时阻塞、易丢的 bridge 细节，而不是把它写成面向全队同步的 Taskdoc 公告牌。
 
 ### 示例
 
 ```typescript
-// 添加任务提醒
+// 添加一条 dialog 级工作集提醒
 add_reminder({
-  content: '当前任务: 创建 i18n 手册 [进行中]',
+  content: '下一步：复核 control 手册是否已经完整表达 Taskdoc progress 的公告牌语义',
 });
 
 // 只有因为这是一条职责相关提示，且在所有由你主理的后续对话里也应继续看到，
@@ -32,10 +32,10 @@ add_reminder({
   scope: 'personal',
 });
 
-// 任务完成后更新
+// 当本地工作集细节变化后更新
 update_reminder({
   reminder_id: 'abc123de',
-  content: '已完成: 创建 i18n 手册 [完成]',
+  content: '阻塞已解除：control 手册文案已与 Taskdoc progress 语义对齐',
 });
 
 // 删除已完成的提醒
@@ -46,8 +46,9 @@ delete_reminder({
 
 ### 关键点
 
-- 当前任务进度、临时阻塞、一次性线索默认都用 `dialog`
+- 本地下一步、临时阻塞、一次性 bridge 细节默认都用 `dialog`
 - 只有职责相关、且在所有由你主理的后续对话里也应继续看到的提醒才用 `personal`
+- 如果信息需要向全队同步当前有效状态、关键决策、下一步或仍成立阻塞，应写入 Taskdoc `progress`
 - 如果内容本质上是长期知识而不是当前工作集提示，应改存到 `personal_memory`
 
 ## 场景 2：支线已完成，按 assignment 头部要求调用 replyTellask
@@ -114,7 +115,7 @@ replyTellaskBack({
 
 ### 场景描述
 
-更新任务进度到差遣牒。
+把当前有效状态、关键决策、下一步与仍成立阻塞公告给全队，而不是写个人流水账。
 
 ### 示例
 
@@ -122,7 +123,7 @@ replyTellaskBack({
 change_mind({
   selector: 'progress',
   content:
-    '## Progress\n\n### 已完成\n- [x] 创建 ws_mod 手册\n- [x] 创建 team_mgmt 手册\n- [x] 创建 personal_memory 手册\n\n### 进行中\n- [ ] 创建 control 手册 [50%]\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- 无',
 });
 ```
 
@@ -184,15 +185,15 @@ recall_taskdoc({
 
 ### 场景描述
 
-维护差遣牒的完整性和一致性。
+维护差遣牒的完整性和一致性，并确保 `progress` 始终是可供全队扫读的当前真相快照。
 
 ### 示例
 
 ```typescript
-// 更新进度（保持 goals 和 progress 一致）
+// 更新 progress（保持 goals / constraints / progress 一致）
 change_mind({
   selector: 'progress',
   content:
-    '## Progress\n\n### 已完成\n- [x] 创建 ws_mod 手册 [100%]\n- [x] 创建 team_mgmt 手册 [100%]\n- [x] 创建 personal_memory 手册 [100%]\n\n### 进行中\n- [ ] 创建 control 手册 [60%]\n\n### 下一步\n- 完成 control 手册\n- 创建 os 手册',
+    '## Progress\n\n### 当前有效状态\n- 边界口径已统一到手册源头与测试\n\n### 已生效决策\n- 角色级资产 / personal_memory / team_memory / Taskdoc-progress / reminders 的职责已经切开\n\n### 下一步\n- 复验 control 手册、Taskdoc 展示文案与边界测试\n\n### 仍成立阻塞\n- 无',
 });
 ```

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

@@ -232,7 +232,7 @@ update_reminder({
 change_mind({
   selector: 'progress',
   content:
-    '## Progress\n\n### 已完成\n- [x] 创建 ws_mod 手册\n- [x] 创建 team_mgmt 手册\n\n### 进行中\n- [ ] 创建 personal_memory 手册 [80%]\n\n### 待开始\n- [ ] 创建 control 手册',
+    '## Progress\n\n### 当前有效状态\n- 手册边界方案已确定：角色级资产 / 个人长期经验 / Taskdoc-progress / reminders 分流\n\n### 已生效决策\n- `persona / knowhow / pitfalls` 不承接成员日常经验\n- `personal_memory` 只承接成员自己的长期可复用经验\n\n### 下一步\n- 补齐 Taskdoc `progress` 的公告牌属性说明\n\n### 仍成立阻塞\n- 无',
 });
 ```
 
@@ -273,5 +273,5 @@ message: <错误消息>
 - 默认提醒项应保持短、新、能直接指导下一步，常见 1–3 条
 - 若用于接续包，默认优先结构化内容：下一步行动、关键定位、运行/验证、容易丢的临时细节
 - 若已吃紧/告急，先保留多条粗略提醒项也可以；当前程只做保信息 + `clear_mind`，系统真正开启新一程后第一步再收敛整理
-- 接续包只保留差遣牒未覆盖的细节；不要重复团队共享状态
+- 接续包只保留差遣牒未覆盖的细节；不要重复团队共享状态。要向全队同步“现在到哪了 / 哪些决策已生效 / 下一步是什么 / 哪些阻塞仍成立”，请写回 Taskdoc `progress`
 - 不要把长日志、大段 tool output、原始材料直接塞进提醒项

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

@@ -29,12 +29,14 @@ personal_memory is Dominds' **personal memory toolset** for managing an agent's
 - **Privacy**: Memory is only visible to the current agent, not shared with other members
 - **Persistence**: Memory is persisted to disk and retained after conversation restarts
 - **Structured**: Supports organizing memory by path for easy categorization and retrieval
+- **Boundary**: Primarily for one member's own reusable long-lived experience and working index, not current task state
 
 Key notes:
 
 - Personal memory is automatically isolated on disk under `.minds/memory/individual/<member-id>/...`.
 - Your `path` must NOT include your member id (do not write `<member-id>/...`).
 - If you have zero memory files yet, just call `add_personal_memory` — the directory will be created automatically.
+- If the content is a role's long-lived responsibilities/methods/examples, put it in `persona / knowhow / pitfalls` instead; if it should synchronize the team's current effective state, key decisions, next steps, or still-active blockers, use Taskdoc `progress`, the quasi-real-time task bulletin board; if it is only a personal/current-dialog short-term working set or continuation detail, use reminders instead.
 
 Tool list:
 

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

@@ -69,17 +69,22 @@ The `personal_memory` toolset uses a **path key-value storage** model:
 - Treat personal memory as a **carry-along stable-facts memo**: enable **0 ripgrep** startup within your scope.
 - Store stable facts only: **anchor points (file/symbol) + 1-line meaning + key contracts/priorities (≤3)**.
 - Fewer memory files is better: group facts that will be updated together into one file; avoid adding extra “directory-of-directory” layers.
+- `personal_memory` should primarily hold knowledge that has **not** been promoted to team-defined role assets yet, but is still worth carrying forward for your own future work: your entry maps, search keywords, debugging methods, and long-lived working preferences.
 - Do not store task progress or daily state here:
-  - Team-visible progress belongs in Taskdoc `progress`
-  - Short-term working set belongs in reminders
+  - Information that must synchronize the team's current effective state, key decisions, next step, or still-active blockers belongs in Taskdoc `progress`, the quasi-real-time task bulletin board
+  - Personal or current-dialog short-term working set details belong in reminders
 
-### 3. Usage Scenarios
+### 3. Recommended Boundaries
 
-- **Task persistence**: Save long-term task progress
-- **Context memory**: Save important information from conversation context
-- **Preference settings**: Save user preferences and configuration information
+- **Role-level long-lived definition assets**: `persona / knowhow / pitfalls`
+- **A member’s own reusable long-lived experience and working index**: `personal_memory`
+- **Taskdoc `progress`**: the team-shared quasi-real-time task bulletin board for current effective state, key decisions, next steps, and still-active blockers
+- **reminders**: personal or current-dialog short-term working set, continuation package, and easy-to-lose volatile details
+- **Team-shared long-lived conventions / invariants / consensus rules**: `team_memory`
 
-> Note: If you find yourself using personal memory to store “current progress of this run”, it likely belongs in Taskdoc `progress` or reminders instead.
+> Note: If the main purpose of the information is to let the team quickly synchronize on where things stand now, which decisions are in effect, what is next, or which blockers still hold, it belongs in Taskdoc `progress`, not in `personal_memory`.
+>
+> Likewise, if what you want to write is a role’s long-lived responsibility boundary, working method, or durable positive/negative example, it should usually live in that role’s `persona / knowhow / pitfalls`, not in `personal_memory`.
 
 ## Relationship with Other Tools