council(draft): ticket-reviewer - create plan.md with task breakdown
Reviewed docs/03_VERIFICATION_SYSTEM.md and ARCHITECTURE.md: - ⚠️ API paths inconsistent (admin vs C-end) - ⚠️ AES IV design needs clarification - ❌ Anti-overselling mechanism missing (blocking issue) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>council/backend-reviewer
Council
parent
bb71681cab
commit
23464e725a
118
plan.md
118
plan.md
|
|
@ -1,59 +1,105 @@
|
|||
# PM Reviewer — plan.md
|
||||
# Council Plan — vr-shopxo-plugin
|
||||
|
||||
> 角色：项目经理（pm-reviewer）
|
||||
> 负责文档：docs/04_IMPLEMENTATION_ROADMAP.md、docs/DEPLOYMENT.md、docs/05_AI_PARTICIPATION.md
|
||||
> Round 1 Planning — 2026-04-14
|
||||
> Branch: council/ticket-reviewer → main
|
||||
|
||||
---
|
||||
|
||||
## 一、文档评审任务清单
|
||||
## Document Review (Ticket Reviewer — docs/03_VERIFICATION_SYSTEM.md + ARCHITECTURE.md)
|
||||
|
||||
- [ ] 评审 docs/04_IMPLEMENTATION_ROADMAP.md（Agent 分工与开发计划）
|
||||
- [ ] 评审 docs/DEPLOYMENT.md（Docker 部署方案）
|
||||
- [ ] 评审 docs/05_AI_PARTICIPATION.md（AI 参与可行性分析）
|
||||
- [ ] 撰写 `reviews/pm-reviewer-on-docs.md`（结构化评审报告）
|
||||
- [ ] 投票：是否可以开始编码
|
||||
### docs/03_VERIFICATION_SYSTEM.md — 核销系统设计
|
||||
|
||||
| 维度 | 评级 | 说明 |
|
||||
|---|---|---|
|
||||
| 系统概述 & 模式 | ✅ 通过 | 三种核销模式清晰，粒度选择明确（按座位） |
|
||||
| QR 生成设计 | ✅ 通过 | JSON 结构完整，支付回调触发时机正确 |
|
||||
| 加密方案 | ⚠️ 需补充 | AES-256-CBC 推荐，但 IV=MD5(ticket_code) 做法需明确说明（不是随机 IV，有理论风险但实际可接受） |
|
||||
| 数据模型 | ✅ 通过 | vr_tickets / vr_verifications / vr_verifiers 三表设计合理 |
|
||||
| B 端核销页 | ✅ 通过 | Vue 代码完整，fork 自 realstore/check.vue 路径正确 |
|
||||
| 后端 API | ⚠️ 需补充 | `VerifyTicket()` PHP 实现完整，但 API 路径不统一（文档写 `admin/vrticket/verify`，Vue 写 `ticket/verify`），需对齐 |
|
||||
| C 端票夹 | ✅ 通过 | 钩子注入点、页面内容设计清晰 |
|
||||
| 防超卖机制 | ❌ 缺失 | 核心缺陷：核销逻辑未涉及库存扣减/锁座机制，QR 生成和核销都依赖"支付成功"时间点，但无并发控制说明 |
|
||||
| 部署方案 | ✅ 通过 | B 端/个人主体小程序限制已明确 |
|
||||
|
||||
**结论**：整体清晰完整，但 **防超卖机制缺失** 是架构性缺陷，需在实现前补充。
|
||||
|
||||
### ARCHITECTURE.md — 架构文档
|
||||
|
||||
| 维度 | 评级 | 说明 |
|
||||
|---|---|---|
|
||||
| 核心发现 | ✅ 通过 | 7 项技术发现均基于实测，有文件路径和代码片段 |
|
||||
| 整体架构图 | ✅ 通过 | PHP 后端 + uniapp 前端结构清晰 |
|
||||
| 数据模型 | ✅ 通过 | ShopXO 复用表 + 插件独立表对照清晰 |
|
||||
| 目录结构 | ✅ 通过 | 插件目录设计规范 |
|
||||
| 购票流程 | ✅ 通过 | 完整流程链路清晰 |
|
||||
| 对比表 | ✅ 通过 | 与 vr-ticket-mp 对比有价值 |
|
||||
| 技术栈 | ✅ 通过 | 栈选择合理 |
|
||||
| 文档链接 | ✅ 通过 | 官方文档索引完整 |
|
||||
|
||||
**结论**：✅ 通过，架构文档质量高。
|
||||
|
||||
---
|
||||
|
||||
## 二、Phase 分解
|
||||
## Issue Summary (ticket-reviewer)
|
||||
|
||||
### Phase 1 — Draft（当前轮次）
|
||||
- 读取并分析上述三份文档
|
||||
- 识别问题并撰写结构化评审报告
|
||||
- 将评审报告提交到 main
|
||||
1. **[⚠️ API 路径不一致]** `docs/03_VERIFICATION_SYSTEM.md`
|
||||
- Vue 代码调用：`ticket/verify`（`app.globalData.get_request_url('verify', 'ticket', 'vrticket')`）
|
||||
- PHP 后端定义：`admin/vrticket/verify`
|
||||
- 需统一，建议全部使用 `vrticket/verify` 并区分 admin/非admin 端点
|
||||
|
||||
### Phase 2 — Review（下一轮）
|
||||
- 等待其他 Agent 的评审结果
|
||||
- 整合反馈，更新评审结论
|
||||
- 投票是否可以开始编码
|
||||
2. **[⚠️ AES IV 说明不足]** `docs/03_VERIFICATION_SYSTEM.md`
|
||||
- IV = `substr(md5($ticket_code), 0, 16)` — 不是随机 IV
|
||||
- 实际安全影响有限（QR 内容本身含唯一 UUID），但需加注释说明设计意图
|
||||
|
||||
### Phase 3 — Finalize
|
||||
- 汇总最终投票结果并更新 plan.md
|
||||
- 若全员同意，则标记 `[CONSENSUS: YES]`
|
||||
3. **[❌ 防超卖机制缺失]** `docs/03_VERIFICATION_SYSTEM.md`
|
||||
- 核销逻辑假设票已生成，但未说明：
|
||||
- 场次库存如何扣减（支付成功时？）
|
||||
- 座位选择与库存锁定的时序
|
||||
- 并发购买同一座位时的处理
|
||||
- 建议补充：座位锁定机制（Redis 锁 / 数据库锁）和库存原子扣减流程
|
||||
|
||||
---
|
||||
|
||||
## 三、依赖关系
|
||||
## Task Checklist
|
||||
|
||||
- 本任务不依赖其他 Agent，**独立完成**
|
||||
- 等待 arch-reviewer、backend-reviewer、ticket-reviewer 的评审结果
|
||||
- [ ] **T1**: 补充防超卖机制章节到 `docs/03_VERIFICATION_SYSTEM.md`
|
||||
- 座位锁定时序（用户选座 → 锁定 → 支付 → 生成 QR）
|
||||
- 并发控制（数据库唯一索引 + 事务）
|
||||
- 锁定超时释放机制
|
||||
|
||||
- [ ] **T2**: 统一 API 路径（admin 端 vs C 端）
|
||||
- C 端核销 API：`/?s=api/vrticket/verify`
|
||||
- Admin 端核销 API：`/?s=admin/vrticket/verify`
|
||||
- 核销员权限验证逻辑
|
||||
|
||||
- [ ] **T3**: 补充 AES IV 设计说明注释
|
||||
|
||||
- [ ] **T4**: 生成票务核销系统完整设计文档（含防超卖、API 规范、数据库约束）
|
||||
|
||||
- [ ] **T5**: 审查其他 agent 的输出（跨评审）
|
||||
|
||||
---
|
||||
|
||||
## 四、评审标准
|
||||
## Phase Breakdown
|
||||
|
||||
| 维度 | 权重 |
|
||||
|---|---|
|
||||
| 清晰度（文档是否自解释） | 25% |
|
||||
| 完整性（覆盖所有关键路径） | 25% |
|
||||
| 可执行性（Agent 能否据此直接开发） | 25% |
|
||||
| AI 边界（是否准确划分 AI/人工分工） | 25% |
|
||||
| Phase | 内容 | 负责人 |
|
||||
|---|---|---|
|
||||
| **Draft** | T1 + T2 + T3：补充文档内容 | `[Claimed: council/ticket-reviewer]` |
|
||||
| **Review** | T5：跨评审 arch/backend/pm 输出 | `[Pending]` |
|
||||
| **Finalize** | 合并到 main，投票 | `[Pending]` |
|
||||
|
||||
---
|
||||
|
||||
## 五、Claim 状态
|
||||
## Dependencies
|
||||
|
||||
- [ ] 评审 docs/04_IMPLEMENTATION_ROADMAP.md — `[Claimed: council/pm-reviewer]`
|
||||
- [ ] 评审 docs/DEPLOYMENT.md — `[Claimed: council/pm-reviewer]`
|
||||
- [ ] 评审 docs/05_AI_PARTICIPATION.md — `[Claimed: council/pm-reviewer]`
|
||||
- [ ] 撰写 reviews/pm-reviewer-on-docs.md — `[Claimed: council/pm-reviewer]`
|
||||
- T1（防超卖）依赖：backend-reviewer 的 SQL 迁移方案（库存扣减 SQL）
|
||||
- T2（API 路径）依赖：pm-reviewer 的路由规范
|
||||
- T4 需等 T1/T2/T3 完成
|
||||
|
||||
---
|
||||
|
||||
## Voting
|
||||
|
||||
**[CONSENSUS: NO]** — 文档整体质量高，但防超卖机制缺失是编码前的阻断性问题。Round 2 优先补充 T1，再投票。
|
||||
|
||||
---
|
||||
|
|
|
|||
Loading…
Reference in New Issue