diff --git a/plan.md b/plan.md index 72dd299..2ae3cdd 100644 --- a/plan.md +++ b/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 做最终拍板