council(review): BackendArchitect - 完成三份文档评审

- reviews/BackendArchitect-on-14_TEMPLATE_RENDER_INVESTIGATION.md
- reviews/BackendArchitect-on-PHASE2_PLAN.md
- reviews/BackendArchitect-on-DEVELOPMENT_LOG.md
- reviews/BackendArchitect-DOCUMENTATION_REVIEW_SUMMARY.md

Top 3 问题：
1. vr_seat_templates 表名前缀不一致（docs/14）
2. docs/14 缺少 Phase 1/Phase 2 改法关系说明
3. DEVELOPMENT_LOG.md 11.3 Git 快照已过时

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

reviews/BackendArchitect-DOCUMENTATION_REVIEW_SUMMARY.md

@@ -0,0 +1,108 @@
+# 文档评审综合报告
+
+> 评审人：BackendArchitect | 日期：2026-04-20 | 评审范围：三份文档综合评估
+
+---
+
+## 三份文档综合评分
+
+| 文档 | 准确性 | 完整性 | 可操作性 | 一致性 | 综合 |
+|------|--------|--------|----------|--------|------|
+| docs/14_TEMPLATE_RENDER_INVESTIGATION.md | 7/10 | 6/10 | 7/10 | 5/10 | 6.3 |
+| docs/PHASE2_PLAN.md | 7/10 | 6/10 | 7/10 | 8/10 | 7.0 |
+| docs/DEVELOPMENT_LOG.md（第十一、十二章）| 8/10 | 6/10 | 7/10 | 7/10 | 7.0 |
+
+---
+
+## Top 3 最需要修正的问题
+
+### 问题 1：表名前缀不一致——vr_seat_templates vs vrt_vr_seat_templates（高优先级）
+
+**影响范围**：docs/14（严重）、docs/PHASE2_PLAN.md（正常）、docs/DEVELOPMENT_LOG.md（正常）
+
+**具体问题**：
+- docs/14 第 2.2 节数据流第 3 步写的是 `vr_seat_templates`（无前缀）
+- docs/DEVELOPMENT_LOG.md 建表 SQL 和 docs/PHASE2_PLAN.md 写的是 `vrt_vr_seat_templates`（有 vrt_ 前缀）
+- 根据 DEVELOPMENT_LOG.md 的建表 SQL，实际表名是有前缀的 `vrt_vr_seat_templates`
+
+**风险**：接手者基于 docs/14 中的表名查询数据会得到"表不存在"错误，同时影响代码实现（如果开发者直接复制表名）。
+
+**建议修正**：将 docs/14 中所有 `vr_seat_templates` 统一改为 `vrt_vr_seat_templates`，并在表格附录中加入前缀约定说明。
+
+**修正位置**：
+- docs/14 第 2.2 节数据流第 3 步
+- docs/14 第 3.1 节"关键问题"段落（如有引用）
+
+---
+
+### 问题 2：docs/14 缺少 Phase 1 / Phase 2 两套 Goods.php 改法的关系说明（高优先级）
+
+**影响范围**：docs/14（严重）
+
+**具体问题**：
+- Phase 1 的 Goods.php 改法（commit 0f5a82d）使用 `MyView('public/../../../plugins/...')`
+- Phase 2 的 Goods.php 改法（commit 7bd896764）使用 `View::fetch($tplFile)` 绝对路径
+- docs/14 仅记录了 Phase 2 的方案，没有说明 Phase 1 的方案是否仍然保留
+- 如果 Phase 1 方案被替换，docs/14 应该说明这是替代关系，不是并存关系
+
+**风险**：接手者可能误以为 Phase 1 的代码仍然存在并尝试复用；或者误以为 docs/14 记录的是唯一的解决方案。
+
+**建议修正**：在 docs/14 第 2.1 节开头增加一段：
+> "本文档记录的是 Phase 2 的解决方案（Goods.php 绝对路径方案）。Phase 1 曾尝试使用 MyView() 相对路径方式，该方案已在本版本中被替代（见 commit 7bd896764）。"
+
+---
+
+### 问题 3：DEVELOPMENT_LOG.md Chapter 11.3 Git 状态快照已过时（中优先级）
+
+**影响范围**：docs/DEVELOPMENT_LOG.md（严重）
+
+**具体问题**：
+- 11.3 节记录的 HEAD 是 `7bd896764`
+- 实际最新提交是 `914e2a0fc`（docs: 修正 docs/14 + 新增 PHASE2_PLAN.md）
+- 文档记录落后于实际状态一个提交
+
+**风险**：任何基于这份 Development Log 做 git 操作或状态判断的人会得到错误结论。
+
+**建议修正**：更新 11.3 节，将 `914e2a0fc` 替换 `7bd896764` 作为最新提交，并补充说明 `914e2a0fc` 的内容。
+
+---
+
+## 次要问题汇总（按优先级排序）
+
+### 次要 1：docs/14 复现前提条件缺失
+
+缺少 ShopXO 版本、PHP 版本、容器配置信息。接手者无法独立复现问题。
+
+### 次要 2：PHASE2_PLAN.md Step 1 容器访问方式缺失
+
+计划高度依赖"大头在本机操作"，但没有说明其他人如何获取同样的访问能力。
+
+### 次要 3：PHASE2_PLAN.md 核销 API 设计要点缺失
+
+Step 4 只给出了 API 路径，没有认证机制、请求参数、响应格式。
+
+### 次要 4：docs/14 中 `sxo_order_detail` 描述不够精确
+
+"sxo_ 是原生平表前缀"的说法不规范，建议改为"本项目对应的订单明细表 `sxo_order_detail`"。
+
+### 次要 5：docs/14 中 `|raw` 输出的安全性前提未说明
+
+如果 `seat_map` 内容完全由后台管理端控制（不可由用户输入），应在文档中注明此安全前提。
+
+---
+
+## 三份文档之间的协作价值
+
+尽管存在上述问题，三份文档之间形成了互补关系：
+
+- **docs/14**：提供了深度的技术调查（ThinkTemplate 渲染机制、include 标签链路），是不可替代的技术知识资产。
+- **docs/PHASE2_PLAN.md**：提供了清晰的下一步行动框架和成功标准，是项目推进的执行依据。
+- **docs/DEVELOPMENT_LOG.md**：提供了完整的时间线和 commit 历史，是追溯决策过程的核心依据。
+
+三者的核心问题是**一致性维护**不足，表名前缀、Phase 关系、Git 状态快照都需要在后续更新中同步修正。
+
+---
+
+## 总体评价
+
+这三份文档是 vr-shopxo-plugin 项目 Phase 2 阶段最重要的知识载体，文档质量在技术描述层面总体可信，但信息一致性和时效性存在明显短板。最关键的问题是表名前缀不一致（影响代码实现）、Phase 关系不清晰（影响方案理解）、Git 快照已过时（影响状态判断）。修正这三个问题不需要改动代码，是纯文档维护工作，成本低但价值高。修正后建议建立文档更新规范：每次 commit 涉及文档时，检查相关文档的状态快照是否同步更新。

reviews/BackendArchitect-on-14_TEMPLATE_RENDER_INVESTIGATION.md

@@ -0,0 +1,104 @@
+# docs/14_TEMPLATE_RENDER_INVESTIGATION.md 评估报告
+
+> 评审人：BackendArchitect | 日期：2026-04-20 | 版本：已修正版
+
+---
+
+## 准确性评分：7/10
+
+### 问题 1：座位模板表名不一致（高）
+
+第 2.2 节数据流第 3 步写道：
+> "从 `vr_seat_templates` 表查询座位模板"
+
+但 DEVELOPMENT_LOG.md 建表 SQL 中表名为 `vrt_vr_seat_templates`（有 vrt_ 前缀）。同一表名在三份文档中出现两种写法，极易误导。
+
+### 问题 2：GetGoodsViewData 返回值字段名存疑
+
+第 2.2 节数据流第 5 步写道返回字段含 `vr_seat_template`（单数），但第 2.1 节 Goods.php 代码示例中注入的是 `vr_seat_template`（注入给模板变量名）和 `goods_spec_data`（来自返回值）。Section 2.2 描述的返回值列表是 `vr_seat_template`（单数）而 section 2.1 代码里注入的也是 `vr_seat_template`，两者一致，但与 section 2.2 描述的返回值结构 `['vr_seat_template' => [...], 'goods_spec_data' => [...]]` 吻合性需要代码核实。
+
+### 问题 3：section 2.3 描述仍可能有歧义
+
+`onOrderPaid()` 修复描述"映射到 ShopXO 原生平表 `sxo_order_detail`"——这里的"原生平表"说法不够精确。`sxo_` 是本项目的表前缀约定，不是 ShopXO 官方命名。建议改为"本项目对应的订单明细表 `sxo_order_detail`"。
+
+### 轻微问题：|raw 变量输出安全性未说明
+
+第 3.2 节提及 `{$vr_seat_template.seat_map|raw}` 需要 `|raw` 过滤器，文档未说明这是否安全。如果 `seat_map` 内容完全由后台管理端控制（不可由用户输入），则 `|raw` 无安全风险，但应在文档中注明此前提条件。
+
+---
+
+## 完整性评分：6/10
+
+### 缺失项 1：复现前提条件未说明
+
+文档未说明分析环境：ShopXO 版本、PHP 版本、容器配置。如果接手者想复现问题，没有这些信息几乎不可能。
+
+### 缺失项 2：ticket_detail.html 模板的实际路径未记录
+
+附录中有路径 `shopxo/app/plugins/vr_ticket/view/goods/ticket_detail.html`，但未说明该文件是否已存在于哪个 commit 中，也未说明文件内容结构。
+
+### 缺失项 3：Phase 1 和 Phase 2 改法的关系未说明
+
+文档将 Phase 1 的 `MyView('public/../../../plugins/...')` 改法（第 5.1 节 DEVELOPMENT_LOG.md）和 Phase 2 的绝对路径 `View::fetch($tplFile)` 改法并列，但未说明两者是替代关系还是并存关系，容易造成混淆。
+
+### 缺失项 4：P1 待解决问题无验收标准
+
+P1 列了三个问题（`{include}` 标签、钩子、loadSoldSeats），但没有说明"解决成功"的标准是什么。例如：`{include}` 标签解析成功的判断依据是"HTML 源码中不再有 ThinkTemplate 原始标签"（见 PHASE2_PLAN.md），应在此文档中也明确记录。
+
+---
+
+## 可操作性评分：7/10
+
+### 建议 1：方向 A/B/C 应给出决策树
+
+第 5 章三个方向有优先级（方向 A 推荐），但没有给出决策条件。例如："若 `{include}` 失败"的判断标准是什么？返回 HTTP 500？页面空白？ThinkTemplate 原始标签？还是部分渲染？补充判断条件可以让接手者独立决策而不需要反复确认。
+
+### 建议 2：docker 操作命令应内联在文档中
+
+文档提到"容器内实测"但命令散布在 PHASE2_PLAN.md 中。建议在 docs/14 中直接包含 `curl` 命令和预期输出示例，让文档自包含。
+
+### 优点：附录文件路径表实用
+
+附录清晰列出了所有相关文件路径，这是文档中做得好的部分。
+
+---
+
+## 一致性评分：5/10
+
+### 冲突项 1（严重）：vr_seat_templates 表名
+
+| 文档 | 表名 |
+|------|------|
+| docs/14 第 2.2 节 | `vr_seat_templates`（无前缀） |
+| docs/DEVELOPMENT_LOG.md 建表 SQL | `vrt_vr_seat_templates`（有 vrt_ 前缀） |
+| docs/PHASE2_PLAN.md | `vrt_vr_seat_templates`（有前缀） |
+
+三份文档中出现了两种命名，docs/14 是唯一使用无前缀版本的，需要修正。
+
+### 冲突项 2：Goods.php 文件路径基准不一致
+
+docs/14 附录写的是 `shopxo/app/index/controller/Goods.php`（以 `shopxo/` 为项目根），但实际项目结构是 `/Users/bigemon/WorkSpace/vr-shopxo-plugin/shopxo/`（`shopxo/` 是子目录）。这种写法在开发环境内是约定俗成，但文档中应明确注明。
+
+---
+
+## 误导风险评估
+
+### 高风险项
+
+**误导 1：认为 ticket_detail.html 已经正常渲染**
+
+第 2.1 节 Goods.php 改动标注"状态：✅ 已提交（7bd896764）"，但 section 4 明确说 `{include file="public/head"}` 是"⚠️ 待验证"。已提交的代码不等于已验证的功能。接手者可能误认为票务商品页已经完全可用。
+
+**误导 2：phase 关系混淆**
+
+Phase 1 和 Phase 2 的 Goods.php 改法不同（MyView vs 绝对路径 View::fetch），但 docs/14 报告本身没有说明这是 Phase 2 的新改法，如果只读这一份文档会以为这是唯一的解决方案。
+
+### 低风险项
+
+docs/14 的"重要修正说明"（第 9-18 行）是一个很好的自我纠正机制，后续接手者可以看到哪些内容已被修正，降低了误信旧信息的风险。
+
+---
+
+## 总体评价
+
+docs/14 是一份技术价值较高的调查文档，保留了完整的 ThinkTemplate 渲染机制分析、include 标签解析链路和 Linux 路径问题记录。最值得肯定的是"重要修正说明"章节，主动暴露了已知的错误。但核心问题是表名前缀不一致（`vr_seat_templates` vs `vrt_vr_seat_templates`），这是唯一出现在已修正说明之外的重大事实错误。此外，文档未说明 Phase 1/Phase 2 两套 Goods.php 改法的替代关系，容易让新读者以为这是唯一的解决方案。加上缺少复现前提条件和验收标准，文档的可操作性低于其技术分析水平。

reviews/BackendArchitect-on-DEVELOPMENT_LOG.md

@@ -0,0 +1,123 @@
+# docs/DEVELOPMENT_LOG.md 评估报告（第十一、十二章）
+
+> 评审人：BackendArchitect | 日期：2026-04-20 | 评审范围：第十一章 + 第十二章
+
+---
+
+## 准确性评分：8/10
+
+### 问题 1：11.3 Git 状态存在事实错误
+
+第十一章第 11.3 节写道：
+
+```
+7bd896764 feat(Phase 2): 完成票务商品前端展示层  ← HEAD
+dc63cff77 chore: clean up my_test_plugin residual hooks
+```
+
+但 git log 显示的最近提交是：
+
+```
+914e2a0fc docs: 修正 docs/14 + 新增 PHASE2_PLAN.md
+7bd896764 feat(Phase 2): 完成票务商品前端展示层
+```
+
+文档记录的最新提交是 7bd896764，而实际最新提交是 914e2a0fc，相差一个提交。Chapter 11 的 Git 状态快照已经过时。
+
+### 问题 2：11.1 完成内容对 TicketService::onOrderPaid 的描述不够精确
+
+> "幂等改为 seat_info"
+
+这描述了实现策略（用 seat_info 做幂等键），但没有说明是哪个字段。实际上幂等保护是"同一订单+同一座位名只发一张票"，seat_info 是座位标识符。描述基本正确，但可以更精确。
+
+### 问题 3：11.5 清理记录时间线歧义
+
+> "docs/14_TEMPLATE_RENDER_INVESTIGATION.md → 重写修正版（删除错误信息，保留调查价值）"
+
+这里"删除错误信息"的描述有歧义：是指删除了文档中原本错误的描述（修正），还是物理上删除了旧版本？结合上下文，这应该是"修正"的意思，但措辞让人以为原文件被删除或覆盖了。
+
+---
+
+## 完整性评分：6/10
+
+### 缺失项 1：第十一章缺少开发者/决策者记录
+
+Chapter 11 记录了完成内容，但没有说明是谁完成的、谁做了决策、谁审核了代码。这是 Development Log 的基本要素——帮助未来的接手者知道找谁了解背景。Phase 1（Chapter 5）同样没有记录执行人，但 Phase 2 更复杂，这个问题更突出。
+
+### 缺失项 2：Phase 2 前台展示层未说明与 Phase 1 的关系
+
+Chapter 11.1 列出了新的 commit（7bd896764）的改动，但没有说明 Phase 1 的改动（commit 0f5a82d，Goods.php MyView 方式）是否仍然保留。根据 docs/14 的内容，Phase 2 的绝对路径方案是替代了 Phase 1 的 MyView 方案，但 DEVELOPMENT_LOG.md 没有明确这一点。
+
+### 缺失项 3：loadSoldSeats() 实现状态未记录
+
+Chapter 11.4（Phase 2 剩余工作）列出了 loadSoldSeats() 为"❌ 未开始"，但没有说明为什么它是一个独立的 TODO 项——它是属于前台展示层还是后台管理层？它的数据来源是什么表？这些上下文没有记录。
+
+### 缺失项 4：cleanup 记录缺少备份文件清单
+
+11.5 清理记录提到"移至 `_backup_20260420/test_ticket.php`"，但没有说明：
+- 备份目录是否被 Git 追踪？
+- 备份文件是否包含敏感信息（数据库凭证、测试数据）？
+- 是否有清理计划（什么时候删除备份）？
+
+---
+
+## 可操作性评分：7/10
+
+### 优点：11.4 Phase 2 剩余工作表格简洁有用
+
+| 任务 | 状态 | 的格式清晰地展示了剩余工作。对于每个未开始的任务，应该补充"负责人"和"依赖项"两列，让计划更可操作。
+
+### 优点：Commit 号准确
+
+Chapter 11.1 记录的 commit 7bd896764 是准确的，可以直接用于 git show 查看具体改动。这是 Development Log 最重要的价值之一。
+
+### 建议：清理记录应给出清理原则
+
+11.5 的清理操作（test_ticket.php 移到备份目录、docs/14 重写）说明的是"做了什么"，但没有说明"为什么"——为什么 test_ticket.php 要备份而不是直接删除？备份多久后应该清理？这些原则性的记录对后续开发者的清理决策有指导价值。
+
+---
+
+## 一致性评分：7/10
+
+### 冲突项 1：表名前缀
+
+DEVELOPMENT_LOG.md 建表 SQL（第四章）中使用 `vrt_vr_seat_templates`（有前缀），与 docs/14 中的 `vr_seat_templates`（无前缀）不一致。这与前面两份评审中发现的问题一致。
+
+### 轻微问题：Chapter 8 文件路径基准
+
+8.3 节写道：
+```
+ShopXO 容器：
+  源码：~/.openclaw/workspace/council-research/shopxo-eval/.worktrees/shopxo-evaluator/shopxo-src/
+  插件：shopxo-src/app/plugins/vr_ticket/
+```
+
+这里的 `shopxo-src/` 路径是相对路径，基准是什么？如果是另一个 worktree，这个路径对当前 worktree 的开发者没有意义。更准确的做法是使用绝对路径或明确说明路径基准。
+
+### 优点：时间线一致性
+
+Chapter 11.1 写的是"2026-04-20"，与 PHASE2_PLAN.md 的文档日期一致，说明这两份文档是同一天更新的。
+
+---
+
+## 误导风险评估
+
+### 高风险项
+
+**误导：Chapter 11.3 Git 状态快照已过时**
+
+11.3 显示的最新提交是 7bd896764，但实际已落后一个提交 914e2a0fc。如果有人基于这份 Development Log 做 git blame 或查看历史，会误以为最新状态是 7bd896764。
+
+**误导：11.5 清理记录的表述**
+
+"docs/14_TEMPLATE_RENDER_INVESTIGATION.md → 重写修正版"这个描述让人误以为是物理覆盖，但实际上是创建了一个新的修正版本。如果后续要追溯原始调查内容，这个记录不够清晰。
+
+### 低风险项
+
+Chapter 8 的路径信息对当前 worktree 已经完全过时（那是 council-research 的 worktree 路径），但由于 Chapter 8 是早期记录，这不构成误导风险（历史文档的路径信息本来就是当时的快照）。
+
+---
+
+## 总体评价
+
+DEVELOPMENT_LOG.md 第十一、十二章在技术准确性上总体良好，commit 号记录准确，时间线与 PHASE2_PLAN.md 一致，剩余工作清单清晰。最突出的问题是 Chapter 11.3 的 Git 状态快照已经过时一个提交，这与文档"记录当前状态"的核心目的相悖。其次，缺少执行人和决策人记录，使得这份 Development Log 难以承担"团队知识传递"的功能——它更像是一个操作记录而不是完整的开发日志。清理记录的描述也需要更精确，以避免后续清理工作时产生歧义。

reviews/BackendArchitect-on-PHASE2_PLAN.md

@@ -0,0 +1,95 @@
+# docs/PHASE2_PLAN.md 评估报告
+
+> 评审人：BackendArchitect | 日期：2026-04-20
+
+---
+
+## 准确性评分：7/10
+
+### 问题 1：模板渲染根因描述过于简化
+
+第一章写道"Goods.php 原来用 MyView() 加载主题模板，票务商品需要加载插件独立模板 ticket_detail.html"。这个描述正确但过于简化，遗漏了关键原因：ShopXO 插件系统是纯 Hook 系统，无法通过 config.json 覆盖控制器模板路径，加上 MyView() 的 view_path 拼接逻辑与绝对路径不兼容。缺少这一层说明会让接手者无法理解为什么必须改 Goods.php 而不是通过插件机制解决。
+
+### 问题 2：Step 1 操作人信息可能过期
+
+"操作人：大头（容器在本机）"——这行信息有价值，但只写了操作人没写操作时间。如果后续大头不记得这回事，接手者不知道该任务是否有主。如果大头不在，其他人能操作吗？应补充操作前提（容器在本机）或操作步骤（远程 SSH 方式）。
+
+### 问题 3：核销 API 路径描述模糊
+
+Step 4 写道"`POST /api/vr_ticket/verify` — B 端小程序扫码调用"，但没有说明该 API 的认证机制（是否需要 token？是否使用 RLS？）、请求参数格式、响应格式。如果开发者要实现这个 API，这份文档几乎没有参考价值。
+
+---
+
+## 完整性评分：6/10
+
+### 缺失项 1：容器访问方式未记录
+
+Step 1 说"在 shopxo-php 容器内"，但没有说明怎么访问。是在宿主机上 `docker exec` 还是 SSH？容器 IP 是多少？端口 9000 是 PHP-FPM 不是 Web 服务。这对于不熟悉这个具体 Docker 配置的人来说是一个重大缺口。
+
+### 缺失项 2：决策点 2 和 3 过于开放
+
+决策点 2（loadSoldSeats 是否实时查库）涉及性能和数据一致性权衡，文档没有给出这两种方案各自的优劣。决策点 3（Layui 是否继续使用）根本没有给出可选方案。对于需要做决策的人来说，这些问题几乎是凭空抛出的。
+
+### 缺失项 3：风险表缺少已知的架构决策不确定性
+
+已知风险表中列出了 5 项风险（include 标签、容器未启动、Admin 鉴权链、座位模板绑定逻辑），但缺少一个关键不确定性：后台控制器已生成但未调试，调试过程中可能发现新的路由或权限问题。这个风险没有体现在表格中。
+
+### 缺失项 4：核销 API 安全性未评估
+
+Step 4 说"B 端小程序扫码调用"，但未说明扫码核销的安全机制：如何防止恶意刷票？如何验证核销员身份？这些问题关系到 API 设计的核心，在 Phase 2 计划阶段应该有所涉及。
+
+---
+
+## 可操作性评分：7/10
+
+### 优点：Step 1 成功标准非常清晰
+
+"HTML 源码中不再有 ThinkTemplate 标签（`{include}` / `{$` / `{if}`），座位图 div 正常显示"——这是一个写得非常好的成功标准，可观测、可验证。
+
+### 优点：模板渲染现状表格简洁有效
+
+| 项目 | 状态 | 说明 | 三列结构一目了然。
+
+### 建议 1：Step 3 缺少具体的联调检查清单
+
+Step 3 说"确认路由可访问（后台 URL 格式）/ 验证 CRUD 操作正常 / 确认 RLS 策略"，但没有说具体怎么确认。对于路由可访问，应该给出预期的 URL 格式（如 `/adminufgeyw.php?s=plugins/index/pluginsname/vr_ticket/pluginscontrol/admin/pluginsaction/seatTemplateList`）；对于 CRUD 操作，应该说清楚需要验证哪些字段。
+
+### 建议 2：决策点应给出时间限制
+
+三个决策点都没有说明谁来决策、何时决策。如果长期悬而未决，Step 1-4 中哪些任务会受阻？应说明决策是阻塞性的还是非阻塞性的。
+
+---
+
+## 一致性评分：8/10
+
+### 优点：与 docs/14 基本一致
+
+与 docs/14 相比，PHASE2_PLAN.md 中表名一致（`vrt_vr_seat_templates`）、commit 号正确（7bd896764）、状态描述吻合。
+
+### 轻微问题：文件路径基准同样不完整
+
+与 docs/14 一样，`app/index/controller/Goods.php` 路径没有注明 `shopxo/` 子目录前缀，实际路径应为 `shopxo/app/index/controller/Goods.php`。
+
+---
+
+## 误导风险评估
+
+### 高风险项
+
+**误导：Step 1 看似个人任务而非团队任务**
+
+"操作人：大头（容器在本机）"让这份计划看起来像是依赖某一个人。如果大头有事不在，Step 1 之后的步骤全部阻塞。更好的做法是说明容器访问方式（Docker exec / SSH），让任何有环境访问权限的成员都能执行。
+
+**误导：Step 2 loadSoldSeats 的定位模糊**
+
+文档将 loadSoldSeats 放在"模板渲染实测"之后、"后台管理页面联调"之前，但没有说明它是前台展示层的任务还是后台管理的任务。如果它是前台座位图状态显示的一部分，它应该和 Step 1 合并，而不是单独列为一个步骤。
+
+### 低风险项
+
+风险表写得比较完整，P0/P1 优先级标注合理。
+
+---
+
+## 总体评价
+
+PHASE2_PLAN.md 整体结构清晰，现状描述准确，成功标准写得很好，与 docs/14 的一致性也令人满意。这份文档最大的问题是信息密度不够均衡：Step 1 的成功标准写得很细，Step 2-4 却缺少操作细节；决策点给出了问题但没有给出决策框架；容器访问方式缺失意味着计划高度依赖特定个人的参与。最需要改进的是补充 Step 1 的具体操作步骤和 Step 4（核销 API）的设计要点。