# 当前行为与缺口

## 当前实现

- `requestCrossConversationReply()` 是 `sendCrossConversationMessage()` 的 `expectReply`
  包装，因此公开工具合并不需要新增通信机制。
- 正式 MCP 与 Codex App 备用 dynamic tools 各自复制 description 和 inputSchema。
- `server.js` 已经导入正式 `CCWEB_MCP_TOOLS`，可以直接按白名单派生备用定义，
  无需增加新的契约模块。
- pending reply 已持久化 requestId、来源/目标、hopCount 和 replyText，可向后兼容地新增
  `originalRequest`。
- 来源忙碌时 ready reply 会保留，空闲后由 flush 逻辑投递；该行为必须保持。

## 已观察失败

- 模型在明确要求“完成后汇报/最终验收”的任务上调用了单向发送工具。
- 同一模型此前使用过自动回传工具，说明仅靠两个工具名称仍不能稳定表达选择规则。
- 某次自动回传正文只是“完成定位、准备修改”，目标后来继续执行；来源续跑需要明确检查完整性。

## 设计结论

- 工具选择必须从“选两个近似工具”改为“调用一个工具时填写必填枚举”。
- 新公开契约不提供默认值；内部兼容层可宽容旧调用。
- 目标与来源的运行提示都必须携带通信模式和关联上下文。
- 提示优化无法完全替代任务完成协议；本任务不扩大到生命周期重构。