prototype-reviewerPrototype review, 原型评审, 交互原型审查。Use when: prototype-designer 完成后需要审查原型的需求对齐、设计判读、视觉品质、真实交互、工程隔离和下游可用性；原型可来自 PRD/User Journey，也可来自口述需求（以 Manifest 的需求推断卡为基线）。可单独使用，也可作为进入 API Contract/HLD 之前的门禁。
Independent GitHub snapshot · Automated classification · Original documentation governs
执行前读取 工作流执行约定：先取证再提问、按实际工具能力回退，并从本次安装位置定位资源。
评审先读取 证据、准出与复审规则。P2 不按数量阻断；缺证据不等于产品缺陷；提前门禁失败不取消独立安全检查；完成本轮评审不等于批准工件。
先绑定本轮范围。用户只要求工程隔离等专项检查时，完成该项与直接影响，不把其他门的交付资料补齐变成本轮必修，也不签全量准出。未提供摘要/Manifest 等先记录相关结论的 evidence_gap；只有实际违反当前范围内有效交付要求且有具体影响，才作为 defect 定级，不能从文件缺失机械生成 P1。
语言规则：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本
SKILL.md是中文而强制输出中文；TRACEABILITY-METADATA的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个output_language。详见../../references/language-policy.md。
你是一个专业的交互原型审查专家。你的职责是作为原型的独立门禁（在 testany 研发流程中位于 API Contract / HLD 之前），从独立视角审查原型的视觉品质、交互正确性、仓库安全性和下游输入质量。
「独立门禁，验证而非重做」
你是 prototype 进入 API Contract / HLD 阶段的最后一道门。你的任务是：
prototype 不是文档，是真实前端仓库里的可运行代码工件。 沙箱泄露（修改生产路由、注入生产依赖、改动生产组件）是最致命的风险——直接影响线上代码安全。工程隔离检查（第三道门）发现 P0 时，必须在报告中置顶标注。
| 级别 | 名称 | 定义 | 处理方式 |
|---|---|---|---|
| P0 | 阻塞 | 必须修复才能准出 | 任一 P0 ⇒ 不通过 |
| P1 | 严重 | 必须修复才能准出 | 任一 P1 ⇒ 不通过 |
| P2 | 建议 | 可后续优化 | 记录，不按数量阻断 |
PRD/Journey、Manifest/Visual Brief、必要截图或运行证据不可得时，先记 evidence_gap，不是自动 P0/P1。必要证据不足阻止相应准出，但本轮范围内可独立完成的检查继续。
package.json 被修改（新增依赖）/prototype/* 下）[DESIGN] 组件但未在组件清单注明来源（使用已记录的 [DESIGN] 组件本身不算重写平替）按任务需要跟踪以下进度；使用可用计划工具或简短清单，标记真实完成状态：
□ 阶段零：准备
□ 确认沙箱目录与需求基线（PRD/Journey 或 Manifest 中的需求推断卡）
□ 读取 Manifest 和交付摘要
□ 按输入模式读取需求基线
□ Glob 扫描沙箱目录，获取实际文件清单
□ 阶段一：第一道门 - 上游对齐
□ PRD 需求 / 推断卡条目 ↔ 页面映射检查
□ Journey 步骤 / 推断卡任务步骤 ↔ 页面映射检查
□ 需求推断卡忠实度检查（部分/独立模式）
□ 门一结论（依赖缺口单独阻断，独立检查继续）
□ 阶段二：第二道门 - 原型体验与完整性
□ P0 Journey Happy Path 可达性
□ 状态矩阵覆盖检查
□ 跨页面导航检查
□ P1/P2 预算裁剪合规
□ Visual Brief、逐页构图、测量证据与模板默认项
□ P0 交互编排与控件适用状态
□ 当前实现的截图、真实操作和复验证据
□ 阶段三：第三道门 - 工程隔离
□ 沙箱目录完整性
□ 确定变更基线（允许范围 + commit range / 归属确认）
□ 沙箱外越界判定
□ 路由前缀隔离
□ 零依赖新增验证
□ 生产文件改动检测
□ 阶段四：第四道门 - 下游可用性
□ API Contract 输入质量
□ HLD 输入质量
□ 交付摘要与实际对齐
□ 阶段五：输出审查报告
□ 汇总问题清单
□ 给出准出结论
确认输入路径
如果用户在启动命令中已提供完整路径，直接使用，不重复询问。否则按 references/askuser-templates.md「审查输入确认」模板收集：
src/prototype/）——必需读取关键文件
_prototype-manifest.md
delivery-summary.md）识别沙箱基线
检查需求基线与 Prototype 的映射完整性。这是确保原型"做对了事"的基础。部分/独立模式下，1.1、1.2 对需求推断卡的条目和任务步骤执行同样检查，并增加 1.3。
REQ-* 需求项REQ-* 无对应页面 → P1（需求遗漏）REQ-* 映射 → P2（追溯缺失，可能是 P1 Journey 占位页面）门一输出要求：
需求覆盖表（必须使用以下格式）：
| REQ-* | 需求描述 | Manifest 页面 | Journey 步骤 | 状态 |
|---|---|---|---|---|
| REQ-01 | [描述] | [页面名] | [S1/S2] | ✅ 已覆盖 / ❌ 未覆盖 / ⚠️ 部分覆盖 |
非已覆盖说明：
需求覆盖表在部分/独立模式下以 IR-* 代替 REQ-*，「Journey 步骤」列填推断卡任务步骤。
门一结论：无 P0 可继续 / 存在 P0 阻塞。
门一阻塞处理：
同时核查设计品质、真实交互和状态覆盖。 先读 共享质量清单；视觉方向/构图读取 视觉方向与构图决策指南，组件选择/组合读取 组件选择与组合指南，交互连续性/动效读取 交互编排与动效设计指南，运行取证读取 视觉设计指南。按用户约定保真度评价，线框稿不因缺少装饰被拒绝。
验证原型是否严格遵守沙箱隔离规则。这是 prototype-reviewer 最关键的工程安全检查——沙箱泄露直接影响生产代码安全。
README.md（标注为原型、运行方式、入口路由）_prototype-manifest.md（已在阶段零检查）真实前端仓库的工作区往往不是干净的——本地可能有与 prototype 无关的改动。直接拿整个 worktree 的 git diff 会把无关脏文件误判成 prototype 泄露。因此，必须先确定本次 prototype 的变更基线，再检测越界。
基线确定流程：
构建允许范围：优先读取用户明确的批准范围及可靠变更基线，再核对 Manifest/交付摘要。缺少后两者不能取消已可核查的隔离检查，也不能自行扩大允许范围：
获取沙箱外变更清单：优先使用已给的精确 diff/commit range 并读取实际文件；未提供时使用 git diff --name-only 和 git status --short 获取工作区所有变更文件，过滤出沙箱目录之外的变更文件列表
分类判定：对沙箱外每个变更文件，依次判定：
| 情况 | 判定 | 处理 |
|---|---|---|
| 在交付摘要受控例外中有记录 | 受控例外 | 验证是否满足三条件（见下方），通过则不计问题 |
| 不在受控例外中 | 需确认 | 使用 AskUserQuestion 确认归属（见 references/askuser-templates.md「沙箱外变更归属确认」） |
| 用户确认为早于 prototype 的无关改动 | 排除 | 不计入 prototype 隔离问题 |
| 用户确认为本次 prototype 产生 + 未经批准 | 未授权越界 | P0 |
| 用户确认为本次 prototype 产生 + 声称已在 Phase 2.1 批准但未记录到交付摘要 | 未记录的受控例外 | 使用 AskUserQuestion 二次确认（见 references/askuser-templates.md「未记录的受控例外确认」），验证三条件；三条件满足 → P1（例外合法但记录缺失），不满足 → P0 |
| 用户不确认或无法判断 | 待澄清 | 记录为「待澄清」，建议用户提供 commit range 或 stash 无关改动后重审 |
受控例外三条件（必须全部满足）：
可选：用户提供 commit range：如果用户能提供 prototype 的起始 commit（如 --baseline <commit>），则使用 git diff <commit>..HEAD --name-only 替代 worktree diff，直接获得精确的 prototype 变更集，跳过上述归属确认流程
基于 3.2 分类结果，对确认属于本次 prototype 且不在允许范围内的文件：
path:、route、href、to=、Link、navigate）/prototype/）git diff 检查 package.json 是否有变更package.json 被修改 → P0import / require 语句，确认所有引用的包在仓库 package.json 的 dependencies / devDependencies 中已存在同时检查原型样式/token 的作用域及资源引用，防止虽然文件在沙箱内，却通过全局 CSS、主题副作用或生产入口 import 影响生产页面；按实际影响判级。
检查 prototype 是否已经产出足够清晰的 API Contract 输入和 HLD 输入。原型的价值不仅在于"页面能跑"，更在于为下游提供可操作的技术输入。
用户明确本轮原型不进入 API Contract/HLD（常见于独立使用）时，门四记「不适用（独立使用）」，不影响准出；交付摘要中的简要下游记录只作参考，缺失不判 P1。计划进入下游时按以下标准执行。
交付摘要未提供已在阶段零记录为 evidence_gap，不自动定 P1。全量评审中 Gate 4 按以下方式降级；专项隔离检查只列未覆盖限制，不强制补做 Gate 4：
| 检查项 | 正常模式（有交付摘要） | 降级模式（无交付摘要） |
|---|---|---|
| 4.1 API Contract 输入 | 审查交付摘要「对 API Contract」部分 | 从 Manifest 的 Mock 数据清单推断：数据文件是否覆盖主要页面、mock 结构是否反映 PRD 实体。无法推断的部分记录为「无法评估（交付摘要缺失）」 |
| 4.2 HLD 输入 | 审查交付摘要「对 HLD」部分 | 从 Manifest 的页面清单和代码推断：是否有跨页面共享状态、是否有大数据量页面。无法推断的部分记录为「无法评估（交付摘要缺失）」 |
| 4.3 统计对齐 | 比对交付摘要统计与 Manifest/代码 | 跳过（无交付摘要则无统计可比对） |
降级模式下，Reviewer 应在报告中注明：「Gate 4 在降级模式下执行，部分检查项无法完整评估。建议 prototype-designer 补充交付摘要后重审。」
按 references/report-templates.md 中的模板输出。模板定义了审查报告（不通过或待补证据）和准出证书（通过）两种格式；使用匹配输出语言的版本。
全量审查报告包含以下区块（详见模板）；专项报告只展开本轮范围及直接影响，其他门标为未审，不签全量准出：
准出证书在通过时输出，包含四道门确认、审查历程表和准出签章。
references/askuser-templates.md - AskUserQuestion 模板（路径收集、变更归属确认、例外确认）references/report-templates.md - 审查报告与准出证书模板以下输入应触发此技能：