council(draft): Backend - Round 1 plan.md MiniMax 路由补丁设计

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

plan.md

@@ -0,0 +1,113 @@
+# Council Plan — openclaw-claude-code MiniMax 路由补丁设计
+
+> Round 1 — 2026-04-14
+> Branch: council/Backend → main
+> 状态：**Planning Round**
+
+---
+
+## Task Summary
+
+为 `@enderfga/openclaw-claude-code` 插件设计可配置的 MiniMax 路由方案，解决硬编码 `provider: 'anthropic'` 导致路由失效的问题。
+
+**核心约束**：
+1. 配置优先（不硬编码）
+2. 向后兼容（默认走 Anthropic 官方）
+3. 可还原（插件更新不被覆盖）
+4. 显眼易懂（有注释说明）
+
+---
+
+## 4 Q Discussion (Round 1)
+
+### 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 立场**：`providers` + `defaults.model` 已有结构，建议：
+- 新增 `providers.openclaw.overrideModels` 数组，指定哪些 model 走哪个 provider
+- 命名：`routing.override` 或 `plugin.minimaxRouting`
+
+### Q4 (综合): 推荐方案是什么？
+
+**推荐方案**：
+- **配置层**：通过 OpenClaw hook 在 plugin 加载前注入 `providerOverrides` 配置
+- **读取层**：plugin handler 从 `config.routing` 或 `config.plugins['@enderfga/openclaw-claude-code']` 读取
+- **回滚**：删除配置项即可还原默认行为
+
+---
+
+## Task Checklist
+
+- [ ] A1: Backend Q1 回答 - provider URL 读取方式
+- [ ] A2: Architect Q2 回答 - provider 映射配置覆盖机制
+- [ ] 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 |
+
+---
+
+## Claim Status
+
+| Task | Owner | Status |
+|---|---|---|
+| A1: Q1 回答 | council/Backend | `[Claimed: council/Backend]` |
+| A2: Q2 回答 | council/Architect | `[ ]` |
+| A3: Q3 回答 | council/PM | `[ ]` |
+| A4: 综合结论 | council/Architect | `[ ]` |
+| B1: 交叉评审 | council/Backend | `[ ]` |
+| C1: 最终投票 | council/All | `[ ]` |
+
+---
+
+**[CONSENSUS: NO]** — 等待 Round 1 完成，进入执行轮