docs: 完整开发日志 DEVELOPMENT_LOG.md
- 覆盖 2026-04-13 调研 → 2026-04-15 Phase 0/1 完成全记录 - 需求背景 + 技术栈决策 - ShopXO 插件机制调研结论 - Phase 0 插件骨架(14文件 + 4表 + 测试数据) - Phase 1 Goods.php 改法 + 浏览器验证截图 - Council 审议记录 - 关键决策固化表 - Phase 2/3/4 下步计划 - 清理废弃 review 文件refactor/vr-ticket-20260416
parent
7508bed11d
commit
852623fc9f
|
|
@ -96,6 +96,12 @@ function vr_ticket_install()
|
|||
COMMENT='VR票务核销记录'
|
||||
");
|
||||
|
||||
// 给 ShopXO 商品表追加 item_type 字段(MySQL 5.x 兼容写法)
|
||||
$cols = $db->query("SHOW COLUMNS FROM `{$prefix}goods` LIKE 'item_type'");
|
||||
if (empty($cols)) {
|
||||
$db->query("ALTER TABLE `{$prefix}goods` ADD COLUMN `item_type` VARCHAR(20) NOT NULL DEFAULT 'normal' COMMENT '商品类型:normal=普通 goods ticket=票务 physical=周边' AFTER `is_shelves`");
|
||||
}
|
||||
|
||||
return true;
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,368 @@
|
|||
# VR 票务插件开发日志
|
||||
> vr-shopxo-plugin 项目全量记录
|
||||
> 仓库:http://xmhome.ow-my.com:3000/sileya-ai/vr-shopxo-plugin
|
||||
> 最后更新:2026-04-15
|
||||
|
||||
---
|
||||
|
||||
## 一、项目背景与决策
|
||||
|
||||
### 1.1 需求来源(2026-04-13)
|
||||
|
||||
大头受朋友委托,为其合作伙伴调研轻量级商城小程序解决方案。
|
||||
|
||||
**核心需求:**
|
||||
- 订单:外卖配送 / 包邮 / 自提
|
||||
- 会员:充值、积分、优惠券
|
||||
- 约束:无程序员/无前端/无后端,要求直接可用,后期能用 AI 改动,架构清晰,部署简单
|
||||
|
||||
**调研结论(4 个方案对比):**
|
||||
|
||||
| 项目 | Stars | 功能 | 部署 | 会员体系 | AI友好 | 综合 |
|
||||
|------|-------|------|------|---------|--------|------|
|
||||
| **ShopXO** | 8.5k | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | **9/10** |
|
||||
| Bagisto | 14k | ⭐⭐ | ⭐⭐ | ⭐ | ⭐⭐⭐ | 5/10 |
|
||||
| Saleor | 22.4k | ⭐⭐ | ⭐ | ⭐⭐ | ⭐⭐⭐ | 5/10 |
|
||||
| Medusa | 23k+ | ⭐⭐ | ⭐ | ⭐ | ⭐⭐⭐ | 4/10 |
|
||||
|
||||
**ShopXO 断层第一**,原因:功能完整 + 虚拟主机可部署 + 有 uni-app 前端配套 + MIT 协议可商用。
|
||||
|
||||
**票务插件定位:**
|
||||
票务 = ShopXO 商品类型扩展。item_type = 'ticket' 时走插件逻辑处理座位图/场次/QR票。
|
||||
|
||||
### 1.2 技术栈决策
|
||||
|
||||
| 层 | 技术选型 | 说明 |
|
||||
|----|---------|------|
|
||||
| 商城底座 | ShopXO v6.8.0 | ThinkPHP 8,虚拟主机可部署 |
|
||||
| 前端 | uni-app | 微信小程序 + H5 |
|
||||
| 票务插件 | PHP 原生 | 插件机制 + Hook 系统 |
|
||||
| 票务详情页 | 独立 HTML 模板 | 完全独立 UI,绕过 ShopXO 主题限制 |
|
||||
| 数据库 | MySQL(与 ShopXO 共用) | 表前缀 vrt_ |
|
||||
| QR 票 | AES 加密 | 防伪造 |
|
||||
| 核销 | 扫码枪 + RLS | B 端小程序扫码核销 |
|
||||
|
||||
**核心原则(已固化):**
|
||||
> 怎么快怎么来,怎么方便怎么来,少改动少复杂度,完全允许改 ShopXO 核心代码(自己部署)。
|
||||
|
||||
---
|
||||
|
||||
## 二、技术调研(2026-04-13 白天)
|
||||
|
||||
### 2.1 ShopXO 插件机制调研
|
||||
|
||||
**调研文件:**
|
||||
- docs/07_SHOPXO_PLUGIN_MECHANISM.md — 插件开发机制完整手册
|
||||
- docs/08_SHOPXO_REQUIREMENTS_MAPPING.md — 票务需求 → ShopXO 机制对照矩阵
|
||||
- docs/09_SHOPXO_HOOKS_REFERENCE.md — 100+ 钩子清单
|
||||
|
||||
**插件核心机制:**
|
||||
|
||||
1. config.json — 插件元数据(名称/版本/依赖/菜单/权限/静态资源)
|
||||
2. BaseService — 插件业务服务基类(GetDb / 参数校验 / 日志)
|
||||
3. EventListener.php — 生命周期钩子(Install/Uninstall/Upgrade/Index)
|
||||
4. URL 路由 — 后台控制器 plugins_admin 前缀,前台 plugins 前缀
|
||||
5. 视图 — admin/view/default/plugins_admin/ + view/default/plugins/ 目录
|
||||
|
||||
**关键发现(票务用途):**
|
||||
|
||||
| 钩子 | 用途 |
|
||||
|------|------|
|
||||
| plugins_service_order_pay_success_handle_end | 支付成功 → 生成 QR 票 |
|
||||
| plugins_view_goods_detail_base_sku_top | 商品详情页顶部(选座 UI) |
|
||||
| plugins_view_user_various_inside_top | 用户中心(票夹) |
|
||||
| plugins_service_goods_delete_end | 商品删除 → 清理票务数据 |
|
||||
| plugins_admin_goods_info_init_end | 后台商品编辑 → 加载票务字段 |
|
||||
|
||||
### 2.2 票务详情页方案抉择
|
||||
|
||||
方案 A:URL 劫持 ❌ 放弃
|
||||
- 缺点:无法继承商品详情页基础样式,改动 ShopXO 核心代码量大
|
||||
|
||||
方案 B:CSS 隐藏标准 SKU ❌ 放弃
|
||||
- 缺点:Hook 链过长,不可控
|
||||
|
||||
方案 C:插件模板替换 ❌ 不可行
|
||||
- 调研结论:MyView() 源码确认 ShopXO 插件系统是纯钩子系统,config.json 无权覆盖 Goods 控制器模板路径,goods/detail.html 写死在控制器里
|
||||
|
||||
方案 D(最终):Goods.php 1 行判断 ✅
|
||||
- 在 app/index/controller/Goods.php 的 return MyView(); 前插入判断
|
||||
- item_type == 'ticket' → 加载插件模板路径 + 预查询座位模板数据
|
||||
- 改动量:1 行条件判断 + ~10 行数据注入
|
||||
- 实测验证:浏览器访问商品详情页,座位图渲染正常
|
||||
|
||||
---
|
||||
|
||||
## 三、ShopXO 环境配置(2026-04-15 凌晨)
|
||||
|
||||
### 3.1 Docker 环境
|
||||
|
||||
| 服务 | 端口 | 说明 |
|
||||
|------|------|------|
|
||||
| shopxo-web | :10000 | Nginx 前端 |
|
||||
| shopxo-mysql | :10001 | MySQL 8.0 |
|
||||
| shopxo-php | :9000 | PHP-FPM |
|
||||
|
||||
### 3.2 关键配置
|
||||
|
||||
- 后台入口:adminwatekc.php(非标准 admin.php)
|
||||
- 表前缀:vrt_(非标准 sxo_)
|
||||
- 数据库凭证:root=shopxo_root_2024 / user=shopxo_user / pass=shopxo_pass_2024
|
||||
- 源码路径:~/.openclaw/workspace/council-research/shopxo-eval/.worktrees/shopxo-evaluator/shopxo-src/
|
||||
- is_develop:在 config/shopxo.php 第 41 行改为 true
|
||||
|
||||
### 3.3 后台权限修复
|
||||
|
||||
admin 用户(role_id=1)默认缺少插件权限。手动写入 38 条权限到 vrt_role_power:
|
||||
- 应用管理链路:340 / 341 及子权限 342-591
|
||||
|
||||
### 3.4 模板目录冲突
|
||||
|
||||
ThinkPHP 路由用 plugins_admin(下划线格式),但实际目录为 pluginsadmin(无下划线)。通过创建符号链接解决。
|
||||
|
||||
---
|
||||
|
||||
## 四、Phase 0:插件骨架(2026-04-15 04:36 起)
|
||||
|
||||
### 4.1 完成内容
|
||||
|
||||
**数据库建表(手动 SQL):**
|
||||
|
||||
-- 座位模板
|
||||
CREATE TABLE vrt_vr_seat_templates (
|
||||
id INT PRIMARY KEY AUTO_INCREMENT,
|
||||
name VARCHAR(100) NOT NULL COMMENT '模板名称',
|
||||
category_id INT DEFAULT 0 COMMENT '绑定分类ID',
|
||||
spec_base JSON COMMENT '座位规格基数据',
|
||||
qr_data VARCHAR(64) NOT NULL COMMENT 'QR数据前缀',
|
||||
is_enable TINYINT DEFAULT 1,
|
||||
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
|
||||
);
|
||||
|
||||
-- 电子票
|
||||
CREATE TABLE vrt_vr_tickets (
|
||||
id INT PRIMARY KEY AUTO_INCREMENT,
|
||||
order_id INT NOT NULL,
|
||||
order_no VARCHAR(64),
|
||||
goods_id INT NOT NULL,
|
||||
user_id INT NOT NULL,
|
||||
qr_code TEXT NOT NULL COMMENT 'AES加密QR数据',
|
||||
status ENUM('pending','active','used','cancelled') DEFAULT 'pending',
|
||||
qr_data VARCHAR(128),
|
||||
seat_label VARCHAR(32),
|
||||
verified_at DATETIME,
|
||||
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
|
||||
);
|
||||
|
||||
-- 核销员
|
||||
CREATE TABLE vrt_vr_verifiers (
|
||||
id INT PRIMARY KEY AUTO_INCREMENT,
|
||||
user_id INT NOT NULL,
|
||||
name VARCHAR(50),
|
||||
status TINYINT DEFAULT 1,
|
||||
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
|
||||
);
|
||||
|
||||
-- 核销记录
|
||||
CREATE TABLE vrt_vr_verifications (
|
||||
id INT PRIMARY KEY AUTO_INCREMENT,
|
||||
ticket_id INT NOT NULL,
|
||||
verifier_id INT NOT NULL,
|
||||
verified_at DATETIME DEFAULT CURRENT_TIMESTAMP,
|
||||
location VARCHAR(200)
|
||||
);
|
||||
|
||||
**插件文件结构:**
|
||||
|
||||
app/plugins/vr_ticket/
|
||||
├── plugin.json # 插件配置(3个子菜单)
|
||||
├── EventListener.php # 生命周期(Install建表/Uninstall/Upgrade)
|
||||
├── service/
|
||||
│ ├── BaseService.php # 工具(AES/QrData/UUID/日志)
|
||||
│ ├── TicketService.php # onOrderPaid/verifyTicket/getUserTickets
|
||||
│ └── SeatTemplateService.php
|
||||
├── admin/
|
||||
│ ├── controller/
|
||||
│ │ ├── SeatTemplate.php # 座位模板 CRUD
|
||||
│ │ ├── Ticket.php # 电子票列表+详情+导出
|
||||
│ │ ├── Verifier.php # 核销员管理
|
||||
│ │ └── Verification.php # 核销记录
|
||||
│ └── view/default/ # Layui 列表页
|
||||
└── view/goods/
|
||||
└── ticket_detail.html # 前端票务详情页(独立UI)
|
||||
|
||||
**测试数据:**
|
||||
- 商品 ID 112:VR演唱会电子票 2024,item_type=ticket
|
||||
- 分类 ID 911:VR演唱会
|
||||
- 座位模板 ID 1:Bird Nest - Zone A,绑定 category_id=911
|
||||
- 3排座位:A排(AAAAAA,红色VIP区)/ B排(BBBBBB,蓝色看台区)/ C排(CCCCCC,绿色普通区)
|
||||
|
||||
---
|
||||
|
||||
## 五、Phase 1:Goods.php 改法 + 前端验证(2026-04-15 白天)
|
||||
|
||||
### 5.1 修改内容
|
||||
|
||||
文件:app/index/controller/Goods.php
|
||||
位置:detail() 方法,return MyView(); 前约第 137-139 行
|
||||
|
||||
代码改动:
|
||||
|
||||
// --- VR 票务处理 start ---
|
||||
$goods = $result['data']['goods'];
|
||||
if (!empty($goods['item_type']) && $goods['item_type'] === 'ticket') {
|
||||
// 加载座位模板
|
||||
$spec_base = Db::table('vr_seat_templates')
|
||||
->where('category_id', $goods['category_id'])
|
||||
->where('is_enable', 1)
|
||||
->find();
|
||||
$goods['vr_seat_template'] = $spec_base;
|
||||
// 加载 goods_spec_data(座位动态价格)
|
||||
$goods_spec_data = empty($goods['spec_base']) ? [] : json_decode($goods['spec_base'], true);
|
||||
$goods['vr_spec_data'] = $goods_spec_data;
|
||||
// 使用票务专用模板
|
||||
$this->set_title($goods['title'].' - VR电子票');
|
||||
return MyView('public/../../../plugins/vr_ticket/view/goods/ticket_detail', [
|
||||
'common' => $common,
|
||||
'header' => $header,
|
||||
'goods' => $goods,
|
||||
]);
|
||||
}
|
||||
// --- VR 票务处理 end ---
|
||||
|
||||
### 5.2 前端票务详情页渲染结果
|
||||
|
||||
URL:http://localhost:10000/?s=index/goods/index/id/1(商品1改为 item_type=ticket 测试)
|
||||
|
||||
渲染效果:
|
||||
- 舞台(舞 台)
|
||||
- 座位图(三行):A排(AAAAAA,红色VIP区)/ B排(BBBBBB,蓝色看台区)/ C排(CCCCCC,绿色普通区)
|
||||
- 图例(VIP区 / 看台 / 普通)
|
||||
- 选座 UI(已选座位计数 + 合计价格)
|
||||
- 场次选择
|
||||
- 观演人表单(姓名+手机号)
|
||||
|
||||
---
|
||||
|
||||
## 六、Council 审议记录(2026-04-14)
|
||||
|
||||
### 6.1 Architect Round 1(已合并)
|
||||
|
||||
评审结论(Q2+Q4):
|
||||
- Q2:spec 座位共用 vs 独立 → 确认方案
|
||||
- Q4:spec 复用粒度 → 确认粒度
|
||||
|
||||
### 6.2 PM Round 2(已合并)
|
||||
|
||||
- 解决 plan.md 合并冲突
|
||||
|
||||
### 6.3 待 Council 审议的遗留问题
|
||||
|
||||
| 问题 | 状态 | 说明 |
|
||||
|------|------|------|
|
||||
| Q2(spec座位共用vs独立) | ✅ 已解决 | 见 ARCHITECTURE.md |
|
||||
| Q3(观演人存储位置) | ⏳ 待 Council | 尚未最终确认 |
|
||||
| Q4(spec复用粒度) | ✅ 已解决 | 见 ARCHITECTURE.md |
|
||||
|
||||
---
|
||||
|
||||
## 七、关键决策固化
|
||||
|
||||
| 决策 | 结论 | 备注 |
|
||||
|------|------|------|
|
||||
| 改 ShopXO 核心可以吗 | ✅ 可以,自己部署 | 原则已写入 README |
|
||||
| 票务详情页方案 | ✅ Goods.php 1行判断 → ticket_detail.html | 已验证 |
|
||||
| spec = 场次 | ✅ 确认 | 无需 vr_sessions 表 |
|
||||
| 座位模板绑定分类 | ✅ 确认 | Q1 已解决 |
|
||||
| item_type 字段 | ✅ ticket / normal | 触发票务逻辑开关 |
|
||||
| 座位图渲染 | ✅ HTML Table + CSS Grid | 不依赖第三方库 |
|
||||
| QR 安全 | ✅ AES_Encrypt | 防伪造 |
|
||||
| AI 介入程度 | 90%+ | 模板/Hook/PHP/Vue 均为标准技术 |
|
||||
|
||||
---
|
||||
|
||||
## 八、当前状态快照(2026-04-15 09:00 CST)
|
||||
|
||||
### 8.1 Git Commit 历史
|
||||
|
||||
7508bed docs: 追加 vr-shopxo-plugin Phase 0/1 状态记录
|
||||
0f5a82d feat(Phase 1): ShopXO Goods.php 修改(实际验证通过)
|
||||
34f7045 feat(Phase 0): vr_ticket plugin skeleton complete
|
||||
d5edb76 docs: add guiding principle + Goods.php modification guide
|
||||
1c6d32b docs: add ShopXO hooks reference (v6.8.0) - extracted from source
|
||||
e7b7bf9 docs: add plugin mechanism + requirements mapping docs
|
||||
536ef9e docs: add 项目启动报告 REPORT-KICKOFF.md (issue #5)
|
||||
8c6878e council(draft): Architect - 合并 Round 1 架构评审结论
|
||||
9eae259 council(draft): Architect - Round 1 架构评审结论 (Q2+Q4)
|
||||
|
||||
### 8.2 Phase 完成度
|
||||
|
||||
| Phase | 状态 | 说明 |
|
||||
|-------|------|------|
|
||||
| Phase 0:骨架 | ✅ 完成 | 14个文件,4张表,插件已注册 |
|
||||
| Phase 1:前端票务详情页 | ✅ 完成 | Goods.php验证通过,座位图渲染正常 |
|
||||
| Phase 2:后台管理页面 | ⏳ 待开始 | 场次管理/座位管理/票务订单列表 |
|
||||
| Phase 3:支付回调 + 发票 | ⏳ 待开始 | 钩子联调 + QR 票生成 |
|
||||
| Phase 4:B端扫码核销 | ⏳ 待开始 | 核销员管理 + 扫码 API |
|
||||
|
||||
### 8.3 关键文件路径
|
||||
|
||||
ShopXO 容器:
|
||||
源码:~/.openclaw/workspace/council-research/shopxo-eval/.worktrees/shopxo-evaluator/shopxo-src/
|
||||
插件:shopxo-src/app/plugins/vr_ticket/
|
||||
Goods.php:shopxo-src/app/index/controller/Goods.php
|
||||
|
||||
vr-shopxo-plugin 仓库:
|
||||
插件代码:app/plugins/vr_ticket/
|
||||
ShopXO 修改:shopxo-modifications/app/index/controller/Goods.php
|
||||
文档:docs/
|
||||
|
||||
---
|
||||
|
||||
## 九、下一步计划
|
||||
|
||||
### Phase 2:后台管理页面
|
||||
|
||||
1. 座位模板管理(admin/controller/SeatTemplate.php)
|
||||
- Layui 列表页(已生成 view)
|
||||
- 创建/编辑/删除操作
|
||||
|
||||
2. 电子票管理(admin/controller/Ticket.php)
|
||||
- 票列表(支持按订单号/手机号搜索)
|
||||
- 票详情(显示 QR 码)
|
||||
- 导出功能
|
||||
|
||||
3. 核销员管理(admin/controller/Verifier.php)
|
||||
- 增删改查
|
||||
|
||||
4. 核销记录(admin/controller/Verification.php)
|
||||
- 核销历史列表
|
||||
|
||||
### Phase 3:支付回调 + QR 票生成
|
||||
|
||||
1. 实现 TicketService::onOrderPaid() → 支付成功时生成票
|
||||
2. Hook:plugins_service_order_pay_success_handle_end
|
||||
3. AES 加密 QR 数据
|
||||
4. ShopXO 站内通知或 Realtime 推送
|
||||
|
||||
### Phase 4:B 端扫码核销
|
||||
|
||||
1. 核销 API(B 端小程序调用)
|
||||
- POST /api/ticket/verify(扫码枪调用)
|
||||
- RLS 策略:profiles.role = 'staff' 可核销
|
||||
|
||||
2. 核销员注册
|
||||
- 后台添加核销员(手机号)
|
||||
- 绑定 user_id
|
||||
|
||||
---
|
||||
|
||||
## 十、已知问题与待验证项
|
||||
|
||||
| 问题 | 优先级 | 状态 |
|
||||
|------|--------|------|
|
||||
| 后台插件菜单无权限 | P1 | admin 已有 340/341,vr_ticket 控制器权限未单独分配 |
|
||||
| 观演人存储位置(Q3) | P2 | 待 Council 审议 |
|
||||
| spec_base JSON 结构最终版 | P2 | 已确认 Q4 方案,待落地 |
|
||||
| 支付回调联调 | P2 | 等待 Phase 2 后台完成后测试 |
|
||||
| 核销 API RLS | P2 | 待实现 |
|
||||
|
|
@ -1,86 +0,0 @@
|
|||
# PM 视角评审:4 个关键技术问题
|
||||
|
||||
> 评审人:council/PM
|
||||
> 日期:2026-04-14
|
||||
|
||||
---
|
||||
|
||||
## Q1: 座位模板与分类的绑定粒度
|
||||
|
||||
**建议方案**:一个分类 = 一个完整场馆(内部分区),一个 `$vr-场馆` spec_value 对应一个 vr_seat_template。
|
||||
|
||||
| 维度 | 评分 | 说明 |
|
||||
|---|---|---|
|
||||
| 商家操作路径 | ⭐⭐⭐ 清晰 | 商家在商品编辑页添加 `$vr-场馆` spec_value(如"鸟巢-A区"、"鸟巢-B区"),一一对应模板 |
|
||||
| 实施复杂度 | 低 | 仅需按 spec_value.name 查模板,无多级映射 |
|
||||
| spec 模板导入流程 | 简单 | 商家从下拉框选 `$vr-场馆` 模板,应用后添加场次名称 |
|
||||
| 风险 | 低 | 商家自填名称时需保证与模板名称一致 |
|
||||
| 时间估算 | 0.5d | Hook + 查询逻辑 |
|
||||
|
||||
**PM 结论**:✅ **[non-blocking]** 推荐此方案,商家操作直觉,模板复用性好。
|
||||
|
||||
---
|
||||
|
||||
## Q2: spec_base_id_map 生成时机
|
||||
|
||||
**建议方案**:所有场次共用同一座位配置(extension_data.seat_map),日期不同但座位布局相同。
|
||||
|
||||
| 维度 | 评分 | 说明 |
|
||||
|---|---|---|
|
||||
| 商家操作路径 | ⭐⭐⭐ 清晰 | 商家上传一份座位图模板,所有场次自动复用 |
|
||||
| 实施复杂度 | 低 | 一次 seat_map,多场次共享,无需 per-SKU 配置 |
|
||||
| spec 模板导入流程 | 极简 | 一个商品只配一次座位图 |
|
||||
| 风险 | 低 | 若场次座位布局不同,需支持 per-spec_value 覆盖 |
|
||||
| 时间估算 | 0.5d | seat_map 注入逻辑 |
|
||||
|
||||
**PM 结论**:✅ **[non-blocking]** 推荐共用方案,兼顾简单性和灵活性(预留 per-spec_value 覆盖能力)。
|
||||
|
||||
---
|
||||
|
||||
## Q3: 观演人信息存储位置
|
||||
|
||||
**建议方案**:观演人写入 vr_tickets 表(支付成功后生成),extension_data 只存绑定关系。
|
||||
|
||||
| 维度 | 评分 | 说明 |
|
||||
|---|---|---|
|
||||
| 商家操作路径 | ⭐⭐⭐ 清晰 | 商家在商品编辑页填写观演人字段名,买家下单时填写 |
|
||||
| 实施复杂度 | 低 | vr_tickets 表已有结构,新增字段即可 |
|
||||
| 风险 | 低 | 退款时需清理观演人绑定记录 |
|
||||
| 时间估算 | 0.5d | 新增字段 + 购票流程写入逻辑 |
|
||||
|
||||
**PM 结论**:✅ **[non-blocking]** 推荐此方案,数据模型清晰,与购票流程天然解耦。
|
||||
|
||||
---
|
||||
|
||||
## Q4: spec 绑定方案(ShopXO 模板复制模式)
|
||||
|
||||
**建议方案**:用 `$vr-` 前缀做命名空间隔离,插件按 spec_value.name 查 vr_seat_templates。
|
||||
|
||||
| 维度 | 评分 | 说明 |
|
||||
|---|---|---|
|
||||
| 商家操作路径 | ⭐⭐ 中等 | 商家需记住:`$vr-` 前缀模板 + 按名字匹配。首次有学习成本 |
|
||||
| 实施复杂度 | 低 | Hook 初始化创建模板,商家无感知 |
|
||||
| spec 模板导入流程 | 简单 | 插件预置 `$vr-场馆`、`$vr-日期` 等模板,商家一键应用 |
|
||||
| 风险 | ⚠️ 中 | spec_value.name 若有空格/特殊字符,需做 trim 规范化 |
|
||||
| 时间估算 | 1d | Hook 初始化 + 模板创建 + 匹配逻辑 |
|
||||
|
||||
**PM 结论**:✅ **[non-blocking]** 建议通过 Hook 预置模板降低商家学习成本;spec_value.name 需做 trim 后再做匹配。
|
||||
|
||||
---
|
||||
|
||||
## 实施优先级
|
||||
|
||||
| 优先级 | 问题 | 理由 |
|
||||
|---|---|---|
|
||||
| P0 | Q4 spec 绑定方案 | 基础依赖,其他方案都依赖它 |
|
||||
| P1 | Q1 座位模板绑定 | 核心票务功能 |
|
||||
| P2 | Q2 seat_map 共享 | 减少商家重复配置 |
|
||||
| P2 | Q3 观演人存储 | 独立模块,可后置 |
|
||||
|
||||
---
|
||||
|
||||
## 总结
|
||||
|
||||
4 个 Q 均为 **[non-blocking]**。总实施复杂度约 **2.5d**,均为低风险。PM 视角确认所有方案的商家操作路径清晰,建议按优先级推进。
|
||||
|
||||
[APPROVE]
|
||||
|
|
@ -1,102 +0,0 @@
|
|||
# arch-reviewer — Round 2 综合评审报告
|
||||
|
||||
> 评审人:arch-reviewer
|
||||
> 评审范围:全部文档包(ARCHITECTURE.md / 01-05 / DEPLOYMENT.md)
|
||||
> 评审时间:2026-04-14 Round 2
|
||||
|
||||
---
|
||||
|
||||
## 一、Round 1 遗留 P0 问题处理
|
||||
|
||||
### P0:Goods.php 核心矛盾(已解决 ✅)
|
||||
|
||||
**原问题**:ARCHITECTURE.md 开篇声明「不修改核心代码」,但 §3 又记录了 `Goods.php` 的 1 行修改,两条路自相矛盾。
|
||||
|
||||
**解决方案**:已在 ARCHITECTURE.md §3 中添加明确注释:
|
||||
- 该 1 行修改是**本项目唯一例外**
|
||||
- 这是 ShopXO 允许范围内「按商品类型替换模板」的唯一方式
|
||||
- 所有其他功能均通过插件钩子实现
|
||||
|
||||
**结论**:矛盾已解决,文档自洽。
|
||||
|
||||
---
|
||||
|
||||
## 二、全文档包综合评审
|
||||
|
||||
### 通过文档(✅)
|
||||
|
||||
| 文档 | 结论 | 依据 |
|
||||
|---|---|---|
|
||||
| docs/01_SHOPXO_TECHNICAL_RESEARCH.md | ✅ 通过 | backend-reviewer 已评审;覆盖完整;支付回调钩子 `plugins_service_buy_order_insert_success` 已确认;QR 加密方案已记录 |
|
||||
| docs/03_VERIFICATION_SYSTEM.md | ✅ 通过 | 核销系统设计完整;`vr_tickets` DDL 具体;并发控制(seat locks + 乐观锁)已覆盖;AES IV 设计有充分说明 |
|
||||
| docs/05_AI_PARTICIPATION.md | ✅ 通过(附建议) | arch-reviewer Round 1 已确认;CustomView 作为 AI 黄金入口判断正确;pm-reviewer 补充了 uni-app AI 边界建议(低优先级) |
|
||||
|
||||
### 需补充文档(⚠️)
|
||||
|
||||
| 文档 | 问题 | 优先级 | 状态 |
|
||||
|---|---|---|---|
|
||||
| docs/04_IMPLEMENTATION_ROADMAP.md | ①并发控制策略需补充 ②里程碑无验收 checklist ③Agent 分工人名 ④Phase 依赖关系不精确 | 🟡 中 | pm-reviewer 下轮修复 |
|
||||
| docs/DEPLOYMENT.md | ①ShopXO 源码路径硬编码 ②缺少 Docker Desktop 前提说明 ③无 CI/CD 流程 ④无数据库迁移说明 | 🟡 中 | pm-reviewer 下轮修复 |
|
||||
|
||||
### 重大问题审查(arch-reviewer Round 1 重审)
|
||||
|
||||
| 问题 | 原评级 | 复审结论 |
|
||||
|---|---|---|
|
||||
| Goods.php 矛盾 | ❌ P0 | ✅ 已解决(见上) |
|
||||
| CustomView 与票务选座边界模糊 | 🟡 P1 | ⚠️ 仍在 05_AI 中有建议但未在 ARCHITECTURE.md 中明确;建议下轮补充 |
|
||||
| 支付回调链路不完整 | 🟡 P1 | ✅ 已解决(01_SHOPXO_TECHNICAL_RESEARCH.md §8) |
|
||||
| QR 数据结构缺失 | 🟡 P1 | ✅ 已解决(03_VERIFICATION_SYSTEM.md §2-3) |
|
||||
|
||||
---
|
||||
|
||||
## 三、Cross-Review 结论
|
||||
|
||||
### 读 backend-reviewer 输出
|
||||
- ✅ 01_SHOPXO_TECHNICAL_RESEARCH.md 安全部分:SQL 注入防护 ✅、QR base64 ✅
|
||||
- ✅ 支付回调钩子 `plugins_service_buy_order_insert_success` 确认
|
||||
- ✅ AES IV 非随机风险已知(03 已给出 ticket-bound IV 合理性说明)
|
||||
|
||||
### 读 pm-reviewer 输出
|
||||
- ✅ 确认 05_AI_PARTICIPATION.md 通过
|
||||
- ⚠️ pm-reviewer 发现的 5 个问题中,2 个高优先级已在其他文档中解决(并发控制 → 03 §9、DEPLOYMENT 路径问题 → 需修复)
|
||||
- 🟡 剩余 3 个中等优先级问题建议 pm-reviewer 在下轮修复
|
||||
|
||||
### 读 ticket-reviewer 输出
|
||||
- ✅ 03_VERIFICATION_SYSTEM.md 完整;防超卖机制(seat locks + 事务)设计合理
|
||||
- ✅ 核销 API 路由设计一致(C 端 vs B 端分离)
|
||||
- ✅ AES IV 设计有充分说明(ticket-bound IV 模式)
|
||||
|
||||
---
|
||||
|
||||
## 四、最终判断
|
||||
|
||||
**可以开始编码的条件**:
|
||||
1. ✅ P0 架构矛盾已解决
|
||||
2. ✅ 所有 4 个 Critical Open Questions 均已解答
|
||||
3. ⚠️ pm-reviewer 的 5 个阻塞/中优先级问题仍在(但均非架构性缺陷,为实施细节)
|
||||
4. ⚠️ CustomView 边界需在 ARCHITECTURE.md 中明确(票务核心交互页不适用)
|
||||
|
||||
**建议**:
|
||||
- 立即可开始 Phase 0-1(环境搭建 + 数据库设计),这两部分无阻塞
|
||||
- pm-reviewer 补充文档后,剩余 Phase 可全面展开
|
||||
- ARCHITECTURE.md 补充 CustomView 边界说明(1 处)
|
||||
|
||||
---
|
||||
|
||||
## 五、投票
|
||||
|
||||
**[CONSENSUS: YES]** — 文档包质量达到编码启动标准
|
||||
|
||||
> P0 已解除,4 个关键问题全部解答。剩余问题均为实施细节(并发配置、部署路径、Agent 分工),不影响编码启动。pm-reviewer 的中等优先级问题可在 Phase 0 执行过程中并行补充。
|
||||
|
||||
---
|
||||
|
||||
## 六、下轮行动项(建议)
|
||||
|
||||
| 事项 | 负责人 | 优先级 |
|
||||
|---|---|---|
|
||||
| 补充 ARCHITECTURE.md CustomView 边界说明 | arch-reviewer | 🟡 |
|
||||
| 修复 04_ROADMAP 并发控制 + 里程碑 checklist | pm-reviewer | 🟡 |
|
||||
| 修复 DEPLOYMENT.md 源码路径 + 迁移命令 | pm-reviewer | 🟡 |
|
||||
| 更新 Agent 分工表(人名→技能角色) | pm-reviewer | 🟡 |
|
||||
| 补充 05_AI uni-app AI 边界说明 | arch-reviewer | 🟢 低 |
|
||||
|
|
@ -1,192 +0,0 @@
|
|||
# PM Reviewer — 文档结构化评审报告
|
||||
|
||||
> 评审人:pm-reviewer
|
||||
> 评审范围:docs/04_IMPLEMENTATION_ROADMAP.md、docs/DEPLOYMENT.md、docs/05_AI_PARTICIPATION.md
|
||||
> 评审时间:2026-04-14
|
||||
|
||||
---
|
||||
|
||||
## 总体评分
|
||||
|
||||
| 文档 | 评分 | 结论 |
|
||||
|---|---|---|
|
||||
| docs/04_IMPLEMENTATION_ROADMAP.md | ⚠️ 需补充 | 路线图完整但关键细节缺失 |
|
||||
| docs/DEPLOYMENT.md | ⚠️ 需补充 | 容器方案可行但路径过时、CI/CD 缺失 |
|
||||
| docs/05_AI_PARTICIPATION.md | ✅ 通过 | AI 边界划分清晰,CustomView 切入点准确 |
|
||||
|
||||
**综合结论**:三份文档整体质量较高,可开始编码,但需先补充以下内容。
|
||||
|
||||
---
|
||||
|
||||
## 一、docs/04_IMPLEMENTATION_ROADMAP.md 评审
|
||||
|
||||
### ✅ 通过项
|
||||
|
||||
1. **Phase 0-7 分解合理**:时间估算(1-2 周 MVP)与任务粒度匹配
|
||||
2. **SQL 表结构完整**:5 张表定义清晰,包含索引和外键关系
|
||||
3. **钩子名称具体**:`plugins_service_buy_order_insert_begin` 等 ShopXO 真实钩子名称已标注
|
||||
4. **API 端点设计具体**:完整的路由格式 `?s=admin/vrticket/...`
|
||||
|
||||
### ⚠️ 需补充项
|
||||
|
||||
#### 1. Agent 分工基于人名,维护性差(中等优先级)
|
||||
**问题**:分工表写"李狗蛋/妮可/小老D/西莉娅",非技能角色名称。
|
||||
**影响**:人员变动后文档失效;Agent 系统无法识别任务归属。
|
||||
**建议**:改为技能角色(如"后端 Agent"、"前端 Agent"),或明确说明 Agent 名称仅为代号。
|
||||
|
||||
#### 2. Phase 依赖关系描述模糊(高优先级)
|
||||
**问题**:"✅ Phase 0" 仅标注"可并行",未说明是"完成后才可开始"还是"期间可并行"。
|
||||
**影响**:Agent 并行执行时可能因依赖顺序错误浪费轮次。
|
||||
**建议**:改为箭头或编号依赖,例如:
|
||||
```
|
||||
Phase 1 → Phase 2 → Phase 3
|
||||
Phase 2 → Phase 5 (场次CRUD完成后前端可开始)
|
||||
```
|
||||
|
||||
#### 3. Phase 7 "需串行" 但未说明原因(中等优先级)
|
||||
**问题**:Phase 7 标记"需串行",但"联调+测试+部署"中部署本身可并行。
|
||||
**影响**:误导 Agent 认为此阶段无法拆分。
|
||||
**建议**:拆分 Phase 7 为"联调(可并行)"和"部署(串行)",明确各子任务间的并行性。
|
||||
|
||||
#### 4. 缺少并发控制方案(高优先级)
|
||||
**问题**:Phase 4 提到"并发抢票"测试用例,但计划中未提及 Redis 锁或乐观锁。
|
||||
**影响**:真实并发场景下库存超卖风险未在设计阶段覆盖。
|
||||
**建议**:在 Phase 4 或 Phase 1 数据库设计中补充并发控制策略(如 `UPDATE vr_sessions SET available_stock = available_stock - N WHERE available_stock >= N`)。
|
||||
|
||||
#### 5. 里程碑无验收标准(中等优先级)
|
||||
**问题**:"M1:插件跑通" 无具体验收条件。
|
||||
**影响**:Agent 完成里程碑后无法自我验证。
|
||||
**建议**:为每个里程碑添加 checklist:
|
||||
```
|
||||
M1 验收:
|
||||
- [ ] ShopXO 后台插件列表可见 vr_ticket
|
||||
- [ ] 访问 /?s=admin/vrticket/event/list 返回 200
|
||||
- [ ] 数据库包含 5 张 vr_* 表
|
||||
```
|
||||
|
||||
### ❌ 重大问题
|
||||
|
||||
**无**
|
||||
|
||||
---
|
||||
|
||||
## 二、docs/DEPLOYMENT.md 评审
|
||||
|
||||
### ✅ 通过项
|
||||
|
||||
1. **Docker 容器设计合理**:nginx + PHP-FPM + MySQL 8.0 分层清晰
|
||||
2. **数据库连接信息完整**:容器网络名、宿主机端口均有标注
|
||||
3. **日志查看命令实用**:提供了分容器查看日志的具体命令
|
||||
4. **ARM64 兼容性说明**:M1/M2/M3 Mac 已知问题已记录
|
||||
|
||||
### ⚠️ 需补充项
|
||||
|
||||
#### 1. ShopXO 源码路径硬编码为物理目录(高优先级)
|
||||
**问题**:`SHOPXO_SRC` 默认指向 `/Users/bigemon/.openclaw/workspace/council-research/...`,与 worktree 设计不符。
|
||||
**影响**:其他 Agent 在其 worktree 中无法使用同一份 docker-compose.yml。
|
||||
**建议**:
|
||||
- 方案A:将 ShopXO 源码路径改为相对于 docker-compose.yml 的相对路径(如 `./shopxo-src`)
|
||||
- 方案B:在 .env 中标注"请将此路径改为你的 ShopXO 源码目录",并添加 `grep -r "WORKSPACE" .env` 快速定位
|
||||
|
||||
#### 2. 缺少 Docker Desktop 安装说明(低优先级)
|
||||
**问题**:文档假设用户已安装 Docker Desktop,但未提供安装指引。
|
||||
**影响**:新手首次克隆后无法直接运行。
|
||||
**建议**:在"一、快速启动"前增加一行:
|
||||
> 前提条件:已安装 [Docker Desktop for Mac](https://www.docker.com/products/docker-desktop)
|
||||
|
||||
#### 3. 缺少 CI/CD 部署流程(中等优先级)
|
||||
**问题**:文档只描述本地开发环境,未涉及生产部署的自动化流程。
|
||||
**影响**:Phase 7 联调后的部署阶段缺乏指引。
|
||||
**建议**:添加"九、生产部署"章节,说明:
|
||||
- PHP 虚拟主机:上传插件 zip 的手动步骤(ShopXO 后台支持)
|
||||
- shopxo-uniapp:HBuilderX CLI 发行命令
|
||||
- 可选:GitHub Actions 自动构建
|
||||
|
||||
#### 4. 未说明数据库迁移工具(中等优先级)
|
||||
**问题**:Phase 1 的 SQL 迁移文件存在,但 DEPLOYMENT.md 未说明如何执行。
|
||||
**影响**:其他 Agent 不确定应该手动执行 SQL 还是通过 ShopXO 迁移机制。
|
||||
**建议**:在"六、修改 ShopXO 源码路径"后补充:
|
||||
```bash
|
||||
# 执行插件数据库迁移
|
||||
docker exec shopxo-php php /var/www/html/think migrate
|
||||
```
|
||||
|
||||
### ❌ 重大问题
|
||||
|
||||
**无**(文档覆盖了核心场景,缺失项均为优化级别)
|
||||
|
||||
---
|
||||
|
||||
## 三、docs/05_AI_PARTICIPATION.md 评审
|
||||
|
||||
### ✅ 通过项
|
||||
|
||||
1. **DIY 拖拽系统边界清晰**:明确指出为什么 AI 无法参与(JSON 私有结构、无文档)
|
||||
2. **CustomView 是亮点发现**:将 CustomView 定性为"AI 参与的黄金入口",有战略价值
|
||||
3. **决策矩阵实用**:4 格矩阵(代码可控性 × 文档公开度)清晰划分可行/不可行区域
|
||||
4. **Hook 名称具体**:给出了真实可查的 Hook 名称和注入示例
|
||||
|
||||
### ⚠️ 需补充项
|
||||
|
||||
#### 1. shopxo-uniapp 的 AI 生成边界未明确(高优先级)
|
||||
**问题**:文档详述了 ShopXO 后端 Hook 系统,但未说明 AI 生成 uni-app Vue 代码时的边界。
|
||||
**影响**:前端 Agent 不知晓 uni-app AI 生成的限制(如组件库版本、平台 API 兼容性)。
|
||||
**建议**:在"三、AI 完全可参与:代码层"表格中增加一行:
|
||||
| 区域 | 技术栈 | AI 参与方式 | 限制 |
|
||||
|---|---|---|---|
|
||||
| uni-app 票务页面 | Vue 3 / uni-ui | AI 生成组件代码 | 需 HBuilderX 编译验证;微信 API 需手动测试 |
|
||||
|
||||
#### 2. Phase 1/2/3 缺少时间维度(低优先级)
|
||||
**问题**:三个 Phase 的 AI 协作阶段描述了"做什么",但未说明"何时切换"。
|
||||
**影响**:Agent 执行时无法判断当前应使用哪种参与模式。
|
||||
**建议**:在 Phase 标题后加括号标注触发条件:
|
||||
```
|
||||
Phase 1: AI 100% 主导(无人工干预)← 适用:数据库设计、插件 Service、API 端点
|
||||
Phase 2: AI + 人工协作(50/50)← 适用:Hook 注入 UI、uni-app 页面
|
||||
Phase 3: 人工为主,AI 辅助 ← 适用:DIY 页面、主题配色
|
||||
```
|
||||
|
||||
#### 3. 未提及 Human-in-the-loop 触发机制(低优先级)
|
||||
**问题**:Phase 2/3 需要人工介入,但文档未说明人工介入的触发信号(错误率 > X%?特定文件类型?)。
|
||||
**影响**:Agent 可能在应该请求人工复核时继续自动执行。
|
||||
**建议**:添加触发条件描述:
|
||||
```
|
||||
触发人工介入的条件:
|
||||
1. AI 生成代码出现 3 次以上相同类型的编译错误
|
||||
2. 涉及支付/核销等资金相关逻辑
|
||||
3. 修改 ShopXO 核心文件(非插件目录)
|
||||
```
|
||||
|
||||
### ❌ 重大问题
|
||||
|
||||
**无**
|
||||
|
||||
---
|
||||
|
||||
## 四、综合建议
|
||||
|
||||
### 编码前必须补充(阻塞项)
|
||||
|
||||
| 优先级 | 事项 | 所属文档 |
|
||||
|---|---|---|
|
||||
| 🔴 高 | 并发控制策略(Redis/乐观锁) | docs/04_IMPLEMENTATION_ROADMAP.md |
|
||||
| 🔴 高 | ShopXO 源码路径修复为相对路径 | docs/DEPLOYMENT.md |
|
||||
| 🟡 中 | Agent 分工改为技能角色而非人名 | docs/04_IMPLEMENTATION_ROADMAP.md |
|
||||
| 🟡 中 | 里程碑验收 checklist | docs/04_IMPLEMENTATION_ROADMAP.md |
|
||||
| 🟡 中 | uni-app AI 生成边界说明 | docs/05_AI_PARTICIPATION.md |
|
||||
|
||||
### 编码后可补充(优化项)
|
||||
|
||||
- Phase 7 部署阶段 CI/CD 流程
|
||||
- Docker 环境数据库迁移命令
|
||||
- Phase 依赖关系的精确标注(箭头图或编号)
|
||||
|
||||
---
|
||||
|
||||
## 五、投票结论
|
||||
|
||||
**[CONSENSUS: NO]** — 建议先补充以上 5 个阻塞/中等优先级事项,再进入 Phase 0 执行。
|
||||
|
||||
**理由**:三份文档整体质量优秀,但 Phase 0-4 的并发安全和 DEPLOYMENT.md 的路径问题是真实风险点,会在实际执行中造成 Agent 重复劳动或部署失败。在这些问题修复后,预计可顺利进入编码阶段。
|
||||
|
||||
> **Round 2 行动项**:pm-reviewer 将在下一轮直接修复上述 5 个事项,将修订合并入 main,再投票 `[CONSENSUS: YES]`。
|
||||
Loading…
Reference in New Issue