126 lines
4.5 KiB
Markdown
126 lines
4.5 KiB
Markdown
# 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。
|
||
|
||
---
|
||
|
||
## 待决策问题（4个）
|
||
|
||
### Q1: 座位模板与分类的绑定粒度
|
||
一个分类 = 一个座位区，还是一个分类 = 完整场馆（内部分区）？
|
||
|
||
**背景**：当前 ARCHITECTURE.md 中 `vr_seat_templates.category_id` 是 UNIQUE KEY（一分类对一模板）。如需一分类支持多个座位区（内部分区），需改为一对多。
|
||
|
||
### Q2: spec_base_id_map 生成时机
|
||
所有 spec 共用座位配置，还是每个 spec 独立座位配置？
|
||
|
||
**背景**：venue_data.seat_map 是所有场次共用还是每个场次独立？spec_base_id_map 的 seat_id → spec_base_id 映射在哪个时机生成。
|
||
|
||
### Q3: 观演人信息存储位置
|
||
观演人信息存 extension_data / vr_tickets / 还是独立暂存表？
|
||
|
||
**背景**：vr_tickets 表已有 real_name/phone/id_card 字段，但填写时机（购票前 vs 支付后）未明确。
|
||
|
||
### Q4: spec 绑定方案（ShopXO 模板复制模式）
|
||
spec_value 是 per-goods COPY，不能用 ID 绑定，只能按名字匹配。
|
||
|
||
**背景**：v2.2 已确认 `$vr-` 前缀隔离方案，但 spec_value.name 的匹配时机和稳定性需确认。
|
||
|
||
---
|
||
|
||
## Task Checklist
|
||
|
||
### 架构评审任务（Round 1）
|
||
|
||
- [x] **A1**: Architect 评审 Q1 — 座位模板与分类绑定粒度
|
||
- 分析：`$vr-` 前缀 + 分类绑定，UNIQUE KEY 限制一分类对一模板
|
||
- 评估：业务合理（一个商品一个场馆），架构一致性 ✅
|
||
- 输出：**NON-BLOCKING** — 当前设计满足 95% 场景
|
||
- `[Done: council/Architect]`
|
||
|
||
- [x] **A2**: Architect 评审 Q2 — spec_base_id_map 生成时机
|
||
- 分析：共用 seat_map（演唱会同天多场，座位布局相同）
|
||
- 评估：前端选座体验一致，后端存储简化
|
||
- 输出：**NON-BLOCKING** — 共用 seat_map 已是最简方案
|
||
- `[Done: council/Architect]`
|
||
|
||
- [x] **A3**: Architect 评审 Q3 — 观演人信息存储
|
||
- 分析：vr_tickets 已有字段，支付后写入（最简洁）
|
||
- 评估：数据一致性有保障，订单状态清晰
|
||
- 输出：**NON-BLOCKING** — vr_tickets 支付后写入
|
||
- `[Done: council/Architect]`
|
||
|
||
- [x] **A4**: Architect 评审 Q4 — spec_value 命名匹配
|
||
- 分析：`$vr-` 前缀 + name 匹配，ShopXO 模板复制模式
|
||
- 评估：已是最佳实践，边界情况文档说明
|
||
- 输出：**NON-BLOCKING** — $vr- 前缀隔离方案确认
|
||
- `[Done: 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]`
|
||
|
||
---
|
||
|
||
## Phase Breakdown
|
||
|
||
| Phase | 内容 | 负责人 |
|
||
|---|---|---|
|
||
| **Round 1 (本轮)** | 并行评审 A1-A4 / P1 / B1 | all |
|
||
| **Round 2** | 综合结论 C1，投票 | Architect |
|
||
| **Finalize** | 合并到 main | all |
|
||
|
||
---
|
||
|
||
## Claim Status
|
||
|
||
| Task | Owner | Status |
|
||
|---|---|---|
|
||
| A1: Q1 架构评审 | council/Architect | `[Done]` |
|
||
| A2: Q2 架构评审 | council/Architect | `[Done]` |
|
||
| A3: Q3 架构评审 | council/Architect | `[Done]` |
|
||
| A4: Q4 架构评审 | council/Architect | `[Done]` |
|
||
| P1: PM 评审 Q1-Q4 | council/PM | `[Pending]` |
|
||
| B1: Backend 评审 Q1-Q4 | council/Backend | `[Pending]` |
|
||
| C1: 综合结论 | council/Architect | `[Pending]` |
|
||
|
||
---
|
||
|
||
## Architect 评审结论
|
||
|
||
| Q | 结论 | blocking |
|
||
|---|---|---|
|
||
| Q1: 座位模板绑定粒度 | 分类绑定（UNIQUE KEY）— 业务合理性 ✅ | **NON-BLOCKING** |
|
||
| Q2: spec_base_id_map | 共用 seat_map — 最简方案 | **NON-BLOCKING** |
|
||
| Q3: 观演人存储 | vr_tickets 支付后写入 | **NON-BLOCKING** |
|
||
| Q4: spec 绑定 | $vr- 前缀隔离 — 已确认 | **NON-BLOCKING** |
|
||
|
||
---
|
||
|
||
## Voting
|
||
|
||
| Agent | Vote | 说明 |
|
||
|---|---|---|
|
||
| Architect | YES (4/4 Q NON-BLOCKING) | 4个问题均为NON-BLOCKING |
|
||
| PM | TBD | 待完成 |
|
||
| Backend | TBD | 待完成 |
|
||
|
||
**[CONSENSUS: NO]** — 等待 PM/Backend 评审完成
|