council(draft): FrontendDev - create plan for ShopXO frontend template research
New plan.md for the 4-question research task: - Q1: ShopXO custom template best practices (FrontendDev) - Q2: Single-order multi-SKU support (BackendArchitect) - Q3: No-code service prompt strategy (ProductManager) - Q4: uni-app compatibility tech stack (FrontendDev) Output: docs/council-research-output.md Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>council/FrontendDev
Council
parent
11fdf0309f
commit
c1ca1efcfb
138
plan.md
138
plan.md
|
|
@ -1,97 +1,95 @@
|
|||
# Plan — 调研「场馆删除后编辑商品出现规格重复错误」问题
|
||||
# Plan — ShopXO 酷炫前端模板实现方案调研
|
||||
|
||||
> 版本：v1.2 | 日期：2026-04-20 | Agent：council/FrontendDev + council/SecurityEngineer + council/BackendArchitect
|
||||
> 版本：v1.0 | 日期：2026-04-20 | Agent：council/FrontendDev（主导）+ council/BackendArchitect + council/ProductManager + council/FirstPrinciples
|
||||
|
||||
---
|
||||
|
||||
## 任务概述
|
||||
|
||||
当票务商品关联的场馆模板被硬删除后，编辑商品时出现「规格不允许重复」错误。
|
||||
|
||||
**根因调查分工**：
|
||||
- FrontendDev：前端规格项构建与 fallback 行为
|
||||
- BackendArchitect：后端规格去重逻辑、`spec_base_id_map` 解析
|
||||
- SecurityEngineer：安全风险评估（P1 vs P2）
|
||||
vr-shopxo-plugin 项目推进自定义前端模板渲染，让票务商品详情页（ticket_detail.html）酷炫起来。4个研究问题并行调研，最终收敛到 `docs/council-research-output.md`。
|
||||
|
||||
---
|
||||
|
||||
## 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`
|
||||
- [ ] [Claimed: council/FrontendDev] **Task F1**: Q1 研究 — ShopXO 自定义模板最佳实践
|
||||
- 读取 `shopxo/app/plugins/vr_ticket/view/goods/ticket_detail.html`（现有模板结构）
|
||||
- 读取 `docs/02_FRONTEND_CUSTOMIZATION.md`、`docs/12_UNIAPP_FRONTEND_RESEARCH.md`（已有调研）
|
||||
- 读取 ShopXO 官方文档中 view/goods/ 目录的自定义模板规范
|
||||
- 给出技术栈选型建议（原生HTML+JS / Vue CDN / Tailwind / 其他）
|
||||
- 给出 H5 预览兼容性保障方案
|
||||
|
||||
---
|
||||
- [ ] [Claimed: council/FrontendDev] **Task F2**: Q4 研究 — uni-app 兼容性技术栈选型
|
||||
- 分析 uni-app + HBuilder 编译到微信小程序的路径
|
||||
- 研究 ShopXO H5 模板与 uni-app 项目共存/桥接方案
|
||||
- 给出"一套代码，H5和小程序双端运行"方案
|
||||
- 输出：最小可行方案 vs 理想方案对比
|
||||
|
||||
## SecurityEngineer 任务清单
|
||||
- [ ] [Claimed: council/BackendArchitect] **Task B1**: Q2 研究 — 单订单多SKU支持
|
||||
- 读取 ShopXO 标准订单模型（订单项表结构）
|
||||
- 分析现有 vr_ticket 订单插件实现
|
||||
- 判断是否支持单个订单包含多个 SKU 行项目
|
||||
- 如不支持，给出最小改动方案
|
||||
- **此结论直接影响多座位选择功能能否落地**
|
||||
|
||||
- [ ] [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`
|
||||
- [ ] [Claimed: council/ProductManager] **Task P1**: Q3 研究 — 第三方无代码构建服务提示词策略
|
||||
- Google App Build / Builder.io / Gamma 等无代码服务
|
||||
- 如何在 prompt 中表达 ShopXO 模板约束（HTML结构、CSS命名、API格式）
|
||||
- 生成代码的后处理步骤
|
||||
- H5 输出物的验收标准
|
||||
|
||||
### 审计问题清单
|
||||
|
||||
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`
|
||||
- [ ] [Claimed: council/FrontendDev] **Task O1**: 汇总输出 — 写入 `docs/council-research-output.md`
|
||||
- 整合 Q1-Q4 所有结论
|
||||
- 明确优先级和依赖关系（Q2 → Q4 前置）
|
||||
- 识别最大技术风险点
|
||||
- 给出"最小可行方案" vs "理想方案"对比表
|
||||
|
||||
---
|
||||
|
||||
## 阶段划分
|
||||
|
||||
| 阶段 | 内容 |
|
||||
|------|------|
|
||||
| **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` |
|
||||
| 阶段 | 内容 | 负责人 |
|
||||
|------|------|--------|
|
||||
| **Draft** | Task F1 + F2 + B1 + P1（并行研究，限时20分钟） | All |
|
||||
| **Review** | 交叉审阅：BackendArchitect 审 F1/F2，FrontendDev 审 B1/P1 | All |
|
||||
| **Finalize** | Task O1：汇总到 council-research-output.md | FrontendDev |
|
||||
|
||||
---
|
||||
|
||||
## 关键文件（必须全部检查）
|
||||
## 依赖关系
|
||||
|
||||
| 文件 | 关注点 |
|
||||
|------|--------|
|
||||
| `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 商品保存钩子入口 |
|
||||
```
|
||||
Q2（多SKU支持）→ Q4（uni-app选型）：Q2 结论决定多座位功能能否实现
|
||||
Q1（模板最佳实践）→ Q3（无代码服务）：Q1 的技术栈选型影响 Q3 的 prompt 约束
|
||||
Q1 + Q4 → 输出文件：两份 FrontendDev 研究成果 + BackendArchitect + ProductManager 研究成果
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 依赖
|
||||
## 风险识别
|
||||
|
||||
- BackendArchitect：后端规格去重逻辑分析
|
||||
- SecurityEngineer：安全风险评估
|
||||
- FrontendDev：前端 fallback 行为分析
|
||||
- 最终汇总由 SecurityEngineer 写入 `reviews/council-ghost-spec-summary.md`
|
||||
| 风险 | 级别 | 描述 |
|
||||
|------|------|------|
|
||||
| **R1**: Q2 多SKU不支持 | P0 | 多座位选择功能无法落地，需改订单模型 |
|
||||
| **R2**: uni-app 与 ShopXO H5 模板冲突 | P1 | 两套前端体系如何共存需要澄清 |
|
||||
| **R3**: 无代码服务生成的代码质量 | P2 | 生成的 HTML/CSS 可能不符合 ShopXO 规范 |
|
||||
| **R4**: H5 预览与微信小程序兼容 | P2 | 部分 CSS/JS API 在双端表现不一致 |
|
||||
|
||||
---
|
||||
|
||||
## 输出文件
|
||||
|
||||
`docs/council-research-output.md` — 包含：
|
||||
1. Q1-Q4 各自的具体可执行结论
|
||||
2. 优先级和依赖关系矩阵
|
||||
3. 最大技术风险点标注
|
||||
4. 最小可行方案 vs 理想方案对比
|
||||
5. 每项结论的置信度（高/中/低）
|
||||
|
||||
---
|
||||
|
||||
## 执行策略
|
||||
|
||||
- 20分钟限时：各 Agent 独立研究，记录置信度
|
||||
- 3轮收敛：Round 1 规划 → Round 2 执行 → Round 3 收敛/投票
|
||||
- 如有分歧：FirstPrinciples 做最终拍板
|
||||
|
|
|
|||
Loading…
Reference in New Issue