4.8 KiB

Raw Permalink Blame History

Plan — VR 演唱会票务小程序 Phase 2 技术评估

版本：v1.0 | 日期：2026-04-21 | Agent：council/FirstPrinciples + council/BackendArchitect + council/FrontendDev

任务概述

评估 Phase 2 已完成的 4 个已知问题（购物车提交格式、舞台缩放、spec 加载、商品详情），识别根因，给出修复方案。

问题清单与分工

P0 — 购物车提交格式错误

负责人：council/BackendArchitect 任务清单：

[Claimed: council/BackendArchitect] Task B-P0-1: 逆向 GoodsCartService::Save，提取真实 API 契约（参数名、格式、类型）
[Claimed: council/BackendArchitect] Task B-P0-2: 对比 ticket_detail.html submit() 当前构造的 params，指出具体差异
[Claimed: council/BackendArchitect] Task B-P0-3: 确认 spec_base_id_map 的语义和作用
[Claimed: council/BackendArchitect] Task B-P0-4: spec 加载标准端点分析（GoodsSpecDetail 或其他）

P1 — 舞台缩放不跟随

负责人：council/FrontendDev 任务清单：

[Claimed: council/FrontendDev] Task F-P1-1: 读取 ticket_detail.html 中 .vr-stage 和 .vr-seat-rows 的 DOM 关系
[Claimed: council/FrontendDev] Task F-P1-2: 评估「舞台进入 .vr-seat-rows」vs「共享 CSS 缩放变量」两个方案
[Claimed: council/FrontendDev] Task F-P1-3: 给出推荐修复方案

P1 — spec 加载机制回滚问题

负责人：council/BackendArchitect 任务清单：

[Claimed: council/BackendArchitect] Task B-P1-1: 梳理 ShopXO spec 加载的完整调用链（从商品详情页到 GoodsSpecDetail）
[Claimed: council/BackendArchitect] Task B-P1-2: 判断 ticket_detail.html 能否接入原生 spec 加载，或需要自定义接口

P2 — 商品详情/图片加载

负责人：council/FrontendDev 任务清单：

[Claimed: council/FrontendDev] Task F-P2-1: 读取 ticket_detail.html 当前 goods_detail/content 渲染状态
[Claimed: council/FrontendDev] Task F-P2-2: 对比 ShopXO 标准商品详情页的渲染方式

FirstPrinciples 核心分析

负责人：council/FirstPrinciples 任务清单：

[Done: council/FirstPrinciples] Task FP-1: 多座位串行提交 — API 设计正交性分析
[Done: council/FirstPrinciples] Task FP-2: spec_base_id_map 复杂度质疑：是否存在更简单方案？
[Done: council/FirstPrinciples] Task FP-3: 选座 → 购物车流程是否必要？直购是否更合适？
[Done: council/FirstPrinciples] Task FP-4: 识别被忽略的关键目标（为什么需要 spec？为什么需要库存？）

阶段划分

阶段	状态	说明
Draft	✅ 完成	各 Agent 读取核心文件，提交 findings
Review	✅ 完成	FirstPrinciples 完成独立 review
Finalize	✅ 完成	BackendArchitect + FrontendDev 合并评估报告已产出

共识状态

BackendArchitect: [APPROVE] — merged report produced
FrontendDev: [APPROVE] — merged report produced, Issue 2 zoom fix proposed
FirstPrinciples: [APPROVE] — final consolidated report at reviews/council-phase2-assessment.md

新增发现（P2 潜在）

GetGoodsViewData multi-session bug: validConfigs[0] 只返回第一个场次，多场次商品会丢失其余场次

输出文件

文件	内容	状态
`reviews/council-phase2-assessment.md`	合并评估报告（最终输出）	✅ Done
`reviews/FirstPrinciples-on-council-assessment.md`	FirstPrinciples review	✅ Done
`reviews/FirstPrinciples-on-phase2-assessment.md`	第一性原则分析报告	✅ Done

Phase 2 评估完成，所有文件已合并至 reviews/council-phase2-assessment.md

依赖关系

Task B-P0-1 → B-P0-2 → B-P0-3（串行，BackendArchitect）
Task B-P1-1 → B-P1-2（串行，BackendArchitect）
Task F-P1-1 → F-P1-2 → F-P1-3（串行，FrontendDev）
Task F-P2-1 → F-P2-2（串行，FrontendDev）
Task FP-1~4 → 等待 B/F 报告后执行（并行但依赖输入）

关键问题提醒（FirstPrinciples 视角）

购物车是否必要？ VR 演唱会票务是单场次、强时效性商品，购物车流程是否增加了不必要的复杂度？
spec_base_id_map 的隐式假设：为什么一个座位选择需要映射到 spec？这个设计是否源于对 ShopXO 架构的路径依赖？
缩放是技术问题还是设计问题？ 如果舞台是「视觉引导」而非「交互元素」，缩放需求本身是否合理？
已售座位展示的优先级：是否真的是 P0？如果座位图本身就是展示性的，已售状态是否可以通过其他方式（如下单时返回错误）处理？

4.8 KiB Raw Permalink Blame History Unescape Escape