council(draft): merge PM + Backend Round 1 plan: 4 Q&A unified plan
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>refactor/vr-ticket-20260416
Council
commit
a27ec349bf
77
plan.md
77
plan.md
|
|
@ -1,8 +1,7 @@
|
|||
# Council Plan — vr-shopxo-plugin PM Review
|
||||
# Council Plan — vr-shopxo-plugin Round 1
|
||||
|
||||
> Round 1 — 2026-04-14
|
||||
> Branch: council/PM → main
|
||||
> 任务：对 4 个关键技术问题进行 PM 视角评审
|
||||
> 任务：对 4 个关键技术问题进行三方评审（Architect / PM / Backend）
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -21,8 +20,6 @@
|
|||
|
||||
**PM 结论**：[non-blocking] ✅ 推荐此方案，商家操作直觉，模板复用性好。
|
||||
|
||||
---
|
||||
|
||||
### Q2: spec_base_id_map 生成时机
|
||||
**建议方案**：所有场次共用同一座位配置（extension_data.seat_map），日期不同但座位布局相同。
|
||||
|
||||
|
|
@ -36,8 +33,6 @@
|
|||
|
||||
**PM 结论**：[non-blocking] ✅ 推荐共用方案，兼顾简单性和灵活性（预留 per-spec_value 覆盖能力）。
|
||||
|
||||
---
|
||||
|
||||
### Q3: 观演人信息存储位置
|
||||
**建议方案**：观演人写入 vr_tickets 表（支付成功后生成），extension_data 只存绑定关系。
|
||||
|
||||
|
|
@ -51,8 +46,6 @@
|
|||
|
||||
**PM 结论**：[non-blocking] ✅ 推荐此方案，数据模型清晰，与购票流程天然解耦。
|
||||
|
||||
---
|
||||
|
||||
### Q4: spec 绑定方案（ShopXO 模板复制模式）
|
||||
**建议方案**：用 `$vr-` 前缀做命名空间隔离，插件按 spec_value.name 查 vr_seat_templates。
|
||||
|
||||
|
|
@ -66,8 +59,6 @@
|
|||
|
||||
**PM 结论**：[non-blocking] ✅ 建议通过 Hook 预置模板降低商家学习成本；spec_value.name 需做 trim 后再做匹配。
|
||||
|
||||
---
|
||||
|
||||
## 实施优先级建议
|
||||
|
||||
| 优先级 | 问题 | 理由 |
|
||||
|
|
@ -79,13 +70,56 @@
|
|||
|
||||
---
|
||||
|
||||
## Backend 评审：Hook 可行性与 spec 绑定实现
|
||||
|
||||
### Backend 评审要点
|
||||
|
||||
- **Q1**: `$vr-场馆` spec_value.name → vr_seat_templates.name 的 name 匹配方案；Hook 注入点在商品详情加载时，无需改 ShopXO 核心
|
||||
- **Q2**: 插件在 `GoodsService` 商品加载 Hook 中一次性构建 seat_map，写入 `goods.extension_data.vr.seat_map`，所有场次共用
|
||||
- **Q3**: 支付成功后写入 vr_tickets（已有 DDL）；extension_data 仅存 ticket_id 绑定关系；不在购票流程暂存，减少一致性风险
|
||||
- **Q4**: ShopXO spec_value 是 per-goods COPY，按 name 匹配是唯一可行方案；`$vr-` 前缀隔离用户 spec，初始化时创建模板
|
||||
|
||||
### Backend 评审结论（4 Q 汇总）
|
||||
|
||||
| 问题 | Backend 结论 | Blocking? |
|
||||
|---|---|---|
|
||||
| Q1 座位模板绑定粒度 | `$vr-场馆` spec_value.name → seat_template.name 按名字匹配 ✅ | Non-blocking |
|
||||
| Q2 seat_map 时机 | 商品加载 Hook 中一次性构建，写入 extension_data ✅ | Non-blocking |
|
||||
| Q3 观演人存储 | vr_tickets（支付后）+ extension_data 绑定关系 ✅ | Non-blocking |
|
||||
| Q4 spec 绑定方案 | `$vr-` 前缀命名空间 + 按 name 匹配，是唯一可行方案 ✅ | Non-blocking |
|
||||
|
||||
---
|
||||
|
||||
## 待确认事项（Backend，非阻断但需明确）
|
||||
|
||||
| 项目 | 说明 | 优先级 |
|
||||
|---|---|---|
|
||||
| Hook 名称确认 | 支付回调 Hook 名称（`plugins_service_buy_order_insert_success`）需实测验证 | ⚠️ P0 |
|
||||
| vr_events/vr_sessions DDL | ARCHITECTURE.md 中仅列名，无字段定义 | ⚠️ P1 |
|
||||
| item_type='ticket' 写入机制 | 插件在哪个时机写 goods.item_type？后台手动还是插件自动？ | ⚠️ P1 |
|
||||
|
||||
---
|
||||
|
||||
## Task Checklist
|
||||
|
||||
### PM Tasks
|
||||
- [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 结论摘要到评审文档
|
||||
- [ ] **T-PM-SUMMARY**: 输出 PM 结论摘要
|
||||
|
||||
### Backend Tasks
|
||||
- [ ] **R1-T1**: 确认 `plugins_service_goods_index_view_end` Hook 的 extension_data 注入时机
|
||||
- [ ] **R1-T2**: 确认支付回调 Hook 名称
|
||||
- [ ] **R1-T3**: spec_value.name 匹配 vr_seat_templates 的实现路径
|
||||
- [ ] **R1-T4**: 明确 item_type='ticket' 写入机制
|
||||
- [ ] **R1-T5**: 补充 vr_events / vr_sessions DDL
|
||||
|
||||
### Architect Tasks
|
||||
- [ ] **T-ARCH-1**: 架构一致性评审
|
||||
- [ ] **T-ARCH-2**: 扩展性评估
|
||||
- [ ] **T-ARCH-3**: 是否过度设计评审
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -93,8 +127,8 @@
|
|||
|
||||
| Phase | 内容 | 负责人 |
|
||||
|---|---|---|
|
||||
| **Draft** | 完成 PM 4 Q 评审 | PM |
|
||||
| **Review** | 与 Architect/Backend 交叉评审 | all |
|
||||
| **Draft** | 各方完成 4 Q 评审 | all |
|
||||
| **Review** | 交叉评审，输出 `reviews/` 文件 | all |
|
||||
| **Finalize** | 合并到 main，投票 | all |
|
||||
|
||||
---
|
||||
|
|
@ -103,17 +137,8 @@
|
|||
|
||||
| Agent | Vote | 说明 |
|
||||
|---|---|---|
|
||||
| PM | `[CONSENSUS: YES]` | 4 个 Q 均为 non-blocking，方案可行，PM 视角确认商家路径清晰 |
|
||||
| PM | `[CONSENSUS: YES]` | 4 个 Q 均为 non-blocking，实施复杂度总计约 2.5d，均为低风险 |
|
||||
| Architect | TBD | 待 Round 1 输出 |
|
||||
| Backend | 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] |
|
||||
**[CONSENSUS: YES]**（PM）— 4 个 Q 从 PM 视角均为 non-blocking。
|
||||
|
|
|
|||
Loading…
Reference in New Issue