98 lines
4.8 KiB
Markdown
98 lines
4.8 KiB
Markdown
# Plan — 调研「场馆删除后编辑商品出现规格重复错误」问题
|
||
|
||
> 版本：v1.2 | 日期：2026-04-20 | Agent：council/FrontendDev + council/SecurityEngineer + council/BackendArchitect
|
||
|
||
---
|
||
|
||
## 任务概述
|
||
|
||
当票务商品关联的场馆模板被硬删除后，编辑商品时出现「规格不允许重复」错误。
|
||
|
||
**根因调查分工**：
|
||
- FrontendDev：前端规格项构建与 fallback 行为
|
||
- BackendArchitect：后端规格去重逻辑、`spec_base_id_map` 解析
|
||
- SecurityEngineer：安全风险评估（P1 vs P2）
|
||
|
||
---
|
||
|
||
## FrontendDev 任务清单
|
||
|
||
- [x] [Done: council/FrontendDev] **Task 1**: 读取 `ticket_detail.html`，分析前端构建规格项的过程
|
||
- [x] [Done: council/FrontendDev] **Task 2**: 当模板不存在时，前端如何处理 `template_snapshot` 和 `spec_base_id_map`？
|
||
- [x] [Done: council/FrontendDev] **Task 3**: `loadSoldSeats()` 函数实际实现了吗？soldSeats 数据如何填充？
|
||
- [x] [Done: council/FrontendDev] **Task 4**: 编辑模式下（已有 vr_goods_config），前端是否正确处理已删除场馆的旧规格？
|
||
- [x] [Done: council/FrontendDev] **Task 5**: 给出前端根因分析（含具体文件路径和行号）
|
||
- [x] [Done: council/FrontendDev] **Task 6**: 给出修复方案
|
||
- [x] [Done: council/FrontendDev] **Task 7**: 将调研报告写入 `reviews/council-ghost-spec-FrontendDev.md`
|
||
|
||
---
|
||
|
||
## SecurityEngineer 任务清单
|
||
|
||
- [ ] [Claimed: council/SecurityEngineer] **Task S1**: 读取 AdminGoodsSaveHandle.php — 安全审计：保存时是否拒绝脏数据
|
||
- [ ] [Claimed: council/SecurityEngineer] **Task S2**: 读取 SeatSkuService.php — 幽灵 spec 注入路径分析
|
||
- [ ] [Claimed: council/SecurityEngineer] **Task S3**: 读取 AdminGoodsSave.php — ShopXO 入口安全检查
|
||
- [ ] [Claimed: council/SecurityEngineer] **Task S4**: 输出安全审计报告 → `reviews/SecurityEngineer-GHOST_SPEC_SECURITY.md`
|
||
- [ ] [Claimed: council/SecurityEngineer] **Task S5**: 更新 `reviews/council-ghost-spec-summary.md`
|
||
|
||
### 审计问题清单
|
||
|
||
1. **S1-Q1**: 当 `template_id` 指向不存在的场馆时，`AdminGoodsSaveHandle` 是否拒绝保存（返回 code -401）？
|
||
2. **S1-Q2**: 幽灵 spec（来自已删除场馆的 `spec_base_id_map`）是否可在保存时被注入到 `vr_goods_config`？
|
||
3. **S1-Q3**: `vr_goods_config` 中若有多个规格项的 `spec_base_id` 相同，是否会触发去重逻辑或安全阻断？
|
||
4. **S2-Q1**: `SeatSkuService::GetGoodsViewData` 在模板不存在时如何 fallback？fallback 数据是否可信？
|
||
5. **S2-Q2**: `template_snapshot` 字段是否可以携带恶意 payload？
|
||
6. **S3-Q1**: ShopXO `AdminGoodsSave.php` 入口是否有参数校验？
|
||
7. **评估**: 根因属于 P1（拒绝脏数据/安全漏洞）还是 P2（功能降级）？
|
||
|
||
### 优先级定义
|
||
|
||
| 级别 | 含义 |
|
||
|------|------|
|
||
| **P1** | 安全漏洞：脏数据注入、XSS、权限绕过、数据覆盖 |
|
||
| **P2** | 功能缺陷：用户体验问题、错误提示不友好 |
|
||
| **P3** | 改进建议：代码健壮性优化 |
|
||
|
||
---
|
||
|
||
## BackendArchitect 任务清单
|
||
|
||
- [ ] **Task B1**: 读取 AdminGoodsSaveHandle.php，找出 `vr_goods_config` 的读取和解析逻辑
|
||
- [ ] **Task B2**: 找出 `spec_base_id_map` 如何被转换成规格项
|
||
- [ ] **Task B3**: 当 `template_id` 指向不存在的场馆时，SeatSkuService.php 的 GetGoodsViewData 如何 fallback？
|
||
- [ ] **Task B4**: 幽灵 spec 是在哪个环节产生的？是否在保存时过滤？
|
||
- [ ] **Task B5**: 商品保存时规格去重逻辑在哪里？`vr_goods_config` 中若有多个规格项的 `spec_base_id` 相同会怎样？
|
||
- [ ] **Task B6**: 给出根因分析（含具体行号）和修复方案
|
||
- [ ] **Task B7**: 将调研报告写入 `reviews/council-ghost-spec-BackendArchitect.md`
|
||
|
||
---
|
||
|
||
## 阶段划分
|
||
|
||
| 阶段 | 内容 |
|
||
|------|------|
|
||
| **Draft** | Task 1-7（FrontendDev）+ Task S1-S3 + Task B1-B6（并行）|
|
||
| **Review** | Task 7 + Task S4 + Task B7（输出各自报告）|
|
||
| **Finalize** | Task S5：汇总到 `reviews/council-ghost-spec-summary.md` |
|
||
|
||
---
|
||
|
||
## 关键文件（必须全部检查）
|
||
|
||
| 文件 | 关注点 |
|
||
|------|--------|
|
||
| `shopxo/app/plugins/vr_ticket/view/goods/ticket_detail.html` | 前端规格项构建、template_snapshot fallback |
|
||
| `shopxo/app/plugins/vr_ticket/service/SeatSkuService.php` | GetGoodsViewData，模板不存在时的 fallback |
|
||
| `shopxo/app/plugins/vr_ticket/hook/AdminGoodsSaveHandle.php` | 商品保存钩子，vr_goods_config 处理 |
|
||
| `shopxo/app/plugins/vr_ticket/admin/Admin.php` | VenueDelete 硬删除逻辑 |
|
||
| `shopxo/app/admin/hook/AdminGoodsSave.php` | ShopXO 商品保存钩子入口 |
|
||
|
||
---
|
||
|
||
## 依赖
|
||
|
||
- BackendArchitect：后端规格去重逻辑分析
|
||
- SecurityEngineer：安全风险评估
|
||
- FrontendDev：前端 fallback 行为分析
|
||
- 最终汇总由 SecurityEngineer 写入 `reviews/council-ghost-spec-summary.md`
|