council(draft): SecurityEngineer - create plan.md for vr-shopxo-plugin security review
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>refactor/vr-ticket-20260416
parent
852623fc9f
commit
b135b772ef
127
plan.md
127
plan.md
|
|
@ -1,82 +1,26 @@
|
|||
# Council Plan — openclaw-claude-code MiniMax 路由补丁设计
|
||||
# Council Plan — vr-shopxo-plugin 安全审议
|
||||
|
||||
> Round 1 — 2026-04-14
|
||||
> Branch: council/Architect → main
|
||||
> 状态:**Draft Phase 完成,待 Review**
|
||||
> Round 1 — 2026-04-15
|
||||
> Branch: council/SecurityEngineer → main
|
||||
> 状态:**Draft Phase**
|
||||
|
||||
---
|
||||
|
||||
## 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 配置?
|
||||
|
||||
**Backend 立场**:**B — OpenClaw config**
|
||||
- 理由:`providers` section 已有 MiniMax 配置示例,符合 OpenClaw 插件生态
|
||||
- 插件可通过 `this.config.providers` 读取,无需额外解析逻辑
|
||||
|
||||
### Q2 (Architect): models.js provider 映射如何支持配置覆盖?
|
||||
|
||||
**Architect 立场**:**A — 启动时覆盖**
|
||||
- 理由:不修改 node_modules,通过 OpenClaw hook 在插件加载前注入配置
|
||||
- 符合"可还原"原则,插件更新后仍生效
|
||||
|
||||
### Q3 (PM): 配置项放在 OpenClaw config 哪个 section?
|
||||
|
||||
**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`
|
||||
- **读取层**:proxy handler 从 `config.routing` 读取覆盖配置
|
||||
- **注入层**:通过 OpenClaw hook 在 plugin 加载前注入配置(不修改 node_modules)
|
||||
- **回滚步骤**:删除 `routing` 配置项即可还原默认行为
|
||||
对 vr-shopxo-plugin 票务插件进行完整代码安全审议,输出独立评审报告(≥500字),列出所有发现的问题(严重/中等/轻微/建议),给出具体修复建议。**仅评论不改代码,变更提交本地 worktree。**
|
||||
|
||||
---
|
||||
|
||||
## Task Checklist
|
||||
|
||||
- [x] A1: Backend Q1 回答 - provider URL 读取方式
|
||||
- [x] A2: Architect Q2 回答 - provider 映射配置覆盖机制
|
||||
- [x] A3: PM Q3 回答 - 配置项位置与命名
|
||||
- [x] A4: 综合 Q4 回答 - 推荐方案
|
||||
- [ ] B1: 交叉评审(各 Agent 互相评审)
|
||||
- [ ] C1: 最终投票
|
||||
- [ ] 1. 插件架构审计(EventListener.php / plugin.json)
|
||||
- [ ] 2. 票务核心审计(TicketService.php / BaseService.php)
|
||||
- [ ] 3. 前端票务详情页审计(ticket_detail.html)
|
||||
- [ ] 4. 数据库 Schema 审计(如有 migrations)
|
||||
- [ ] 5. 安全性综合审计(SQL注入/XSS/重放攻击/QR伪造)
|
||||
- [ ] 6. 输出评审报告到 reviews/code-review-SecurityEngineer.md
|
||||
- [ ] 7. 提交 plan.md 到 main
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -84,8 +28,8 @@
|
|||
|
||||
| Phase | 内容 | 状态 |
|
||||
|---|---|---|
|
||||
| **Draft** | 4 Q 独立回答 + 综合方案 | ✅ Done |
|
||||
| **Review** | 交叉评审,输出 `reviews/` 文件 | ⏳ Pending |
|
||||
| **Draft** | 各模块代码审计 + 报告撰写 | ⏳ Pending |
|
||||
| **Review** | 评审其他成员报告(如有) | ⏳ Pending |
|
||||
| **Finalize** | 合并到 main,投票 | ⏳ Pending |
|
||||
|
||||
---
|
||||
|
|
@ -94,13 +38,42 @@
|
|||
|
||||
| Task | Owner | Status |
|
||||
|---|---|---|
|
||||
| A1: Q1 回答 | council/Backend | `[Done]` |
|
||||
| A2: Q2 回答 | council/Architect | `[Done]` |
|
||||
| A3: Q3 回答 | council/PM | `[Done]` |
|
||||
| A4: 综合结论 | council/Architect | `[Done]` |
|
||||
| B1: 交叉评审 | council/All | `[Pending]` |
|
||||
| C1: 最终投票 | council/All | `[Pending]` |
|
||||
| 插件架构审计 | council/SecurityEngineer | `[Claimed]` |
|
||||
| 票务核心审计 | council/SecurityEngineer | `[Claimed]` |
|
||||
| 前端票务页审计 | council/SecurityEngineer | `[Claimed]` |
|
||||
| 数据库Schema审计 | council/SecurityEngineer | `[Claimed]` |
|
||||
| 安全综合审计 | council/SecurityEngineer | `[Claimed]` |
|
||||
| 输出评审报告 | council/SecurityEngineer | `[Claimed]` |
|
||||
|
||||
---
|
||||
|
||||
**[CONSENSUS: NO]** — Draft 完成,等待 Review 轮
|
||||
## 审计关注点清单
|
||||
|
||||
### 插件架构
|
||||
- [ ] 生命周期钩子(Install/Uninstall/Enable/Disable)完整性
|
||||
- [ ] 权限/菜单注册安全性
|
||||
- [ ] 升级迁移策略
|
||||
|
||||
### 票务核心
|
||||
- [ ] onOrderPaid() 并发安全(库存锁定/原子操作)
|
||||
- [ ] verifyTicket() 核销鉴权(状态机完整性)
|
||||
- [ ] AES QR 加密(密钥管理/IV/模式选择)
|
||||
- [ ] 订单状态流转安全性
|
||||
|
||||
### 前端安全
|
||||
- [ ] XSS 输出转义
|
||||
- [ ] 表单 CSRF 防护
|
||||
- [ ] 敏感信息暴露
|
||||
|
||||
### 数据库
|
||||
- [ ] SQL 拼接风险点
|
||||
- [ ] 参数化查询使用情况
|
||||
- [ ] 索引覆盖完整性
|
||||
|
||||
### 支付安全
|
||||
- [ ] 支付回调重放攻击(nonce/一次性token)
|
||||
- [ ] 签名验证完整性
|
||||
|
||||
---
|
||||
|
||||
**[CONSENSUS: NO]** — Round 1 完成,进入执行轮
|
||||
|
|
|
|||
Loading…
Reference in New Issue