diff --git a/plan.md b/plan.md
index df9d560..2c3b1a7 100644
--- a/plan.md
+++ b/plan.md
@@ -2,41 +2,50 @@
 
 > Round 1 — 2026-04-14
 > Branch: council/PM → main
-> 状态：**规划中**
+> 状态：**Planning Round**
 
 ---
 
-## 任务背景
+## Task Summary
 
-**问题**：插件 `@enderfga/openclaw-claude-code` 的 proxy 层将 Claude Code 请求路由到各 AI Provider，目前所有 `sonnet`/`opus`/`haiku` 模型都被硬编码映射到 `provider: 'anthropic'`（走真实 Anthropic API），但用户环境是 MiniMax 的 Anthropic 兼容端点，导致路由失效。
+为 `@enderfga/openclaw-claude-code` 插件设计可配置的 MiniMax 路由方案，解决硬编码 `provider: 'anthropic'` 导致路由失效的问题。
 
-**目标**：设计一个可配置、符合 OpenClaw 插件最佳实践的方案。
+**核心约束**：
+1. 配置优先（不硬编码）
+2. 向后兼容（默认走 Anthropic 官方）
+3. 可还原（插件更新不被覆盖）
+4. 显眼易懂（有注释说明）
 
 ---
 
-## 4 Q 任务分配
+## 4 Q Discussion (Round 1)
 
-| Q | 任务描述 | Owner | 预期输出 |
-|---|---|---|---|
-| Q1 | 插件 proxy handler 如何优雅地读取 provider URL 配置？ | council/Backend | 配置读取方案（环境变量 / OpenClaw config / 插件独立配置） |
-| Q2 | models.js 的 provider 映射如何支持配置覆盖？ | council/Architect | 架构设计（外部配置注入机制） |
-| Q3 | 配置项应该放在 OpenClaw 配置的哪个 section？命名规范？ | council/PM | 配置结构建议（providers/defaults/ext 位置） |
-| Q4 | 综合推荐方案（配置文件结构、修改文件列表、回滚步骤、注释） | council/Architect | 最终方案文档 |
+### 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` 读取，无需额外解析逻辑
+- 环境变量不统一，插件独立配置增加用户认知负担
 
-1. **配置优先**：从 OpenClaw 配置或环境变量读取，不硬编码
-2. **向后兼容**：不配置默认走原有逻辑（Anthropic 官方）
-3. **可还原**：通过 OpenClaw 配置层注入，不改 node_modules
-4. **显眼易懂**：配置项有注释说明
+### Q2 (Architect): models.js provider 映射如何支持配置覆盖？
 
----
+**选项**：
+- A: 启动时从外部配置注入覆盖默认值
+- B: 修改 plugin 源码，动态读取 provider
+- C: Monkey patch after plugin load
 
-## 关键参考
+**Architect 立场**：**A — 启动时覆盖**
+- 理由：不修改 node_modules，通过 OpenClaw hook 在插件加载前注入配置
+- 符合"可还原"原则，插件更新后仍生效
 
-OpenClaw 配置示例（`~/.openclaw/openclaw.json`）：
+### Q3 (PM): 配置项放在 OpenClaw config 哪个 section？
+
+**参考**：
 ```json
 {
   "providers": {
@@ -52,9 +61,61 @@ OpenClaw 配置示例（`~/.openclaw/openclaw.json`）：
 }
 ```
 
-插件文件：
-- proxy handler: `node_modules/@enderfga/openclaw-claude-code/dist/src/proxy/handler.js`
-- 模型注册表: `node_modules/@enderfga/openclaw-claude-code/dist/src/models.js`
+**PM 立场**：建议新增 `routing` section，结构如下：
+```json
+{
+  "routing": {
+    // 路由覆盖配置
+    "modelProviderOverride": {
+      // 模型名 → provider 映射
+      "claude-sonnet-4-20250514": "minimax-portal",
+      "claude-opus-4-6": "minimax-portal",
+      "claude-haiku-4-20250514": "minimax-portal"
+    },
+    // 可选：baseUrl 覆盖（如果 provider 配置的 baseUrl 需要临时覆盖）
+    "baseUrlOverride": {
+      "minimax-portal": "https://custom-api.minimaxi.com/v1"
+    }
+  }
+}
+```
+
+**理由**：
+- `routing` 语义清晰，表示"路由规则"
+- `modelProviderOverride` 显式声明哪些模型走哪个 provider
+- 放在顶层 `routing` 而非嵌套在 `providers` 里，醒目且独立
+- 向后兼容：不配置则使用默认行为
+
+### Q4 (综合): 推荐方案是什么？
+
+**推荐方案**：
+- **配置层**：`~/.openclaw/openclaw.json` 新增 `routing.modelProviderOverride`
+- **读取层**：plugin handler 从 `config.routing` 读取覆盖配置
+- **注入层**：通过 OpenClaw hook 在 plugin 加载前注入配置（不修改 node_modules）
+- **回滚**：删除 `routing` 配置项即可还原默认行为
+
+---
+
+## Task Checklist
+
+- [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，投票
+
+---
+
+## Phase Breakdown
+
+| Phase | 内容 | 状态 |
+|---|---|---|
+| **Draft** | 4 Q 独立回答 + 等待同步 | 🔄 In Progress |
+| **Review** | 交叉评审，输出 `reviews/` 文件 | ⏳ Pending |
+| **Finalize** | 合并到 main，投票 | ⏳ Pending |
 
 ---
 
@@ -62,21 +123,13 @@ OpenClaw 配置示例（`~/.openclaw/openclaw.json`）：
 
 | Task | Owner | Status |
 |---|---|---|
-| Q1: 配置读取方案 | council/Backend | `[Claimed: council/Backend]` |
-| Q2: 架构设计 | council/Architect | `[Claimed: council/Architect]` |
-| Q3: 配置结构 | council/PM | `[Claimed: council/PM]` |
-| Q4: 综合方案 | council/Architect | `[Pending]` |
+| A1: Q1 回答 | council/Backend | `[Done]` |
+| A2: Q2 回答 | council/Architect | `[Done]` |
+| A3: Q3 回答 | council/PM | `[Done]` |
+| A4: 综合结论 | council/Architect | `[Pending]` |
+| B1: 交叉评审 | council/Backend | `[Pending]` |
+| C1: 最终投票 | council/All | `[Pending]` |
 
 ---
 
-## Phase Breakdown
-
-| Phase | 内容 | 目标时间 |
-|---|---|---|
-| **Draft** (本轮) | Backend/Architect/PM 分别输出 Q1-Q3 讨论结论 | Round 1 |
-| **Review** | 交叉评审，Architect 整合 Q4 综合方案 | Round 2 |
-| **Finalize** | 合并到 main，投票 | Round 2 |
-
----
-
-**[CONSENSUS: NO]** — Round 1 规划完成，等待 Backend/Architect/PM 执行 Q1-Q3
\ No newline at end of file
+**[CONSENSUS: NO]** — Round 1 Q1-Q3 已完成，等待 Q4 综合方案后进入 Review 轮
\ No newline at end of file