调整 855 适配阶段目标为可上线替换

- 将第一阶段目标调整为完成 855 全量 provider 化并具备上线条件
- 明确 855 第一阶段需覆盖当前项目已使用的全部核心能力
- 将 864 接入调整为第二阶段，避免阶段目标过于保守

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

@@ -76,19 +76,20 @@
 - 入口清晰
 - 新人容易顺藤摸瓜读代码
 
-### 3.3 先统一主链路，再扩展高级能力
+### 3.3 第一阶段先完成 855 全量可上线接入
 
-第一阶段只统一机器人运行必需能力：
+考虑到当前项目已经依赖 855/859 风格能力在真实环境运行，第一阶段不能只做“主链路最小闭环”，而要做到：
 
-- 登录
-- 在线状态检查
-- 消息接收
-- 文本发送
-- 用户资料
-- 联系人列表
-- 群信息和群成员
+- 855 provider 能完整替代当前 `Robot + wechat_ipad/client` 的现网接入方式
+- 替换后可以直接上线运行
+- 业务行为、插件调用、后台功能、消息归档链路不发生明显退化
 
-图片、语音、卡片、朋友圈等能力可以后续逐步补齐。
+因此第一阶段目标应定义为：
+
+- 先完成 855 全量接入与运行时收口
+- 再在第二阶段接入 864
+
+这比“先抽最小接口、后补功能”更符合当前项目实际。
 
 ## 4. 推荐架构
 
@@ -211,6 +212,33 @@ Gateway 不负责：
 - `get_chatroom_info()`
 - `get_chatroom_member_list()`
 
+### 6.5 855 第一阶段必须覆盖的现网能力
+
+如果目标是“第一阶段即可上线替换”，那么 855 provider 第一版建议直接覆盖当前项目已在使用的能力，而不只是最小主链路。
+
+至少应包含：
+
+- 登录 / 唤醒登录 / 登录缓存读取
+- 心跳 / 长心跳 / 二次登录恢复
+- 消息同步与消息接收分发
+- 文本消息发送
+- 图片消息发送
+- 语音消息发送
+- 视频消息发送
+- 表情消息发送
+- 链接 / 卡片 / app 消息发送
+- 撤回消息
+- 联系人列表与联系人详情
+- 用户资料与扩展资料
+- 群详情、群公告、群成员列表
+- 群邀请、拉人等当前项目已在用的群管理能力
+- 项目内已经依赖的下载或转发能力
+
+原则：
+
+- 只要当前主程序、插件、后台、调度逻辑已经依赖，就纳入 855 第一阶段
+- 不要求第一阶段补齐“server 支持但项目暂未使用”的全部接口
+
 ## 7. 消息同步策略如何统一
 
 ### 7.1 不统一“消息获取方式”
@@ -319,66 +347,56 @@ wechat_ipad/
 
 ## 10. 推荐推进路线
 
-### 阶段一：先搭接口，不改变现有行为
+### 阶段一：完成 855 全量 provider 化并达到可上线状态
 
 目标：
 
 - 让 `Robot` 依赖 Gateway
-- 但底层行为先只对齐当前 855/859，保证现有能力不受影响
+- 由 `providers/legacy_855/` 完整承接当前 855/859 接入能力
+- 替换后可以直接上线，不依赖旧 `wechat_ipad/client/`
 
 建议步骤：
 
 1. 新增 `gateway.py`
 2. 新增 `provider_base.py`
 3. 新增 `providers/legacy_855/` 目录与 `provider.py`
-4. 把当前 855 所需的登录、消息、联系人能力逐步迁入该目录
-5. 把 `robot.py` 中直接依赖 `WechatAPIClient` 的位置改成依赖 Gateway
+4. 将当前项目已使用的 855 功能按模块迁入该目录：
+   - `login.py`
+   - `message.py`
+   - `contact.py`
+   - `group.py`
+   - `profile.py`
+   - `runtime.py`
+5. 将 `Robot` 中的登录、心跳、长心跳、消息轮询、恢复逻辑迁入 855 provider
+6. 把 `robot.py` 中直接依赖 `WechatAPIClient` 的位置改成依赖 Gateway
+7. 跑通人工回归，确认能替换现有接入链路上线
 
 阶段结果：
 
-- 行为不变
-- 但主链路与具体 server 实现开始解耦
+- 855 provider 完整替代旧接入实现
+- `Robot` 主链路与具体 server 实现解耦
+- 项目可继续按 855 方案稳定上线
 
-### 阶段二：把运行时逻辑从 Robot 挪到 provider
+### 阶段二：实现 864 provider 的最小闭环
 
 目标：
 
-- `Robot` 不再持有 855 专属的心跳 / 轮询 / 掉线恢复细节
+- 在不影响 855 现网运行的前提下，引入 864 provider
 
 建议步骤：
 
-1. 把心跳逻辑迁入 `legacy_855.py`
-2. 把长心跳逻辑迁入 `legacy_855.py`
-3. 把消息轮询逻辑迁入 `legacy_855.py`
-4. `Robot` 只保留统一的消息处理入口，例如 `on_message(...)`
-
-阶段结果：
-
-- 855 的运行模型被收口到 provider 内部
-- 为 864 provider 留出实现空间
-
-### 阶段三：实现 864 provider 的最小闭环
-
-目标：
-
-- 先支持最小可运行能力，而不是一次支持所有接口
-
-建议先实现：
-
-1. 登录状态获取
-2. 基础登录/唤醒逻辑
-3. 消息接收
-4. 文本发送
-5. 获取个人资料
-6. 获取联系人列表
-7. 获取群信息和群成员
+1. 新增 `providers/server_864/`
+2. 先实现登录状态获取与基础登录能力
+3. 实现 864 的消息接收策略
+4. 实现文本发送、联系人、群信息等核心能力
+5. 在 Gateway 中通过 `server_type` 切换 provider
 
 阶段结果：
 
 - 864 可以先跑主链路
 - 高级能力后续再补
 
-### 阶段四：扩展高级能力
+### 阶段三：扩展 864 与后续 provider 的高级能力
 
 后续再逐步统一：
 
@@ -390,13 +408,14 @@ wechat_ipad/
 
 ## 11. 当前最值得优先落地的改造点
 
-如果要把任务压缩成最小可执行版本，建议优先做以下 5 项：
+如果当前目标是“尽快把架构收口，同时保证可以上线”，建议优先做以下 6 项：
 
 1. 新增 `gateway.py`
-2. 抽 `legacy_855.py`
-3. 让 `Robot` 不再直接 new `WechatAPIClient`
-4. 把心跳和消息轮询迁入 `legacy_855.py`
-5. 把 `Robot` 统一成“收到标准消息后处理业务”
+2. 抽 `providers/legacy_855/`
+3. 梳理当前项目实际使用到的 855 接口清单
+4. 把运行时逻辑全部迁入 855 provider
+5. 让 `Robot` 不再直接 new `WechatAPIClient`
+6. 做一套 855 provider 的人工回归清单，确认具备上线条件
 
 ## 12. 不建议当前阶段做的事情