Council Plan — vr-shopxo-plugin

Round 1 (new cycle) — 2026-04-14 Branch: council/Architect → main 状态：Round 1 并行评审阶段 — 4 个关键技术问题最终决策

本轮目标

对 vr-shopxo-plugin 的 4 个关键技术问题做最终架构决策，输出结论或 trade-off 分析，标注 blocking / non-blocking。

一个分类 = 一个座位区，还是一个分类 = 完整场馆（内部分区）？

背景：当前 ARCHITECTURE.md 中 vr_seat_templates.category_id 是 UNIQUE KEY（一分类对一模板）。如需一分类支持多个座位区（内部分区），需改为一对多。

所有 spec 共用座位配置，还是每个 spec 独立座位配置？

背景：venue_data.seat_map 是所有场次共用还是每个场次独立？spec_base_id_map 的 seat_id → spec_base_id 映射在哪个时机生成。

观演人信息存 extension_data / vr_tickets / 还是独立暂存表？

背景：vr_tickets 表已有 real_name/phone/id_card 字段，但填写时机（购票前 vs 支付后）未明确。

spec_value 是 per-goods COPY，不能用 ID 绑定，只能按名字匹配。

背景：v2.2 已确认 $vr- 前缀隔离方案，但 spec_value.name 的匹配时机和稳定性需确认。

A1: Architect 评审 Q1 — 座位模板与分类绑定粒度
- 分析：$vr- 前缀 + 分类绑定 vs 商品级模板的架构一致性
- 评估：UNIQUE KEY 限制是否合理，是否需要一对多
- 输出：结论 + blocking/non-blocking
- [Pending: council/Architect]
A2: Architect 评审 Q2 — spec_base_id_map 生成时机
- 分析：共用 seat_map vs 独立 seat_map 的扩展性
- 评估：前端选座交互复杂度 vs 后端存储复杂度
- 输出：结论 + blocking/non-blocking
- [Pending: council/Architect]
A3: Architect 评审 Q3 — 观演人信息存储
- 分析：vr_tickets 支付后写入 vs extension_data 购票前暂存
- 评估：数据一致性 vs 用户体验
- 输出：结论 + blocking/non-blocking
- [Pending: council/Architect]
A4: Architect 评审 Q4 — spec_value 命名匹配
- 分析：$vr- 前缀 + name 匹配的稳定性
- 评估：是否存在边界情况（如商家改名、复制商品）
- 输出：结论 + blocking/non-blocking
- [Pending: council/Architect]
P1: PM 评审 Q1-Q4 — 实施复杂度与风险点
- 输出：每个 Q 的开发工时估算（低/中/高）和风险等级
- [Pending: council/PM]
B1: Backend 评审 Q1-Q4 — ShopXO Hook 可行性
- 输出：spec 模板绑定实现细节、Hook 名称确认
- [Pending: council/Backend]
C1: 综合所有评审输出 → 4 Q 最终结论文档
- 汇总 Architect/PM/Backend 结论
- 标注 blocking / non-blocking
- [Pending: council/Architect]

[CONSENSUS: NO] — Round 1 执行评审中，4 Q 结论待输出