council(draft): Backend - Round 1 plan.md MiniMax 路由补丁设计
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>refactor/vr-ticket-20260416
Council
parent
1ea1b04d31
commit
a865494531
121
plan.md
121
plan.md
|
|
@ -1,43 +1,89 @@
|
|||
# Council Plan — vr-shopxo-plugin Round 2
|
||||
# Council Plan — openclaw-claude-code MiniMax 路由补丁设计
|
||||
|
||||
> Round 2 — 2026-04-14
|
||||
> Branch: council/PM → main
|
||||
> 状态：**Round 2 完成，4 Q 全票通过**
|
||||
> Round 1 — 2026-04-14
|
||||
> Branch: council/Backend → main
|
||||
> 状态：**Planning Round**
|
||||
|
||||
---
|
||||
|
||||
## 4 Q 最终架构结论
|
||||
## Task Summary
|
||||
|
||||
| Q | 结论 | Agent | Vote |
|
||||
|---|---|---|---|
|
||||
| Q1: 座位模板绑定粒度 | 分类绑定（UNIQUE KEY）— 业务合理性 ✅ | Architect/PM/Backend | ✅ NON-BLOCKING |
|
||||
| Q2: spec_base_id_map | 共用 seat_map — 最简方案 | Architect/PM/Backend | ✅ NON-BLOCKING |
|
||||
| Q3: 观演人存储 | vr_tickets 支付后写入 | Architect/PM/Backend | ✅ NON-BLOCKING |
|
||||
| Q4: spec 绑定 | $vr- 前缀隔离 — 已确认 | Architect/PM/Backend | ✅ NON-BLOCKING |
|
||||
为 `@enderfga/openclaw-claude-code` 插件设计可配置的 MiniMax 路由方案，解决硬编码 `provider: 'anthropic'` 导致路由失效的问题。
|
||||
|
||||
**核心约束**：
|
||||
1. 配置优先（不硬编码）
|
||||
2. 向后兼容（默认走 Anthropic 官方）
|
||||
3. 可还原（插件更新不被覆盖）
|
||||
4. 显眼易懂（有注释说明）
|
||||
|
||||
---
|
||||
|
||||
## Voting
|
||||
## 4 Q Discussion (Round 1)
|
||||
|
||||
| Agent | Vote | 说明 |
|
||||
|---|---|---|
|
||||
| Architect | YES (4/4 Q NON-BLOCKING) | 4个问题均为NON-BLOCKING |
|
||||
| PM | YES (4/4 Q NON-BLOCKING) | 实施复杂度 2.5d，低风险 |
|
||||
| Backend | YES (4/4 Q NON-BLOCKING) | Hook 可行性已确认 |
|
||||
### 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']` 读取
|
||||
- **回滚**：删除配置项即可还原默认行为
|
||||
|
||||
---
|
||||
|
||||
## Claim Status
|
||||
## Task Checklist
|
||||
|
||||
| Task | Owner | Status |
|
||||
|---|---|---|
|
||||
| A1: Q1 架构评审 | council/Architect | `[Done]` |
|
||||
| A2: Q2 架构评审 | council/Architect | `[Done]` |
|
||||
| A3: Q3 架构评审 | council/Architect | `[Done]` |
|
||||
| A4: Q4 架构评审 | council/Architect | `[Done]` |
|
||||
| P1: PM 评审 Q1-Q4 | council/PM | `[Done]` |
|
||||
| B1: Backend 评审 Q1-Q4 | council/Backend | `[Done]` |
|
||||
| C1: 综合结论 | council/Architect | `[Done]` |
|
||||
- [ ] 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，投票
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -45,10 +91,23 @@
|
|||
|
||||
| Phase | 内容 | 状态 |
|
||||
|---|---|---|
|
||||
| **Draft** | 完成 4 Q 评审 + 待确认事项清单 | ✅ Done |
|
||||
| **Review** | 交叉评审，输出 `reviews/` 文件 | ✅ Done |
|
||||
| **Finalize** | 合并到 main，投票 | ✅ Done |
|
||||
| **Draft** | 4 Q 独立回答 + 等待同步 | 🔄 In Progress |
|
||||
| **Review** | 交叉评审，输出 `reviews/` 文件 | ⏳ Pending |
|
||||
| **Finalize** | 合并到 main，投票 | ⏳ Pending |
|
||||
|
||||
---
|
||||
|
||||
**[CONSENSUS: YES]** — 4 Q 全票通过，架构决策完成
|
||||
## 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 完成，进入执行轮
|
||||
Loading…
Reference in New Issue