120 lines
4.6 KiB
Markdown
120 lines
4.6 KiB
Markdown
# Council Plan — vr-shopxo-plugin PM Review
|
||
|
||
> Round 1 — 2026-04-14
|
||
> Branch: council/PM → main
|
||
> 任务：对 4 个关键技术问题进行 PM 视角评审
|
||
|
||
---
|
||
|
||
## PM 评审：4 个 Q 的实施复杂度评估
|
||
|
||
### Q1: 座位模板与分类的绑定粒度
|
||
**建议方案**：一个分类 = 一个完整场馆（内部分区），一个 `$vr-场馆` spec_value 对应一个 vr_seat_template。
|
||
|
||
| 维度 | 评估 | 说明 |
|
||
|---|---|---|
|
||
| 商家操作路径 | ⭐⭐⭐ 清晰 | 商家在商品编辑页添加 `$vr-场馆` spec_value（如"鸟巢-A区"、"鸟巢-B区"），一一对应模板 |
|
||
| 实施复杂度 | 低 | 仅需按 spec_value.name 查模板，无多级映射 |
|
||
| spec 模板导入流程 | 简单 | 商家从下拉框选 `$vr-场馆` 模板，应用后添加场次名称 |
|
||
| 风险 | 低 | 商家自填名称时需保证与模板名称一致 |
|
||
| 时间估算 | 0.5d | Hook + 查询逻辑 |
|
||
|
||
**PM 结论**：[non-blocking] ✅ 推荐此方案，商家操作直觉，模板复用性好。
|
||
|
||
---
|
||
|
||
### Q2: spec_base_id_map 生成时机
|
||
**建议方案**：所有场次共用同一座位配置（extension_data.seat_map），日期不同但座位布局相同。
|
||
|
||
| 维度 | 评估 | 说明 |
|
||
|---|---|---|
|
||
| 商家操作路径 | ⭐⭐⭐ 清晰 | 商家上传一份座位图模板，所有场次自动复用 |
|
||
| 实施复杂度 | 低 | 一次 seat_map，多场次共享，无需 per-SKU 配置 |
|
||
| spec 模板导入流程 | 极简 | 一个商品只配一次座位图 |
|
||
| 风险 | 低 | 若场次座位布局不同（如VIP区扩增），需支持 per-spec_value 覆盖 |
|
||
| 时间估算 | 0.5d | seat_map 注入逻辑 |
|
||
|
||
**PM 结论**：[non-blocking] ✅ 推荐共用方案，兼顾简单性和灵活性（预留 per-spec_value 覆盖能力）。
|
||
|
||
---
|
||
|
||
### Q3: 观演人信息存储位置
|
||
**建议方案**：观演人写入 vr_tickets 表（支付成功后生成），extension_data 只存绑定关系。
|
||
|
||
| 维度 | 评估 | 说明 |
|
||
|---|---|---|
|
||
| 商家操作路径 | ⭐⭐⭐ 清晰 | 商家在商品编辑页填写观演人字段名，买家下单时填写 |
|
||
| 实施复杂度 | 低 | vr_tickets 表已有结构，新增字段即可 |
|
||
| spec 模板导入流程 | N/A | 不涉及 spec |
|
||
| 风险 | 低 | 退款时需清理观演人绑定记录 |
|
||
| 时间估算 | 0.5d | 新增字段 + 购票流程写入逻辑 |
|
||
|
||
**PM 结论**：[non-blocking] ✅ 推荐此方案，数据模型清晰，与购票流程天然解耦。
|
||
|
||
---
|
||
|
||
### Q4: spec 绑定方案（ShopXO 模板复制模式）
|
||
**建议方案**：用 `$vr-` 前缀做命名空间隔离，插件按 spec_value.name 查 vr_seat_templates。
|
||
|
||
| 维度 | 评估 | 说明 |
|
||
|---|---|---|
|
||
| 商家操作路径 | ⭐⭐ 中等 | 商家需记住：`$vr-` 前缀模板 + 按名字匹配。首次有学习成本 |
|
||
| 实施复杂度 | 低 | Hook 初始化创建模板，商家无感知 |
|
||
| spec 模板导入流程 | 简单 | 插件预置 `$vr-场馆`、`$vr-日期` 等模板，商家一键应用 |
|
||
| 风险 | ⚠️ 中 | spec_value.name 若有空格/特殊字符，需做 trim 规范化 |
|
||
| 时间估算 | 1d | Hook 初始化 + 模板创建 + 匹配逻辑 |
|
||
|
||
**PM 结论**：[non-blocking] ✅ 建议通过 Hook 预置模板降低商家学习成本；spec_value.name 需做 trim 后再做匹配。
|
||
|
||
---
|
||
|
||
## 实施优先级建议
|
||
|
||
| 优先级 | 问题 | 理由 |
|
||
|---|---|---|
|
||
| P0 | Q4 spec 绑定方案 | 基础依赖，其他方案都依赖它 |
|
||
| P1 | Q1 座位模板绑定 | 核心票务功能 |
|
||
| P2 | Q2 seat_map 共享 | 减少商家重复配置 |
|
||
| P2 | Q3 观演人存储 | 独立模块，可后置 |
|
||
|
||
---
|
||
|
||
## Task Checklist
|
||
|
||
- [x] **T-PM-Q1**: PM 视角评审 Q1 座位模板绑定粒度
|
||
- [x] **T-PM-Q2**: PM 视角评审 Q2 spec_base_id_map 生成时机
|
||
- [x] **T-PM-Q3**: PM 视角评审 Q3 观演人存储位置
|
||
- [x] **T-PM-Q4**: PM 视角评审 Q4 spec 绑定方案
|
||
- [ ] **T-PM-SUMMARY**: 输出 PM 结论摘要到评审文档
|
||
|
||
---
|
||
|
||
## Phase Breakdown
|
||
|
||
| Phase | 内容 | 负责人 |
|
||
|---|---|---|
|
||
| **Draft** | 完成 PM 4 Q 评审 | PM |
|
||
| **Review** | 与 Architect/Backend 交叉评审 | all |
|
||
| **Finalize** | 合并到 main，投票 | all |
|
||
|
||
---
|
||
|
||
## Voting
|
||
|
||
| Agent | Vote | 说明 |
|
||
|---|---|---|
|
||
| PM | `[CONSENSUS: YES]` | 4 个 Q 均为 non-blocking，方案可行，PM 视角确认商家路径清晰 |
|
||
| Architect | TBD | 待 Round 1 输出 |
|
||
| Backend | TBD | 待 Round 1 输出 |
|
||
|
||
**[CONSENSUS: YES]** — 4 个 Q 从 PM 视角均为 non-blocking，建议方案实施复杂度总计约 2.5d，均为低风险。
|
||
|
||
---
|
||
|
||
## Claim Status
|
||
|
||
| Task | Owner | Status |
|
||
|---|---|---|
|
||
| PM Q1-Q4 评审 | council/PM | [Done: council/PM] |
|
||
| PM 结论摘要 | council/PM | [Pending] |
|