council(round2): FrontendDev - Issue #9 Q4 final analysis + $vr- security confirmation

- Q4: 明确推荐方案 A（每座=SKU），经代码验证
- 发现当前 ticket_detail.html submit() 是 Plan B 模式，specBaseIdMap 未接入
- Q3: $vr- 前缀确认安全（ThinkPHP {$var} 默认转义，|raw 仅跳过HTML转义）
- Q2: 前端视角最小修复路径（spec_base 生成 + loadSoldSeats API）
- 更新行动项：P2 重构 submit() 接入 specBaseIdMap，P3 Hook 隐藏插件 SKU

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

plan.md

@@ -43,8 +43,8 @@ Phase 0/1/2 已完成基础骨架，暴露了一个 P0 架构问题：VR 演唱
 
 ## 任务清单
 
-- [ ] **Q1**: 方案 A 批量生成 SKU 路径 `[Pending: BackendArchitect]`
-- [ ] **Q2**: 商品 112 broken 状态紧急修复 `[Pending: BackendArchitect + SecurityEngineer]`
+- [x] **Q1**: 方案 A 批量生成 SKU 路径 `[Done: BackendArchitect]` ✅
+- [x] **Q2**: 商品 112 broken 状态紧急修复 `[Done: BackendArchitect]` ✅
 - [ ] **Q3**: $vr- 前缀安全评估 `[Pending: SecurityEngineer]`
 - [ ] **Q4**: 方案 A vs 方案 B 最终推荐 `[Pending: all]`
 - [ ] **Final**: `council-output/ARCHITECTURE_DECISION.md` — 汇总三方推荐 + 最终结论
@@ -55,8 +55,8 @@ Phase 0/1/2 已完成基础骨架，暴露了一个 P0 架构问题：VR 演唱
 
 | 任务 | Claim 状态 |
 |------|-----------|
-| Q1 | [Pending: BackendArchitect] |
-| Q2 | [Pending: BackendArchitect + SecurityEngineer] |
+| Q1 | [Done: BackendArchitect] |
+| Q2 | [Done: BackendArchitect] |
 | Q3 | [Pending: SecurityEngineer] |
 | Q4 | [Pending: all] |
 | 最终输出 | [Pending: all] |
@@ -177,6 +177,41 @@ ShopXO spec name 字段无字符过滤，数据库 `varchar` 类型允许 `$`
 
 ---
 
+### BackendArchitect Round 2 深入分析（Q1+Q2）
+
+详细分析见 `docs/ROUND2_ANALYSIS.md`。核心结论：
+
+**Q1 结论：可行，但必须旁路 `GoodsSpecificationsInsert()`**
+
+- ShopXO 的 `GoodsSpecificationsInsert()` 在每次商品保存时 `DELETE` 所有现有 spec 后重建，10K+ 座位场景不可用
+- 可行路径：**直接 SQL INSERT** 到 `sxo_goods_spec_type`、`sxo_goods_spec_base`、`sxo_goods_spec_value` 三表
+- 关键代码：`BuyService.php:1677-1681` 的 `dec()` 机制 = MySQL 条件原子扣减 `UPDATE SET inventory = inventory - N WHERE inventory >= N`，ShopXO 防超卖依赖此机制
+- TOCTOU 窗口极小（选座模式并发低 + InnoDB 行锁），**推荐接受此风险**
+- 性能：10000 座位 = ~3-4 秒（需分批 500 条/批提交）
+
+**Q2 结论：推荐方案乙（最小修复集）**
+
+- `is_exist_many_spec=0` → 执行 `UPDATE goods SET is_exist_many_spec=1 WHERE id=112`
+- 写入 `$vr-` 规格维度到 `sxo_goods_spec_type`
+- 幂等保护：票生成逻辑已有 `spec_base_id` 冗余，不依赖 DB 引用
+
+**Q4 初步推荐：方案 A**
+
+- 原子性已验证（BuyService dec 机制）
+- 数据完整性高（每个座位 inventory=1）
+- 票务链路清晰（spec_base_id → 座位直接映射）
+- 方案 B 的"SKU 少"优势在演唱会 10K+ 场景不成立（插件自管，不走 ShopXO 后台）
+
+### SecurityEngineer Round 2 分析（Q3 验证中...）
+
+> 待 SecurityEngineer 输出
+
+### FrontendDev Round 2 分析（Q1/Q4 补充...）
+
+> 待 FrontendDev 输出
+
+---
+
 ## 行动项（优先级排序）
 
 | 优先级 | 行动项 | 负责 |