删除历史client目录并同步适配路线图

docs/wechat_ipad多版本Server适配路线图.md

@@ -24,11 +24,12 @@
 - 已将 855 的登录、历史消息拉取、心跳、长心跳、消息轮询、掉线二次登录恢复迁入 `legacy_855` provider
 - 已将 [robot.py](/d:/learn/abot/robot.py:1) 精简为“注册回调 + 业务处理”，不再直接维护 855 的运行时主循环
 - 已补上 `Legacy855WechatClient` 的显式初始化入口，避免 provider 多继承构造链不稳定
+- 已删除历史 `wechat_ipad/client/` 目录，避免后续误回退到旧实现
 
 当前尚未完成的关键项：
 
 - 855 provider 仍需完成一轮“当前项目实际依赖接口”的可上线回归验证
-- 855 provider 仍需继续梳理“项目真实使用到的接口覆盖面”，确认是否还有遗漏的旧能力残留在历史目录
+- 855 provider 仍需继续梳理“项目真实使用到的接口覆盖面”，确认是否还有遗漏能力未纳入 provider 目录
 - 864 provider 尚未开始接入，当前统一接口仍主要围绕 855 第一阶段目标进行验证
 
 因此，当前状态可以定义为：
@@ -46,11 +47,11 @@
 - 历史版本曾直接依赖 `wechat_ipad/config.toml`，当前已开始切向 `config.yaml + .env`
 - `Robot` 的实例化入口虽然已切到 `WechatGateway`，但配置读取与业务初始化仍在主程序中
 - 855 的运行时职责已经迁入 provider，但 864 尚未接入验证，统一抽象仍需继续收敛
-- `wechat_ipad/client/*.py` 仍作为历史目录存在，接口路径、请求体、返回结构都面向旧 server 编写
+- 公共 `models/` 仍在服务主链路，而多版本协议实现已正式收口到 `providers/*/`
 
 这导致一个结果：
 
-- 如果继续在历史目录或 `Robot` 主链路里堆版本判断，后续 server 版本变化时改动面仍会再次放大
+- 如果继续在 `Robot` 主链路里堆版本判断，后续 server 版本变化时改动面仍会再次放大
 
 ### 2.2 855 / 864 的核心差异
 
@@ -106,7 +107,7 @@
 
 考虑到当前项目已经依赖 855/859 风格能力在真实环境运行，第一阶段不能只做“主链路最小闭环”，而要做到：
 
-- 855 provider 能完整替代当前 `Robot + wechat_ipad/client` 的现网接入方式
+- 855 provider 能完整替代当前 `Robot + 旧接入实现` 的现网接入方式
 - 替换后可以直接上线运行
 - 业务行为、插件调用、后台功能、消息归档链路不发生明显退化
 
@@ -167,9 +168,9 @@ Gateway 不负责：
 
 说明：
 
-- 不再要求 855 继续复用现有 `wechat_ipad/client/`
+- 不再保留旧 `wechat_ipad/client/` 作为正式实现入口
 - 更推荐每个 provider 自带独立目录，内部自行管理登录、消息、联系人、群信息等协议实现
-- 这样可以把不同 server 的协议差异彻底隔离，避免为了兼容新版本继续污染旧 client
+- 这样可以把不同 server 的协议差异彻底隔离，避免为了兼容新版本继续污染历史实现
 
 ## 5. 为什么要把“运行模型”抽出来
 
@@ -379,7 +380,7 @@ wechat_ipad/
 
 - 让 `Robot` 依赖 Gateway
 - 由 `providers/legacy_855/` 完整承接当前 855/859 接入能力
-- 替换后可以直接上线，不依赖旧 `wechat_ipad/client/`
+- 替换后可以直接上线，不依赖历史 `client` 目录
 
 建议步骤：
 
@@ -450,7 +451,7 @@ wechat_ipad/
 1. 不建议一次抽象所有微信功能
 2. 不建议为每个 API endpoint 单独建类
 3. 不建议让 `Robot` 持续保留 `if server_type == ...` 的运行逻辑分叉
-4. 不建议强行让 864 复用当前 `client/*.py`
+4. 不建议让 864 回退复用已经移除的旧 client 结构
 5. 不建议现在就引入太多类型层、事件总线或复杂工厂模式
 
 ## 13. 结论