# 技术设计：统一 ccweb 消息回传接口

## 数据流

```text
MCP 工具 Schema
    ↓ replyMode
内部 dispatcher
    ↓ one_way / expectReply
sendCrossConversationMessage
    ├─ one_way → 目标运行，结果留在目标
    └─ return_and_continue
         ↓ pending(requestId + originalRequest)
       目标完成 → ready → 来源空闲
         ↓
       写回展示消息 + 带关联信息的隐藏续跑消息
```

## 建议模块边界

- `lib/ccweb-mcp-server.js`
  - 继续作为正式工具定义的单一来源。
  - 导出 reply mode 常量；send schema 复用这些常量。
  - 不再公开 request-reply definition。
- `server.js`
  - dynamic tools 从已导入的 `CCWEB_MCP_TOOLS` 按白名单筛选并添加 namespace。
  - dispatcher 保留旧别名。
  - 发送、pending、目标提示和来源续跑接入 reply mode。

## 兼容边界

- 新 Schema：`replyMode` 必填。
- 旧 `send_message`：内部缺省归一为 `one_way`。
- 旧 `request_reply`：内部固定归一为 `return_and_continue`。
- 旧 MCP/dynamic 客户端：隐藏 allowlist 接受 `ccweb_request_reply`，但工具列表不公开。
- 旧 pending 数据：`originalRequest` 缺失时来源提示显示明确占位，不失败。

## 测试策略

先补失败断言，再实现：

1. 共享定义：send schema 必填 replyMode、enum 正确、旧工具不公开。
2. `one_way`：目标提示标注不自动回传，不创建 requestId。
3. `return_and_continue`：创建 requestId，目标提示禁止手工回传，来源收到结果并自动续跑。
4. 来源续跑：包含 requestId、目标信息、原始请求、完整性判断指令。
5. 兼容别名：内部 `ccweb_request_reply` 仍建立回传。
6. 隐藏入口：正式 MCP tools/call 与旧 dynamic call 接受旧名，tools/list 不包含旧名。
7. 双路径一致：正式 MCP 和 dynamic tools 的 send definition 深度一致（namespace 除外）。