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 文件

app/plugins/vr_ticket/EventListener.php

@@ -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;
 }
 

docs/DEVELOPMENT_LOG.md

@@ -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 | 待实现 |

reviews/PM-Q1-Q4-review.md

@@ -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]

reviews/arch-reviewer-on-docs-round2.md

@@ -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 | 🟢 低 |

reviews/pm-reviewer-on-docs.md

@@ -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]`。