sileya-ai
/
vr-shopxo-plugin
1
0
Fork 0
Code Issues 3 Pull Requests Packages Projects Releases Wiki Activity
vr-shopxo-plugin/plan.md

6.5 KiB
Raw Blame History

Council Plan — vr-shopxo-plugin Round 1

Round 1 — 2026-04-14 任务：对 4 个关键技术问题进行三方评审（Architect / PM / Backend）

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 观演人存储 独立模块，可后置

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

  • T-PM-Q1: PM 视角评审 Q1 座位模板绑定粒度
  • T-PM-Q2: PM 视角评审 Q2 spec_base_id_map 生成时机
  • T-PM-Q3: PM 视角评审 Q3 观演人存储位置
  • T-PM-Q4: PM 视角评审 Q4 spec 绑定方案
  • 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: 是否过度设计评审

Phase Breakdown

Phase 内容 负责人
Draft 各方完成 4 Q 评审 all
Review 交叉评审，输出 reviews/ 文件 all
Finalize 合并到 main，投票 all

Voting

Agent Vote 说明
PM [CONSENSUS: YES] 4 个 Q 均为 non-blocking，实施复杂度总计约 2.5d，均为低风险
Architect TBD 待 Round 1 输出
Backend TBD 待 Round 1 完成

[CONSENSUS: YES]（PM）— 4 个 Q 从 PM 视角均为 non-blocking。