docs: add Council evaluation report (Architect + BackendArchitect)

综合评审： - docs/14: 表名前缀不一致（vr_seat_templates vs vrt_vr_seat_templates） - DEVELOPMENT_LOG: Git 状态落后一个提交 - PHASE2_PLAN: 核销 API 安全上下文缺失 Top 3 问题已定位，行动清单已列出
council(review): Architect - 完成三份文档评审，输出 Top 3 修正建议
2026-04-20 05:30:23 +08:00 · 2026-04-20 05:29:36 +08:00 · 2026-04-20 05:25:54 +08:00
6 changed files with 536 additions and 203 deletions
--- a/docs/COUNCIL_EVALUATION_REPORT.md
+++ b/docs/COUNCIL_EVALUATION_REPORT.md
@ -0,0 +1,192 @@
+# 文档评估综合报告
+
+> 评估时间：2026-04-20 | Council: Architect + BackendArchitect
+> 评审文档：docs/14_TEMPLATE_RENDER_INVESTIGATION.md / docs/PHASE2_PLAN.md / docs/DEVELOPMENT_LOG.md
+
+---
+
+## 一、docs/14_TEMPLATE_RENDER_INVESTIGATION.md
+
+### 各维度评分
+
+| 维度 | Architect | BackendArchitect |
+|------|-----------|-----------------|
+| 准确性 | 7/10 | 7/10 |
+| 完整性 | 6/10 | 6/10 |
+| 可操作性 | 8/10 | 7/10 |
+| 一致性 | 8/10 | 5/10 |
+
+### 跨文档共识问题
+
+**表名前缀不一致（一致性 5/10）**
+
+| 文档 | 表名 |
+|------|------|
+| docs/14 Section 2.2 | `vr_seat_templates`（无前缀）❌ |
+| DEVELOPMENT_LOG.md 建表 SQL | `vrt_vr_seat_templates`（有前缀）✅ |
+| PHASE2_PLAN.md | `vrt_vr_seat_templates`（有前缀）✅ |
+
+这是**唯一的重大跨文档一致性问题**，必须修正。
+
+### Architect 发现
+
+- `$assign` 变量在 Section 2.1 代码示例中未定义（与实际 `MyViewAssign()` 不符）
+- JOIN 联查条件（`spec_base_id` / `goods_id`）未记录
+- Section 2.1 标题写"✅ 已提交"，Section 4 状态表写"⚠️ 待验证"——矛盾
+
+### BackendArchitect 发现
+
+- "ShopXO 原生平表"说法不精确，应改为"本项目对应的 `sxo_order_detail`"
+- `|raw` 过滤器安全性前提未注明（需后台管理端完全控制）
+- Phase 1/Phase 2 两套 Goods.php 改法（MyView vs 绝对路径）关系未说明
+
+---
+
+## 二、docs/PHASE2_PLAN.md
+
+### 各维度评分
+
+| 维度 | Architect | BackendArchitect |
+|------|-----------|-----------------|
+| 准确性 | 7/10 | 7/10 |
+| 完整性 | 7/10 | 6/10 |
+| 可操作性 | 7/10 | 7/10 |
+| 一致性 | 8/10 | 8/10 |
+
+### Architect 发现
+
+**高风险：Step 4 核销 API 缺少认证描述**
+- 无 JWT token / session 说明
+- 无权限模型（RLS profiles.role='staff'）说明
+- 直接实现可能暴露无鉴权接口
+
+**高风险：决策点第3项过时**
+- "Layui 是否继续使用"列在决策项，但 4 个后台控制器已用 Layui
+- 容易让读者困惑当前技术栈状态
+
+**缺失：Step 1 前置条件清单**
+- 需确认：goods_id=118 的票务商品 + 座位模板绑定 + 场次 spec_base
+- 无测试数据则 Step 1 无法执行
+
+### BackendArchitect 发现
+
+**高风险：Step 1 操作绑定个人**
+- "操作人：大头" → 其他成员无法执行
+- 应改为说明容器访问方式（Docker exec / SSH）
+
+**缺失：决策点无决策框架**
+- loadSoldSeats 实时查库 vs 前端 JS 状态管理各自的优劣未列出
+- 长期悬而未决会阻塞 Step 1-4
+
+**轻微：Step 3 联调缺少 URL 格式和期望行为定义**
+
+---
+
+## 三、docs/DEVELOPMENT_LOG.md（第十一、十二章）
+
+### 各维度评分
+
+| 维度 | BackendArchitect |
+|------|-----------------|
+| 准确性 | 8/10 |
+| 完整性 | 6/10 |
+| 可操作性 | 7/10 |
+| 一致性 | 7/10 |
+
+### BackendArchitect 发现
+
+**高风险：Git 状态快照落后一个提交**
+- 11.3 写最新提交是 `7bd896764`
+- 实际最新是 `914e2a0fc`（docs 修正提交）
+- 基于旧快照做 git blame 会误判
+
+**缺失：执行人/决策人未记录**
+- Phase 2 比 Phase 1 更复杂，缺少执行人记录影响知识传递
+
+**缺失：Phase 2 与 Phase 1 关系未说明**
+- Section 11.1 未说明 Phase 1 的 `MyView()` 改法是否被替代
+- docs/14 提到 Phase 2 绝对路径方案，但 DEVELOGOPMENT_LOG 无对应说明
+
+**轻微：cleanup 记录措辞歧义**
+- "重写修正版"让人以为物理覆盖原文件
+
+---
+
+## 四、Top 3 最需要修正的问题
+
+### 🔴 #1：跨文档表名前缀不一致
+
+**问题**：`docs/14` 第 2.2 节用 `vr_seat_templates`（无前缀），其他文档统一用 `vrt_vr_seat_templates`（有前缀）。
+
+**修正**：docs/14 Section 2.2 第 3 步，将 `vr_seat_templates` → `vrt_vr_seat_templates`。
+
+**影响**：不修正在此文档指导下工作的人会查询不存在的表。
+
+---
+
+### 🔴 #2：docs/DEVELOPMENT_LOG.md Section 11.3 Git 状态落后
+
+**问题**：记录最新提交为 `7bd896764`，实际为 `914e2a0fc`，相差一个 docs 修正提交。
+
+**修正**：Section 11.3 更正为：
+```
+914e2a0fc docs: 修正 docs/14 + 新增 PHASE2_PLAN.md  ← HEAD
+7bd896764 feat(Phase 2): 完成票务商品前端展示层
+```
+
+**影响**：开发者基于此做 git blame / git log 会误判最新状态。
+
+---
+
+### 🟡 #3：docs/PHASE2_PLAN.md Step 4 核销 API 安全上下文缺失
+
+**问题**：`POST /api/vr_ticket/verify` 无认证机制、权限模型、请求参数格式说明。
+
+**修正**：补充以下内容：
+```
+### 核销 API 设计要点
+
+认证：JWT Bearer Token（从微信小程序静默登录获取）
+权限：RLS — `auth.jwt->>'role' = 'staff'`
+
+请求：
+POST /api/vr_ticket/verify
+{
+  "ticket_code": "string",
+  "verifier_id": int,
+  "token": "Bearer <jwt>"
+}
+
+响应：
+{
+  "code": 0,
+  "msg": "核销成功",
+  "data": { seat_info, real_name, goods_name }
+}
+```
+
+**影响**：不做此补充，后续实现可能产生无鉴权接口，在测试环境暴露安全风险。
+
+---
+
+## 五、各文档综合评价
+
+| 文档 | 综合评分 | 评价 |
+|------|---------|------|
+| docs/14 | 6.8/10 | 技术分析价值高，但表名前缀错误和状态矛盾是硬伤。修正说明机制设计良好。 |
+| PHASE2_PLAN | 7.0/10 | 结构清晰，现状准确，Step 1 成功标准写得很好。核销 API 安全上下文缺失是最大风险。 |
+| DEVELOPMENT_LOG | 7.0/10 | commit 号准确，时间线一致。Git 快照落后 + 缺少执行人记录是主要问题。 |
+
+---
+
+## 六、下一步行动
+
+| 优先级 | 行动 | 负责人 |
+|--------|------|--------|
+| P0 | 修正 docs/14 表名前缀（`vr_seat_templates` → `vrt_vr_seat_templates`） | 西莉雅 |
+| P0 | 更新 DEVELOPMENT_LOG Section 11.3 Git 状态快照 | 西莉雅 |
+| P1 | PHASE2_PLAN Step 1 补充前置条件清单（测试数据检查） | 西莉雅 |
+| P1 | PHASE2_PLAN Step 4 补充核销 API 安全设计要点 | 西莉雅 |
+| P2 | DEVELOPMENT_LOG 补充执行人记录 | 待定 |
+| P2 | docs/14 补充 spec_base_id_map JSON 结构说明 | 待定 |
+| P3 | docs/14 明确 Phase 1 / Phase 2 两套 Goods.php 改法的替代关系 | 待定 |
--- a/plan.md
+++ b/plan.md
@ -1,228 +1,54 @@
-# vr-shopxo-plugin Phase 2 Bugfix — plan.md
+# Plan — 文档评估 (Architect)

-> 版本：v1.0 | 日期：2026-04-16 | Agent：council/FrontendDev
-> 背景：Phase 2 后台管理两个致命问题 — 侧栏乱码 + 路由无法渲染
+> 版本：v1.0 | 日期：2026-04-20 | Agent：council/Architect

 ---

-## 问题总览
+## 任务概述

-| # | 问题 | 症状 | 优先级 |
-|---|------|------|--------|
-| **P1** | 插件控制器路由无法渲染 | 内容区空白，"template not exists" | 高 |
-| **P2** | 侧边栏插件名乱码 | `VRç¥¨åŠ¡`（应为 `VR票务`） | 中 |
+对 vr-shopxo-plugin 项目三份文档进行评审：
+1. `docs/14_TEMPLATE_RENDER_INVESTIGATION.md`
+2. `docs/PHASE2_PLAN.md`
+3. `docs/DEVELOPMENT_LOG.md`（第十一、十二章）
+
+评审维度：准确性、完整性、可操作性、一致性、误导风险。
+**不读代码文件，只读文档。输出到 `reviews/` 目录。**

 ---

-## P1 — 路由无法渲染问题
+## 任务清单

-### 已知现象
- 访问 `adminwatekc.php?s=VrTicket/SeatTemplateList` → 侧栏正常，主内容区空白
- ShopXO `Plugins/Index` 控制器调用插件时有 `strtolower+ucfirst` 类名匹配问题
- 当前 `SeatTemplate.php` 在 `admin/controller/` 子目录
+- [x] **Task 1**: 评审 `docs/14_TEMPLATE_RENDER_INVESTIGATION.md` → `reviews/Architect-on-doc14.md`
+  - [Done: council/Architect]

-### 已知正确模式（freightfee/answers）
-```
-app/plugins/{plugin}/
-├── Admin.php              ← 直接在插件根目录，继承 think\Controller
-├── Hook.php
-├── config.json
-└── admin/view/...         ← 视图在 admin/view/ 子目录
-```
+- [x] **Task 2**: 评审 `docs/PHASE2_PLAN.md` → `reviews/Architect-on-PHASE2_PLAN.md`
+  - [Done: council/Architect]

-### 当前 vr_ticket 结构（有问题）
-```
-app/plugins/vr_ticket/
-├── admin/controller/SeatTemplate.php  ← ❌ 在子目录
-└── admin/view/seat_template/list.html
-```
+- [x] **Task 3**: 评审 `docs/DEVELOPMENT_LOG.md`（第十一、十二章）→ `reviews/Architect-on-DEV_LOG.md`
+  - [Done: council/Architect]

-### 任务清单
-
- [x] **P1-T1**: 验证 `strtolower+ucfirst` 路由匹配机制
-  - PluginsService::PluginsControlCall: `class = \app\plugins\{plugin}\{group}\{ucfirst(control)}`
-  - sidebar URL `/plugins/vr_ticket/admin/seatTemplateList`
-  - → pluginsname=vr_ticket, pluginscontrol=admin, pluginsaction=seatTemplateList
-  - → class = \app\plugins\vr_ticket\admin\Admin ✓
-  - → method = ucfirst('seatTemplateList') = 'SeatTemplateList' ✓
- [x] **P1-T2**: 对比 Admin.php 根目录模式 vs 当前 admin/controller/ 子目录模式
-  - 根目录 Admin.php (`app/plugins/vr_ticket/admin/Admin.php`) 可以被正确加载 ✓
-  - 旧子目录控制器无法被 PluginsService 找到（类路径不匹配）✗
- [x] **P1-T3**: 实施修复 — 创建 `admin/Admin.php`（注意：不是根目录，是 admin/ 子目录）
-  - `admin/Admin.php` 路径 → 类名 `\app\plugins\vr_ticket\admin\Admin` ✓
-  - 方法使用 camelCase：`SeatTemplateList()`, `TicketList()` 等
-  - sidebar URL 必须用 camelCase：`pluginsaction=seatTemplateList`
-  - 修复 plugin.json sidebar URL：改为 `/plugins/vr_ticket/admin/seatTemplateList` 格式
- [ ] **P1-T4**: 验证修复后路由能否正常渲染（需实际访问 URL 截图）
-
---
-
-## P2 — 侧栏插件名乱码问题
-
-### 已知现象
- 侧栏显示：`VRç¥¨åŠ¡`（应为 `VR票务`）
- 这是 UTF-8 字符串被当作 Latin1/ISO-8859-1 解码的结果
- 乱码规律：`票` (E7 A5 8A) → Latin1 解码为 `ç¥¨åŠ¡`
-
-### 乱码根因假设
-| 假设 | 可能性 | 验证方式 |
-|------|--------|----------|
-| 数据库 `vrt_power` 表 name 字段 latin1 编码存储 | 高 | 检查 MySQL `SHOW CREATE TABLE vrt_power` |
-| 数据库连接 charset 不匹配 | 中 | 检查 ShopXO 数据库配置 charset |
-| plugin.json 编码问题 | 低 | plugin.json 已是正确 UTF-8 |
-
-### 任务清单
-
- [ ] **P2-T1**: 确认乱码根因 — 检查 vrt_power 表结构
-  - `SHOW CREATE TABLE vrt_power`
-  - `SHOW FULL COLUMNS FROM vrt_power`
-  - 确认 name 字段 charset 和 collate
- [ ] **P2-T2**: 如果是数据库 latin1 问题 — 修复方案
-  - 方案A：ALTER TABLE 转换 latin1 → utf8mb4
-  - 方案B：MySQL CONVERT/CAST 函数读取时转换
-  - 方案C：PHP 层以 latin1 读出再转 utf8
-
---
-
-## 视图路径问题（Round 5 根因确认 + 修复）
-
-### 根因（BackendArchitect 分析）
-ThinkPHP 5 视图路径解析规则：
-1. 相对路径（如 `'seat_template/list'`）：相对于**控制器 namespace 对应的默认视图目录**
-2. namespace `app\plugins\vr_ticket\admin` → 默认视图目录 `app/plugins/vr_ticket/admin/view/`
-3. 实际文件在 `app/admin/view/default/plugins/view/vr_ticket/admin/view/` ← 路径不匹配！
-
-### 实际文件位置
-```
-app/admin/view/default/plugins/view/vr_ticket/admin/view/
-├── seat_template/
-│   ├── list.html
-│   └── save.html
-├── ticket/
-│   ├── list.html
-│   └── detail.html
-├── venue/
-│   ├── list.html
-│   └── save.html
-├── verifier/
-│   ├── list.html
-│   └── save.html
-└── verification/
-    └── list.html
-```
-
-### 修复方案
-ThinkPHP 5 以 `/` 开头的视图路径为**绝对路径**，相对于配置的视图根目录（`app/admin/view/default/`）解析。
-
-修复前（错误）：
-```php
-return view('seat_template/list', $data);  // 解析到 app/plugins/vr_ticket/admin/view/ ← 不存在
-```
-
-修复后（正确）：
-```php
-return view('/plugins/view/vr_ticket/admin/view/seat_template/list', $data);
-// → app/admin/view/default/plugins/view/vr_ticket/admin/view/seat_template/list.html ✓
-```
-
-**所有 9 个 view() 调用已全部修复为绝对路径格式。**
-
-### Vrticket.php 的参考价值
-`shopxo/app/admin/controller/Vrticket.php` 使用 `MyView('../../../plugins/vr_ticket/admin/' . $template)` 手动处理路径。
-Admin.php 使用 ThinkPHP `view()` 函数，以 `/` 开头则由 ThinkPHP 自动解析到 `app/admin/view/default/`。
+- [x] **Task 4**: 综合三份评审，输出 Top 3 修正建议 → `reviews/Architect-DOC-SUMMARY.md`
+  - [Done: council/Architect]

 ---

 ## 阶段划分

-| 阶段 | 内容 | 负责 |
-|------|------|------|
-| **Round 1（规划）** | 分析根因，制定修复方案 | FrontendDev |
-| **Round 2（执行）** | 实施 admin/Admin.php + plugin.json 修复 | FrontendDev |
-| **Round 3（综合）** | 合并到 main，完整验证 | 所有成员 |
+| 阶段 | 内容 |
+|------|------|
+| **Draft** | ✅ Task 1-3：逐份文档输出独立评审报告 |
+| **Review** | ✅ Task 4：综合汇总，Top 3 修正建议 |
+| **Finalize** | ✅ 提交到 main，标注完成 |

 ---

-## 依赖关系
+## 依赖

- P1-T3 和 P1-T4 需要实际访问 URL 验证（无法在 CLI 环境截图）
- P2-T1 需要连接数据库检查编码
+- 三份文档已读取完毕，无需额外探索
+- 不需要 BackendArchitect / SecurityEngineer 配合，可独立完成

 ---

-## 交付物
+## 执行顺序

-1. 修复后的 `shopxo/app/plugins/vr_ticket/admin/Admin.php`（路由正确）
-2. 修复后的 `shopxo/app/plugins/vr_ticket/plugin.json`（sidebar URL 使用 camelCase）
-3. 乱码问题修复（需数据库层修复）
-
-## 状态
-
-| 任务 | 状态 | 备注 |
-|------|------|------|
-| P1-T1 | [Done] | PluginsService 路由机制已分析 |
-| P1-T2 | [Done] | admin/Admin.php 模式正确 |
-| P1-T3 | [Done] | admin/Admin.php 已创建 + plugin.json 已修复 |
-| P1-T4 | [Pending] | 需实际访问 URL 截图验证 |
-| P2-T1 | [Done] | 根因：plugins.name 字段 Latin1 存储 |
-| P2-T2 | [Done] | SQL 修复脚本见 docs/SQL_FIX_garbled_plugin_name.md |
-| P1-视图路径 | [Done] | 所有 9 个 view() 改为绝对路径 `/plugins/view/vr_ticket/admin/view/...` |
-
---
-
-## BackendArchitect Round 5 实现
-
-### 交付物
-1. ✅ `shopxo/app/plugins/vr_ticket/admin/Admin.php` — 9 个 view() 调用全部改为 `/plugins/view/vr_ticket/admin/view/...` 绝对路径
-2. ✅ `docs/SQL_FIX_garbled_plugin_name.md` — 乱码修复 SQL 脚本
-3. ✅ `plan.md` — 更新根因分析
-
-### P1 乱码 DB 根因（最终确认）
- `plugins.name` 字段 = `VRç¥¨åŠ¡`（Latin1 解码的 UTF-8 字节）
- 安装时 `plugin.json` 的 `title: "VR票务"` 被以 Latin1 编码存入 MySQL
- 读取时 MySQL 连接 charset 是 utf8mb4，所以 Latin1 字节被错误解码为乱码
- **修复**：执行 `UPDATE sx_plugins SET name = 'VR票务' WHERE plugins = 'vr_ticket'`
-
-### 乱码字节分析
-`票` UTF-8: `E7 A5 8A` → Latin1 解读为: `ç¥¨åŠ¡`
-`务` UTF-8: `E5 8A B1` → (in `VRç¥¨åŠ¡` combined string)
-
-
---
-
-## SecurityEngineer Round 5 补充
-
-### 关键发现：VenueList() 方法缺失（Critical Bug）
-plugin.json sidebar URL `/plugins/vr_ticket/admin/venueList` 链接到 `VenueList()` 方法，但 admin/Admin.php 中该方法不存在 → 点击"场馆配置"菜单会导致 500 错误。
-
-**已修复**：在 admin/Admin.php 中添加：
- `VenueList()` — 场馆列表（含 v3.0 seat_map 解析）
- `VenueSave()` — 场馆创建/编辑（含 v3.0 JSON 构建和验证）
- `VenueDelete()` — 场馆软删除（含审计日志）
- `countSeatsV2()` — v2 格式（数组）座位计数辅助方法
-
-### 安全审计结论
-
-| 安全项 | 风险等级 | 结论 |
-|--------|----------|------|
-| SQL 注入 | LOW | 所有查询使用 ThinkPHP query builder + 参数绑定 |
-| XSS | LOW | ThinkPHP 模板引擎自动转义，无 `\|raw` 输出 |
-| 路径遍历 | LOW | 所有视图路径为硬编码方法名，无用户输入 |
-| CSRF | MEDIUM | ShopXO 框架级缺失，插件层面无法单独修复 |
-| 数据编码（P1乱码）| LOW | DB latin1 存储导致乱码，非安全漏洞 |
-
-### P1 乱码 DB 修复 SQL
-
-```sql
-- 1. 诊断
-SELECT id, name, title, LENGTH(name), HEX(name) FROM shx_plugins WHERE name LIKE '%vr%';
-
-- 2. 修复 plugins 表
-UPDATE shx_plugins SET name = 'vr_ticket', title = 'VR票务' WHERE name = 'vr_ticket';
-
-- 3. 修复 vrt_power 表（如果存在乱码）
-SELECT id, name, LENGTH(name), HEX(name) FROM vrt_power WHERE name LIKE '%ç¥¨%';
-UPDATE vrt_power SET name = 'VR票务' WHERE HEX(name) LIKE '%E7A58A%';
-```
-
-详细安全分析见：`reviews/SecurityEngineer-round5-review.md`
+Task 1 → Task 2 → Task 3 → Task 4（串行，每份评审写完即 commit）
--- a/reviews/Architect-DOC-SUMMARY.md
+++ b/reviews/Architect-DOC-SUMMARY.md
@ -0,0 +1,107 @@
+# 文档评审综合报告
+
+> 评估时间：2026-04-20 | 评估人：council/Architect
+> 评审范围：docs/14_TEMPLATE_RENDER_INVESTIGATION.md、docs/PHASE2_PLAN.md、docs/DEVELOPMENT_LOG.md（十一、十二章）
+
+---
+
+## 各文档评分汇总
+
+| 文档 | 准确性 | 完整性 | 可操作性 | 一致性 | 综合 |
+|------|--------|--------|----------|--------|------|
+| docs/14_TEMPLATE_RENDER_INVESTIGATION.md | 7/10 | 6/10 | 8/10 | 8/10 | **7.3** |
+| docs/PHASE2_PLAN.md | 7/10 | 7/10 | 7/10 | 8/10 | **7.3** |
+| docs/DEVELOPMENT_LOG.md（十一、十二章）| 6/10 | 7/10 | 7/10 | 5/10 | **6.3** |
+
+---
+
+## Top 3 最需要修正的问题
+
+### 🔴 问题 1：`{include}` 标签验证状态未闭环（高风险）
+
+**涉及文档**：doc14（Section 2.1/4）、PHASE2_PLAN.md（Section 2）
+
+**问题描述**：
+doc14 在 Section 2.1 标题标注"✅ 已验证（已提交 7bd896764）"，Section 6 "关联提交"也声称代码已提交。但在 Section 4 模板渲染现状表格中，`{include file="public/head"}` 明确标注"⚠️ 待验证"，Section 5 列出了方向 A/B/C 作为待实测方案。PHASE2_PLAN.md Section 2 也将 `{include}` 解析列为"待实测项"。
+
+**核心矛盾**：已提交 ≠ 已验证成功。这两件事被混淆在同一份文档里，读者无法判断票务商品详情页的 `{include}` 标签当前是否工作。
+
+**实际状态**：根据 commit 7bd896764 的描述，该提交仅完成了" Goods.php 绝对路径方案 + SeatSkuService::GetGoodsViewData() + TicketService::onOrderPaid() 修复"，`{include}` 标签解析**从未在容器内被实测验证**。这是 Phase 2 当前最大的未闭环风险点。
+
+**修正建议**：
+1. doc14 Section 2.1 标题的"✅ 已验证"改为"✅ 代码已提交（P0：容器内实测待完成）"
+2. Section 4 状态表格提升优先级标注：标记 `{include}` 解析为 **P0**，而非普通"待验证"项
+3. 在 PHASE2_PLAN.md Section 3 Step 1 补充：执行 curl 之前必须先确认测试数据存在（goods_id=118 + 对应座位模板 + 场次 spec_base）
+
+---
+
+### 🔴 问题 2：DEVELOPMENT_LOG 存在两条未衔接的 Git 时间线（高风险）
+
+**涉及文档**：docs/DEVELOPMENT_LOG.md
+
+**问题描述**：
+Chapter 8.1（"当前状态快照 2026-04-15"）记录 commit 历史截止 `7508bed`（Phase 0/1 完成）。Chapter 11（"Phase 2 前台展示层完成 2026-04-20"）直接引用 commit `7bd896764` 作为当前 HEAD，但该 commit 未出现在 Chapter 8.1 的历史列表中。同时，Chapter 5.1 的 Goods.php 代码示例（Phase 1 版本）与 doc14 Section 2.1（Phase 2 最终版本）存在根本性差异（相对路径 vs 绝对路径），后者没有在 DEVELOPMENT_LOG 中记录。
+
+**风险**：接手者无法从 DEVELOPMENT_LOG 独立重建"Phase 1 → Phase 2"的代码演进路径。Chapter 5.1 的 Goods.php 代码示例是已被替换的旧版本，但没有任何注释说明。
+
+**修正建议**：
+1. 将 DEVELOPMENT_LOG 的 Git 历史合并为单一时间线，从 `34f7045`（Phase 0）到 `7bd896764`（Phase 2 前台），在 Chapter 11.3 中补充完整的 commit 序列
+2. 在 Chapter 5.1 或新增 Chapter 10.5 中记录 Phase 1 → Phase 2 Goods.php 代码的演进原因（为什么从相对路径 MyView 改为绝对路径 View::fetch）
+3. 清理 Chapter 8.3 失效路径信息（`~/.openclaw/workspace/...`），改为当前 vr-shopxo-plugin 的实际目录结构
+
+---
+
+### 🟡 问题 3：测试数据 goods_id 在四份文档中出现三个不同值（误导风险）
+
+**涉及文档**：DEVELOPMENT_LOG.md（Chapter 4/5）、doc14（Section 1）、PHASE2_PLAN.md（Section 3 Step 1）
+
+**问题描述**：
+| 来源 | goods_id | 含义 |
+|------|----------|------|
+| DEVELOPMENT_LOG Chapter 4 | 112 | Phase 0 测试数据："VR演唱会电子票 2024" |
+| DEVELOPMENT_LOG Chapter 5.2 | 1 | Phase 1 URL 测试：`id/1` |
+| doc14 Section 1 | 118 | 调查对象 URL：`id/118.html` |
+| PHASE2_PLAN.md Step 1 | 118 | Step 1 实测 URL：`id/118.html` |
+
+没有任何文档解释：goods_id 112 和 118 是否是同一商品的不同 ID？goods_id=1 是什么商品？Phase 1 和 Phase 2 是否使用不同的测试商品？
+
+**风险**：读者无法判断当前哪个 goods_id 是有效的测试入口，容易在调研过程中以错误的 ID 访问到不相关商品，进而对系统行为产生误判。
+
+**修正建议**：
+1. 在 DEVELOPMENT_LOG Chapter 4 测试数据节中，明确列出所有 Phase 0-2 使用过的测试商品 ID 及其用途（如 goods_id=112 是 Phase 0 场次模板绑定测试商品，goods_id=118 是 Phase 2 票务详情页渲染测试商品）
+2. PHASE2_PLAN.md Step 1 补充"当前有效测试商品"清单（只保留 goods_id=118，标注为 Phase 2 唯一有效测试入口）
+3. 删除或标注 goods_id=1 的 Phase 1 测试记录（因为它与当前代码版本不对应）
+
+---
+
+## 次要问题（建议修复，但不阻塞）
+
+| # | 问题 | 涉及文档 | 优先级 |
+|---|------|----------|--------|
+| A | `spec_base_id_map` JSON 结构未记录（座位图渲染核心字段）| doc14 Section 2.2 | 高 |
+| B | Step 4 核销 API 缺少认证/权限上下文 | PHASE2_PLAN.md Section 3 | 高 |
+| C | `vrt_vr_tickets.order_no` 无 NOT NULL 约束，缺少空值防御 | DEVELOPMENT_LOG Chapter 4 | 中 |
+| D | "第十二章"在任务要求中出现但文档中不存在 | DEVELOPMENT_LOG.md | 中 |
+| E | 决策点3（Layui 是否继续使用）已过时（后台已用 Layui）| PHASE2_PLAN.md Section 6 | 低 |
+| F | doc14 Section 3.1 缺少根因总结（view_path 拼接错误）| doc14 Section 3.1 | 低 |
+
+---
+
+## 文档间一致性总览
+
+| 检查项 | 状态 | 说明 |
+|--------|------|------|
+| 表名前缀（vrt_vr_ vs sx_/sxo_） | ✅ 一致 | 插件表 vrt_vr_，ShopXO 原生平表 sxo_ |
+| commit 7bd896764 引用 | ✅ 一致 | 三份文档均引用 |
+| `goods.vr_goods_config` JSON 字段 | ✅ 一致 | 三份文档均正确 |
+| `sxo_order_detail` 表名 | ✅ 一致 | 三份文档均一致 |
+| Goods.php 方法名（Index vs detail）| ❌ 不一致 | DEVELOPMENT_LOG 写 detail()，doc14 写 Index() |
+| Goods.php 路径方案（相对 vs 绝对）| ❌ 不一致 | Phase 1 相对路径 vs Phase 2 绝对路径 |
+| goods_id 测试数据 | ❌ 不一致 | 1 / 112 / 118 三个不同值 |
+| Git 时间线 | ❌ 不一致 | Chapter 8.1 截止 Phase 1，Chapter 11 从 Phase 2 开始 |
+
+---
+
+## 总体结论
+
+三份文档的修正意识值得肯定（doc14 修正说明表格、Chapter 11 清理记录），但在"已提交 vs 已验证"的闭环性、多时间线合并、以及测试数据的唯一性方面存在系统性问题。最紧迫的是**立即在容器内实测 `{include}` 标签解析**（Top 1），这是整个 Phase 2 前台展示层是否真正完成的关键验证节点；其次是**整理 DEVELOPMENT_LOG 的时间线**（Top 2），使项目历史可以被独立追溯；最后**统一测试数据 goods_id**（Top 3），避免后续开发者在错误的测试数据上浪费时间。
--- a/reviews/Architect-on-DEV_LOG.md
+++ b/reviews/Architect-on-DEV_LOG.md
@ -0,0 +1,76 @@
+# docs/DEVELOPMENT_LOG.md 评估报告（第十一、十二章）
+
+> 评估时间：2026-04-20 | 评估人：council/Architect
+
+---
+
+## 准确性评分：6/10
+
+- **问题1（高）**：Chapter 8.1 "Git Commit 历史"最新记录是 `7508bed`（Phase 0/1 完成），但 Chapter 11 开篇就提到 commit `7bd896764`（Phase 2 前台展示层），该 commit **未出现在 Chapter 8.1 的历史列表中**。Chapter 8.1 的历史在 Chapter 11 之后被追加，但两章内容没有合并，造成同一日志中出现两段不同时间线的 commit 历史。
+
+- **问题2（高）**：Chapter 5.1 "修改内容"中 `return MyView('public/../../../plugins/vr_ticket/view/goods/ticket_detail', [...])` 这行代码使用的是相对路径 `public/../../../`，而 doc14 中说明的实际实现（commit 7bd896764）使用的是**绝对路径** `ROOT . 'app' . DS . 'plugins' ...`。两个文件描述的是**不同版本的代码**，Chapter 5.1 记录的是 Phase 1 早期版本，而非最终提交版本。
+
+- **问题3（高）**：Chapter 5.1 位置描述"detail() 方法"，但 doc14 和 PHASE2_PLAN.md 均使用 `Goods::Index()`。ShopXO Goods 控制器实际方法名为 `Index()`（对应 `goods/index` 路由）或 `detail()`（对应 `goods/detail` 路由），需要确认实际的路由 URL 才能判断哪个正确——但基于文档内部不一致，**必定有一处是错的**。
+
+- **问题4（中等）**：Chapter 4 Phase 0 建表 DDL 中 `vrt_vr_tickets.order_no VARCHAR(64)` 没有 NOT NULL 约束，但 TicketService::onOrderPaid()（doc14 Section 2.3）会写入 `order_no` 字段。如果 phase0 建表时 order_no 允许 NULL，后续业务逻辑没有对此做防御性处理。
+
+- **问题5（中等）**：Chapter 4 DDL `spec_base JSON COMMENT '座位规格基数据'` 字段名是 `spec_base`，但 doc14 Section 2.2 中 `vr_seat_templates` 表的联查提到的是 `goods_spec_value` + `goods_spec_base`。两张表都叫 `spec_base`，但一个是插件表 JSON 列（`vrt_vr_seat_templates.spec_base`），一个是 ShopXO 原生平表（`goods_spec_base`）。文档没有明确区分，容易混淆。
+
+---
+
+## 完整性评分：7/10
+
+- **缺失项1（高）**：Chapter 5 Phase 1 完成内容（座位图三行渲染、场次选择、观演人表单）没有说明这些 UI 是在 Phase 1 完成还是在 Phase 2 完成。Chapter 11 说 Phase 2 前台展示层（commit 7bd896764）才引入 `SeatSkuService::GetGoodsViewData()` 和独立 `ticket_detail.html`，而 Chapter 5 的 Phase 1 记录里 Goods.php 代码示例没有提到这个服务。这说明 Phase 1 和 Phase 2 的前端渲染能力有显著差异，但两章的边界描述不够清晰。
+
+- **缺失项2（中等）**：Chapter 11.4 Phase 2 剩余工作提到 "vr_ticket Hook.php 补充：`plugins_service_goods_spec_data`"，但没有说明这个钩子**为什么未实现**、对票务功能的具体影响是什么，以及**是否阻塞**其他任务。
+
+- **缺失项3（中等）**：Chapter 11.5 清理记录提到"临时测试脚本 → 移至 `_backup_20260420/`"，但没有说明该备份目录是否已提交到仓库，还是只存在于本地文件系统。
+
+- **缺失项4（低）**：Chapter 12（第十二章）在当前 DEVELOPMENT_LOG.md 中**完全不存在**，只到第十一章。但任务要求评审"第十一、十二章"。这可能意味着第十二章尚未创建，或日志结构与要求不符。
+
+---
+
+## 可操作性评分：7/10
+
+- **优点**：Chapter 11.1 完成内容中每个文件改动都有简洁说明，便于后续接手者定位改动范围。清理记录（Chapter 11.5）有助于理解项目状态的来龙去脉。
+
+- **建议1（中等）**：Chapter 8.3 "关键文件路径"中的 ShopXO 容器源码路径 (`~/.openclaw/...`) 是旧的工作空间路径，与当前 `vr-shopxo-plugin` 的实际目录结构不符。应更新为当前实际路径或删除此节（该节内容已严重过时）。
+
+- **建议2（低）**：Chapter 4 DDL 建表语句没有版本号或日期标记，后续如果表结构变更，无法追溯哪个版本引入了哪些字段。建议在 DDL 头部加上版本注释（如 `-- v1.0 2026-04-15 Phase 0`）。
+
+---
+
+## 一致性评分：5/10
+
+- **冲突项1（高）**：`goods_id` 在不同章节不一致：
+  - Chapter 4 测试数据：`goods_id = 112`
+  - Chapter 5.2 URL：商品1（`id/1`）
+  - doc14 调查 URL：`id/118.html`
+  - PHASE2_PLAN.md Step 1：`id/118.html`
+  四个不同的 goods_id，没有解释为什么。读者无法判断哪个是当前有效的测试商品。
+
+- **冲突项2（高）**：Goods.php 代码示例在 Chapter 5.1（Phase 1 记录）与 doc14 Section 2.1（Phase 2 最终版本）完全不同：Phase 1 用相对路径 `MyView('public/../../../plugins/...')`，Phase 2 用绝对路径 `View::fetch($tplFile)`。DEVELOPMENT_LOG 没有说明这次重大改动的背景和原因。
+
+- **冲突项3（中等）**：Chapter 8.1 Git 历史截止 `7508bed`，而 Chapter 11.3 Git 状态显示 `7bd896764` 才是 HEAD。两段 commit 历史没有衔接，读者无法理解从 Phase 0/1 到 Phase 2 的演进路径。
+
+- **一致项**：
+  - vrt_ 表前缀使用一致
+  - 票务插件目录结构（`app/plugins/vr_ticket/`）记录一致
+
+---
+
+## 误导风险评估
+
+- **高风险项**：
+  - Goods.php 代码示例（Chapter 5.1）展示的是 Phase 1 早期版本，但没有任何注释说明这是"旧版本/已被替换"。接手者如果从 DEVELOPMENT_LOG 出发，很可能直接复制这段代码使用，而不知道 doc14 中有更新的版本。
+  - 四个不同的 `goods_id`（1 / 112 / 118 / 未指定）散布在不同章节，没有任何解释，极易让读者认为存在多个测试商品或数据混乱，进而对整体系统状态产生错误判断。
+  - "第十二章"在任务要求中出现但文档中不存在，可能导致任务发起者误以为章节已写而未被评审。
+
+- **低风险项**：
+  - Chapter 8.3 的旧路径信息（如 `~/.openclaw/workspace/council-research/...`）现在完全无效，但仍然保留在文档中。读者如果信任这个路径去查找文件，会浪费时间。
+
+---
+
+## 总体评价
+
+DEVELOPMENT_LOG.md 是项目的核心历史记录，第十一章对 Phase 2 前台展示层的完成内容有较为清晰的总结，清理记录也有助于理解项目演进。主要问题集中在**两段时间线未合并**（Chapter 8.1 截止 Phase 1，Chapter 11 从 Phase 2 重新开始），以及 **Goods.php 代码示例存在两个不同版本**（Phase 1 相对路径 vs Phase 2 绝对路径），均未标注版本关系。这使得 DEVELOPMENT_LOG 无法独立作为"当前状态参考"，必须配合 doc14 和 commit 历史才能还原真实代码演进。建议将 DEVELOPMENT_LOG 重组为时间线顺序（Phase 0 → Phase 1 → Phase 2），并为每个关键代码示例标注对应的 commit hash。同时，"第十二章"缺失需要向任务发起者确认是否需要补充。
--- a/reviews/Architect-on-PHASE2_PLAN.md
+++ b/reviews/Architect-on-PHASE2_PLAN.md
@ -0,0 +1,67 @@
+# docs/PHASE2_PLAN.md 评估报告
+
+> 评估时间：2026-04-20 | 评估人：council/Architect
+
+---
+
+## 准确性评分：7/10
+
+- **问题1（中等）**：Section 2 "模板渲染问题现状"描述"Goods.php 原来用 `MyView()` 加载主题模板"，但实际 Goods.php 原代码中使用的是 `return MyView();`（无参数），而修正方案改用 `View::fetch($tplFile)`。文档将"原方案"简化为 `MyView()`，忽略了 `MyView()` 在 Phase 1 验证阶段已经过多次迭代（详见 DEVELOPMENT_LOG Chapter 5），读者无法理解这次改动的上下文。
+
+- **问题2（中等）**：Section 2 解决路径第7步写"ThinkTemplate 渲染 ticket_detail.html（含 {include} 标签）"，但如 doc14 评审所指出，`{include}` 标签是否能正确解析**从未被容器实测验证**。将此描述为"解决路径"而非"待验证路径"存在准确性风险。
+
+- **问题3（低）**：Section 3 Step 1 成功标准写"HTML 源码中不再有 ThinkTemplate 标签（`{include}` / `{$` / `{if}`）"，但实际上票务模板可能根本没有 `{if}` 标签，这个成功标准缺少针对性。
+
+---
+
+## 完整性评分：7/10
+
+- **缺失项1（高）**：Section 3 "Phase 2 接下来的工作"没有说明 Step 1 的依赖条件——需要商品数据（goods_id=118 的票务商品 + 绑定座位模板 + 场次 spec_base）。如果这些测试数据不存在，Step 1 根本无法执行。应在 Step 1 前补充"前置条件检查清单"。
+
+- **缺失项2（高）**：Step 4 "核销 API"只写了端点 `POST /api/vr_ticket/verify`，但没有说明认证方式（JWT token / session）、权限模型（RLS profiles.role='staff'）和请求参数格式。这使 Step 4 几乎无法直接执行。
+
+- **缺失项3（中等）**：Section 5 "已知风险"没有提到"测试数据缺失"风险——容器内商品 ID 118 是否存在？座位模板是否已绑定对应分类？这些是 Step 1 的前置依赖，但风险表中未提及。
+
+- **缺失项4（中等）**：Section 6 "决策点"第2点"loadSoldSeats() 是否需要实时查库"没有给出背景说明——为什么这是决策项？实时查库的性能影响有多大？前端座位状态管理的备选方案各有什么优劣？
+
+- **缺失项5（低）**：Section 4 数据库表结构中没有列出 `goods` 表（ShopXO 原生平表），但这是 Phase 2 前台展示层最重要的数据来源之一，缺少它会导致读者对数据流理解不完整。
+
+---
+
+## 可操作性评分：7/10
+
+- **优点**：Step 顺序清晰，每个 Step 都有操作命令示例（docker / curl），失败备选也有代码。
+
+- **建议1（中等）**：Step 1 提到"操作人：大头（容器在本机）"，但计划文档应该是环境无关的行动指南，不应将操作绑定到个人。建议改为"前置条件：容器运行中 + 测试数据就绪"，避免文档因人员变动而失效。
+
+- **建议2（中等）**：Step 3 "后台管理页面联调"列出了3个子项（路由、CRUD、RLS），但没有给出具体的 URL 格式和期望行为定义。接手者需要自行探索 ShopXO 后台路由规则。建议补充期望的 URL 和返回格式。
+
+- **建议3（低）**：Step 2 loadSoldSeats() 的描述是文字说明，没有给出 spec_base_id_map 如何映射到已售座位的具体逻辑，这会让实现者产生歧义。
+
+---
+
+## 一致性评分：8/10
+
+- **一致项**：
+  - 表名 `sxo_order_detail` / `goods.vr_goods_config` 与 doc14 一致
+  - commit 7bd896764 引用一致
+  - vrt_vr_* 表前缀使用合理（插件表 vs ShopXO 原生平表区分清晰）
+
+- **不一致项（低）**：Section 5 风险表提到"shopxo-php 容器未启动"，但这个风险在 Step 1 里没有对应的预防性检查命令。建议统一：在 Step 1 开头加 `docker ps | grep shopxo-php` 检查。
+
+---
+
+## 误导风险评估
+
+- **高风险项**：
+  - Step 4 "核销 API"缺少认证和权限描述，可能让接手者直接实现一个无鉴权的 API，在测试环境中暴露安全风险。
+  - "决策点"中"Layui 是否继续使用"列在决策项里，但 4 个后台控制器（Section 1 ❌ 未开始）如果已经用了 Layui，这实际上不是一个待决策项。容易让读者困惑当前技术栈状态。
+
+- **低风险项**：
+  - "容器内操作"的说明文字暗示这是开发人员的手动步骤，但没有说明如何在 CI/CD 或自动化测试环境中复现，降低了文档的长期可维护性。
+
+---
+
+## 总体评价
+
+PHASE2_PLAN.md 作为阶段性状态文档，结构清晰、优先级划分合理，对已完成工作的记录较为准确。主要风险在于 Step 1 的前置条件（测试数据、容器状态）描述不足，使得"看起来可执行"但"实际无法直接执行"；Step 4 核销 API 缺少安全上下文的描述，存在直接实现无鉴权接口的误导风险。决策点的第三项（Layui 选型）已过时（后台控制器已使用 Layui），建议删除或改为确认项。整体适合作为技术负责人的执行参考，但需要补充前置条件清单和 API 安全规范才能独立驱动开发。
--- a/reviews/Architect-on-doc14.md
+++ b/reviews/Architect-on-doc14.md
@ -0,0 +1,65 @@
+# docs/14_TEMPLATE_RENDER_INVESTIGATION.md 评估报告
+
+> 评估时间：2026-04-20 | 评估人：council/Architect
+
+---
+
+## 准确性评分：7/10
+
+- **问题1（中等）**：Section 2.1 Goods.php 代码示例中 `$assign` 变量未定义。实际代码（Section 2.2）中数据通过 `MyViewAssign()` 注入，而非 `fetch($tplFile, $assign)` 的第二个参数传参。示例代码与说明不一致，容易让读者误以为 `$assign` 需要额外构建。
+
+- **问题2（中等）**：Section 2.2 数据流第4步描述"从 ShopXO 原生表 `goods_spec_value` + `goods_spec_base` 联查"，但没有说明联查的 JOIN 条件（`spec_base_id` / `goods_id`）。缺少关键连接字段会让接手者无法独立还原查询逻辑。
+
+- **问题3（低）**：Section 4 模板渲染现状表格中，`{include file="public/head"}` 和 `{$vr_seat_template.seat_map|raw}` 均标注"⚠️ 待验证"，但 Section 2.1 标题已写"✅ 已验证（已提交）"。状态标记存在矛盾。
+
+- **问题4（低）**：Section 3.1 描述 ThinkTemplate `parseTemplateFile()` 时，写的是 `$template = $this->config['view_path'] . $template . '.' . $view_suffix`，这是 ThinkPHP 5 的标准行为，但文档没有说明这正是导致票务模板无法渲染的根因（ThinkTemplate 拼接了错误的 view_path 前缀）。
+
+---
+
+## 完整性评分：6/10
+
+- **缺失项1（高）**：`vr_seat_templates.spec_base_id_map` JSON 的结构完全没有说明。这个字段是前端渲染座位图的核心数据源，缺少字段说明会导致接手者无法理解座位 ID 如何映射到 spec_base_id。
+
+- **缺失项2（高）**：`plugins_service_goods_spec_data` 钩子未实现（P1 问题），文档中仅一句话带过，但没有说明这个钩子当前对票务功能的影响范围（是否会导致某些规格无法显示）。
+
+- **缺失项3（中等）**：`loadSoldSeats()` 函数为空（TODO），但没有说明这个函数应该由谁实现、前端座位图对已售座位的灰化处理依赖此函数。
+
+- **缺失项4（中等）**：Section 2.2 第5步返回三个 key，但 Goods.php 中实际注入的是 `vr_seat_template` 和 `goods_spec_data`（与模板变量名对应）。文档没有说明为什么返回结构与模板使用结构有差异，以及这些变量在模板中具体如何使用。
+
+---
+
+## 可操作性评分：8/10
+
+- **优点**：三个方向（A/B/C）描述清晰，每种方案都有具体操作步骤，失败切换路径明确。
+
+- **建议1（低）**：Section 5 容器实测命令缺少 `docker ps` 前置确认，建议加入 `--first-flow` 步骤，避免读者在容器未启动时执行 curl 导致误导（误以为方案失败）。
+
+- **建议2（低）**：`sxo_order_detail.spec` JSON 解码逻辑（Section 2.3）只是描述性文字，没有给出 PHP 示例代码。后续接手者需要参考 `TicketService.php` 源码才能理解实际解析方式，建议在此补充一行示例。
+
+---
+
+## 一致性评分：8/10
+
+- **冲突项（低）**：Section 6 "关联提交"中声称"代码已提交"，但 Section 4 的状态表格明确列出 `{include}` 和 `{$vr_seat_template.seat_map|raw}` 均未验证。已提交 ≠ 已验证成功，这种混淆会导致读者认为功能已完成。
+
+- **一致项**：
+  - 表名 `sxo_order_detail` 与 PHASE2_PLAN.md 一致
+  - commit 7bd896764 在各文档中引用一致
+  - `goods.vr_goods_config` JSON 字段描述一致
+
+---
+
+## 误导风险评估
+
+- **高风险项**：
+  - "Section 2.1 改动状态：✅ 已提交（7bd896764）"与"Section 4 `{include}` 标签：⚠️ 待验证"并存在同一文档中，读者容易误认为 `{include}` 问题已解决，而实际上问题未经验证。
+  - Section 3.1 的 ThinkTemplate 根因分析没有明确指出"错误的 view_path 拼接"是渲染失败的根本原因，读者可能无法理解为什么Goods.php 绝对路径方案能work。
+
+- **低风险项**：
+  - 修正说明表格（Section 0）设计良好，清晰告知读者哪些内容已被修正，降低了误信旧信息的风险。
+
+---
+
+## 总体评价
+
+这份文档在修正版中大幅改善了表名和数据流描述（相比原版），修正说明表格设计合理，体现了良好的文档维护意识。主要风险在于"已提交"与"已验证"的混淆——`{include}` 标签解析在容器内**从未被实测验证过**，但文档的语气暗示问题已解决。此外 `spec_base_id_map` JSON 结构完全缺失，使得文档只能指导"怎么改的"而无法回答"为什么这样改"。建议在完成容器实测后更新 Section 4 的状态标记，并在 Section 2.2 补充 spec_base_id_map 结构说明。