diff --git a/plan.md b/plan.md index bdb406b..a7bcd8f 100644 --- a/plan.md +++ b/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,再投票。 + +---