3.8 KiB
3.8 KiB
vr-shopxo-plugin 架构决策评议 — plan.md
版本:v1.0 | 制定日期:2026-04-15 | Agent:council/BackendArchitect 关联:Issue #9
任务背景
Phase 0/1/2 已完成基础骨架,暴露了一个 P0 架构问题:VR 演唱会票务商品中 ShopXO SPEC 与 SKU 的绑定方案。
已知事实:
- ShopXO
goods_spec_base(SKU表)当前为空,商品 112 的is_exist_many_spec=0 spec_base_id_map中的 ID(如 1001/1002/1003)在 DB 中不存在- ShopXO 防超卖机制(原子扣 inventory)完全未启用
两种架构方向:
- 方案 A:每个座位 = 一个 SKU(stock=1),ShopXO 原生防超卖
- 方案 B:每个 Zone = 一个 SKU(stock=Zone座位数),自建 FOR UPDATE 防超卖
阶段划分
| 阶段 | 内容 | 负责 |
|---|---|---|
| Round 1 | 独立评议 + plan.md 合并 | 所有成员 |
| Round 2 | 各成员深入分析(后台实现路径、安全评估、前端方案) | 所有成员 |
| Round 3 | 综合推荐 + 输出最终决策报告 | 所有成员 |
Agent 任务分配
| Agent | 主要评议方向 |
|---|---|
| BackendArchitect | Q1(Plan A 后台批量 SKU 生成可行性)+ Q4(最终推荐) |
| SecurityEngineer | Q3($vr- 前缀安全风险)+ Q4(安全性维度) |
| FrontendDev | 前端方案 A/B 的实现差异 + Q4(前端实现成本) |
任务清单
Q1 — Plan A 后台批量生成 SKU 路径评估 [Pending: BackendArchitect]
- 分析 ShopXO spec_base 表写入路径
- 确认是否需要修改 ShopXO 核心代码还是通过插件可完成
- 评估批量生成的性能(上万座位场景)
- 给出可行性结论
Q2 — 商品 112 broken 状态紧急修复 [Pending: BackendArchitect]
- 评估 is_exist_many_spec=0 + spec_base 空的实际影响
- 确定最小修复集(是否需要立即修复)
- 制定修复方案
Q3 — $vr- 前缀安全评估 [Pending: SecurityEngineer]
- 检查 ShopXO 对带 $ 字符 spec name 的处理逻辑
- 识别潜在冲突或注入风险
- 给出安全结论
Q4 — 方案 A vs 方案 B 最终推荐 [Pending: all]
- BackendArchitect:从实现成本、ShopXO 原生机制利用角度评议
- SecurityEngineer:从防超卖安全性角度评议
- FrontendDev:从前端复杂度角度评议
最终输出
council-output/ARCHITECTURE_DECISION.md— 汇总三方推荐 + 最终结论(Round 3)
依赖关系
- Q1(BackendArchitect)先完成,后 Q4 才能给出完整推荐
- Q3(SecurityEngineer)可与 Q1 并行
- Q2 可独立完成,紧急程度由 BackendArchitect 判定
Claim 状态
| 任务 | Claim 状态 |
|---|---|
| Q1 | [Pending: BackendArchitect] |
| Q2 | [Pending: BackendArchitect] |
| Q3 | [Pending: SecurityEngineer] |
| Q4 | [Pending: all] |
| 最终输出 | [Pending: all] |
本轮(Round 1)初判(BackendArchitect)
Q1 初步判断:Plan A 后台批量生成 SKU 可行。ShopXO 的 goods_spec_base 是标准 MySQL 表,插件可直接 INSERT。但需要确认:
- ShopXO 商品保存时是否校验 spec_base 的 referential integrity
- 上万座位时批量 INSERT 的性能
- spec_base_id_map 中的 ID 是否需要与 ShopXO 内部 ID 对齐
Q2 初步判断:当前 broken 状态暂不需要立即修复。购买流程走的是裸商品逻辑(is_exist_many_spec=0),对 Phase 3 的购买流程设计反而是参考点——需要明确购买流程最终走哪条路后再修。
Q4 初步判断:倾向 方案 A。ShopXO 原生防超卖机制比自建锁更可靠(DB 层面原子操作),且不破坏 ShopXO 生态完整性。
[CONSENSUS: NO] — 本轮仅完成规划,实际分析待 Round 2 开始