@jsonstudio/rcc 0.89.1803 → 0.89.1959

package/docs/providers/deepseek-web-provider-design.md

@@ -0,0 +1,192 @@
+# DeepSeek Web 原生标准 Provider 设计（对标 antigravity）
+
+本文定义 DeepSeek Web 在 RouteCodex 中的标准接入方案：
+- 目标是 **内建标准 provider**（不是 sidecar / 反向代理进程依赖）
+- 保持单执行路径：`HTTP server -> llmswitch-core Hub Pipeline -> Provider V2 -> upstream`
+- 严格分层：Provider 做 transport；工具语义在 llmswitch-core compat
+
+---
+
+## 1. 设计目标
+
+1. 将 DeepSeek Web 登录/会话/PoW/completion 纳入 Provider V2。
+2. 保证工具调用在标准响应面可消费：优先结构化 `tool_calls`，文本意图可选 fallback。
+3. 错误与健康状态统一进入 `providerErrorCenter` / `errorHandlingCenter`。
+4. 保证后续可观测、可回放、可灰度（same-shape + control replay）。
+
+## 2. 非目标
+
+1. 不把 `deepseek2api` 作为 routecodex 上游依赖。
+2. 不在 Provider 层做工具路由、语义修复、参数猜测。
+3. 不在 Host/Provider 里复制 compat 的 fallback 逻辑。
+
+## 3. 分层与职责边界
+
+### 3.1 RouteCodex Provider（传输层）
+
+建议模块：
+- `src/providers/core/runtime/deepseek-http-provider.ts`
+- `src/providers/auth/deepseek-account-auth.ts`
+- `src/providers/core/runtime/deepseek-session-pow.ts`
+
+职责：
+- auth（tokenFile 读取/热更新、header 注入）
+- session（会话创建/复用）
+- PoW（challenge 获取、求解、超时控制）
+- HTTP 发送（stream/non-stream）、重试矩阵、上游错误映射
+- 失败统一 `emitProviderError(...)`，不静默 fallback
+
+禁止：
+- 工具调用提取/补全
+- route/tool_choice 决策
+- payload 语义清洗（messages/tool args 语义）
+
+### 3.2 llmswitch-core Compat（语义适配层）
+
+建议模块：
+- `sharedmodule/llmswitch-core/src/conversion/compat/profiles/chat-deepseek-web.json`
+- `sharedmodule/llmswitch-core/src/conversion/compat/actions/deepseek-web-request.ts`
+- `sharedmodule/llmswitch-core/src/conversion/compat/actions/deepseek-web-response.ts`
+
+职责：
+- 请求侧：OpenAI/Responses 形状 -> DeepSeek Web 合同字段
+- 响应侧：DeepSeek Web 形状 -> 标准 assistant / SSE / tool_calls
+- tool_call_id 标准化（无 id 时生成稳定 id）
+- 文本工具意图 fallback（受配置开关/strict 约束）
+
+禁止：
+- HTTP 请求发送
+- 认证与 token 管理
+- provider transport 重试策略
+
+## 4. 配置草案（示意）
+
+```jsonc
+{
+  "virtualrouter": {
+    "providers": {
+      "deepseek-web": {
+        "id": "deepseek-web",
+        "enabled": true,
+        "type": "openai",
+        "providerModule": "deepseek-http-provider",
+        "compatibilityProfile": "chat:deepseek-web",
+        "baseURL": "https://chat.deepseek.com",
+        "auth": {
+          "type": "deepseek-account",
+          "entries": [
+            {
+              "alias": "1",
+              "type": "deepseek-account",
+              "tokenFile": "~/.routecodex/auth/deepseek-account-1.json"
+            }
+          ]
+        },
+        "deepseek": {
+          "strictToolRequired": true,
+          "textToolFallback": true,
+          "powTimeoutMs": 15000,
+          "sessionReuseTtlMs": 1800000
+        }
+      }
+    }
+  }
+}
+```
+
+说明：
+- `type` 继续使用标准 `openai`，家族差异通过 `providerModule` + `compatibilityProfile` 表达。
+- 凭据通过 `tokenFile` 引用（`deepseek-account-*.json`），支持多账号轮转，不把明文回写到配置。
+
+## 5. 工具调用状态机（Compat 单一实现）
+
+### 5.1 状态定义
+
+1. `native_tool_calls`
+   - 上游已返回结构化工具调用
+   - compat 做字段映射、id 补齐、参数 JSON 合法性校验
+2. `text_tool_calls`
+   - 上游仅返回文本工具意图
+   - compat 解析并生成标准 `tool_calls`
+3. `no_tool_calls`
+   - 无法识别工具调用
+
+### 5.2 严格策略
+
+- 若 `tool_choice=required` 且最终状态为 `no_tool_calls`：
+  - compat 抛显式错误（fail-fast）
+  - provider 不兜底为普通文本成功
+
+### 5.3 单一真相源
+
+- fallback 解析器仅在 `deepseek-web-response.ts` 维护。
+- Host / Provider 不复制解析规则，避免双实现漂移。
+
+## 6. 错误分类与重试策略（Provider）
+
+### 6.1 不重试（直接 fail-fast）
+
+- 认证失败（401/403）
+- 合同失败（4xx，如必填字段/格式错误）
+- compat 显式错误（如 strict tool required）
+
+### 6.2 可重试（有限次）
+
+- 网络抖动 / 超时
+- 5xx 上游故障
+- PoW 挑战服务短暂失败（带总超时）
+
+### 6.3 统一上报字段
+
+每次错误事件应包含：
+- `requestId`
+- `providerId` / `providerKey` / `providerProtocol`
+- `model` / `route`
+- `statusCode` / `upstreamCode`
+- `processingTime`
+
+## 7. 可观测与回放
+
+### 7.1 请求级追踪
+
+- `requestId` 全链路透传
+- 记录 provider runtime key 与 session key（不暴露敏感值）
+- tool 归一化日志：`source=native|fallback`、`parse_ok`、`schema_ok`
+
+### 7.2 回放要求
+
+每次兼容行为修改后必须提供：
+1. 目标 provider same-shape replay（1 例）
+2. 非目标 provider control replay（1 例）
+
+## 8. 里程碑
+
+### M1（设计冻结）
+
+- 冻结配置字段、错误码、观测字段、strict/fallback 开关定义
+- 产物：本文档 + `routecodex-132` 及子任务
+- M1 合同落盘（当前仓）：
+  - `src/providers/core/contracts/deepseek-provider-contract.ts`
+  - `src/providers/core/api/provider-config.ts`
+  - `src/providers/core/api/provider-types.ts`
+  - `src/providers/profile/provider-profile-loader.ts`
+
+### M2（Provider Skeleton）
+
+- 落地 provider/auth/session/pow runtime
+- 打通 non-stream / stream
+- 接入 provider error 上报
+
+### M3（Compat + Tool Calling）
+
+- 落地 `chat:deepseek-web` profile 与 request/response actions
+- 完成工具调用三态与 strict 策略
+- 增加回归脚本并完成 replay 证据
+
+## 9. 验证命令（按双仓顺序）
+
+1. `sharedmodule/llmswitch-core`: `npm run build`
+2. `routecodex`: `npm run build:dev`
+3. `routecodex`: `npm run install:global`
+4. provider 定向脚本：`scripts/provider-deepseek-*`（M2/M3 新增）
+5. replay：same-shape + control provider

package/docs/routing-instructions.md

@@ -164,7 +164,7 @@ RouteCodex 支持通过用户消息中的特殊指令 `<**...**>` 来动态控
 **语法：**
 
 - 启用 / 更新自动续写：
-  - `<**stopMessage:"继续"**>` → 默认最多自动续写 1 次；
+  - `<**stopMessage:"继续"**>` → 默认最多自动续写 10 次；
   - `<**stopMessage:"继续",3**>` → 最多自动续写 3 次；
   - `<**stopMessage:<file://stopMessage/message1.md>**>` → 读取 `~/.routecodex/stopMessage/message1.md` 作为 stopMessage 文案（设置时读取并缓存到内存）；
 - 清理 stopMessage 状态：
@@ -177,6 +177,9 @@ RouteCodex 支持通过用户消息中的特殊指令 `<**...**>` 来动态控
   - `stopMessageText`：自动补发的用户消息内容；
   - `stopMessageMaxRepeats`：允许自动续写的最大次数（>=1）；
   - `stopMessageUsed`：已执行次数（从 0 开始计数）；
+- stopMessage 阶段策略的 BD 状态判定：默认优先尝试真实命令查询（`bd --no-db list/ready --json`），命令失败时回退到历史消息启发式；
+  - 可用 `ROUTECODEX_STOPMESSAGE_BD_MODE=auto|runtime|heuristic` 控制（默认 `auto`）；
+  - 可用 `ROUTECODEX_STOPMESSAGE_BD_TIMEOUT_MS`、`ROUTECODEX_STOPMESSAGE_BD_CACHE_TTL_MS`、`ROUTECODEX_STOPMESSAGE_BD_WORKDIR` 调整运行参数；
 - 当满足以下条件时，servertool 会自动发起后续请求：
   - 当前响应的 `choices[0].finish_reason === "stop"`；
   - 当前轮没有工具调用（`tool_calls` 为空）；

package/docs/stop-message-auto.md

@@ -17,8 +17,8 @@
 
 - 启用 / 更新：`<**stopMessage:"继续",3**>`
   - `"继续"`：自动补发的用户消息内容，内部如需引号，用 `\"` 转义。
-  - `3`：本会话最多自动续写 3 轮；省略时默认 `1`。
-- 仅设置文案（默认 1 次）：`<**stopMessage:"继续"**>` → `maxRepeats = 1`。
+  - `3`：本会话最多自动续写 3 轮；省略时默认 `10`。
+- 仅设置文案（默认 10 次）：`<**stopMessage:"继续"**>` → `maxRepeats = 10`。
 - 清理：`<**stopMessage:clear**>` → 清空本会话 stopMessage 状态。
 
 > 注意：这些标签仅用于路由与 servertool，不应出现在发给 provider 的文本中。
@@ -32,12 +32,13 @@
 - `stopMessageUsed: number` — 已执行的自动续写次数，初始为 `0`。
 - `stopMessageUpdatedAt?: number` — 最近一次解析 `<**stopMessage:"..."**>` 指令的时间戳。
 - `stopMessageLastUsedAt?: number` — 最近一次 servertool 自动补发 stopMessage 的时间戳。
+- BD 状态判断默认走真实命令（`bd --no-db list/ready --json`），失败时回退到消息启发式；可通过 `ROUTECODEX_STOPMESSAGE_BD_MODE=auto|runtime|heuristic` 配置。
 
 行为：
 
 - 解析到 `stopMessage:"...",N`：
   - `stopMessageText = text`
-  - `stopMessageMaxRepeats = N || 1`
+  - `stopMessageMaxRepeats = N || 10`
   - `stopMessageUsed = 0`
   - `stopMessageUpdatedAt = Date.now()`，`stopMessageLastUsedAt = undefined`
 - 解析到 `stopMessage:clear`：

package/docs/v2-architecture/PROVIDER-V2-CHANGESET-RELEASE-CHECKLIST.md

@@ -0,0 +1,80 @@
+# Provider V2 变更集发布检查清单
+
+- Date: 2026-02-09
+- Source branch: `main`
+- Scope: 最近 4 个提交（架构草案 + iflow provider 对齐 + validate 进程清理）
+
+## 1) Changeset 映射
+
+| Commit | 主题 | Wave/任务对应 | 风险级别 | 备注 |
+|---|---|---|---|---|
+| `167400e0b` | Provider V2 架构草案全集（113.1~113.5） | 113 规划阶段 | Low | 文档与 `.beads/issues.jsonl` |
+| `8ea3ab778` | 文档约束增强（M10/M13/M16 + 验证门槛） | 113.5 审阅收敛 | Low | 文档与 `.beads/issues.jsonl` |
+| `ecf3dbe70` | iFlow CLI 头/签名对齐 | Wave-1（iflow）预实现 | High | 运行时代码变更 + 单测 |
+| `3857b25e6` | validate 启动/清理避免孤儿进程 | 运维/CLI 稳定性 | Medium | 运行时代码变更 |
+
+## 2) 推荐 cherry-pick 顺序
+
+## A. 生产热修（仅功能）
+
+适用于先上修复，不带规划文档：
+
+1. `ecf3dbe70`
+2. `3857b25e6`
+
+## B. 完整同步（功能 + 规划）
+
+适用于将规划与执行基线一并对齐：
+
+1. `167400e0b`
+2. `8ea3ab778`
+3. `ecf3dbe70`
+4. `3857b25e6`
+
+> 说明：两个 docs 提交都改了 `.beads/issues.jsonl`，建议按上述顺序连续 pick，避免 BD 冲突。
+
+## 3) Mandatory Gate（功能提交必须）
+
+对包含 `ecf3dbe70` / `3857b25e6` 的发布，至少执行：
+
+1. 目标测试
+   - `npm run jest:run -- --runTestsByPath tests/providers/core/runtime/http-transport-provider.headers.test.ts`
+   - `npm run test:cli`
+2. 类型与构建
+   - `npx tsc --noEmit`
+   - `npm run build:dev`
+   - `npm run install:global`
+
+## 4) Replay Gate（Wave-1 iflow）
+
+## Same-shape（iflow）
+
+```bash
+npm run replay:codex-sample -- \
+  --sample <iflow-sample-client-request.json> \
+  --label wave-1-iflow-same-shape
+```
+
+## Control（非受影响 provider）
+
+```bash
+npm run replay:codex-sample -- \
+  --sample <control-sample-client-request.json> \
+  --label wave-1-iflow-control
+```
+
+## 5) 风险与回滚点
+
+- `ecf3dbe70`（High）
+  - 关注：`x-iflow-signature` 计算一致性、`session-id/conversation-id` 映射。
+  - 回滚：直接回退该 commit；不影响其它文档提交。
+- `3857b25e6`（Medium）
+  - 关注：validate 自启 server 后停止逻辑、异常分支 cleanup。
+  - 回滚：直接回退该 commit；不影响 provider 主链路。
+
+## 6) 发布后观察建议
+
+- 观察 iflow 400/435 比例是否下降。
+- 观察 validate 后是否仍残留 `routecodex`/`rcc start` 进程。
+- 若异常，按单 commit 回滚并保留 same-shape/control 证据。
+

package/docs/v2-architecture/PROVIDER-V2-LAYERING-ADR-DRAFT.md

@@ -0,0 +1,225 @@
+# Provider V2 分层重构 ADR（Draft）
+
+- Status: Draft
+- Date: 2026-02-09
+- Owner: routecodex-113.1
+- Scope: 仅架构与迁移草案，不包含运行时代码改动
+
+## 1. 背景与问题
+
+当前 Provider V2 已实现“协议优先 + 家族表达”的主线，但仍存在以下问题：
+
+1. 通用传输层（`HttpTransportProvider`）混入了多品牌特判，Kernel 职责边界被侵蚀。
+2. Protocol 与 Family 差异部分耦合，导致新增供应商时改动面偏大。
+3. 兼容行为分散在 profile/header/body/metadata 多点，回归面难以预测。
+
+基于当前代码可观察到的典型信号（作为迁移切入点）：
+
+- Kernel 中存在 iFlow/Antigravity/Codex UA 分支逻辑与签名行为。
+- `service-profiles.ts` 既承载基础配置，也承载品牌特定 header 与行为暗约束。
+- Factory 在协议映射、module 选择、brand 归一间承担了超出“构造器”范畴的语义。
+
+## 2. 决策（Proposed Decision）
+
+采用三层分离并固定执行次序：
+
+`Kernel -> Protocol -> Family Profile`
+
+并将 Protocol 固定为四大线：
+
+1. OpenAI Chat
+2. OpenAI Responses
+3. Anthropic Messages
+4. Gemini（Gemini CLI 作为同协议变体长期保留）
+
+同时固定配置驱动解析规则：
+
+- 配置显式字段 `providerProtocol` + `providerId` + `compatibilityProfile` 共同决定：
+  - 加载哪个 Protocol Adapter
+  - 选择哪个 Family 特殊分支（Profile）
+  - 启用哪个 Compat Profile
+- `providerId` / `providerFamily` 的单一事实来源为“配置文件 + provider 目录映射”。
+- runtime metadata 仅承载已解析结果，不再进行二次覆盖决策。
+
+## 3. 分层职责定义
+
+### 3.1 Kernel（基础坑位）
+
+Kernel 只保留“与业务语义无关”的纯通用能力：
+
+- 认证装配（apikey/oauth/tokenfile/cookie）
+- HTTP 执行（重试、超时、连接层错误标准化）
+- 观测与审计（snapshot、provider error 上报）
+- 运行时 metadata 传递与最小标准化
+- Hook 调度框架（仅调度，不承载品牌策略）
+
+Kernel 禁止：
+
+- 品牌识别分支（例如 `iflow` / `qwen` / `glm`）
+- 特定上游签名算法、header 语义修复
+- 模型级行为修复与策略 fallback
+
+### 3.2 Protocol（四大协议层）
+
+Protocol 层只负责 wire contract：
+
+- 路径与方法约束（例如 `/chat/completions`、`/responses`、`/v1/messages`）
+- 请求体基础 shape（消息字段、stream 字段、tools 字段）
+- 响应体解析与流式边界
+- 与 Hub Pipeline 的协议接口一致性
+
+Protocol 禁止：
+
+- 品牌业务规则
+- OAuth/风控策略特判
+
+### 3.3 Family Profile（供应商品牌层）
+
+Family Profile 承载“同协议下不同品牌”的差异策略：
+
+- header policy（默认头、优先级、互斥/清理）
+- auth policy（oauthProviderId 解析、token 形态扩展）
+- request policy（字段注入、字段裁剪、模型映射）
+- response policy（错误 envelope 归一、供应商业务码映射）
+- optional signing policy（例如 iFlow 的签名规则）
+
+Profile 必须是声明式 + 小型策略函数，不允许变成第二个 transport kernel。
+
+## 4. 建议抽象（接口草案）
+
+> 下面是抽象方向草案，用于统一未来实现，不代表本次已改代码。
+
+### 4.1 Kernel SPI
+
+```ts
+interface ProviderKernel {
+  send(input: KernelRequest): Promise<KernelResponse>;
+  buildContext(runtime: ProviderRuntimeProfile): ProviderContext;
+  reportError(error: unknown, context: ProviderContext): ProviderErrorAugmented;
+}
+```
+
+### 4.2 Protocol Adapter
+
+```ts
+interface ProtocolAdapter {
+  protocol: 'openai-chat' | 'openai-responses' | 'anthropic-messages' | 'gemini';
+  resolveEndpoint(input: ProtocolInput): string;
+  buildBody(input: ProtocolInput): Record<string, unknown>;
+  parseResponse(raw: unknown, context: ProviderContext): Record<string, unknown>;
+}
+```
+
+### 4.3 Family Profile
+
+```ts
+interface ProviderFamilyProfile {
+  family: string;
+  applyRequestPolicy(input: RequestPolicyInput): RequestPolicyOutput;
+  applyHeaderPolicy(input: HeaderPolicyInput): HeaderPolicyOutput;
+  applyResponsePolicy(input: ResponsePolicyInput): ResponsePolicyOutput;
+  classifyUpstreamError?(error: unknown, context: ProviderContext): ProviderErrorAugmented;
+}
+```
+
+### 4.4 组合执行顺序
+
+1. Kernel 构建上下文
+2. Protocol 生成基础 endpoint/body
+3. Family Profile 应用增量策略
+4. Kernel 发送请求并标准化错误
+5. Protocol 解析响应
+6. Family Profile 后处理（可选）
+
+### 4.5 配置驱动解析顺序（已定稿）
+
+1. 从配置读取 `providerProtocol`，绑定唯一 Protocol Adapter。
+2. 从配置读取 `providerId`（并通过 provider 目录映射到 `providerFamily`），绑定 Family Profile。
+3. 从配置读取 `compatibilityProfile`，绑定 Compat Profile。
+4. 若缺字段或映射不存在，直接 fail-fast（禁止运行时猜测或静默降级）。
+
+## 5. 目录与模块建议（目标态）
+
+```text
+src/providers/core/
+  kernel/
+    provider-kernel.ts
+    http-executor.ts
+    auth-runtime.ts
+    error-normalizer.ts
+  protocols/
+    openai-chat/
+    openai-responses/
+    anthropic-messages/
+    gemini/
+  profiles/
+    families/
+      iflow/
+      qwen/
+      glm/
+      antigravity/
+      openai/
+      anthropic/
+      gemini/
+    registry.ts
+  runtime/
+    provider-composer.ts
+    provider-factory.ts
+```
+
+## 6. 当前代码到目标层的迁移原则
+
+1. 先抽“边界”再迁“逻辑”：先把入口与调用点稳定，再移动策略实现。
+2. 保持 fail-fast：任何未知 family/profile 不自动兜底修复。
+3. 单一事实来源：同一策略只能在一层实现一次。
+4. 一次一个 family 的最小切片迁移，配套 replay 证据。
+
+## 7. 分阶段计划（与 BD 子任务对应）
+
+### Phase A（routecodex-113.1）
+
+- 冻结分层定义、接口草案、风险边界（本 ADR）
+
+### Phase B（routecodex-113.2）
+
+- 完成“现有特判 -> Kernel/Protocol/Profile”迁移矩阵
+
+### Phase C（routecodex-113.3）
+
+- 确定 Profile API 与 Registry 解析顺序
+
+### Phase D（routecodex-113.4）
+
+- 输出迁移批次和回滚机制（按 family 批次）
+
+### Phase E（routecodex-113.5）
+
+- 固化验证矩阵：same-shape replay + control replay + build/install gate
+
+## 8. 关键风险与控制
+
+1. **风险：Profile 膨胀为新内核**
+   - 控制：Profile API 仅允许策略函数，禁止直接发 HTTP。
+2. **风险：Protocol 与 Profile 双重改写冲突**
+   - 控制：定义字段所有权，冲突即 fail-fast。
+3. **风险：迁移期行为漂移**
+   - 控制：每个切片必须提供 before/after replay 对照。
+
+## 9. 非目标（本轮明确不做）
+
+- 不在本 ADR 阶段做运行时代码迁移。
+- 不改 Hub Pipeline 的工具与路由职责边界。
+- 不引入新协议类型（先稳定四协议）。
+
+## 10. 已确认决策（2026-02-09）
+
+1. Gemini CLI 长期作为 Gemini 协议变体。
+2. `providerId` / `providerFamily` 单一事实来源来自配置文件与 provider 目录映射。
+3. 配置显式字段 `providerProtocol + providerId + compatibilityProfile` 决定 protocol/profile/compat 加载。
+
+## 11. 待后续细化（routecodex-113.2/113.3）
+
+1. provider 目录映射表的最终落地位置与维护方式。
+2. compatibilityProfile 在 host/provider/core 的边界校验策略（仅透传 vs 预校验）。
+3. Profile API 的最小能力集（首批是否仅 header/auth/request）。
+

package/docs/v2-architecture/PROVIDER-V2-MIGRATION-MATRIX-DRAFT.md

@@ -0,0 +1,88 @@
+# Provider V2 特判迁移矩阵（Draft）
+
+- Status: Draft
+- Date: 2026-02-09
+- Owner: routecodex-113.2
+- Strategy: 先实现，不连线；最后按批次逐个连线
+
+## 1. 迁移方法（按你确认的策略）
+
+本矩阵遵循固定执行法：
+
+1. 先把 Kernel / Protocol / Profile 的新实现落地为“未接线模块”（dark implementation）。
+2. 在不改变现网执行路径前提下，补齐单测、样本回放、same-shape 对比。
+3. 最后按 provider family 逐个接线，单批次可回滚。
+
+## 2. 当前特判清单与归属矩阵
+
+| ID | 当前位置（文件:行） | 当前行为 | 目标层 | 迁移动作 | 风险级别 | 连线阶段 |
+|---|---|---|---|---|---|---|
+| M01 | `src/providers/core/runtime/http-transport-provider.ts:780` | `iflowWebSearch` 特判 endpoint `/chat/retrieve` | Family Profile（iflow） | 从 Kernel 抽离为 `iflow.requestPolicy.resolveEndpoint()` | 高 | Wave-1（iflow） |
+| M02 | `src/providers/core/runtime/http-transport-provider.ts:804` | `iflowWebSearch` 特判 body 直透 `request.data` | Family Profile（iflow） | 抽离为 `iflow.requestPolicy.buildBody()` | 高 | Wave-1（iflow） |
+| M03 | `src/providers/core/runtime/iflow-http-provider.ts:40` | iFlow 子类重复实现 webSearch endpoint/body 特判 | Family Profile（iflow） | 去重，保留单一事实实现（profile） | 高 | Wave-1（iflow） |
+| M04 | `src/providers/core/runtime/http-transport-provider.ts:992` | iFlow UA 优先级反转（service UA > inbound UA） | Family Profile（iflow） | 抽离为 `iflow.headerPolicy.resolveUserAgentPriority()` | 高 | Wave-1（iflow） |
+| M05 | `src/providers/core/runtime/http-transport-provider.ts:1212` | iFlow `session-id/conversation-id` 规范化 + 签名头 | Family Profile（iflow） | 抽离为 `iflow.signingPolicy.applyHeaders()` | 高 | Wave-1（iflow） |
+| M06 | `src/providers/core/runtime/http-request-executor.ts:499` | iFlow HTTP200 + status=439 token expired 特判抛错 | Family Profile（iflow） | 抽离为 `iflow.responsePolicy.classifyBusinessEnvelope()` | 高 | Wave-1（iflow） |
+| M07 | `src/providers/core/runtime/http-request-executor.ts:531` | iFlow business envelope `error_code/msg` -> HTTP_400 | Family Profile（iflow） | 抽离为 `iflow.errorPolicy.toProviderError()` | 高 | Wave-1（iflow） |
+| M08 | `src/providers/core/runtime/http-transport-provider.ts:888` | Gemini-family 注入 `X-Goog-Api-Client` / `Client-Metadata` | Family Profile（gemini, qwen） | 下沉到对应 profile header policy | 中 | Wave-2（gemini/qwen） |
+| M09 | `src/providers/core/runtime/http-transport-provider.ts:1048` | Antigravity 删除 `session_id/conversation_id` | Family Profile（antigravity） | 抽离为 `antigravity.headerPolicy.cleanup()` | 中 | Wave-2（antigravity） |
+| M10 | `src/providers/core/runtime/http-request-executor.ts:403` | Antigravity 多 base fallback 条件（429/400/context-error） | Family Profile（antigravity）+ Kernel retry SPI | 先抽 Kernel Retry SPI（实现重试），profile 仅提供 retry 条件策略（不实现重试流程） | 高 | Wave-2（antigravity） |
+| M11 | `src/providers/core/runtime/gemini-http-provider.ts:70` | OpenAI 消息转 Gemini `contents/systemInstruction` | Protocol（gemini） | 保留在 Gemini Protocol Adapter，统一入口 | 中 | Wave-3（protocol） |
+| M12 | `src/providers/core/runtime/gemini-http-provider.ts:176` | Antigravity 签名类错误包装为 response | Family Profile（antigravity） | 抽离为 profile response policy | 中 | Wave-2（antigravity） |
+| M13 | `src/providers/core/runtime/provider-factory.ts:388` | `gemini-cli-oauth` 决定实例化 GeminiCLI provider | Protocol + Profile 选择器 | factory 仅装配（不解析/不实例化 profile）；选择逻辑迁到 registry resolver（只解析不实例化） | 中 | Wave-3（factory clean） |
+| M14 | `src/providers/core/runtime/base-provider.ts:582` | gemini-cli/antigravity 429 bucket 粒度按 model | Family Profile（antigravity/gemini-cli） | 抽离为 rate-limit profile policy | 中 | Wave-2 |
+| M15 | `src/providers/core/config/service-profiles.ts:123` | glm/qwen/iflow/gemini-cli 默认 header/base/model 混在基础 profile | Profile 目录（family defaults） | 拆成 protocol-base + family-default overlay | 中 | Wave-3 |
+| M16 | `src/providers/core/utils/provider-type-utils.ts:14` | LEGACY family->type 映射与协议映射耦合 | Registry（provider 目录映射） | 单独迁入 provider-directory map；归一完成即冻结，runtime 禁止二次推断 | 中 | Wave-3 |
+| M17 | `src/providers/core/config/provider-oauth-configs.ts:26` | OAuth 配置按 providerId 硬编码（qwen/iflow/gemini-cli/antigravity） | Family Profile（auth policy） | 抽为 profile-auth config，kernel 仅执行 flow | 中 | Wave-2 |
+| M18 | `src/providers/core/runtime/http-transport-provider.ts:1290` | `isIflow/isAntigravity` 运行时识别散落在 transport | Registry + Profile resolver | 由配置 `providerId` + provider目录映射统一识别 | 高 | Wave-1/2 |
+
+## 3. 哪些应该留在 Kernel（不迁）
+
+以下能力保留在 Kernel，禁止品牌化：
+
+- 认证 provider 生命周期装配（auth provider 初始化与 headers 合并）。
+- HTTP 重试/超时/请求快照写入。
+- Provider error 上报与标准字段补齐。
+- runtime metadata 的只读透传。
+
+## 4. 高风险项与依赖
+
+### 高风险项
+
+1. iFlow 业务错误 envelope（M06/M07）
+   - 风险：迁移不完整会导致 200 响应落到后续阶段才报 malformed。
+2. iFlow 签名头（M05）
+   - 风险：签名 payload 任何字段顺序变化都会直接 400。
+3. Antigravity fallback（M10）
+   - 风险：错误重试策略漂移会放大失败率。
+4. iflowWebSearch 双实现（M01/M02/M03）
+   - 风险：双源逻辑导致行为不一致，必须先去重再连线。
+
+### 前置依赖
+
+- 需要先完成 `routecodex-113.3` 的 Profile API 与 Registry 解析顺序。
+- 需要在 `routecodex-113.5` 固化 same-shape/control replay 模板后再做批量连线。
+
+## 5. “先实现不连线”落地清单
+
+### 实现阶段（不接线）
+
+1. 新建 `profiles/families/iflow/*`，实现 endpoint/body/header/signature/error policy。
+2. 新建 `profiles/families/antigravity/*`，实现 fallback/header/error policy。
+3. 新建 `protocols/gemini/*` 适配器，承接消息 shape 转换。
+4. 新建 `profiles/registry.ts` 与 provider-directory 映射解析器。
+
+> 以上阶段只做“可调用实现 + 单测 + 回放对比”，不替换现有执行路径。
+
+### 连线阶段（逐批次）
+
+1. Wave-1 仅接 iFlow（M01~M07, M18-iflow）。
+2. Wave-2 接 antigravity/gemini-cli（M09/M10/M12/M14/M17）。
+3. Wave-3 做 factory/service-profile/provider-type-utils 清理（M11/M13/M15/M16）。
+
+## 6. 验收证据（113.2 完成定义）
+
+- 必须提供每个 Mxx 的“旧位点 + 新归属 + 迁移批次 + 风险”映射。
+- 必须明确哪些保留在 Kernel，防止过度下沉。
+- 必须给出分批连线顺序与回滚单位。
+