13 KiB

Raw Blame History

Council Plan — vr-shopxo-plugin Round 1

<<<<<<< HEAD

Round 1 — 2026-04-14 <<<<<<< HEAD 任务：对 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 汇总）

=======

Branch: council/Backend 角色: ⚙️ Backend — Hook 可行性与 spec 模板绑定实现评审状态：Round 1 Draft 完成，等待 Review 阶段

4 Q 评审结论（Backend 视角）

council/Backend

问题 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 结论	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

<<<<<<< HEAD

待确认事项（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

=======

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 的匹配时机和稳定性需确认。

council/Architect

Task Checklist

<<<<<<< HEAD

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: 是否过度设计评审 ======= 4 Q 全部 non-blocking — 从 Hook 可行性和 spec 绑定实现角度，所有建议方案均可行。

待确认事项（非阻断但需明确）

项目	说明	优先级
Hook 名称确认	支付回调 Hook（`plugins_service_buy_order_insert_success`）需实测验证	⚠️ P0
vr_events/vr_sessions DDL	仅 ARCHITECTURE.md 列名，无字段定义	⚠️ P1
item_type='ticket' 写入机制	插件自动写 vs 后台手动？需明确	⚠️ P1

Task Checklist（Backend Round 1）

R1-T1: 读取 docs/01_SHOPXO_TECHNICAL_RESEARCH.md Hook 列表，确认注入点
R1-T2: 确认支付回调 Hook 名称，更新 docs/03_VERIFICATION_SYSTEM.md
R1-T3: spec_value.name 匹配 vr_seat_templates 实现路径
R1-T4: 明确 item_type='ticket' 写入机制
R1-T5: 补充 vr_events / vr_sessions DDL 到 ARCHITECTURE.md
R1-T6: 输出 Backend 评审报告到 reviews/Backend-QA-review.md

council/Backend =======

架构评审任务（Round 1）

A1: Architect 评审 Q1 — 座位模板与分类绑定粒度
- 分析：$vr- 前缀 + 分类绑定，UNIQUE KEY 限制一分类对一模板
- 评估：业务合理（一个商品一个场馆），架构一致性 ✅
- 输出：NON-BLOCKING — 当前设计满足 95% 场景
- [Done: council/Architect]
A2: Architect 评审 Q2 — spec_base_id_map 生成时机
- 分析：共用 seat_map（演唱会同天多场，座位布局相同）
- 评估：前端选座体验一致，后端存储简化
- 输出：NON-BLOCKING — 共用 seat_map 已是最简方案
- [Done: council/Architect]
A3: Architect 评审 Q3 — 观演人信息存储
- 分析：vr_tickets 已有字段，支付后写入（最简洁）
- 评估：数据一致性有保障，订单状态清晰
- 输出：NON-BLOCKING — vr_tickets 支付后写入
- [Done: council/Architect]
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]

council/Architect

Phase Breakdown

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

<<<<<<< HEAD

Phase	内容	状态
Draft	完成 4 Q 评审 + 待确认事项清单	✅ PM Done, ⚠️ Backend In Progress
Review	输出 `reviews/Backend-QA-review.md`	Pending
Finalize	合并到 main，投票	Pending

council/Backend

Voting

Agent	Vote	说明
<<<<<<< HEAD
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。

[CONSENSUS: NO] — Round 1 Draft 阶段，Backend 需完成 R1-T1 ~ T6 后再投票

council/Backend ======= | 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	`[Done]`
B1: Backend 评审 Q1-Q4	council/Backend	`[Done]`
C1: 综合结论	council/Architect	`[Done]`

4 Q 最终架构结论

Q	结论	Agent	Vote
Q1: 座位模板绑定粒度	分类绑定（UNIQUE KEY）— 业务合理性 ✅	Architect/PM/Backend	✅ NON-BLOCKING
Q2: spec_base_id_map	共用 seat_map — 最简方案	Architect/PM/Backend	✅ NON-BLOCKING
Q3: 观演人存储	vr_tickets 支付后写入	Architect/PM/Backend	✅ NON-BLOCKING
Q4: spec 绑定	$vr- 前缀隔离 — 已确认	Architect/PM/Backend	✅ NON-BLOCKING

Voting

Agent	Vote	说明
Architect	YES (4/4 Q NON-BLOCKING)	4个问题均为NON-BLOCKING
PM	YES (4/4 Q NON-BLOCKING)	实施复杂度 2.5d，低风险
Backend	YES (4/4 Q NON-BLOCKING)	Hook 可行性已确认

[CONSENSUS: YES] — 4 Q 全票通过，架构决策完成

13 KiB Raw Blame History Unescape Escape

Council Plan — vr-shopxo-plugin Round 1

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

Q1: 座位模板与分类的绑定粒度

Q2: spec_base_id_map 生成时机

Q3: 观演人信息存储位置

Q4: spec 绑定方案（ShopXO 模板复制模式）

实施优先级建议

Backend 评审：Hook 可行性与 spec 绑定实现

Backend 评审要点

Backend 评审结论（4 Q 汇总）

4 Q 评审结论（Backend 视角）

<<<<<<< HEAD

待确认事项（Backend，非阻断但需明确）

本轮目标

待决策问题（4个）

Q1: 座位模板与分类的绑定粒度

Q2: spec_base_id_map 生成时机

Q3: 观演人信息存储位置

Q4: spec 绑定方案（ShopXO 模板复制模式）

Task Checklist

PM Tasks

Backend Tasks

Architect Tasks

待确认事项（非阻断但需明确）

Task Checklist（Backend Round 1）

架构评审任务（Round 1）

Phase Breakdown

<<<<<<< HEAD

Voting

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

Claim Status

4 Q 最终架构结论

Voting

13 KiB

Raw Blame History