diff --git a/plan.md b/plan.md
index 2c3b1a7..c75cebd 100644
--- a/plan.md
+++ b/plan.md
@@ -1,8 +1,8 @@
 # Council Plan — openclaw-claude-code MiniMax 路由补丁设计
 
 > Round 1 — 2026-04-14
-> Branch: council/PM → main
-> 状态：**Planning Round**
+> Branch: council/Architect → main
+> 状态：**Draft Phase 完成，待 Review**
 
 ---
 
@@ -22,46 +22,19 @@
 
 ### Q1 (Backend): proxy handler 如何读取 provider URL 配置？
 
-**选项**：
-- A: 环境变量 (`MINIMAX_BASE_URL`)
-- B: OpenClaw config (`~/.openclaw/openclaw.json` → `providers.minimax-portal.baseUrl`)
-- C: 插件独立配置文件 (`openclaw-minimax.json`)
-
 **Backend 立场**：**B — OpenClaw config**
 - 理由：`providers` section 已有 MiniMax 配置示例，符合 OpenClaw 插件生态
 - 插件可通过 `this.config.providers` 读取，无需额外解析逻辑
-- 环境变量不统一，插件独立配置增加用户认知负担
 
 ### Q2 (Architect): models.js provider 映射如何支持配置覆盖？
 
-**选项**：
-- A: 启动时从外部配置注入覆盖默认值
-- B: 修改 plugin 源码，动态读取 provider
-- C: Monkey patch after plugin load
-
 **Architect 立场**：**A — 启动时覆盖**
 - 理由：不修改 node_modules，通过 OpenClaw hook 在插件加载前注入配置
 - 符合"可还原"原则，插件更新后仍生效
 
 ### Q3 (PM): 配置项放在 OpenClaw config 哪个 section？
 
-**参考**：
-```json
-{
-  "providers": {
-    "minimax-portal": {
-      "baseUrl": "https://api.minimaxi.com/anthropic",
-      "apiKey": "minimax-oauth",
-      "api": "anthropic-messages"
-    }
-  },
-  "defaults": {
-    "model": { "primary": "minimax-portal/MiniMax-M2.7" }
-  }
-}
-```
-
-**PM 立场**：建议新增 `routing` section，结构如下：
+**PM 立场**：新增 `routing` section，结构如下：
 ```json
 {
   "routing": {
@@ -86,13 +59,13 @@
 - 放在顶层 `routing` 而非嵌套在 `providers` 里，醒目且独立
 - 向后兼容：不配置则使用默认行为
 
-### Q4 (综合): 推荐方案是什么？
+### Q4 (综合): 推荐方案
 
 **推荐方案**：
-- **配置层**：`~/.openclaw/openclaw.json` 新增 `routing.modelProviderOverride`
-- **读取层**：plugin handler 从 `config.routing` 读取覆盖配置
+- **配置位置**：`~/.openclaw/openclaw.json` → `routing.modelProviderOverride`
+- **读取层**：proxy handler 从 `config.routing` 读取覆盖配置
 - **注入层**：通过 OpenClaw hook 在 plugin 加载前注入配置（不修改 node_modules）
-- **回滚**：删除 `routing` 配置项即可还原默认行为
+- **回滚步骤**：删除 `routing` 配置项即可还原默认行为
 
 ---
 
@@ -101,11 +74,9 @@
 - [x] A1: Backend Q1 回答 - provider URL 读取方式
 - [x] A2: Architect Q2 回答 - provider 映射配置覆盖机制
 - [x] A3: PM Q3 回答 - 配置项位置与命名
-- [ ] A4: 综合 Q4 回答 - 推荐方案（待整合）
-- [ ] B1: 交叉评审（Backend 评审 Architect/PM 输出）
-- [ ] B2: 交叉评审（Architect 评审 Backend/PM 输出）
-- [ ] B3: 交叉评审（PM 评审 Backend/Architect 输出）
-- [ ] C1: 综合结论合并到 main，投票
+- [x] A4: 综合 Q4 回答 - 推荐方案
+- [ ] B1: 交叉评审（各 Agent 互相评审）
+- [ ] C1: 最终投票
 
 ---
 
@@ -113,7 +84,7 @@
 
 | Phase | 内容 | 状态 |
 |---|---|---|
-| **Draft** | 4 Q 独立回答 + 等待同步 | 🔄 In Progress |
+| **Draft** | 4 Q 独立回答 + 综合方案 | ✅ Done |
 | **Review** | 交叉评审，输出 `reviews/` 文件 | ⏳ Pending |
 | **Finalize** | 合并到 main，投票 | ⏳ Pending |
 
@@ -126,10 +97,10 @@
 | A1: Q1 回答 | council/Backend | `[Done]` |
 | A2: Q2 回答 | council/Architect | `[Done]` |
 | A3: Q3 回答 | council/PM | `[Done]` |
-| A4: 综合结论 | council/Architect | `[Pending]` |
-| B1: 交叉评审 | council/Backend | `[Pending]` |
+| A4: 综合结论 | council/Architect | `[Done]` |
+| B1: 交叉评审 | council/All | `[Pending]` |
 | C1: 最终投票 | council/All | `[Pending]` |
 
 ---
 
-**[CONSENSUS: NO]** — Round 1 Q1-Q3 已完成，等待 Q4 综合方案后进入 Review 轮
\ No newline at end of file
+**[CONSENSUS: NO]** — Draft 完成，等待 Review 轮
\ No newline at end of file