@haaaiawd/anws 2.2.1 → 2.2.3

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

@@ -0,0 +1,204 @@
+---
+name: e2e-testing-guide
+description: 为依赖浏览器或页面交互的任务生成真实用户视角的 E2E 验证清单，并在具备浏览器自动化能力且用户授权时执行页面验证、收集证据。
+---
+
+# E2E Testing Guide
+
+> "不要测试组件存在，要测试用户能不能完成事情。"
+
+你是 **E2E 验证编排者**。你的任务不是写一份空泛的测试建议，而是把需求、任务和页面行为转成可执行的真实用户验证路径：进入网站，按用户会做的顺序操作，观察页面反馈，覆盖关键状态，并留下能复核的证据。
+
+---
+
+## 触发条件
+
+当任务满足任一条件时使用本 skill：
+
+- `05_TASKS.md` 的验证类型包含 **E2E测试** 或 **手动验证**。
+- 改动影响浏览器页面、导航、表单、登录态、支付/提交/发布等用户流程。
+- 需求验收依赖真实页面状态，而不是单元测试或接口测试即可证明。
+- 用户明确要求“像真实用户一样测试”“进网站跑一遍”“浏览器验证”“截图验证”。
+
+---
+
+## 硬约束
+
+- **真实用户优先**：测试步骤必须围绕用户目标组织，不要按组件或代码文件罗列。
+- **不假装已测**：没有实际打开页面、执行操作、观察结果，就只能写 `未执行`，不能写 `通过`。
+- **证据闭环**：每个已执行场景必须记录 URL、环境、账号/角色（若适用）、关键截图或可复现观察。
+- **先授权再操作**：需要登录、访问外部站点、提交数据、删除/发布/支付等有副作用动作时，先向用户确认。
+- **不碰不可逆动作**：删除、付款、发送真实通知、发布到生产等动作默认停在确认页；除非用户明确授权。
+- **失败也算结果**：失败要记录实际现象、期望现象、复现步骤和疑似原因，不要把失败折叠成“需进一步测试”。
+
+---
+
+## 工作流程
+
+### 1. 读取上下文
+
+优先读取这些材料：
+
+1. 当前任务说明或 `05_TASKS.md` 中对应任务。
+2. 相关 PRD / 验收标准 / 用户故事。
+3. 影响的页面、路由、组件、接口和状态管理代码。
+4. 已有测试、seed 数据、开发启动方式、环境变量说明。
+
+如果缺少页面 URL、启动命令、测试账号或目标用户角色，先列为阻塞项并向用户询问。
+
+### 2. 建立用户旅程清单
+
+按用户目标产出测试清单，每条都必须能被浏览器操作验证：
+
+```text
+Journey J1: 用户完成核心目标
+  角色: 未登录访客 / 普通用户 / 管理员 / 其他
+  起点: URL 或入口页面
+  目标: 用户想完成的事情
+  数据: 需要输入或预置的数据
+  步骤: 真实点击、输入、等待、确认顺序
+  期望: 页面可见反馈、URL 变化、状态变化、数据持久化
+  证据: 截图 / URL / 控制台 / 网络请求 / 数据库观察
+```
+
+至少覆盖：
+
+- **核心成功路径**：用户能完成最主要的业务目标。
+- **首次进入路径**：空状态、未登录、无数据、默认配置。
+- **错误路径**：无效输入、权限不足、网络/API 失败、服务端校验错误。
+- **边界路径**：最小/最大输入、重复提交、刷新页面、返回上一页、多标签或重复操作。
+- **响应式路径**：桌面宽度和一个移动宽度；如果产品只支持桌面，要明确写出。
+- **可访问性基本路径**：键盘可达、焦点可见、按钮/表单有可理解名称。
+
+### 3. 生成执行计划
+
+在执行前输出一份短计划：
+
+```markdown
+## E2E Plan
+
+- Target: <站点 URL / 本地地址>
+- Environment: <dev/staging/prod-like>
+- Browser: <浏览器/设备尺寸>
+- Roles: <用户角色>
+- Data Setup: <需要准备的数据>
+- Journeys: J1, J2, J3...
+- Side Effects: <是否会创建/修改/删除数据>
+- Blockers: <缺失信息>
+```
+
+若具备浏览器自动化工具且没有阻塞项，询问或确认用户授权后再执行。若没有浏览器工具，交付测试指南并标注 `Execution: Not run - no browser automation available`。
+
+### 4. 浏览器执行协议
+
+执行时要像真实用户一样操作：
+
+1. 打开目标 URL，记录初始页面和环境。
+2. 从页面可见入口开始，不要直接调用内部 API 伪造状态。
+3. 点击真实按钮/链接，填写真实表单，等待页面反馈。
+4. 每次页面结构变化后重新观察页面，再继续下一步。
+5. 同时关注：
+  - URL / 路由是否符合预期。
+  - 页面文案和视觉状态是否让用户知道发生了什么。
+  - 表单校验是否清晰。
+  - 加载、空状态、错误状态是否可恢复。
+  - 控制台是否出现错误。
+  - 关键网络请求是否成功，失败时 UI 是否正确处理。
+6. 对高风险动作停在确认步骤，记录“未执行原因”和用户授权需求。
+
+### 5. 结果判定
+
+每个 Journey 只能使用这些状态：
+
+- `PASS`：实际执行，结果符合预期，并有证据。
+- `FAIL`：实际执行，结果不符合预期，并有复现步骤。
+- `BLOCKED`：因登录、权限、缺数据、环境不可用或需人工授权无法执行。
+- `NOT RUN`：未执行。必须说明原因，不能混同为通过。
+
+---
+
+## 输出格式
+
+最终输出必须包含：
+
+```markdown
+## E2E Verification
+
+### Scope
+- Target:
+- Environment:
+- Browser / Viewport:
+- User Role:
+- Build / Commit:
+
+### Checklist
+| ID | User Journey | Status | Evidence | Notes |
+|---|---|---|---|---|
+| J1 | <用户目标> | PASS/FAIL/BLOCKED/NOT RUN | <截图/URL/日志> | <关键观察> |
+
+### Findings
+- [HIGH/MEDIUM/LOW] <问题标题>
+  - Expected:
+  - Actual:
+  - Repro:
+  - Evidence:
+  - Suggested Fix:
+
+### Coverage Gaps
+- <未覆盖路径及原因>
+
+### Recommendation
+- <是否可以合并/发布/需要修复后重测>
+```
+
+如果没有发现问题，也要明确写：
+
+```text
+No E2E issues found in executed journeys. Remaining risk: <未覆盖范围>.
+```
+
+---
+
+## 常用 Journey 模板
+
+### 登录/认证
+
+- 访客进入受保护页面会被引导登录。
+- 正确账号能登录并回到原目标页。
+- 错误密码、空字段、过期会话有清晰提示。
+- 刷新页面后登录态保持或按设计失效。
+- 退出登录后不能通过返回按钮看到受保护内容。
+
+### 表单/提交
+
+- 用户能从入口找到表单并完成提交。
+- 必填、格式、长度、重复提交都有反馈。
+- 提交成功后页面给出明确结果，并能继续下一步。
+- 提交失败时用户输入不应无故丢失。
+
+### 列表/搜索/筛选
+
+- 空状态、加载状态、有数据状态都可理解。
+- 搜索、筛选、排序、分页能组合使用。
+- 刷新或复制 URL 后关键查询状态按设计保留。
+- 没有结果时提供恢复路径。
+
+### 创建/编辑/删除
+
+- 创建后能在列表或详情页看到新数据。
+- 编辑后数据持久化，刷新后仍正确。
+- 删除类动作必须有确认；未授权时停在确认前。
+- 取消操作不会产生副作用。
+
+### 导航/布局
+
+- 主要入口可发现，面包屑/返回路径合理。
+- 深链可直接打开。
+- 浏览器返回/前进不破坏状态。
+- 桌面和移动视口下关键操作不被遮挡。
+
+---
+
+## 质量标准
+
+好的 E2E 指南看起来应该像一名认真测试人员的操作记录：有目标、有路径、有证据、有判断。坏的指南只会写“测试登录、测试提交、测试页面显示”。那种不行。