vr-shopxo-plugin/plan.md

# 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？如果座位图本身就是展示性的，已售状态是否可以通过其他方式（如下单时返回错误）处理？