Council Plan — vr-shopxo-plugin PM Review

Round 1 — 2026-04-14 Branch: council/PM → main 任务：对 4 个关键技术问题进行 PM 视角评审

PM 评审：4 个 Q 的实施复杂度评估

建议方案：一个分类 = 一个完整场馆（内部分区），一个 $vr-场馆 spec_value 对应一个 vr_seat_template。

维度	评估	说明
商家操作路径	⭐⭐⭐ 清晰	商家在商品编辑页添加 `$vr-场馆` spec_value（如"鸟巢-A区"、"鸟巢-B区"），一一对应模板
实施复杂度	低	仅需按 spec_value.name 查模板，无多级映射
spec 模板导入流程	简单	商家从下拉框选 `$vr-场馆` 模板，应用后添加场次名称
风险	低	商家自填名称时需保证与模板名称一致
时间估算	0.5d	Hook + 查询逻辑

PM 结论：[non-blocking] ✅ 推荐此方案，商家操作直觉，模板复用性好。

建议方案：所有场次共用同一座位配置（extension_data.seat_map），日期不同但座位布局相同。

维度	评估	说明
商家操作路径	⭐⭐⭐ 清晰	商家上传一份座位图模板，所有场次自动复用
实施复杂度	低	一次 seat_map，多场次共享，无需 per-SKU 配置
spec 模板导入流程	极简	一个商品只配一次座位图
风险	低	若场次座位布局不同（如VIP区扩增），需支持 per-spec_value 覆盖
时间估算	0.5d	seat_map 注入逻辑

PM 结论：[non-blocking] ✅ 推荐共用方案，兼顾简单性和灵活性（预留 per-spec_value 覆盖能力）。

建议方案：观演人写入 vr_tickets 表（支付成功后生成），extension_data 只存绑定关系。

PM 结论：[non-blocking] ✅ 推荐此方案，数据模型清晰，与购票流程天然解耦。

建议方案：用 $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 后再做匹配。

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，均为低风险。

Task	Owner	Status
PM Q1-Q4 评审	council/PM	[Done: council/PM]
PM 结论摘要	council/PM	[Pending]