docs: add channel modes plan and expand tasklist

plans/CHANNEL_MODES_AND_SHUFFLE.md

@@ -0,0 +1,208 @@
+# Channel Modes & Turn Shuffle 规划
+
+## 背景
+
+`feat/new-feat-notes` 分支中的 `NEW_FEAT.md` 提出了两项新的行为增强需求，需要整合进入 `main` 分支下的 `plans/`：
+
+1. **Multi-Message Mode（人类连续多消息模式）**
+2. **Shuffle Mode（轮转顺序重洗牌）**
+
+这两项能力都与 Dirigent 当前的 turn-manager、moderator handoff、no-reply override 机制直接相关，因此应作为 turn orchestration 的功能扩展纳入规划，而不是孤立实现。
+
+---
+
+## 1. Multi-Message Mode
+
+### 1.1 目标
+
+允许人类在一个 channel 中连续发送多条消息而不被 Agent 打断。
+
+当用户显式进入 multi-message mode 后：
+- 当前 channel 的 turn manager 暂停
+- 所有 Agent 在该 channel 中进入 no-reply 覆盖
+- moderator bot 对每条人类追加消息发送 prompt marker，提示继续输入
+- 直到人类发送 end marker 才恢复 turn manager
+- 恢复后由 moderator 按现有调度机制唤醒下一位 Agent
+
+---
+
+### 1.2 配置项
+
+建议新增以下可配置项：
+
+- `multiMessageStartMarker`：默认 `↗️`
+- `multiMessageEndMarker`：默认 `↙️`
+- `multiMessagePromptMarker`：默认 `⤵️`
+
+这些配置应加入插件 config schema，并在运行时可被 hook/turn-manager 使用。
+
+---
+
+### 1.3 行为规则
+
+#### 进入 multi-message mode
+当 **human** 消息中包含 start marker：
+- 当前 channel 进入 `multi-message` 状态
+- turn manager 暂停
+- 当前 channel 下所有 Agent 在该 channel/session 中走 no-reply override
+
+#### multi-message mode 中
+在该模式下：
+- 人类每发一条消息
+- moderator bot 自动回复 prompt marker（例如 `⤵️`）
+- Agent 不应参与正常轮转回复
+
+#### 退出 multi-message mode
+当 **human** 消息中包含 end marker：
+- 当前 channel 退出 `multi-message` 状态
+- turn manager 恢复
+- moderator bot 发送当前调度标识（scheduling identifier）唤醒下一位 Agent
+
+---
+
+### 1.4 状态建议
+
+每个 Discord channel 维护一个 channel mode：
+
+- `normal`
+- `multi-message`
+- （后续可扩展其他模式）
+
+multi-message mode 应与 discussion channel / wait-for-human / no-reply 决策互相兼容，优先级需要明确。
+
+建议优先级初稿：
+
+1. closed discussion channel
+2. multi-message mode
+3. waiting-for-human
+4. normal turn-manager
+
+---
+
+## 2. Shuffle Mode
+
+### 2.1 目标
+
+在 turn-based speaking 中，为每个 Discord channel 增加可选的 turn order reshuffle 能力。
+
+当 shuffle mode 开启时：
+- 在一轮 turn list 的最后一位 speaker 发言完成后
+- 对 turn order 重新洗牌
+- 但必须保证：**上一轮最后一位发言者不能在新一轮中成为第一位**
+
+---
+
+### 2.2 配置 / 控制方式
+
+为每个 Discord channel 维护：
+
+- `shuffling: boolean`
+
+并新增 slash command：
+
+- `/turn-shuffling on`
+- `/turn-shuffling off`
+- `/turn-shuffling`（查看当前状态）
+
+该状态应与 channel 级 policy / runtime state 做清晰分工：
+- 若只是运行时开关，可放 runtime memory
+- 若希望重启保留，则需要落盘策略
+
+---
+
+### 2.3 行为规则
+
+当 `shuffling = true` 时：
+- 正常按 turn order 轮转
+- 当“当前 speaker 是该轮最后一位”并完成发言后
+- 进入下一轮前重洗 turn order
+- 新 turn order 必须满足：
+  - 上一轮最后 speaker != 新 turnOrder[0]
+
+若无法满足（极端小集合场景），需要定义 fallback：
+- 两个 Agent 时可退化为简单交换/固定顺序
+- 单 Agent 时不需要 shuffle
+
+---
+
+## 3. 与当前系统的关系
+
+这两个能力都不是独立子系统，而是 Dirigent turn orchestration 的扩展。
+
+### 涉及模块
+
+- `plugin/turn-manager.ts`
+- `plugin/hooks/message-received.ts`
+- `plugin/hooks/before-model-resolve.ts`
+- `plugin/hooks/before-message-write.ts`
+- `plugin/hooks/message-sent.ts`
+- `plugin/commands/dirigent-command.ts`
+- `plugin/index.ts`
+- `plugin/openclaw.plugin.json`
+- 如有必要新增 `plugin/core/channel-modes.ts` 或类似 runtime state 模块
+
+---
+
+## 4. 建议实现方向
+
+### 4.1 Multi-Message Mode
+
+建议不要把 multi-message mode 直接塞进规则判断字符串里，而是做成显式 channel runtime state。
+
+建议新增：
+- channel mode state store
+- helper：
+  - `enterMultiMessageMode(channelId)`
+  - `exitMultiMessageMode(channelId)`
+  - `isMultiMessageMode(channelId)`
+
+然后：
+- `message-received` 检测 human 消息中的 start/end marker
+- `before-model-resolve` 检测当前 channel 是否处于 multi-message mode，若是则直接走 no-reply override
+- `message-received` 或合适的消息链路中触发 moderator prompt marker
+- 退出时触发一次 scheduling handoff
+
+---
+
+### 4.2 Shuffle Mode
+
+建议将 shuffle 状态与 turn order 状态放在一起，或由 turn-manager 引用单独的 channel config/state。
+
+建议新增 helper：
+- `setChannelShuffling(channelId, enabled)`
+- `getChannelShuffling(channelId)`
+- `reshuffleTurnOrder(channelId, { avoidFirstAccountId })`
+
+并在 turn cycle 的边界点调用重洗逻辑，而不是在任意发言后随机改顺序。
+
+---
+
+## 5. 风险与边界
+
+### Multi-Message Mode
+
+- 需要防止 moderator prompt marker 自己再次触发 turn logic
+- 需要明确 start/end marker 的匹配规则（全文包含、末尾匹配、独立一条指令等）
+- 需要明确 multi-message mode 下 human @mention 是否还有特殊行为
+- 需要避免与 discussion closed / waiting-for-human 冲突
+
+### Shuffle Mode
+
+- 两个 Agent 的洗牌约束需要单独处理
+- turn order 若正处于 mention override / waiting-for-human / dormant，需要明确何时允许 reshuffle
+- 若 turn order 成员变化，shuffle 与 bootstrap 的先后顺序要明确
+
+---
+
+## 6. 结论
+
+`feat/new-feat-notes` 分支中的内容可以整合为 `main` 下的一份独立规划文档，建议命名为：
+
+- `plans/CHANNEL_MODES_AND_SHUFFLE.md`
+
+其定位是：
+- 汇总 multi-message mode 与 shuffle mode 的产品行为
+- 明确它们与现有 turn-manager / moderator / no-reply 机制的关系
+- 为后续代码开发和 TASKLIST 拆分提供依据
+
+后续应将对应开发任务补充进 `plans/TASKLIST.md`。

plans/TASKLIST.md

@@ -0,0 +1,344 @@
+# TASKLIST - Dirigent 开发任务拆分
+
+## A. CSM / Discussion Callback
+
+### A1. 需求与方案冻结
+- [ ] 通读并确认 `plans/CSM.md` 中的 MVP 范围、非目标和边界条件
+- [ ] 确认 CSM 第一版只新增一条对外工具：`discuss-callback`
+- [ ] 确认 `discord_channel_create` 仅做参数扩展，不改变普通建频道行为
+- [ ] 确认讨论结束后的 session 级 no-reply 覆盖继续沿用现有插件机制
+- [ ] 确认 `summaryPath` 的合法范围仅限发起讨论 Agent 的 workspace
+- [ ] 确认 discussion metadata 是否仅做内存态，还是需要落盘恢复
+
+### A2. 模块拆分与落点确认
+- [ ] 确认 `plugin/tools/register-tools.ts` 负责：
+  - [ ] 扩展 `discord_channel_create`
+  - [ ] 注册 `discuss-callback`
+- [ ] 确认 `plugin/core/` 下新增 discussion metadata 管理模块
+- [ ] 确认 `plugin/core/moderator-discord.ts` 继续负责 moderator 发消息能力
+- [ ] 确认 `plugin/turn-manager.ts` 仅负责 turn 状态与轮转，不直接承担业务文案拼接
+- [ ] 确认 discussion 业务编排逻辑应放在新模块，而不是散落到多个 hook 中
+- [ ] 确认 origin callback 与 discussion close 逻辑的调用路径
+
+### A3. `plugin/tools/register-tools.ts`
+#### A3.1 扩展 `discord_channel_create`
+- [ ] 阅读当前 `discord_channel_create` 的参数定义与执行逻辑
+- [ ] 为 `discord_channel_create` 增加可选参数 `callbackChannelId`
+- [ ] 为 `discord_channel_create` 增加可选参数 `discussGuide`
+- [ ] 添加联动校验：若传 `callbackChannelId`，则必须传 `discussGuide`
+- [ ] 保证不传 `callbackChannelId` 时，行为与当前版本完全一致
+- [ ] 创建成功后识别是否为 discussion 模式 channel
+- [ ] 在 discussion 模式下调用 metadata 初始化逻辑
+- [ ] 在 discussion 模式下调用 moderator kickoff 发送逻辑
+
+#### A3.2 注册 `discuss-callback`
+- [ ] 定义 `discuss-callback` 的 parameters schema
+- [ ] 注册新工具 `discuss-callback`
+- [ ] 将 `discuss-callback` 执行逻辑接到 discussion service / manager
+- [ ] 为工具失败场景返回可读错误信息
+
+### A4. `plugin/core/` 新增 discussion metadata/service 模块
+#### A4.1 新建 metadata/state 模块
+- [ ] 新建 discussion state 类型定义文件（如 `plugin/core/discussion-state.ts`）
+- [ ] 定义 discussion metadata 类型：
+  - [ ] `mode`
+  - [ ] `discussionChannelId`
+  - [ ] `originChannelId`
+  - [ ] `initiatorAgentId`
+  - [ ] `initiatorSessionId`
+  - [ ] `discussGuide`
+  - [ ] `status`
+  - [ ] `createdAt`
+  - [ ] `completedAt`
+  - [ ] `summaryPath`
+- [ ] 提供按 `discussionChannelId` 查询 metadata 的方法
+- [ ] 提供创建 metadata 的方法
+- [ ] 提供更新状态的方法
+- [ ] 提供关闭 discussion channel 的状态写入方法
+
+#### A4.2 新建 discussion service 模块
+- [ ] 新建 discussion service（如 `plugin/core/discussion-service.ts`）
+- [ ] 封装 discussion channel 创建后的初始化逻辑
+- [ ] 封装 callback 校验逻辑
+- [ ] 封装 callback 成功后的收尾逻辑
+- [ ] 封装 origin channel moderator 通知逻辑
+- [ ] 封装“channel 已关闭，仅做留档使用”的统一回复逻辑
+
+#### A4.3 workspace 路径校验
+- [ ] 新增 path 校验辅助函数
+- [ ] 校验 `summaryPath` 文件存在
+- [ ] 校验 `summaryPath` 位于 initiator workspace 下
+- [ ] 防止 `..`、绝对路径越界、软链接绕过等路径逃逸问题
+
+### A5. `plugin/core/moderator-discord.ts`
+- [ ] 确认当前 `sendModeratorMessage(...)` 是否已足够支撑新流程
+- [ ] 如有必要，补充统一错误日志和返回值处理
+- [ ] 确认可被 discussion service 复用发送：
+  - [ ] kickoff message
+  - [ ] idle reminder
+  - [ ] callback 完成通知
+  - [ ] channel closed 固定回复
+
+### A6. `plugin/turn-manager.ts`
+#### A6.1 理解现有轮转机制
+- [ ] 梳理 `initTurnOrder` / `checkTurn` / `onNewMessage` / `onSpeakerDone` / `advanceTurn`
+- [ ] 确认“轮转一圈无人发言”在现有实现中的判定条件
+- [ ] 确认 discussion 模式需要在哪个信号点插入“idle reminder”
+
+#### A6.2 discussion 模式的空转处理
+- [ ] 设计 discussion 模式下的 idle reminder 触发方式
+- [ ] 确定是直接改 `turn-manager.ts`，还是由上层在 `nextSpeaker === null` 时识别 discussion channel
+- [ ] 确保 discussion channel 空转时 moderator 会提醒 initiator 收尾
+- [ ] 确保普通 channel 仍保持原有 dormant 行为
+
+#### A6.3 关闭后禁言
+- [ ] 明确 discussion channel `closed` 后 turn-manager 是否还需要保留状态
+- [ ] 如需要，增加对 closed discussion channel 的快速短路判断
+- [ ] 避免 closed channel 再次进入正常轮转
+
+### A7. Hooks 与 session 状态
+#### A7.1 `plugin/hooks/before-model-resolve.ts`
+- [ ] 梳理当前 session 级 no-reply 覆盖的触发路径
+- [ ] 确认如何将 closed discussion channel 相关 session 强制落到 `noReplyProvider` / `noReplyModel`
+- [ ] 确认该逻辑是通过 metadata 状态判断，还是通过额外 session 标记判断
+- [ ] 确保该覆盖只作用于指定 discussion session，不影响其他 channel/session
+- [ ] 为 closed discussion channel 的覆盖路径补充调试日志
+
+#### A7.2 `plugin/hooks/before-message-write.ts`
+- [ ] 梳理当前 NO_REPLY / end-symbol / waitIdentifier 的处理逻辑
+- [ ] 找到 discussion channel 中“轮转一圈无人发言”后最适合触发 idle reminder 的位置
+- [ ] 如果 `nextSpeaker === null` 且当前 channel 是 active discussion channel：
+  - [ ] 调用 moderator idle reminder
+  - [ ] 不直接让流程无提示沉默结束
+- [ ] 避免重复发送 idle reminder
+- [ ] closed discussion channel 下，阻止继续进入正常 handoff 流程
+
+#### A7.3 `plugin/hooks/message-sent.ts`
+- [ ] 确认该 hook 是否也会参与 turn 收尾，避免与 `before-message-write.ts` 重复处理
+- [ ] 检查 discussion channel 场景下是否需要同步补充 closed/idle 分支保护
+- [ ] 确保 callback 完成后的 closed channel 不会继续触发 handoff
+
+#### A7.4 `plugin/hooks/message-received.ts`
+- [ ] 梳理 moderator bot 消息当前是否已被过滤，避免 moderator 自己再次触发讨论链路
+- [ ] 对 closed discussion channel 的新消息增加统一处理入口
+- [ ] 若 closed discussion channel 收到新消息：
+  - [ ] 不再唤醒任何 Agent 正常讨论
+  - [ ] 由 moderator 回复“channel 已关闭，仅做留档使用”
+- [ ] 避免 moderator 的 closed 提示消息反复触发自身处理
+
+#### A7.5 `plugin/core/session-state.ts`（如需）
+- [ ] 检查现有 session 相关缓存是否适合扩展 discussion 状态
+- [ ] 若需要，为 discussion session 增加专用标记缓存
+- [ ] 区分：普通 no-reply 决策 vs discussion close 强制 no-reply
+- [ ] 确保 session 生命周期结束后相关缓存可清理
+
+### A8. `plugin/core/identity.ts` / `plugin/core/channel-members.ts` / `plugin/core/turn-bootstrap.ts`
+- [ ] 梳理 initiator identity 的可获取路径
+- [ ] 确认 callback 时如何稳定识别 initiator account/session
+- [ ] 确认 discussion channel 创建后 turn order 是否需立即 bootstrap
+- [ ] 确认 discussion participant 的成员集合获取方式是否可直接复用现有逻辑
+
+### A9. `plugin/index.ts`
+- [ ] 注入新增 discussion metadata/service 模块依赖
+- [ ] 将 discussion service 传入工具注册逻辑
+- [ ] 将 discussion 相关辅助能力传入需要的 hooks
+- [ ] 保持插件初始化结构清晰，避免在 `index.ts` 中堆业务细节
+
+### A10. moderator 消息模板整理
+#### A10.1 kickoff message
+- [ ] 定稿 discussion started 模板
+- [ ] 模板中包含 `discussGuide`
+- [ ] 模板中明确 initiator 结束责任
+- [ ] 模板中明确 `discuss-callback(summaryPath)` 调用要求
+
+#### A10.2 idle reminder
+- [ ] 定稿 discussion idle 模板
+- [ ] 模板中提醒 initiator：写总结文件并 callback
+- [ ] 避免提醒文案歧义或像自动总结器
+
+#### A10.3 origin callback message
+- [ ] 定稿发回原工作 channel 的结果通知模板
+- [ ] 模板中包含 `summaryPath`
+- [ ] 模板中包含来源 discussion channel
+- [ ] 模板中明确“继续基于该总结文件推进原任务”
+
+#### A10.4 closed reply
+- [ ] 定稿 closed channel 固定回复模板
+- [ ] 明确 channel 已关闭，仅做留档使用
+
+### A11. `discuss-callback` 详细校验任务
+- [ ] 校验当前 channel 必须是 discussion channel
+- [ ] 校验当前 discussion 状态必须是 `active`
+- [ ] 校验调用者必须是 initiator
+- [ ] 校验 `summaryPath` 非空
+- [ ] 校验 `summaryPath` 文件存在
+- [ ] 校验 `summaryPath` 路径在 initiator workspace 内
+- [ ] 校验 callback 未重复执行
+- [ ] callback 成功后写入 `completedAt`
+- [ ] callback 成功后记录 `summaryPath`
+- [ ] callback 成功后切换 discussion 状态为 `completed` / `closed`
+
+### A12. 关闭后的行为封口
+- [ ] closed discussion channel 中所有旧 session 继续使用 no-reply 覆盖
+- [ ] closed discussion channel 中任何新消息都不再进入真实讨论
+- [ ] closed discussion channel 的任何新消息统一走 moderator 固定回复
+- [ ] 防止 closed channel 中 moderator 自己的回复再次触发回环
+- [ ] 明确 archived-only 的最终行为与边界
+
+### A13. 测试与文档收尾
+#### A13.1 工具层测试
+- [ ] 测试普通 `discord_channel_create` 不带新参数时行为不变
+- [ ] 测试 `discord_channel_create` 带 `callbackChannelId` 但缺 `discussGuide` 时失败
+- [ ] 测试 discussion 模式 channel 创建成功
+- [ ] 测试 `discuss-callback` 注册成功并可调用
+
+#### A13.2 metadata / service 测试
+- [ ] 测试 discussion metadata 创建成功
+- [ ] 测试按 channelId 查询 metadata 成功
+- [ ] 测试状态流转 `active -> completed/closed` 成功
+- [ ] 测试重复 callback 被拒绝
+
+#### A13.3 turn / hook 测试
+- [ ] 测试 discussion channel 空转后发送 idle reminder
+- [ ] 测试普通 channel 空转逻辑不受影响
+- [ ] 测试 callback 成功后 discussion channel 不再 handoff
+- [ ] 测试 closed discussion channel 新消息不会继续唤醒 Agent
+
+#### A13.4 路径校验测试
+- [ ] 测试合法 `summaryPath` 通过
+- [ ] 测试不存在文件失败
+- [ ] 测试 workspace 外路径失败
+- [ ] 测试 `..` 路径逃逸失败
+- [ ] 测试绝对路径越界失败
+
+#### A13.5 回调链路测试
+- [ ] 测试 callback 成功后 moderator 在 origin channel 发出通知
+- [ ] 测试 origin channel 收到路径后能继续原工作流
+- [ ] 测试 discussion channel 后续只保留留档行为
+
+#### A13.6 文档交付
+- [ ] 根据最终代码实现更新 `plans/CSM.md`
+- [ ] 为 `discord_channel_create` 新增参数补文档
+- [ ] 为 `discuss-callback` 补工具说明文档
+- [ ] 补 discussion metadata 与状态机说明
+- [ ] 补开发/调试说明
+- [ ] 输出 MVP 验收清单
+
+---
+
+## B. Multi-Message Mode / Shuffle Mode
+
+### B1. 方案整理
+- [ ] 通读并确认 `plans/CHANNEL_MODES_AND_SHUFFLE.md`
+- [ ] 确认 Multi-Message Mode 与 Shuffle Mode 的 MVP 范围
+- [ ] 确认两项能力是否都只做 channel 级 runtime state，不立即落盘
+- [ ] 明确它们与 discussion channel / waiting-for-human / dormant 的优先级关系
+
+### B2. 配置与 schema
+#### B2.1 `plugin/openclaw.plugin.json`
+- [ ] 增加 `multiMessageStartMarker`
+- [ ] 增加 `multiMessageEndMarker`
+- [ ] 增加 `multiMessagePromptMarker`
+- [ ] 为新增配置设置默认值：`↗️` / `↙️` / `⤵️`
+- [ ] 评估是否需要增加 shuffle 默认配置项
+
+#### B2.2 `plugin/rules.ts` / config 类型
+- [ ] 为 multi-message mode 相关配置补类型定义
+- [ ] 为 shuffle mode 相关 channel state / config 补类型定义
+- [ ] 确保运行时读取配置逻辑可访问新增字段
+
+### B3. `plugin/core/` 新增 channel mode / shuffle state 模块
+- [ ] 新增 channel mode state 模块（如 `plugin/core/channel-modes.ts`）
+- [ ] 定义 channel mode：`normal` / `multi-message`
+- [ ] 提供 `enterMultiMessageMode(channelId)`
+- [ ] 提供 `exitMultiMessageMode(channelId)`
+- [ ] 提供 `isMultiMessageMode(channelId)`
+- [ ] 提供 shuffle 开关状态存取方法
+- [ ] 评估 shuffle state 是否应并入 turn-manager 内部状态
+
+### B4. `plugin/hooks/message-received.ts`
+#### B4.1 Multi-Message Mode 入口/出口
+- [ ] 检测 human 消息中的 multi-message start marker
+- [ ] start marker 命中时，将 channel 切换到 multi-message mode
+- [ ] 检测 human 消息中的 multi-message end marker
+- [ ] end marker 命中时，将 channel 退出 multi-message mode
+- [ ] 避免 moderator 自己的 prompt marker 消息触发 mode 切换
+
+#### B4.2 Multi-Message Mode 中的 moderator 提示
+- [ ] 当 channel 处于 multi-message mode 时，人类每发一条消息触发 moderator prompt marker
+- [ ] prompt marker 文案/内容使用配置项 `multiMessagePromptMarker`
+- [ ] 避免重复触发或回环
+
+#### B4.3 与现有 mention override 的兼容
+- [ ] 明确 multi-message mode 下 human @mention 是否忽略
+- [ ] 避免 multi-message mode 与 mention override 冲突
+
+### B5. `plugin/hooks/before-model-resolve.ts`
+- [ ] 当 channel 处于 multi-message mode 时，强制相关 session 走 `noReplyProvider` / `noReplyModel`
+- [ ] 确保 multi-message mode 的 no-reply 覆盖优先于普通 turn 决策
+- [ ] 确保退出 multi-message mode 后恢复正常 turn 逻辑
+- [ ] 补充必要调试日志
+
+### B6. `plugin/turn-manager.ts`
+#### B6.1 Multi-Message Mode 与 turn pause/resume
+- [ ] 设计 multi-message mode 下 turn manager 的暂停语义
+- [ ] 明确 pause 是通过外层 gating，还是 turn-manager 内显式状态
+- [ ] 退出 multi-message mode 后恢复 turn manager
+- [ ] 退出时确定下一位 speaker 的选择逻辑
+
+#### B6.2 Shuffle Mode
+- [ ] 为每个 channel 增加 `shuffling` 开关状态
+- [ ] 识别“一轮最后一位 speaker 发言完成”的边界点
+- [ ] 在进入下一轮前执行 reshuffle
+- [ ] 保证上一轮最后 speaker 不会成为新一轮第一位
+- [ ] 处理单 Agent 场景
+- [ ] 处理双 Agent 场景
+- [ ] 处理 mention override / waiting-for-human / dormant 状态下的 reshape 边界
+
+### B7. `plugin/commands/dirigent-command.ts`
+- [ ] 新增 `/turn-shuffling` 子命令
+- [ ] 支持：
+  - [ ] `/turn-shuffling`
+  - [ ] `/turn-shuffling on`
+  - [ ] `/turn-shuffling off`
+- [ ] 命令返回当前 channel 的 shuffling 状态
+- [ ] 命令帮助文本补充说明
+
+### B8. `plugin/index.ts`
+- [ ] 注入 channel mode / shuffle state 模块依赖
+- [ ] 将新状态能力传给相关 hooks / turn-manager
+- [ ] 保持初始化关系清晰，避免 mode 逻辑散落
+
+### B9. moderator 消息模板
+- [ ] 定义 multi-message mode 下的 prompt marker 发送规则
+- [ ] 明确是否需要 start / end 的 moderator 确认消息
+- [ ] 定义退出 multi-message mode 后的 scheduling handoff 触发格式
+
+### B10. 测试
+#### B10.1 Multi-Message Mode
+- [ ] 测试 human 发送 start marker 后进入 multi-message mode
+- [ ] 测试 multi-message mode 中 Agent 被 no-reply 覆盖
+- [ ] 测试每条 human 追加消息都触发 prompt marker
+- [ ] 测试 human 发送 end marker 后退出 multi-message mode
+- [ ] 测试退出后 moderator 正确 handoff 给下一位 Agent
+- [ ] 测试 moderator prompt marker 不会触发回环
+
+#### B10.2 Shuffle Mode
+- [ ] 测试 `/turn-shuffling on/off` 生效
+- [ ] 测试 shuffling 关闭时 turn order 不变
+- [ ] 测试 shuffling 开启时每轮结束后会 reshuffle
+- [ ] 测试上一轮最后 speaker 不会成为下一轮第一位
+- [ ] 测试双 Agent 场景行为符合预期
+- [ ] 测试单 Agent 场景不会异常
+
+#### B10.3 兼容性测试
+- [ ] 测试 multi-message mode 与 waiting-for-human 的边界
+- [ ] 测试 multi-message mode 与 mention override 的边界
+- [ ] 测试 shuffle mode 与 dormant 状态的边界
+- [ ] 测试 shuffle mode 与 mention override 的边界
+
+### B11. 文档收尾
+- [ ] 根据最终实现更新 `plans/CHANNEL_MODES_AND_SHUFFLE.md`
+- [ ] 为新增配置项补文档
+- [ ] 为 `/turn-shuffling` 补使用说明
+- [ ] 输出 Multi-Message Mode / Shuffle Mode 的验收清单