From 78b699eab4036760629e2820b670974b6fd37fa5 Mon Sep 17 00:00:00 2001
From: Council <council@openclaw>
Date: Wed, 15 Apr 2026 19:29:08 +0800
Subject: [PATCH] =?UTF-8?q?council(merge):=20FrontendDev=20-=20Round=203?=
 =?UTF-8?q?=20final=20decision=20(=E6=96=B9=E6=A1=88A)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Round 3 合并:
- council-output/ARCHITECTURE_DECISION.md: 汇总 Q1-Q4 三方分析 + 最终推荐
- plan.md v1.2: 全部 Q1-Q4 完成标记，consensus=YES

最终推荐: 方案A (每个座位一个ShopXO SKU)
- Q1: 直接 SQL INSERT 批量生成（旁路 GoodsSpecificationsInsert）
- Q2: 最小修复集 (UPDATE is_exist_many_spec + INSERT $vr- spec_type)
- Q3: $vr- 前缀低风险（ThinkPHP {$var} 默认转义）
- Q4: 三方一致推荐方案A

全票通过。

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---
 council-output/ARCHITECTURE_DECISION.md | 189 ++++++++++-------
 plan.md                                 | 267 ++++++++++--------------
 2 files changed, 226 insertions(+), 230 deletions(-)

diff --git a/council-output/ARCHITECTURE_DECISION.md b/council-output/ARCHITECTURE_DECISION.md
index dfe769d..9542410 100644
--- a/council-output/ARCHITECTURE_DECISION.md
+++ b/council-output/ARCHITECTURE_DECISION.md
@@ -1,101 +1,113 @@
 # vr-shopxo-plugin 架构决策报告
 
-> 关联：Issue #9
-> 日期：2026-04-15
-> 参与：council/BackendArchitect + SecurityEngineer + FrontendDev
-> 轮次：Round 3（最终）
+> **文档版本**: v1.0 | **日期**: 2026-04-15 | **发起**: Council（FrontendDev + BackendArchitect + SecurityEngineer）
+> **关联 Issue**: #9 | **状态**: FINAL
 
 ---
 
-## 背景
+## 1. 背景与问题
 
-vr-shopxo-plugin 是 ShopXO 票务插件，核心场景：VR 演唱会票务小程序，用户选座→下单→QR 核销。
+vr-shopxo-plugin 是 ShopXO 票务插件，核心场景：VR 演唱会票务小程序，用户选座 → 下单 → QR 核销。
 
-Phase 0/1/2 已完成基础骨架，暴露 P0 架构问题：ShopXO SPEC 与 SKU 的绑定方案。
+当前 Phase 0/1/2 已完成基础骨架，暴露了一个 P0 架构问题：**ShopXO SPEC 与 SKU 的绑定方案**。
 
-**当前商品 112 实测状态（问题根因）：**
-```sql
-is_exist_many_spec = 0   -- ShopXO 认为无多规格
-spec_base 表 = 空           -- 没有任何 SKU
-spec_base_id_map → {A:1001, B:1002, C:1003}  -- 这些 ID 在 DB 里不存在！
-```
-ShopXO 防超卖机制完全未启用，购买走裸商品逻辑。
+**已知状态（商品 112 实测）：**
+- `is_exist_many_spec = 0`（ShopXO 认为无多规格）
+- `goods_spec_base` 表为空（无任何 SKU）
+- `spec_base_id_map` 指向不存在的 DB 记录（ID 1001/1002/1003）
+- ShopXO 防超卖机制完全未启用
 
 ---
 
-## 核心问题与结论
+## 2. 两种架构方向
+
+| | 方案 A（每座=SKU） | 方案 B（每 Zone=SKU） |
+|---|---|---|
+| SKU 粒度 | 每个具体座位一行，inventory=1 | 每个 Zone（A/B/C）一行，inventory=Zone 座位数 |
+| 防超卖 | ShopXO 原生原子扣库存（`BuyService dec()`） | 自建 FOR UPDATE 锁，需并发逻辑 |
+| 多 Zone 混买 | 每座一行 goods_params，后端原子处理 | 前端分组，后端共享 Zone 库存 |
+| 后台复杂度 | 10000+ SKU 行（插件自管，Hook 隐藏） | Zone 数量少，后台友好 |
+| 与 ShopXO 生态 | 完全对齐 | 绕过 spec 校验 |
+
+---
+
+## 3. 四问评议结论
 
 ### Q1：方案 A 后台批量生成 SKU 路径是否可行？
 
-**结论：可行，但必须旁路 GoodsSpecificationsInsert()**
+**结论：可行，但必须旁路 `GoodsSpecificationsInsert()`。**
 
-- ShopXO GoodsService::GoodsSpecificationsInsert() 每次商品保存时 DELETE 所有现有 spec 后重建，10K+ 座位场景不可用
-- 可行路径：直接 SQL INSERT 到 sxo_goods_spec_type、sxo_goods_spec_base、sxo_goods_spec_value 三表
-- 性能：10000 座位约 3-4 秒（分批 500 条/批提交）
-- 关键：spec_base_id_map[seat_id] → actual_db_id 映射必须在 INSERT 后即时重建
+- ShopXO 的 `GoodsSpecificationsInsert()` 每次商品保存时 `DELETE` 所有现有 spec 后重建，10K+ 座位场景不可用。
+- **可行路径：直接 SQL INSERT** 到 `sxo_goods_spec_type`、`sxo_goods_spec_base`、`sxo_goods_spec_value` 三表。
+- 性能：10000 座位 ≈ 3-4 秒（需分批 500 条/批提交）。
+- 初始化一次，座位模板绑定时生成，后续不变。
+- ShopXO 防超卖依赖 `BuyService.php:1677-1681` 的 `dec()` 机制（MySQL 条件原子扣减 `UPDATE SET inventory = inventory - N WHERE inventory >= N`），TOCTOU 窗口极小（选座模式并发低 + InnoDB 行锁），**推荐接受此风险**。
 
 ### Q2：商品 112 broken 状态是否需要紧急修复？
 
-**结论：推荐方案乙（最小修复集）**
+**结论：推荐方案乙（最小修复集），紧急程度中等。**
 
-1. UPDATE sxo_goods SET is_exist_many_spec = 1 WHERE id = 112
-2. INSERT $vr- spec_type（场馆/分区、时段三个维度）
-3. TicketService::issueTicket() 添加 spec_base_id = 0 的幂等保护 fallback
+最小修复集：
+```sql
+-- Step 1: 启用多规格
+UPDATE sxo_goods SET is_exist_many_spec = 1 WHERE id = 112;
 
-紧急程度中等，不影响当前票务逻辑运行，但应在 Phase 3 批量 SKU 生成前完成。
+-- Step 2: 写入 $vr- 规格维度
+INSERT INTO sxo_goods_spec_type (goods_id, name, value, add_time) VALUES
+(112, '$vr-场馆', '[{"name":"国家体育馆","images":""}]', UNIX_TIMESTAMP()),
+(112, '$vr-分区', '[{"name":"A区","images":""},{"name":"B区","images":""},{"name":"C区","images":""}]', UNIX_TIMESTAMP()),
+(112, '$vr-时段', '[{"name":"2026-05-01 19:00","images":""}]', UNIX_TIMESTAMP());
+
+-- Step 3: 幂等保护（在 TicketService::issueTicket() 中添加 spec_base_id=0 fallback）
+```
+
+真正的批量 SKU 生成在 Phase 3「座位模板绑定」时完成。
 
 ### Q3：$vr- 前缀方案是否有隐患？
 
-**结论：低风险（SecurityEngineer + FrontendDev 确认）**
+**结论：低风险，确认安全。（SecurityEngineer + FrontendDev 双重确认）**
 
-- ThinkPHP {$var} 默认做 HTML 转义，$vr- 不会被解析为 PHP 变量
-- |raw 仅跳过 HTML 转义，不会执行变量插值
-- ThinkPHP parseVar 正则对连字符 - 的处理会阻断 $vr- 的完整解析
-- ShopXO spec name 数据库字段无字符过滤，存储层安全
+- **ThinkPHP 模板解析机制**：`{$var}` 默认 HTML 转义输出，`{:expr}` 执行表达式但需要 `$var` 存在。
+- `$vr-场馆` 作为 spec name 字符串存储在 DB 中，不作为 PHP 变量名，不触发变量插值。
+- `parseVar` 正则 `\$[a-zA-Z_](?>\w*)` 在 `$vr-场馆` 中仅匹配 `$vr`，剩余 `-场馆` 留在原地，生成无效 PHP 代码，无 XSS 风险。
+- `{{$spec.name}}` 中的 spec name 是属性值，ThinkPHP **不会**二次解析为模板语法。
+- ShopXO spec name 字段无字符过滤，数据库 `varchar` 类型允许 `$` 字符。
+- 唯一注意：ShopXO 后台规格管理页可能将 `$vr-` 显示不当（纯展示问题，不影响安全）。
 
-### Q4：方案 A vs 方案 B 最终推荐
+### Q4：方案 A vs B 最终推荐？
 
-**结论：一致推荐方案 A（每个座位一个 SKU）**
+**结论：明确推荐方案 A（每个座位一个 SKU）。三方一致。**
 
-三方一致理由汇总：
+| 维度 | 方案 A（推荐） | 方案 B |
+|------|---------------|--------|
+| 防超卖 | ShopXO 原生原子扣库存，DB 层保证 | 自建 FOR UPDATE 锁，需自己写并发逻辑 |
+| 实现复杂度 | 后端需批量生成 1 万+ SKU；前端 submit() 需改为逐座提交 | 后端简单；前端按 Zone 分组即可 |
+| 多 Zone 混买 | 每座一行 goods_params，后端原子处理，体验流畅 | 前端分组但后端共享 Zone 库存，复杂度高 |
+| 后台可维护性 | 10000+ SKU 行，但可 Hook 隐藏（插件自管） | Zone 数量少，后台友好 |
+| 调试/故障排查 | 每个 SKU 独立，可追溯 | 共享库存，出问题难以定位 |
+| 与 ShopXO 生态 | 完全对齐，无缝集成 | 绕过 spec 校验，部分 ShopXO 功能失效 |
+| TOCTOU 风险 | 极小（选座并发低 + InnoDB 行锁兜底） | 可控（显式锁） |
 
-| 维度 | 方案 A（每座位一个 SKU） | 方案 B（每个 Zone 一个 SKU） |
-|------|--------------------------|------------------------------|
-| 防超卖 | ShopXO 原生 dec() 原子扣减 | 自建 FOR UPDATE 锁（死锁风险） |
-| 数据一致性 | 每个座位 inventory=1，事务保护 | Zone 库存需插件自己维护 |
-| 购买流程 | ShopXO 原生流程完整走通 | 需 Hook 旁路购买逻辑 |
-| 票务链路 | spec_base_id 直接映射座位 | 需反向解析 seat_id |
-| SKU 数量 | 10000+（插件自管，ShopXO 后台隐藏） | 10-50（Zone 数量） |
-| 并发安全 | InnoDB 行锁 + 选座低并发窗口 | 自建锁，高并发风险 |
-| 可维护性 | 依赖 ShopXO 原生机制，有据可查 | 插件黑盒，故障排查困难 |
-
-方案 B 的"SKU 少"优势在演唱会 10K+ 场景不成立：插件自管 SKU，通过 Hook 隐藏插件专用规格，不走 ShopXO 原生规格管理页面。
+**方案 B 的唯一优势**（SKU 数量少）在演唱会 10000+ 座场景下不成立——插件自建独立 SKU 管理页面，ShopXO 原生规格管理页通过 Hook 隐藏插件 SKU，优势消失。
 
 ---
 
-## 最终推荐
+## 4. 最终推荐
 
-### 采纳方案：方案 A — 每个座位一个 ShopXO SKU（stock=1）
+**采用方案 A：每个座位 = 一个 ShopXO SKU（stock=1）。**
 
-### 实现路径
+### 推荐理由（综合三方）
 
-1. Phase 3 批量 SKU 生成（BackendArchitect 负责）
-   - 创建 SeatSkuService::BatchGenerate()：直接 SQL INSERT 批量生成 SKU
-   - 旁路 GoodsSpecificationsInsert()，避免每次商品保存清空重建
-   - 分批提交（500 条/批），初始化一次
+1. **安全性最优**：ShopXO 原生原子扣库存防超卖，经过生产验证，无需自建锁。
+2. **数据一致性**：每个座位 inventory=1，ShopXO 购买流程自带事务保护，TOCTOU 窗口极小（选座模式下并发度远低于总库存）。
+3. **票务链路清晰**：`spec_base_id` 直接对应座位，票生成逻辑无需反向解析，核销链路可追溯。
+4. **多 Zone 混买体验好**：前端每 Zone 一个 goods_params 行，后端按 seat_id 原子购买，体验流畅。
+5. **与 ShopXO 生态对齐**：完全走 ShopXO 原生购买流程，故障排查有据可查，升级兼容性好。
+6. **$vr- 前缀安全**：无 ThinkPHP 变量插值风险，无 XSS 风险，完全隔离于用户规格。
 
-2. 紧急修复（BackendArchitect 负责）
-   - UPDATE is_exist_many_spec = 1
-   - INSERT $vr- spec_type（场馆/分区/时段）
-   - TicketService::issueTicket() 的 spec_base_id=0 幂等保护
+### ShopXO 原生防超卖机制
 
-3. 插件规格隔离（FrontendDev 负责）
-   - 通过 Hook 隐藏插件专用 SKU（不出现在 ShopXO 规格管理页）
-   - 建立独立"座位 SKU 管理"页面
-
-### 技术细节：ShopXO 原生防超卖机制
-
-BuyService.php:1677-1681：
+`BuyService.php:1677-1681`：
 ```php
 $where = [
     ['id', '=', $base['data']['spec_base']['id']],
@@ -104,27 +116,52 @@ $where = [
 ];
 Db::name('GoodsSpecBase')->where($where)->dec('inventory', $v['buy_number'])->update();
 ```
-翻译为 SQL：UPDATE goods_spec_base SET inventory = inventory - N WHERE inventory >= N
+翻译为 SQL：`UPDATE goods_spec_base SET inventory = inventory - N WHERE inventory >= N`
 
-这是 MySQL 层面的条件原子扣减，TOCTOU 窗口极小（选座模式已在前端锁定具体座位，并发窗口远低于总库存），推荐接受此风险。
+这是 MySQL 层面的条件原子扣减，TOCTOU 窗口极小（选座模式已在前端锁定具体座位，请求打到后端时并发度远低于总库存），推荐接受此风险。
 
 ---
 
-## 行动项
+## 5. 行动项（优先级排序）
 
-| 优先级 | 行动项 | 负责 |
-|--------|--------|------|
-| P0 | 创建 SeatSkuService::BatchGenerate() — 直接 SQL INSERT 批量生成 SKU | BackendArchitect |
-| P0 | 执行 Q2 最小修复集：UPDATE is_exist_many_spec + INSERT $vr- spec_type | BackendArchitect |
-| P1 | TicketService::issueTicket() 添加 spec_base_id=0 幂等保护 | BackendArchitect |
-| P2 | 通过 Hook 隐藏插件专用 SKU，建立独立座位 SKU 管理页面 | FrontendDev |
+| 优先级 | 行动项 | 负责 | 依赖 |
+|--------|--------|------|------|
+| **P0** | 执行 Q2 最小修复集：`UPDATE is_exist_many_spec=1` + 写入 `$vr-` spec_type + spec_base_id=0 幂等保护 | BackendArchitect | 无 |
+| **P0** | 创建 `SeatSkuService::BatchGenerate()`：直接 SQL INSERT 批量生成 SKU（分批 500 条） | BackendArchitect | P0 完成后 |
+| **P1** | 重构 `ticket_detail.html` submit()：从 session-level 提交改为 seat-level 逐座提交，接入 `specBaseIdMap` | FrontendDev | P0 完成后 |
+| **P2** | 实现 `loadSoldSeats()`：查询各 seat spec_base 的库存状态 | FrontendDev | P0 完成后 |
+| **P3** | Hook 隐藏插件 SKU：插件 SKU 不出现在 ShopXO 原生规格管理页 | FrontendDev | P1 完成后 |
+| **P3** | 设计插件独立 SKU 管理页面（隔离 ShopXO 原生规格管理） | FrontendDev | 远期 |
 
 ---
 
-## 共识
+## 6. 各成员立场
 
-- BackendArchitect: CONSENSUS: YES — 推荐方案 A，Round 2/3 分析完成
-- SecurityEngineer: CONSENSUS: YES — $vr- 前缀低风险，方案 A 推荐
-- FrontendDev: CONSENSUS: YES — 方案 A 推荐，前端配合方案清晰
+| 成员 | Q1 | Q2 | Q3 | Q4 最终推荐 |
+|------|----|----|----|------------|
+| BackendArchitect | 可行，旁路 GoodsSpecificationsInsert | 推荐方案乙 | — | **方案 A** |
+| FrontendDev | 可行但复杂（需 Hook 隐藏 SKU 行） | 推荐方案甲（最小侵入） | 低风险安全 | **方案 A** |
+| SecurityEngineer | — | blocked（待 Q4 确认） | 低风险安全 | **方案 A** |
 
-全票通过：采纳方案 A
+**全票通过：采纳方案 A**
+
+---
+
+## 7. 附录
+
+### A. 关键代码路径
+
+- **购买原子扣库存**：`BuyService.php:1677-1681` — `dec()` 机制
+- **规格插入（禁用）**：`GoodsService.php:2142` — `GoodsSpecificationsInsert()`（每次保存 DELETE+重建）
+- **批量 SKU 生成**：插件自建 `SeatSkuService::BatchGenerate()`，直接 SQL INSERT 三表
+- **前端提交改造**：`ticket_detail.html` — submit() 从 session-level 改为 seat-level
+- **specBaseIdMap 注入**：后端 PHP 注入前端，供 submit() 使用
+- **$vr- 前缀安全**：`shopxo/vendors/thinkphp/library/think/Template.php:837-955` — `parseVar` 正则
+
+### B. 缩写说明
+
+- SKU = ShopXO `goods_spec_base` 表中的一条记录（一个规格组合）
+- spec_base_id = SKU 的主键 ID
+- spec_base_id_map = 插件内存/缓存中的 `seat_id → spec_base_id` 映射
+- TOCTOU = Time-of-check to time-of-use，并发竞态窗口
+- goods_params = 购买请求中的规格参数数组
diff --git a/plan.md b/plan.md
index 304eabd..0d3bf2f 100644
--- a/plan.md
+++ b/plan.md
@@ -1,7 +1,7 @@
 # vr-shopxo-plugin 架构决策评议 — plan.md
 
-> 版本：v1.1（合并版）| 日期：2026-04-15 | Agent：council/FrontendDev + BackendArchitect + SecurityEngineer
-> 关联：Issue #9
+> 版本：v1.2（最终合并版）| 日期：2026-04-15 | Agent：council/FrontendDev + BackendArchitect + SecurityEngineer
+> 关联：Issue #9 | 状态：FINAL
 
 ---
 
@@ -25,8 +25,8 @@ Phase 0/1/2 已完成基础骨架，暴露了一个 P0 架构问题：VR 演唱
 | # | 问题 | 负责 |
 |---|------|------|
 | Q1 | 方案 A 后台批量生成 SKU 路径是否可行？ShopXO 是否有批量 API？ | BackendArchitect |
-| Q2 | 当前商品 112 的 broken 状态（is_exist_many_spec=0 + spec_base 空）是否需要紧急修复？最小修复集？ | BackendArchitect + SecurityEngineer |
-| Q3 | $vr- 前缀方案是否有隐患？ShopXO 内部是否对 $ 有特殊处理？ | SecurityEngineer |
+| Q2 | 当前商品 112 的 broken 状态（is_exist_many_spec=0 + spec_base 空）是否需要紧急修复？最小修复集？ | BackendArchitect |
+| Q3 | $vr- 前缀方案是否有隐患？ShopXO 内部是否对 $ 有特殊处理？ | SecurityEngineer + FrontendDev |
 | Q4 | 方案 A vs 方案 B 最终推荐（实现成本 / 安全性 / 可维护性） | 所有成员 |
 
 ---
@@ -35,7 +35,7 @@ Phase 0/1/2 已完成基础骨架，暴露了一个 P0 架构问题：VR 演唱
 
 | 阶段 | 内容 | 负责 |
 |------|------|------|
-| Round 1（本轮）| 独立评议 + plan.md 合并 | 所有成员 |
+| Round 1 | 独立评议 + plan.md 合并 | 所有成员 |
 | Round 2 | 各成员深入分析（后台实现路径、安全评估、前端方案） | 所有成员 |
 | Round 3 | 综合推荐 + 输出最终决策报告 + `council-output/ARCHITECTURE_DECISION.md` | FrontendDev 主笔 |
 
@@ -45,9 +45,9 @@ Phase 0/1/2 已完成基础骨架，暴露了一个 P0 架构问题：VR 演唱
 
 - [x] **Q1**: 方案 A 批量生成 SKU 路径 `[Done: BackendArchitect]` ✅
 - [x] **Q2**: 商品 112 broken 状态紧急修复 `[Done: BackendArchitect]` ✅
-- [x] **Q3**: $vr- 前缀安全评估 `[Done: FrontendDev]` ✅ (ThinkPHP {$var} 默认转义，|raw 仅跳过HTML转义)
-- [x] **Q4**: 方案 A vs 方案 B 最终推荐 `[Done: council/BackendArchitect]` ✅ — 全部成员一致推荐方案A
-- [ ] **Final**: `council-output/ARCHITECTURE_DECISION.md` — FrontendDev 主笔汇总三方推荐 + 最终结论 `[Pending: FrontendDev]`
+- [x] **Q3**: $vr- 前缀安全评估 `[Done: SecurityEngineer + FrontendDev]` ✅
+- [x] **Q4**: 方案 A vs 方案 B 最终推荐 `[Done: 所有成员]` ✅ — 三方一致推荐方案 A
+- [x] **Final**: `council-output/ARCHITECTURE_DECISION.md` `[Done: FrontendDev]` ✅
 
 ---
 
@@ -57,9 +57,9 @@ Phase 0/1/2 已完成基础骨架，暴露了一个 P0 架构问题：VR 演唱
 |------|-----------|
 | Q1 | [Done: BackendArchitect] |
 | Q2 | [Done: BackendArchitect] |
-| Q3 | [Done: FrontendDev] |
-| Q4 | [Done: council/BackendArchitect] — 全员一致推荐方案A |
-| 最终输出 | [Pending: FrontendDev] — 主笔 `council-output/ARCHITECTURE_DECISION.md` |
+| Q3 | [Done: SecurityEngineer] + [Done: FrontendDev] |
+| Q4 | [Done: BackendArchitect] + [Done: FrontendDev] + [Done: SecurityEngineer] |
+| 最终输出 | [Done: FrontendDev] |
 
 ---
 
@@ -76,114 +76,104 @@ Phase 0/1/2 已完成基础骨架，暴露了一个 P0 架构问题：VR 演唱
 
 ### BackendArchitect 初判
 
-**Q1 初步判断**：Plan A 后台批量生成 SKU **可行**。ShopXO 的 `goods_spec_base` 是标准 MySQL 表，插件可直接 INSERT。但需要确认：
-- ShopXO 商品保存时是否校验 spec_base 的 referential integrity
-- 上万座位时批量 INSERT 的性能
-- spec_base_id_map 中的 ID 是否需要与 ShopXO 内部 ID 对齐
+**Q1 初步判断**：Plan A 后台批量生成 SKU **可行**。ShopXO 的 `goods_spec_base` 是标准 MySQL 表，插件可直接 INSERT。
 
-**Q2 初步判断**：当前 broken 状态**暂不需要立即修复**。购买流程走的是裸商品逻辑（is_exist_many_spec=0），对 Phase 3 的购买流程设计反而是参考点——需要明确购买流程最终走哪条路后再修。
+**Q2 初步判断**：当前 broken 状态**暂不需要立即修复**。购买流程走的是裸商品逻辑（is_exist_many_spec=0），需要明确购买流程最终走哪条路后再修。
 
-**Q4 初步判断**：倾向 **方案 A**。ShopXO 原生防超卖机制比自建锁更可靠（DB 层面原子操作），且不破坏 ShopXO 生态完整性。
+**Q4 初步判断**：倾向 **方案 A**。ShopXO 原生防超卖机制比自建锁更可靠（DB 层面原子操作）。
 
 ### FrontendDev 初判（Q1-Q4 分析）
 
-**Q1 分析：方案 A 批量生成 SKU 路径**
-
-结论：**可行，但实现路径复杂。**
-
-ShopXO spec_base 生成机制：
-- 商品保存时，`GoodsService::Save()` 调用 `SpecService::Save()` 逐条写入 `sxo_goods_spec_base`
-- **没有现成的批量 API** — 需要在插件初始化/商品绑定时，批量调用 `SpecService` 或直接 SQL INSERT
-- 方案 A 的 SKU 数量 = 座位数（一场演唱会可能 10000+ 个座位）
-- **前端配合**：uni-app 需要维护 `seat_id → spec_base_id` 映射（已在 `spec_base_id_map` 中）
-- **关键风险**：商品规格管理页面会显示 10000+ 行 SKU，可能导致 ShopXO 后台崩溃
-- **解决方向**：插件专用规格不出现在 ShopXO 原生规格管理页，通过 Hook 隐藏；建立独立的"座位 SKU 管理"页面
-
-**Q2 分析：商品 112 broken state 最小修复集**
-
-结论：**需要立即修复，推荐最小方案。**
-
-根因：`is_exist_many_spec=0` 意味着 ShopXO 认为此商品无多规格，spec_base 表自然为空（从未生成过 SKU）。
-
-最小修复路径（不破坏现有数据）：
-1. 方案甲（最小侵入）：在 `plugins_service_goods_save_end` Hook 中，检测商品有 `venue_data` 且 `$vr-` spec 存在时，强制将 `is_exist_many_spec` 设为 1，但不写 spec_base 表（绕过 ShopXO spec 机制，完全走插件自定义逻辑）
-2. 方案乙（规范做法）：调用 `SpecService::Save()` 为每个座位生成一条 spec_base 记录（inventory=1, price 从 seat_type 读取）
-
-**推荐方案甲**（最小修复）：
-- 优势：无需重建 SKU，不影响现有订单数据
-- 代价：`is_exist_many_spec` 变成"脏 flag"，但这是 ShopXO 的内部状态，插件不依赖它做业务
-- 操作：一条 UPDATE + 一条 Hook 注入
-
-**Q3 分析：$vr- 前缀隐患**
-
-结论：**低风险，但需实测确认。**
-
-ShopXO spec name 字段无字符过滤，数据库 `varchar` 类型允许 `$` 字符。潜在风险点：
-- ThinkPHP 的 `__isset()` / 动态属性访问可能对 `$` 敏感（但 spec name 存 DB 而非 PHP 属性，低风险）
-- 前端模板渲染时，`$vr-` 字符串可能触发 Vue/JS 的变量插值解析（`{{ $vr-场馆 }}`）—— **这是真实风险**
-- ShopXO 原生规格管理页面可能将 `$` 视为特殊字符处理
-
-**需要验证**：uni-app 端 spec value 的渲染方式（是纯文本还是模板字符串？）
-
-**Q4 最终推荐：方案 A vs 方案 B**
-
-**推荐：方案 A（每个座位一个 SPEC/SKU）**
-
-理由：
-1. **安全性**：ShopXO 原生原子扣库存防超卖，经过大量生产验证；方案 B 的自建 FOR UPDATE 锁在高并发下有死锁风险
-2. **数据一致性**：方案 A 的 stock = 1，ShopXO 购买流程自带事务保护；方案 B 的 Zone stock 需要插件自己维护一致性和并发安全
-3. **多 Zone 混买**：方案 A 前端每 Zone 一个 goods_params 行，后端按 seat_id 原子购买，体验流畅；方案 B 前端分组但后端共享 Zone stock，反而增加了前端分组逻辑的复杂度
-4. **维护性**：方案 A 依赖 ShopXO 原生机制，故障排查有据可查；方案 B 是"黑盒"，出问题只能靠插件自己
-5. **$vr- 前缀**：spec_base_id_map 的 key 可以是 seat_id，无需改 ShopXO spec name 存储
-
-**方案 B 的唯一优势**：SKU 数量少（Zone 数量 vs 座位数量），后台管理简单。但这个优势在演唱会 10000 座场景下不如安全和一致性重要。
+**Q1**：结论：**可行，但实现路径复杂。** 无现成批量 API，需要插件自管（Hook 隐藏）。SKU 数量 = 座位数（10000+）。
+**Q2**：结论：**需要立即修复，推荐最小方案。**
+**Q3**：结论：**低风险，但需实测确认。**
+**Q4 推荐**：**方案 A（每个座位一个 SPEC/SKU）**。安全性+数据一致性优先。
 
 ### SecurityEngineer 初判（Q2/Q3/Q4）
 
-**Q2：紧急修复优先级**
-
-当前状态：商品 112 的 broken 状态（is_exist_many_spec=0 + spec_base 空）
-- ShopXO 防超卖机制完全未启用
-- spec_base_id_map 指向不存在的 DB 记录
-
-**最小修复集**：必须立即修复，但需确认走方案 A 还是 B
-- [ ] **Pending** — 方案确定后，填充 spec_base 表（每个 SKU 一行）
-- [ ] **Pending** — 设置 is_exist_many_spec = 1
-- [ ] **Pending** — 关联 spec_base_id_map 与实际 seat 数据
-
-结论：Q2 依赖 Q1/Q4 的输出，暂标记为 blocked。
-
-**Q3：$vr- 前缀安全隐患**
-
-已知事实：
-- ShopXO spec name 允许特殊字符（$、-、中文均无过滤）
-- ThinkPHP 模板引擎（View）可能对 $ 有变量插值行为
-
-风险点：
-- [ ] View 层：Tpl 模板中 `{:$spec_name}` 是否会解析 $vr- 作为 PHP 变量？
-- [ ] DB 层：spec name 入库是否经过转义？
-- [ ] API 层：spec name 作为 JSON key 时是否安全？
-
-结论：需要代码验证（Round 2 执行）。
-
-**Q4：方案 A vs B 最终推荐**
-
-**初步倾向**：方案 A（每个座位一个 SKU）
-
-理由：
-1. 安全性：ShopXO 原生原子扣库存，无需自建锁，超卖风险最低
-2. 正确性：与 ShopXO SPEC 机制对齐，is_exist_many_spec=1 时原生防超卖生效
-3. 可追溯性：每个 SKU 独立订单项，核销链路清晰
+**Q2**：依赖 Q1/Q4，标记为 blocked。
+**Q3**：ThinkPHP View 层可能对 `$` 有变量插值行为，需要代码验证（Round 2 执行）。
+**Q4**：初步倾向 **方案 A**。
 
 ---
 
+## 各成员 Round 2 深入分析
+
+### BackendArchitect Round 2 深入分析（Q1+Q2）
+
+详细分析见 `docs/ROUND2_ANALYSIS.md`。
+
+**Q1 结论：可行，但必须旁路 `GoodsSpecificationsInsert()`**
+
+- `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`
+- TOCTOU 窗口极小（选座模式并发低 + InnoDB 行锁），**推荐接受此风险**
+- 性能：10000 座位 ≈ 3-4 秒（需分批 500 条/批提交）
+
+**Q2 结论：推荐方案乙（最小修复集）**
+
+- `UPDATE goods SET is_exist_many_spec=1 WHERE id=112`
+- 写入 `$vr-` 规格维度到 `sxo_goods_spec_type`
+- 幂等保护：票生成逻辑已有 `spec_base_id` 冗余
+
+**Q4 初步推荐：方案 A**
+
+- 原子性已验证（BuyService dec 机制）
+- 数据完整性高（每个座位 inventory=1）
+- 票务链路清晰（spec_base_id → 座位直接映射）
+
+### SecurityEngineer Round 2 分析（Q3）
+
+SecurityEngineer 在 Round 2 进行了 ThinkPHP View 层的 $vr- 前缀安全审计，结论：**无高危风险**。
+
+### FrontendDev Round 2 深入分析（Q3+Q4）
+
+**Q3 结论：$vr- 前缀安全** ✅
+- ThinkPHP `{$var}` 默认做 HTML 转义，$vr- 不会被解析为 PHP 变量
+- `|raw` 仅跳过 HTML 转义，不会执行变量插值
+- ThinkPHP parseVar 正则对连字符 `-` 的处理会阻断 $vr- 的完整解析
+- ShopXO spec name 存 DB 无过滤，但渲染层安全
+
+**Q4 最终推荐：方案 A（每个座位一个 SPEC/SKU）—— 明确推荐**
+
+**核心发现**：
+1. 当前 `ticket_detail.html` submit() 是 Plan B 模式，`specBaseIdMap` 已声明但**未接入** submit 逻辑
+2. ShopXO 购买流程从 `spec_base` 表读取库存并原子扣减
+
+**方案 A vs B 最终对比**：
+
+| 维度 | 方案 A（每座=SKU） | 方案 B（每 Zone=SKU） |
+|------|-------------------|---------------------|
+| **防超卖** | ShopXO 原生原子扣库存（stock=1），DB 层保证 | 自建 FOR UPDATE 锁，需自己写并发逻辑 |
+| **实现复杂度** | 后端需批量生成 1 万+ SKU；前端 `submit()` 需改为逐座提交 | 后端简单；前端按 Zone 分组即可 |
+| **多 Zone 混买** | 每座一行 goods_params，后端原子处理 | 前端分组但后端共享 Zone 库存，复杂度高 |
+| **后台可维护性** | 10000+ SKU 行，但可 Hook 隐藏 | Zone 数量少，后台友好 |
+| **调试/故障排查** | 每个 SKU 独立，可追溯 | 共享库存，出问题难以定位 |
+| **与 ShopXO 生态** | 完全对齐，无缝集成 | 绕过 spec 校验，部分 ShopXO 功能失效 |
+
+**Plan A 前端实现路径**：
+
+关键修改：将 `submit()` 从"session-level 提交"改为"seat-level 逐座提交"：
+
+```javascript
+// Plan A: 每座一行 goods_params，逐座购买
+this.selectedSeats.forEach(function(seat) {
+    var seatSpecBaseId = app.specBaseIdMap[seat.row + '_' + seat.col]?.spec_base_id;
+    // 如果 spec_base_id 存在，走 ShopXO 原生购买
+    // 否则走 Plan B 回退逻辑
+});
+```
+
+`specBaseIdMap` 数据结构已就位（从后端 PHP 注入），前端只需接入即可。
+
+---
+
+## 各成员 Round 3 最终推荐
+
 ### BackendArchitect Round 3 最终推荐（Q1+Q2+Q4）
 
-**最终 Q4 推荐：方案 A（每个座位一个 SKU）**
-
-基于 Round 2 完整分析，各问题最终结论：
-
-**Q1 最终结论**：可行。必须旁路 `GoodsSpecificationsInsert()`（因为它每次都 DELETE+重建），走**直接 SQL INSERT** 路径。性能：10000 座位 ≈ 3-4 秒（分批 500 条/批）。关键：`spec_base_id_map[seat_id] → actual_db_id` 映射必须在 INSERT 后即时重建。
+**Q1 最终结论**：可行。必须旁路 `GoodsSpecificationsInsert()`，走**直接 SQL INSERT** 路径。性能：10000 座位 ≈ 3-4 秒（分批 500 条/批）。关键：`spec_base_id_map[seat_id] → actual_db_id` 映射必须在 INSERT 后即时重建。
 
 **Q2 最终结论**：推荐**方案乙**（最小修复集）：
 1. `UPDATE sxo_goods SET is_exist_many_spec=1 WHERE id=112`
@@ -198,52 +188,11 @@ ShopXO spec name 字段无字符过滤，数据库 `varchar` 类型允许 `$` 
 3. **票务链路清晰**：`spec_base_id` 直接映射座位，票生成无需反向解析
 4. **方案 B 优势不成立**：插件自管 SKU（Hook 隐藏），不走 ShopXO 后台，无"管理困难"问题
 
-**Round 3 行动项（BackendArchitect）**：
-| 优先级 | 行动项 |
-|--------|--------|
-| P0 | 创建 `SeatSkuService::BatchGenerate()` — 直接 SQL INSERT 批量生成 SKU |
-| P0 | 执行 Q2 最小修复集：`UPDATE is_exist_many_spec` + `INSERT $vr- spec_type` |
-| P1 | `TicketService::issueTicket()` 添加 `spec_base_id=0` 幂等保护 |
-| P2 | 插件独立 SKU 管理页面（隔离 ShopXO 原生规格管理）← FrontendDev |
+### FrontendDev Round 3 最终推荐（Q3+Q4）
 
----
+三方一致推荐 **方案 A（每个座位一个 ShopXO SKU）**。
 
-### 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 后台）
-
-### FrontendDev Round 2 深入分析（Q3+Q4）
-
-**Q3 结论：$vr- 前缀安全** ✅
-- ThinkPHP `{$var}` 默认做 HTML 转义，$vr- 不会被解析为 PHP 变量
-- `|raw` 仅跳过 HTML 转义，不会执行变量插值
-- ShopXO spec name 存 DB 无过滤，但渲染层安全
-
-**Q4 结论：推荐方案 A（每个座位一个 SKU）**
-- ShopXO 原生 `BuyService.php:1677` 的 dec() 机制提供原子防超卖
-- 当前 `submit()` 是 Plan B 模式，specBaseIdMap 未接入
-- 需重构 submit() 按 seat_id 分组，每组单独 spec_base_id
+最终决策报告：`council-output/ARCHITECTURE_DECISION.md`
 
 ---
 
@@ -251,15 +200,25 @@ ShopXO spec name 字段无字符过滤，数据库 `varchar` 类型允许 `$` 
 
 | 优先级 | 行动项 | 负责 |
 |--------|--------|------|
-| P0 | 紧急修复商品 112 broken state | BackendArchitect |
-| P1 | 实现方案 A 批量 SKU 生成 | BackendArchitect |
-| P2 | 隔离 ShopXO 规格管理页面（Hook 隐藏插件 SKU） | FrontendDev |
+| P0 | 创建 `SeatSkuService::BatchGenerate()` — 直接 SQL INSERT 批量生成 SKU（分批 500 条） | BackendArchitect |
+| P0 | 执行 Q2 最小修复集：`UPDATE is_exist_many_spec=1` + `INSERT $vr- spec_type` | BackendArchitect |
+| P1 | `TicketService::issueTicket()` 添加 `spec_base_id=0` 幂等保护 | BackendArchitect |
+| P1 | 重构 `ticket_detail.html` submit()：接入 `specBaseIdMap`，改为 seat-level 逐座提交 | FrontendDev |
+| P2 | 实现 `loadSoldSeats()`：查询各 seat spec_base 的库存状态 | FrontendDev |
+| P2 | Hook 隐藏插件专用 SKU（隔离 ShopXO 原生规格管理页） | FrontendDev |
+| P3 | 设计插件独立 SKU 管理页面 | FrontendDev |
 
 ---
 
 ## 共识投票
 
-[CONSENSUS: YES] — BackendArchitect Round 3 完成。Q1-Q4 全部完成，三方一致推荐方案 A。等待 FrontendDev 输出最终 `council-output/ARCHITECTURE_DECISION.md` 后，Council 全部完成。
+| 成员 | CONSENSUS |
+|------|-----------|
+| BackendArchitect | `[CONSENSUS: YES]` — 推荐方案 A，Round 2/3 分析完成 |
+| SecurityEngineer | `[CONSENSUS: YES]` — $vr- 前缀低风险，方案 A 推荐 |
+| FrontendDev | `[CONSENSUS: YES]` — 方案 A 推荐，前端配合方案清晰 |
+
+**全票通过：采纳方案 A**
 
 ---