102 lines
4.8 KiB
Markdown
102 lines
4.8 KiB
Markdown
# 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
|
||
**任务清单**：
|
||
- [x] [Done: council/FirstPrinciples] **Task FP-1**: 多座位串行提交 — API 设计正交性分析
|
||
- [x] [Done: council/FirstPrinciples] **Task FP-2**: spec_base_id_map 复杂度质疑：是否存在更简单方案？
|
||
- [x] [Done: council/FirstPrinciples] **Task FP-3**: 选座 → 购物车流程是否必要？直购是否更合适？
|
||
- [x] [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 视角）
|
||
|
||
1. **购物车是否必要？** VR 演唱会票务是单场次、强时效性商品，购物车流程是否增加了不必要的复杂度？
|
||
2. **spec_base_id_map 的隐式假设**：为什么一个座位选择需要映射到 spec？这个设计是否源于对 ShopXO 架构的路径依赖？
|
||
3. **缩放是技术问题还是设计问题？** 如果舞台是「视觉引导」而非「交互元素」，缩放需求本身是否合理？
|
||
4. **已售座位展示的优先级**：是否真的是 P0？如果座位图本身就是展示性的，已售状态是否可以通过其他方式（如下单时返回错误）处理？
|