council(draft): FrontendDev - plan Phase 2 technical assessment, claim Issue 2/4
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>council/FrontendDev
Council
parent
74a235e154
commit
9ec1c5f53f
116
plan.md
116
plan.md
|
|
@ -1,94 +1,78 @@
|
|||
# Plan — ShopXO 酷炫前端模板实现方案调研
|
||||
# Plan — VR 演唱会票务小程序 Phase 2 技术评估
|
||||
|
||||
> 版本：v1.0 | 日期：2026-04-20 | Agent：council/FrontendDev（主导）+ council/BackendArchitect + council/ProductManager + council/FirstPrinciples
|
||||
> 版本：v1.0 | 日期：2026-04-21 | Agent：council/FrontendDev + council/BackendArchitect + council/FirstPrinciples
|
||||
|
||||
---
|
||||
|
||||
## 任务概述
|
||||
|
||||
vr-shopxo-plugin 项目推进自定义前端模板渲染，让票务商品详情页（ticket_detail.html）酷炫起来。4个研究问题并行调研，最终收敛到 `docs/council-research-output.md`。
|
||||
对 Phase 2 票务插件的 4 个已知问题进行根因分析，产出一份合并评估报告 `reviews/council-phase2-assessment.md`，包含根因、修复方案、API 设计建议。
|
||||
|
||||
---
|
||||
|
||||
## 任务清单
|
||||
## 已知问题清单
|
||||
|
||||
- [x] [Done: council/FrontendDev] **Task F1**: Q1 研究 — ShopXO 自定义模板最佳实践
|
||||
- ✅ 读取 ticket_detail.html（现有模板已验证可用）
|
||||
- ✅ 读取 docs/02_FRONTEND_CUSTOMIZATION.md、docs/12_UNIAPP_FRONTEND_RESEARCH.md
|
||||
- ✅ 结论：原生 HTML+CSS+JS 是 ShopXO PHP 模板最优解；Vue CDN 不可行（ThinkTemplate 冲突）
|
||||
- ✅ 酷炫化方向：CSS动画 > 3D舞台 > 触控缩放 > GSAP > 暗色主题
|
||||
- [ ] **Issue 1 (P0)**: 购物车提交格式错误 — `ticket_detail.html` 的 submit() 构造 params 不符合 `GoodsCartService::Save` 契约
|
||||
- 责任人：BackendArchitect（优先）、FrontendDev（配合验证前端逻辑）
|
||||
- 关键文件：`shopxo/app/plugins/vr_ticket/view/goods/ticket_detail.html`（submit 函数）
|
||||
|
||||
- [x] [Done: council/FrontendDev] **Task F2**: Q4 研究 — uni-app 兼容性技术栈选型
|
||||
- ✅ shopxo-uniapp fork 是微信小程序唯一可行路径（完全独立于 PHP 模板）
|
||||
- ✅ 两套前端体系（PHP H5 vs uni-app）完全独立，无桥接需求
|
||||
- ✅ 最小可行：增强现有 ticket_detail.html；理想方案：fork shopxo-uniapp
|
||||
- ✅ Q4 不等待 Q2，可先执行 fork shopxo-uniapp 基础工作
|
||||
- [ ] **Issue 2 (P1)**: 缩放时舞台元素不跟随 — `.vr-stage` 在 `.vr-seat-rows` 容器外
|
||||
- 责任人：FrontendDev（优先）
|
||||
- 关键文件：`ticket_detail.html`（CSS transform + DOM 结构）
|
||||
|
||||
- [ ] [Claimed: council/BackendArchitect] **Task B1**: Q2 研究 — 单订单多SKU支持
|
||||
- 读取 ShopXO 标准订单模型（订单项表结构）
|
||||
- 分析现有 vr_ticket 订单插件实现
|
||||
- 判断是否支持单个订单包含多个 SKU 行项目
|
||||
- 如不支持，给出最小改动方案
|
||||
- **此结论直接影响多座位选择功能能否落地**
|
||||
- [ ] **Issue 3 (P1)**: spec 加载问题回滚 — 真实库存和已售座位未成功加载，spec 加载链路不明确
|
||||
- 责任人：BackendArchitect（API 链路）、FrontendDev（前端调用）
|
||||
- 关键文件：`SeatSkuService.php`、`ticket_detail.html`
|
||||
|
||||
- [ ] [Claimed: council/ProductManager] **Task P1**: Q3 研究 — 第三方无代码构建服务提示词策略
|
||||
- Google App Build / Builder.io / Gamma 等无代码服务
|
||||
- 如何在 prompt 中表达 ShopXO 模板约束（HTML结构、CSS命名、API格式）
|
||||
- 生成代码的后处理步骤
|
||||
- H5 输出物的验收标准
|
||||
|
||||
- [ ] [Claimed: council/FrontendDev] **Task O1**: 汇总输出 — 写入 `docs/council-research-output.md`（等待 B1/P1 完成后执行）
|
||||
- 整合 Q1-Q4 所有结论
|
||||
- 明确优先级和依赖关系（Q2 → Q4 前置）
|
||||
- 识别最大技术风险点
|
||||
- 给出"最小可行方案" vs "理想方案"对比表
|
||||
- [ ] **Issue 4 (P2)**: 商品详情/图片加载现状评估
|
||||
- 责任人：FrontendDev（优先）
|
||||
- 关键文件：`ticket_detail.html`、`Goods.php`
|
||||
|
||||
---
|
||||
|
||||
## 阶段划分
|
||||
|
||||
| 阶段 | 内容 | 负责人 |
|
||||
|------|------|--------|
|
||||
| **Draft** | Task F1 + F2 + B1 + P1（并行研究，限时20分钟） | All |
|
||||
| **Review** | 交叉审阅：BackendArchitect 审 F1/F2，FrontendDev 审 B1/P1 | All |
|
||||
| **Finalize** | Task O1：汇总到 council-research-output.md | FrontendDev |
|
||||
|
||||
---
|
||||
|
||||
## 依赖关系
|
||||
|
||||
```
|
||||
Q2（多SKU支持）→ Q4（uni-app选型）：Q2 结论决定多座位功能能否实现
|
||||
Q1（模板最佳实践）→ Q3（无代码服务）：Q1 的技术栈选型影响 Q3 的 prompt 约束
|
||||
Q1 + Q4 → 输出文件：两份 FrontendDev 研究成果 + BackendArchitect + ProductManager 研究成果
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 风险识别
|
||||
|
||||
| 风险 | 级别 | 描述 |
|
||||
| 阶段 | 内容 | 时长 |
|
||||
|------|------|------|
|
||||
| **R1**: Q2 多SKU不支持 | P0 | 多座位选择功能无法落地，需改订单模型 |
|
||||
| **R2**: uni-app 与 ShopXO H5 模板冲突 | P1 | 两套前端体系如何共存需要澄清 |
|
||||
| **R3**: 无代码服务生成的代码质量 | P2 | 生成的 HTML/CSS 可能不符合 ShopXO 规范 |
|
||||
| **R4**: H5 预览与微信小程序兼容 | P2 | 部分 CSS/JS API 在双端表现不一致 |
|
||||
| **Round 1 (本轮)** | 规划：各 Agent 独立分析，创建 findings 文件 | ~2 min |
|
||||
| **Round 2** | 执行：读取关键文件，深入分析，产出初步 findings | ~5 min |
|
||||
| **Round 3** | 合并：各 Agent 交叉审阅，合并至 `reviews/council-phase2-assessment.md` | ~5 min |
|
||||
| **Round 4** | 收敛：投票 Consensus | ~1 min |
|
||||
|
||||
---
|
||||
|
||||
## 分工 Claim
|
||||
|
||||
| Issue | Claim |
|
||||
|-------|-------|
|
||||
| Issue 1 (P0) | [Claimed: council/BackendArchitect] + [FrontendDev 验证前端 submit 逻辑] |
|
||||
| Issue 2 (P1) | [Claimed: council/FrontendDev] |
|
||||
| Issue 3 (P1) | [Claimed: council/BackendArchitect] + [FrontendDev 配合] |
|
||||
| Issue 4 (P2) | [Claimed: council/FrontendDev] |
|
||||
| 第一性原则综合分析 | [Claimed: council/FirstPrinciples] |
|
||||
|
||||
---
|
||||
|
||||
## 输出文件
|
||||
|
||||
`docs/council-research-output.md` — 包含：
|
||||
1. Q1-Q4 各自的具体可执行结论
|
||||
2. 优先级和依赖关系矩阵
|
||||
3. 最大技术风险点标注
|
||||
4. 最小可行方案 vs 理想方案对比
|
||||
5. 每项结论的置信度（高/中/低）
|
||||
- `reviews/FrontendDev-Issue2-StageZoom.md` — Issue 2 根因 + 修复方案（FrontendDev）
|
||||
- `reviews/FrontendDev-Issue3-SpecLoading.md` — Issue 3 前端视角分析（FrontendDev）
|
||||
- `reviews/FrontendDev-Issue4-GoodsDetail.md` — Issue 4 评估（FrontendDev）
|
||||
- `reviews/council-phase2-assessment.md` — **合并报告**（各 Agent 合并，FrontendDev 汇总执笔）
|
||||
|
||||
---
|
||||
|
||||
## 执行策略
|
||||
## 第一性原则关键问题（FirstPrinciples）
|
||||
|
||||
- 20分钟限时：各 Agent 独立研究，记录置信度
|
||||
- 3轮收敛：Round 1 规划 → Round 2 执行 → Round 3 收敛/投票
|
||||
- 如有分歧：FirstPrinciples 做最终拍板
|
||||
1. 多座位提交 API 设计是否正交？
|
||||
2. spec_base_id_map 是否过于复杂？
|
||||
3. 选座是否必须走购物车流程？
|
||||
4. spec/库存的真实业务价值是什么？
|
||||
|
||||
---
|
||||
|
||||
## 约束
|
||||
|
||||
- 最大 4 轮，每轮 ≤ 25 tool turns
|
||||
- 最大总耗时 20 分钟
|
||||
- 不 push，只 local merge 到 main
|
||||
|
|
|
|||
Loading…
Reference in New Issue