# control 原则与核心概念

## 模板（原则）

### 设计目标

- <目标 1>
- <目标 2>

### 契约原则

- <输入/输出契约规则>

### 安全与边界

- <访问约束/护栏>

### 失败与恢复

- <调用失败时的行动>

### 术语表

- <该工具集特有术语>

## 核心概念

### 1. 提醒（Reminder）

提醒是临时手头工作提示，但现在分成三个 scope：

- `dialog`：仅当前对话可见
- `task`：当前差遣牒任务内、所有由你主理的对话里都可见
- `agent`：所有由你主理的对话里都可见，但只用于紧急、短期、全局刺眼提醒

默认用 `task`。只有当这条提醒只对当前对话局部有效时，才降到 `dialog`；只有当它是紧急、短期、全局刺眼提醒时，才升到 `agent`。

**特点：**

- `dialog` 提醒只留在当前对话
- `task` 提醒会在当前差遣牒任务内继续可见
- `agent` 提醒会在所有由你主理的后续对话里继续可见
- 可随时添加、修改、删除
- 默认应保持少量、可扫读、可直接指导下一步
- 准备 `clear_mind` 时，主线对话先把应由下一程知会的未落文档讨论细节补进差遣牒，再压缩成结构化接续包提醒项；支线对话直接维护足够详尽的接续包提醒项。若 Dominds 已提醒上下文吃紧/告急，支线提醒项没有固定长度限制，也可先保留多条粗略提醒项过桥

**与 memory 的区别：**
| 特性 | dialog reminder | task reminder | agent reminder | personal memory |
|------|-----------------|---------------|----------------|-----------------|
| 持久性 | 仅当前对话 | 当前差遣牒任务 | 跨所有由你主理的后续对话 | 长期 / 文件持久化 |
| 可见性 | 当前对话 | 当前任务相关对话 | 你当前可见的提醒范围 | 当前智能体 |
| 最适合 | 当前下一步、阻塞、易丢线索 | 同一任务下的手头工作 | 紧急、短期、全局刺眼提醒 | 稳定事实 / 可复用知识 |

### 1.1 Scope 选用原则

- 默认用 `task`：
  - 这个任务下反复要用到的首选命令
  - 这个任务持续要执行的安全检查
  - 应该跨对话保留、但只对当前差遣牒任务有效的注意点
- 其余真正只对当前对话有效的，一律用 `dialog`：
  - 当前阻塞
  - 临时路径、id、命令、样例输入
  - 只对这次对话 / 当前程有用的过桥备注
- 如果内容本质上是长期稳定事实或知识资产，而不是当前手头工作提示，它更可能属于 `personal_memory`，而不是 reminder。

### 2. 差遣牒

差遣牒是**任务契约**，也是任务执行期的**全队共享真相载体**；其中 `progress` 承担的是**准实时全队任务公告牌 / 当前有效状态快照**职责。

**结构：**

- **goals.md**：任务目标
- **constraints.md**：约束条件
- **progress.md**：面向全队同步的当前有效状态、关键决策、下一步与仍成立阻塞

**更新规则：**

- `do_mind` 用于创建新章节；`mind_more` 用于少量追加条目；`change_mind` 用于替换已有整章；`never_mind` 用于删除整章文件
- 不开启新 course
- 变更对所有队友可见
- 写入 `progress` 时，应默认假设全队成员会用它快速同步“当前任务真相”，而不是阅读你的个人过程记录
- 不要无脑连续使用 `mind_more` 把 `progress` 写成流水账；当公告牌开始堆积、重复或含过期信息时，用 `change_mind` 按当前仍有效的事实压缩整理
- 细节展开、调查过程、长日志、方案全文和验收记录应落进 rtws 正式文档；差遣牒只保留要点、当前结论、下一步，以及指向正式文档的路径/章节/命令等定位 pointer

## 工具概览

| 工具            | 功能                              |
| --------------- | --------------------------------- |
| add_reminder    | 添加提醒                          |
| delete_reminder | 删除提醒                          |
| update_reminder | 更新提醒内容                      |
| do_mind         | 创建新差遣牒章节                  |
| mind_more       | 向差遣牒追加条目（默认 progress） |
| change_mind     | 整章替换已有差遣牒章节            |
| never_mind      | 删除差遣牒章节文件                |
| recall_taskdoc  | 读取差遣牒章节                    |

## 跨对话回复路由

### 决策规则

- 当前支线未完成时，先判断团队规程 / SOP / 职责卡能否明确负责人；若能明确且属于执行性处理，直接 `tellask` / `tellaskSessionless` 对应负责人
- 不要把智能体队友当成真人同事：祂不会因为你又发一条诉请而被打扰。同一个队友 + 同一个 `sessionSlug` = 接着同一件事说，并更新那件正在做的事；`tellaskSessionless` 或不同 `sessionSlug` = 另一件独立任务
- 只有当必须向诉请者补需求、澄清目标、裁决取舍、确认验收口径、提供缺失输入，或现有规程无法明确判责时：调用 `tellaskBack({ tellaskContent })`
- 需要人类亲自登录 / GUI / 验证码 / 高风险授权时：调用 `askHuman({ tellaskContent })`
- 当前支线已经完成，且当前任务开头明确要求 `replyTellask`：调用 `replyTellask({ replyContent })`
- 当前支线已经完成，且当前任务开头明确要求 `replyTellaskSessionless`：调用 `replyTellaskSessionless({ replyContent })`
- 当前是在回复一条诉请者发来的 `tellaskBack` 续诉请，且 Dominds 显示了 `replyTellaskBack`：调用 `replyTellaskBack({ replyContent })`
- 普通文本不是跨对话完成交付通道；如果你直接写出了可回给诉请者的最终内容但没按 Dominds 点名的回复工具发送，Dominds 可能临时提醒你改用那个工具。不要把普通文本当成正式回贴路径；对方可能收不到正式回贴。

### 心智负担最小化规则

- 先专注把当前任务做对；只有最终内容准备好、且 Dominds 点名了回复工具时，才发送最终回贴
- 不要靠记忆硬选回复工具；以当前任务开头和 Dominds 当前点名/显示的回复工具为准
- 回复工具自身说明文案故意保持极简，只承载最小规格；情景判断看本手册的 principles / scenarios
- 若 Dominds 只点名/显示一个回复工具，那就是当前应调用的唯一完成路径
- `tellaskBack` 只在“无法按现有规程明确判责，或必须回问诉请者”时成立，不是所有阻塞的默认第一动作

## 最佳实践

### 1. 提醒使用场景

- **当前手头工作**：当前下一步、阻塞、关键定位信息
- **易丢细节**：临时路径、id、命令、样例输入
- **换程接续**：在 `clear_mind` 前整理接续包；若 Dominds 已提醒当前程吃紧/告急，可先保留多条粗略提醒项
- **任务延续提示**：如果在当前差遣牒任务内都应该继续看到它，用 `task`
- **全局刺眼提示**：如果它应该在所有由你主理的后续对话里继续看到，而且是短期、紧急、全局刺眼提醒，用 `agent`

### 2. 差遣牒更新时机

- **目标变更**：当任务目标发生变化时
- **约束调整**：当约束条件需要调整时
- **进度更新**：当需要向全队同步当前有效状态、关键决策、下一步或仍成立阻塞时

### 3. 更新策略

- 保持简洁：默认提醒项常见 1–3 条，优先 `update_reminder` 压缩/合并
- 区分载体：需要向全队同步的当前有效状态、关键决策、下一步与仍成立阻塞，写入 `progress` 这一准实时任务公告牌；提醒项只留个人/当前对话恢复所需细节
- 避免重复系统状态：后台进程状态、后台进行中诉请/协作、浏览器/会话附件状态等 Dominds 会自动维护的信息，不要写进手工提醒项；这些状态以 Dominds 自动维护的提醒、面板和工具输出为准，手工副本容易过时并造成认知干扰
- 面向全队：`progress` 应保持可扫读、以“当前仍有效”为准，不要退化成个人日志、流水账、临时便签或历史残影堆积；少量新增用 `mind_more`，需要清旧/重排/压缩时先调用 `recall_taskdoc`，再用 `change_mind` 并携带返回的 `content_hash` 作为 `previous_content_hash`
- 按需整理：`mind_more` 不是默认记账动作。若同一主题已有多条阶段性记录，优先用 `change_mind` 合并成当前摘要；把细节放进 rtws 正式文档，并在差遣牒里保留文档定位 pointer。若会冲掉原有内容，必须有直接人类确认，或已按人类认可 SOP/验收标准充分考虑原有内容后再改写
- 换程前收束：主线对话先把尚未落实到文档、且下一程需要知会的讨论细节写入差遣牒合适章节，再整理结构化接续包提醒项；支线对话不要维护差遣牒，也不要整理差遣牒更新提案，直接维护足够详尽的接续包提醒项。若 Dominds 已提醒上下文吃紧/告急，则先保留多条粗略提醒项过桥也可以；当前程只做落文档/保信息 + `clear_mind`（支线只做保信息 + `clear_mind`），Dominds 真正开启新一程后第一步再收敛
- 拒绝原料堆积：不要把长日志/大段 tool output 直接塞进提醒项
- 文档分层：差遣牒写“现在应如何同步/推进”，正式文档写“为什么、怎么做、详细证据和完整过程”。差遣牒需要引用正式文档时，写稳定路径/章节名/相关命令，而不是复制整段内容

### 4. `progress` 内容取舍

- 适合写进 `progress`：
  - 当前已经生效的关键决策
  - 当前已确认、仍成立的 blocker
  - 当前全队应共识的下一步
  - 当前阶段性闭环与尚未闭环的 gap
  - 已落正式文档的关键内容摘要，以及定位该文档的 pointer
- 不适合写进 `progress`：
  - “我刚刚看了什么文件”
  - “我准备先试一个小想法”
  - 只对当前说话者自己有用的临时便签
  - 无法判断是否仍然有效的历史痕迹
  - 可在 rtws 正式文档中承载的细节展开、长日志、完整方案或验收记录全文

## 限制与注意事项

1. `dialog` 提醒会随对话结束而结束；`task` 提醒会在当前差遣牒任务内继续可见；`agent` 提醒会在所有由你主理的后续对话里继续可见
2. 缺失差遣牒章节用 `do_mind` 创建；差遣牒少量新增可用 `mind_more` 追加；已有章节整段替换用 `change_mind`，请确保合并已有内容，并先调用 `recall_taskdoc` 取得当前 `content_hash` 作为 `previous_content_hash`；确需删除整章文件时用 `never_mind`。不要把 `mind_more` 当流水账工具；需要整理、去旧、合并同主题记录时先 `recall_taskdoc` 再 `change_mind`
3. `do_mind` / `mind_more` / `change_mind` / `never_mind` 不开启新 course
4. 接续包提醒项只保留差遣牒仍未覆盖、但恢复工作容易丢的细节；主线对话应先把当前对话历史中应由下一程知会的未落文档讨论细节写入差遣牒合适章节；支线对话在吃紧/告急时只维护足够详尽的接续包提醒项
5. 不要把 `task` / `agent` 提醒堆成长期事实仓库；耐久知识应迁到 `personal_memory`
