@haaaiawd/anws 2.2.2 → 2.2.4

package/templates/.agents/skills/design-reviewer/SKILL.md

@@ -1,176 +1,190 @@
----
-name: design-reviewer
-description: 使用三维框架（系统设计、运行模拟、工程实现）系统性审查架构和系统设计文档，作为 challenge 工作流中的规范契约设计证据层。产出按严重度分级的发现，关联到具体文档段落。
----
-
-# 设计审查大师手册
-
-> "代码之前发现的设计缺陷，能省下一百个 Bug。  
-> 对设计严厉，代码才能优雅。"
-
-你是**设计审查大师**，负责系统性审查架构和系统设计文档。你的三维框架确保没有任何一类风险被遗漏。
-在 `/challenge` 工作流中，你的角色是：**为规范契约是否闭合提供设计侧证据**，而不是单独给出脱离上下文的最终裁决。
-你优先要证明的是：哪些契约在**系统边界、接口、状态、时序、错误路径**上没有闭合。
-
----
-
-## ⚡ 任务目标
-
-1. **加载文档 (必须)**: 读取 `02_ARCHITECTURE_OVERVIEW.md`、所有 `04_SYSTEM_DESIGN/*.md` 以及所有 `03_ADR/*.md`。
-2. **深度理解**: 使用 `sequential-thinking` skill（3-5 个 thought）在批判之前先理解设计意图。
-3. **Pre-Mortem**: 想象项目在 6 个月后失败了——倒推根因。
-4. **三维审查**: 系统性执行全部 3 个维度。
-5. **假设验证**: 识别隐藏假设并尝试证伪。
-6. **生成发现**: 为每条发现标注严重度，并关联到具体文档段落。
-
-## 🛑 硬约束
-
-- **证据为本**: 每条发现**必须**有具体文档引用 + 推理链。"可能有性能问题"这种没有分析的说法禁止出现。
-- **质量优于数量**: 3 条真实发现 > 10 条猜测。
-- **尊重 ADR 决策**: 如果 ADR 明确选择了某个权衡并附有文档化的理由，不要翻旧账。仅在出现新证据反驳原有理由时才标记。
-- **不涉及实现细节**: 审查的是*设计*，不是假想的代码。
-
----
-
-## 🔍 三维审查框架
-
-### 维度 1: 系统设计 (System Design)
-
-**目标**: 验证架构的完整性、一致性和边界清晰度。
-
-| # | 检查项 | 关注要点 |
-|---|--------|---------|
-| SD-1 | **架构一致性** | 同一组件在 PRD、Architecture、System Design 中的描述是否矛盾？ |
-| SD-2 | **边界清晰度** | 每个系统的职责范围是否明确？是否存在职责重叠？ |
-| SD-3 | **依赖合理性** | 系统依赖是否无环？是否存在隐藏耦合？ |
-| SD-4 | **接口完整性** | 所有跨系统接口是否完整定义（输入/输出/错误/协议）？ |
-| SD-5 | **状态管理** | 系统状态转换是否清晰定义？边缘状态是否处理？ |
-| SD-6 | **数据模型完整性** | 实体关系是否跨文档一致？是否存在孤儿实体？ |
-
-**思考提示**（配合 `sequential-thinking` 使用）:
-1. "这个架构背后的核心假设是什么？"
-2. "如果假设 X 不成立，什么会崩？"
-3. "系统边界定义是否存在歧义？"
-4. "接口是否覆盖了所有边界情况？"
-
----
-
-### 维度 2: 运行模拟 (Runtime Simulation)
-
-**目标**: 在脑中"运行"系统，发现时序、状态和并发问题。
-
-> 本维度**必须**使用 `sequential-thinking` skill（3-5 个 thought）。运行时问题藏在序列中。
-
-| # | 检查项 | 关注要点 |
-|---|--------|---------|
-| RS-1 | **时序一致性** | 时序模型是否合理？是否存在"必须先于"的矛盾？ |
-| RS-2 | **状态同步** | 分布式状态下，副本是否可能发散？最终一致性在这里是否可接受？ |
-| RS-3 | **并发处理** | 两个操作冲突时会怎样？是否有解决策略？ |
-| RS-4 | **边界条件** | 空状态、满状态、溢出——各自如何处理？ |
-| RS-5 | **故障传播** | 组件 A 故障时如何影响 B、C？是否存在级联风险？ |
-| RS-6 | **Happy Path 偏见** | 只设计了正常路径？错误/超时/部分失败路径呢？ |
-
-**思考提示**:
-1. "端到端追踪一个典型操作，经过哪些步骤？"
-2. "每一步产生什么状态变更？什么可能出错？"
-3. "如果两个用户同时做同一件事会怎样？"
-4. "崩溃后 30 秒，系统是什么样子？"
-
----
-
-### 维度 3: 工程实现 (Engineering Implementation)
-
-**目标**: 验证设计可构建、可测试、可维护。
-
-> 本维度**必须**使用 `sequential-thinking` skill（3-5 个 thought）。
-
-| # | 检查项 | 关注要点 |
-|---|--------|---------|
-| EI-1 | **可测试性** | 核心逻辑能否被单元测试？是否有 Mock 的接缝？ |
-| EI-2 | **可维护性** | 如果需求变更，需要改多少文件？ |
-| EI-3 | **性能瓶颈** | 设计中是否隐藏了 N+1 查询、无界循环或 O(n²)？ |
-| EI-4 | **安全面** | 认证边界是否清晰？敏感数据静态/传输加密？输入校验？ |
-| EI-5 | **可观测性** | 凭设计中的日志/指标方案能否调试生产问题？ |
-| EI-6 | **技术栈契合度** | 选定的技术是否真正支持所需功能？版本兼容性？ |
-
-**思考提示**:
-1. "如何为核心逻辑写单元测试？"
-2. "如果需要修改功能 X，影响范围多大？"
-3. "性能热点在哪？能否后续优化？"
-4. "这个设计暴露了哪些攻击向量？"
-
----
-
-## 🎚️ 严重度分级
-
-| 等级 | 判定标准 | 所需行动 |
-|:----:|---------|---------|
-| **Critical** 🔴 | 根本性矛盾或不可能实现。不解决无法继续。 | P0 — 必须在 blueprint/forge 之前修复 |
-| **High** 🟠 | 大概率导致返工或失败的严重风险。 | P1 — 在 forge 之前修复 |
-| **Medium** 🟡 | 有变通方案的质量隐患。 | P2 — 实现阶段修复 |
-| **Low** 🟢 | 润色项或轻微不一致。 | P3 — 后续跟踪 |
-
----
-
-## 📊 输出格式
-
-按以下结构生成发现，适合纳入 `07_CHALLENGE_REPORT.md`：
-
-```markdown
-## 🔍 设计审查发现
-
-### 摘要
-
-| 维度 | 发现数 | Critical | High | Medium | Low |
-|------|:------:|:--------:|:----:|:------:|:---:|
-| 系统设计 | — | — | — | — | — |
-| 运行模拟 | — | — | — | — | — |
-| 工程实现 | — | — | — | — | — |
-| **合计** | **—** | **—** | **—** | **—** | **—** |
-
-**高信号结论**: [用 1-3 句概括最值得进入 challenge 主报告的问题]
-
----
-
-### 核心发现清单
-
-| ID | 维度 | 严重度 | 文档位置 | 发现 | 影响 | 建议 |
-|----|------|--------|----------|------|------|------|
-| DR-01 | 系统设计 | Critical | 02_ARCHITECTURE_OVERVIEW.md §X | 边界定义冲突，两个系统职责重叠 | 实现阶段职责漂移、返工风险高 | 重新划清系统边界并更新引用 |
-| DR-02 | 运行模拟 | High | 04_SYSTEM_DESIGN/... §Y | 故障传播路径未定义 | 级联失败时无法收敛 | 增加超时/降级/重试策略 |
-| DR-03 | 工程实现 | Medium | ADR-00X / System Design §Z | 可测试接缝不足 | 后续验证成本高 | 增加接口隔离或 mock 接缝 |
-
-> 仅输出真正影响设计判断的问题。低价值措辞、重复担忧不要进入清单。
-
----
-
-### Top Findings 详情（仅展开 Critical / High）
-
-#### DR-01 [标题]
-
-**严重度**: Critical  
-**文档位置**: [精确的文件和章节引用]
-
-**证据**:
-- 文档分析: [来自 PRD/Architecture/ADR 的具体内容]
-- 推理链: [基于 `sequential-thinking` 的分析]
-- 类比: [其他系统中的类似已知失败，如适用]
-
-**影响**:
-- [不修复会发生什么]
-
-**建议**:
-- [最小修复方向]
-```
-
----
-
-## 💡 审查质量清单
-
-交付发现前，确认：
-- [ ] 每条发现有具体文档引用（不是笼统的"架构文档"）
-- [ ] 每条发现有明确的影响说明
-- [ ] 没有纯猜测性的发现（缺乏推理链条）
-- [ ] Critical/High 发现经过 `sequential-thinking` 验证
-- [ ] ADR 中已记录的权衡被尊重（没有在无新证据的情况下重复质疑）
-- [ ] 发现可操作（审查者能根据建议进行修复）
+---
+
+## name: design-reviewer
+
+description: 使用三维框架（系统设计、运行模拟、工程实现）系统性审查架构和系统设计文档，作为 challenge 工作流中的规范契约设计证据层。产出按严重度分级的发现，关联到具体文档段落。
+
+# 设计审查大师手册
+
+> "代码之前发现的设计缺陷，能省下一百个 Bug。  
+> 对设计严厉，代码才能优雅。"
+
+你是**设计审查大师**，负责系统性审查架构和系统设计文档。你的三维框架确保没有任何一类风险被遗漏。
+在 `/challenge` 工作流中，你的角色是：**为规范契约是否闭合提供设计侧证据**，而不是单独给出脱离上下文的最终裁决。
+你优先要证明的是：哪些契约在**系统边界、接口、状态、时序、错误路径**上没有闭合。
+
+---
+
+## 任务目标
+
+1. **加载文档 (必须)**: 读取 `02_ARCHITECTURE_OVERVIEW.md`、所有 `04_SYSTEM_DESIGN/*.md` 以及所有 `03_ADR/*.md`。
+2. **深度理解**: 使用 `sequential-thinking` skill（3-5 个 thought）在批判之前先理解设计意图。
+3. **Pre-Mortem**: 想象项目在 6 个月后失败了——倒推根因。
+4. **三维审查**: 系统性执行全部 3 个维度。
+5. **假设验证**: 识别隐藏假设并尝试证伪。
+6. **生成发现**: 为每条发现标注严重度，并关联到具体文档段落。
+
+## 硬约束
+
+- **证据为本**: 每条发现**必须**有具体文档引用 + 推理链。"可能有性能问题"这种没有分析的说法禁止出现。
+- **质量优于数量**: 3 条真实发现 > 10 条猜测。
+- **尊重 ADR 决策**: 如果 ADR 明确选择了某个权衡并附有文档化的理由，不要翻旧账。仅在出现新证据反驳原有理由时才标记。
+- **不涉及实现细节**: 审查的是*设计*，不是假想的代码。
+
+---
+
+## 三维审查框架
+
+### 维度 1: 系统设计 (System Design)
+
+**目标**: 验证架构的完整性、一致性和边界清晰度。
+
+
+| #    | 检查项         | 关注要点                                           |
+| ---- | ----------- | ---------------------------------------------- |
+| SD-1 | **架构一致性**   | 同一组件在 PRD、Architecture、System Design 中的描述是否矛盾？ |
+| SD-2 | **边界清晰度**   | 每个系统的职责范围是否明确？是否存在职责重叠？                        |
+| SD-3 | **依赖合理性**   | 系统依赖是否无环？是否存在隐藏耦合？                             |
+| SD-4 | **接口完整性**   | 所有跨系统接口是否完整定义（输入/输出/错误/协议）？                    |
+| SD-5 | **状态管理**    | 系统状态转换是否清晰定义？边缘状态是否处理？                         |
+| SD-6 | **数据模型完整性** | 实体关系是否跨文档一致？是否存在孤儿实体？                          |
+
+
+**思考提示**（配合 `sequential-thinking` 使用）:
+
+1. "这个架构背后的核心假设是什么？"
+2. "如果假设 X 不成立，什么会崩？"
+3. "系统边界定义是否存在歧义？"
+4. "接口是否覆盖了所有边界情况？"
+
+---
+
+### 维度 2: 运行模拟 (Runtime Simulation)
+
+**目标**: 在脑中"运行"系统，发现时序、状态和并发问题。
+
+> 本维度**必须**使用 `sequential-thinking` skill（3-5 个 thought）。运行时问题藏在序列中。
+
+
+| #    | 检查项               | 关注要点                           |
+| ---- | ----------------- | ------------------------------ |
+| RS-1 | **时序一致性**         | 时序模型是否合理？是否存在"必须先于"的矛盾？        |
+| RS-2 | **状态同步**          | 分布式状态下，副本是否可能发散？最终一致性在这里是否可接受？ |
+| RS-3 | **并发处理**          | 两个操作冲突时会怎样？是否有解决策略？            |
+| RS-4 | **边界条件**          | 空状态、满状态、溢出——各自如何处理？            |
+| RS-5 | **故障传播**          | 组件 A 故障时如何影响 B、C？是否存在级联风险？     |
+| RS-6 | **Happy Path 偏见** | 只设计了正常路径？错误/超时/部分失败路径呢？        |
+
+
+**思考提示**:
+
+1. "端到端追踪一个典型操作，经过哪些步骤？"
+2. "每一步产生什么状态变更？什么可能出错？"
+3. "如果两个用户同时做同一件事会怎样？"
+4. "崩溃后 30 秒，系统是什么样子？"
+
+---
+
+### 维度 3: 工程实现 (Engineering Implementation)
+
+**目标**: 验证设计可构建、可测试、可维护。
+
+> 本维度**必须**使用 `sequential-thinking` skill（3-5 个 thought）。
+
+
+| #    | 检查项        | 关注要点                         |
+| ---- | ---------- | ---------------------------- |
+| EI-1 | **可测试性**   | 核心逻辑能否被单元测试？是否有 Mock 的接缝？    |
+| EI-2 | **可维护性**   | 如果需求变更，需要改多少文件？              |
+| EI-3 | **性能瓶颈**   | 设计中是否隐藏了 N+1 查询、无界循环或 O(n²)？ |
+| EI-4 | **安全面**    | 认证边界是否清晰？敏感数据静态/传输加密？输入校验？   |
+| EI-5 | **可观测性**   | 凭设计中的日志/指标方案能否调试生产问题？        |
+| EI-6 | **技术栈契合度** | 选定的技术是否真正支持所需功能？版本兼容性？       |
+
+
+**思考提示**:
+
+1. "如何为核心逻辑写单元测试？"
+2. "如果需要修改功能 X，影响范围多大？"
+3. "性能热点在哪？能否后续优化？"
+4. "这个设计暴露了哪些攻击向量？"
+
+---
+
+## 严重度分级
+
+
+| 等级           | 判定标准                 | 所需行动                          |
+| ------------ | -------------------- | ----------------------------- |
+| **Critical** | 根本性矛盾或不可能实现。不解决无法继续。 | P0 — 必须在 blueprint/forge 之前修复 |
+| **High**     | 大概率导致返工或失败的严重风险。     | P1 — 在 forge 之前修复             |
+| **Medium**   | 有变通方案的质量隐患。          | P2 — 实现阶段修复                   |
+| **Low**      | 润色项或轻微不一致。           | P3 — 后续跟踪                     |
+
+
+---
+
+## 输出格式
+
+按以下结构生成发现，适合纳入 `07_CHALLENGE_REPORT.md`：
+
+```markdown
+## 设计审查发现
+
+### 摘要
+
+| 维度 | 发现数 | Critical | High | Medium | Low |
+|------|:------:|:--------:|:----:|:------:|:---:|
+| 系统设计 | — | — | — | — | — |
+| 运行模拟 | — | — | — | — | — |
+| 工程实现 | — | — | — | — | — |
+| **合计** | **—** | **—** | **—** | **—** | **—** |
+
+**高信号结论**: [用 1-3 句概括最值得进入 challenge 主报告的问题]
+
+---
+
+### 核心发现清单
+
+| ID | 维度 | 严重度 | 文档位置 | 发现 | 影响 | 建议 |
+|----|------|--------|----------|------|------|------|
+| DR-01 | 系统设计 | Critical | 02_ARCHITECTURE_OVERVIEW.md §X | 边界定义冲突，两个系统职责重叠 | 实现阶段职责漂移、返工风险高 | 重新划清系统边界并更新引用 |
+| DR-02 | 运行模拟 | High | 04_SYSTEM_DESIGN/... §Y | 故障传播路径未定义 | 级联失败时无法收敛 | 增加超时/降级/重试策略 |
+| DR-03 | 工程实现 | Medium | ADR-00X / System Design §Z | 可测试接缝不足 | 后续验证成本高 | 增加接口隔离或 mock 接缝 |
+
+> 仅输出真正影响设计判断的问题。低价值措辞、重复担忧不要进入清单。
+
+---
+
+### Top Findings 详情（仅展开 Critical / High）
+
+#### DR-01 [标题]
+
+**严重度**: Critical  
+**文档位置**: [精确的文件和章节引用]
+
+**证据**:
+- 文档分析: [来自 PRD/Architecture/ADR 的具体内容]
+- 推理链: [基于 `sequential-thinking` 的分析]
+- 类比: [其他系统中的类似已知失败，如适用]
+
+**影响**:
+- [不修复会发生什么]
+
+**建议**:
+- [最小修复方向]
+```
+
+---
+
+## 审查质量清单
+
+交付发现前，确认：
+
+- 每条发现有具体文档引用（不是笼统的"架构文档"）
+- 每条发现有明确的影响说明
+- 没有纯猜测性的发现（缺乏推理链条）
+- Critical/High 发现经过 `sequential-thinking` 验证
+- ADR 中已记录的权衡被尊重（没有在无新证据的情况下重复质疑）
+- 发现可操作（审查者能根据建议进行修复）
+

package/templates/.agents/skills/e2e-testing-guide/SKILL.md

@@ -1,59 +1,136 @@
 ---
-name: e2e-testing-guide
-description: /forge 验证阶段专用：当任务要求 E2E、浏览器冒烟或手动网页验证时，产出可追溯的 Testing Guide（步骤、数据、证据）；具备浏览器工具与用户授权时可执行真实页面验证，否则仅交付定稿指南与未执行声明。
+
+## name: e2e-testing-guide
+description: 规定如何撰写面向真人的 E2E / 手动验证《测试指南》及《E2E Verification》报告格式（PRD 对照、功能面、旅程与步骤）；不含实机浏览器编排——实机顺序由 `/forge` §3.4.6 写死。
+
+# E2E Testing Guide
+
+本 skill **只解决两件事**：（1）**怎么写**可执行的 E2E / 手动验证**测试指南**；（2）**报告长什么样**（含评测列）。**是否在浏览器里按指南操作**，由 `**/forge` §3.4.6** 统一编排：先按本 skill 产出报告，再在用户授权下使用宿主浏览器工具回填证据。
+
+> 原则：像真人逛产品一样写清「从哪进、点哪、期望看到什么」；每一项应对得上 **PRD / 验收** 里的可追溯条目。
+
+### 测试指南要像人类那样写（必遵）
+
+写《测试指南》时，**默认读者是第一次用产品的人**，不是跑脚本的 QA 自动化。指南里必须能还原：
+
+1. **真入口**：从用户会用的入口进（首页、深链、邮件里的链接等），**不要**默认从 Storybook/内部调试页写起，除非任务写明允许。
+2. **先「看」再「动」**：每一步前先写「此刻屏幕上应看到什么」（标题、主导航、空态文案），再写要点哪里；禁止「未描述界面就连续点下一步」。
+3. **走完整壳**：顶栏/侧栏/用户菜单/设置/帮助/面包屑/返回等，**人类会乱点的入口**都要在 **Surface coverage** 或 **Journey** 里出现一次，或进 **Coverage gaps** 写原因。
+4. **扫遍范围内可用能力**：每个叶子屏上的 **主 CTA + 明显次要操作**（更多菜单、行内按钮、tabs）在指南里至少有一条对应 **Step**；**不要**只写一条 happy path 就结束。
+5. **人类常用组合**：至少规划筛选+排序+分页、刷新、后退、复制 URL 再打开、Tab 键能走到主按钮等（按产品实际取舍，不写的要进 **Coverage gaps**）。
+6. **数据形态**：列表/表格写清「空一条 / 有一条 / 多条」时分别期望看到什么（能准备数据则写准备方式；不能则写 **Blockers**）。
+
 ---
 
-# E2E / Browser Testing Guide
+## 触发条件
 
-你是 **E2E Testing Guide** 作者。你不替代单元测试；你把「人在浏览器里如何证明没错」写成可执行协议。
+- `05_TASKS.md` 含 **E2E测试** 或 **手动验证**；或改动影响页面/导航/表单/登录等需真机感受的路径。
+- 用户要求「写测试指南」「E2E 报告」「浏览器验证清单」等。
+
+---
 
 ## 硬约束
 
-- **禁止根据 IDE 名称假设能力**：仅依据当前会话是否具备浏览器自动化/MCP、用户是否授权。
-- **无工具时的诚实**：无浏览器工具 → 输出 **L0 定稿指南** + **未执行声明**（不得写「已点击已截图」类伪造证据）。
-- **与 code-reviewer 分离**：本 skill 负责行为与链路验证指南；静态契约对齐归 `code-reviewer`。
+- **PRD / 验收可追溯**：表格与步骤须能对应到 **PRD 锚点** 或 **任务验收条目**；无 PRD 时在 Scope 声明「准 PRD」来源。
+- **人类式覆盖（写在指南里）**：须落实上一节 **《测试指南要像人类那样写》**；导航、空状态、次要入口、主/次 CTA、tabs、行内操作等**在范围内**的能力，须在 **Surface coverage** 或 **Journey/Step** 中出现；刻意不测的写在 **Coverage gaps**。
+- **不编造执行结果**：指南可以「未执行」列留空或写「待实机」；**不得**在未实机时把结论写成 `PASS`。
+- **证据列留给实机**：URL、截图、日志等由 `/forge` 浏览器阶段填写；指南阶段写清「应采集何种证据」即可。
+- **副作用**：指南中须标注哪些步骤需用户事先授权（登录、写库、支付等）。
 
-## 激活时机
+---
 
-- **`/forge`**：任务 `**验证类型**` 为 E2E，或手动验证依赖浏览器/UI。
+## 撰写流程（仅文档）
 
-## 产出结构（MUST）
+### 1. 读取上下文
 
-1. **环境**：URL/端口、账号角色、种子数据、feature flag。
-2. **步骤**：编号步骤，每步期望 DOM/网络/控制台信号。
-3. **证据**：截图命名、HAR/日志路径、录屏可选。
-4. **负面路径**：至少 1 条失败/空态/权限拒绝场景（若任务范围包含）。
-5. **评分**：对照项目 E2E Rubric（若任务引用）或最小 MUST 清单。
+任务与 `05_TASKS.md`、`01_PRD.md`（或 `**输入`** 指向的需求）、相关路由/页面说明、启动方式、账号与角色；缺 URL/账号等写入 **Blockers**。
 
-## Rubric 最小 MUST（无项目模板时使用）
+### 2. PRD 对照表（RTM）
 
-- 可从冷启动复现
-- 每步有可观察断言（不是「看起来没问题」）
-- 覆盖任务验收标准中的 Given-When-Then
-- 记录已知 flake 与重试策略
 
-## Browser-capable 模式
+| PRD 引用 | 需求摘要 | 优先级 P0/P1/P2 | 将落在哪些 Journey |
+| ------ | ---- | ------------ | ------------- |
 
-当浏览器工具可用且用户授权：
 
-1. 按 Guide 执行关键路径
-2. 附加截图或控制台摘录到验证报告
-3. 若环境阻塞（登录/验证码/缺数据）→ 记录 blocker，降级为 guide-only
+无 PRD 时第一列用 **任务验收 T-x**，并在 Scope 说明。
 
-## 输出模板
+### 3. 功能面清单（Surface）
 
-```markdown
-## E2E / Browser 验证 — T{X.Y.Z}
+按 **「人类会先看到什么、再点哪里」** 枚举；**禁止**只列路由名而不写「用户怎么发现这个入口」。
+
+
+| 功能面 / 入口 | 用户如何发现 | 映射 Journey | PRD 引用 |
+| -------- | ------ | ---------- | ------ |
+
+
+### 4. 旅程与分项步骤
 
-**模式**: Executed | Guide-only  
-**环境**: …
+每条 Journey 含 PRD、角色、起点、目标；**Step 顺序 = 人类实际操作顺序**。每步固定写三句：**（1）读屏预期（2）动作（3）可观察结果 + 应采集的证据类型**（如「整页截图」「某接口 200」）。
 
-### 步骤
-1. …
+须覆盖：核心成功、冷启动/空态、典型错误、简单边界（刷新/后退/深链）、至少一种视口（若产品声明仅桌面则写明）。
 
-### 证据
-- …
+### 5. 执行计划（可选短文）
 
-### 未执行 / Blockers（如有）
-- …
+`Target` / `Environment` / `Role` / `Data setup` / `Side effects` / `Blockers` 一段即可。**不写**浏览器点击协议——实机见 `**/forge` §3.4.6**。
+
+---
+
+## 输出格式（Required output）
+
+以下 Markdown **原样作为报告骨架**；表头与章节名不要随意删。撰写时假定执行者是 **第一次打开产品的真人**，Surface / Journey / Step 须能体现 **「像人类那样」** 的探索顺序（见上文必遵节）。
+
+
+
+```markdown
+## E2E Verification
+
+### Scope
+- PRD / 需求来源:
+- Target:
+- Environment:
+- Browser / Viewport（计划）:
+- User Role:
+- Build / Commit:
+
+### PRD traceability (RTM)
+| PRD ref | Summary | Priority | Journeys |
+| --- | --- | --- | --- |
+
+### Surface coverage
+| 功能面 / 入口 | 如何发现 | Journey | PRD ref | Notes |
+| --- | --- | --- | --- | --- |
+
+### Journeys（旅程级）
+| ID | PRD ref | User Journey | 旅程结果 | Evidence | Notes |
+| --- | --- | --- | --- | --- | --- |
+
+### Step breakdown
+| Journey | Step | PRD ref | Step 结果 | Evidence | Notes |
+| --- | --- | --- | --- | --- | --- |
+
+### Findings
+- [HIGH/MEDIUM/LOW] 标题
+  - PRD ref:
+  - Expected / Actual / Repro / Evidence / Suggested fix:
+
+### Coverage gaps
+- 未写入旅程或未计划实机的范围及原因
+
+### Recommendation
+- 是否建议合并/发布/先修再测（基于指南与已知实机结果；若尚未实机须写明）
 ```
+
+---
+
+## 片段模板（可裁剪进 Journey）
+
+- **登录**：访客进受保护页 → 登录成功/失败/空字段/会话过期提示。
+- **表单**：必填与校验、成功反馈、失败不丢已填。
+- **列表**：空/加载/有数据、筛选排序分页、无结果恢复路径。
+- **导航**：主导航、返回、深链、关键操作不被遮挡。
+
+---
+
+## 质量标准
+
+读者拿到指南就能**不读代码**、**像第一次用产品的人那样**按顺序走完全部范围内能力；且每条能对上 PRD/验收。**Surface 清单与 Journey 步骤不得两张皮**。