vr-shopxo-plugin/plan.md

# 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 开始