feat: overhaul task board and cross-conversation workflows

.trellis/tasks/08-11-unify-ccweb-message-reply/research/current-behavior.md

@@ -0,0 +1,25 @@
+# 当前行为与缺口
+
+## 当前实现
+
+- `requestCrossConversationReply()` 是 `sendCrossConversationMessage()` 的 `expectReply`
+  包装，因此公开工具合并不需要新增通信机制。
+- 正式 MCP 与 Codex App 备用 dynamic tools 各自复制 description 和 inputSchema。
+- `server.js` 已经导入正式 `CCWEB_MCP_TOOLS`，可以直接按白名单派生备用定义，
+  无需增加新的契约模块。
+- pending reply 已持久化 requestId、来源/目标、hopCount 和 replyText，可向后兼容地新增
+  `originalRequest`。
+- 来源忙碌时 ready reply 会保留，空闲后由 flush 逻辑投递；该行为必须保持。
+
+## 已观察失败
+
+- 模型在明确要求“完成后汇报/最终验收”的任务上调用了单向发送工具。
+- 同一模型此前使用过自动回传工具，说明仅靠两个工具名称仍不能稳定表达选择规则。
+- 某次自动回传正文只是“完成定位、准备修改”，目标后来继续执行；来源续跑需要明确检查完整性。
+
+## 设计结论
+
+- 工具选择必须从“选两个近似工具”改为“调用一个工具时填写必填枚举”。
+- 新公开契约不提供默认值；内部兼容层可宽容旧调用。
+- 目标与来源的运行提示都必须携带通信模式和关联上下文。
+- 提示优化无法完全替代任务完成协议；本任务不扩大到生命周期重构。