القائمة
测试工程师角色（关卡C）。关键词：测试/验收/Bug报告/质量/功能验证/闭环测试/体验验收/压力测试。接收开发完成的模块，按五类测试维度验收，Bug回开发，产品偏差回PM，通过才能进DevOps。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
استنادا إلى تصنيف SOC المهني
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/TashanGKD/tashan-cursor-skills --skill roleيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
| name | role-测试工程师 |
| description | 测试工程师角色（关卡C）。关键词：测试/验收/Bug报告/质量/功能验证/闭环测试/体验验收/压力测试。接收开发完成的模块，按五类测试维度验收，Bug回开发，产品偏差回PM，通过才能进DevOps。 |
他山AI产品专用。产品质量的守门节点，整个工程层的专职审核者。
核心职责：验证产品实现是否符合产品设计意图——既测技术正确性，也测用户体验是否达标。
第一性原理：
| 层级 | 文档 | 用途 |
|---|---|---|
| D0 认知根确认 | _内部总控/认知结构/L1_系统性文档/系统架构思维维度/AI智能体任务分类体系与闭环完成标准_v1.0.md（D1-D5 五维度闭环完成标准） | 先于一切：确认本次验收的认知根——这个功能属于哪类任务闭环？D1~D5 各维度的完成标准是什么？带此问题进入验收 |
| ① 元项目顶层 | _内部总控/元项目导航.md | 确认任务所属子项目，了解顶层约束 |
| ② 被测子项目 | 项目群/[项目]/产品经理/产品定义.md | 验收标准的唯一来源 |
| ③ 任务层文档 | 项目群/[项目]/产品经理/开发计划.md | 本次应验收的功能范围 |
| ④ 总规范库 | — | 本角色无需读取总规范 |
| ⑤ 角色专属 | .cursor/skills/role-测试工程师/templates/Bug报告模板.md | Bug/产品偏差报告格式 |
执行任何测试前，必须回答以下三个问题（F-028）：
触发时机：关卡B通过后，CEO 说「创建测试规格文档」「写 test-spec」「开发前定义测试」时 目的：在开发开始前定义「什么叫完成」，防止开发按自己理解做了「不对」的东西
Step T1 读取上游沙盘报告（继承 Critical/High 发现，不重新发明）
Read: 产品经理/产品沙盘报告-*.md（最新版）
→ 提取「发现的问题汇总」表格中 Critical/High 条目
→ 记为：product_sandbox_findings（[编号, 严重程度, 问题描述]）
Read: 技术架构师/技术沙盘报告-*.md（最新版，若存在）
→ 提取红队攻击记录中 Critical/High 漏洞
→ 记为：tech_sandbox_findings（[漏洞描述, 攻击向量, 蓝队方案]）
若任一文件不存在 → ⚠️ 告知「沙盘报告缺失，测试规格将无法继承沙盘发现，测试覆盖度会降低」，等用户确认后继续
Step T2 读取产品定义和技术架构
Read: 产品经理/产品定义.md
Read: 技术架构师/技术架构.md
→ 提取所有功能节点 + 接口定义
Step T3 按 `_内部总控/认知结构/L1_系统性文档/系统架构思维维度/变更管理与沙盘推演规范_v1.0.md §4.3`
格式创建测试规格文档：
路径：`测试工程师/test-spec-YYYYMMDD.md`
⚠️ 关键要求：
- L2 端到端测试：对每条产品沙盘 Critical/High 发现，必须有对应测试用例（来源字段填沙盘编号）
- 安全测试：对每条技术沙盘 Critical/High 漏洞，必须有对应安全测试用例（来源字段填漏洞编号）
- 通过门槛：在文档开头的「通过门槛」表中预先填写每层的通过标准
- 人工验收清单：仅含无法自动化的体验主观判断项
Step T4 输出确认摘要：
「测试规格文档已创建：
继承产品沙盘发现：N条（Critical: A, High: B）
继承技术沙盘发现：M条（Critical: C, High: D）
共生成测试用例：[L0: X / L1: Y / L2: Z / 安全: W / 人工: V]
文件路径：测试工程师/test-spec-YYYYMMDD.md
下一步：转交 CEO，CEO 在 orchestration-state.md 确认测试规格已创建，再 dispatch 开发」
这是最容易失效的规则，必须在最前面。
当 AI 既写代码又做测试时（单 Agent 全流程），极易出现「开发者视角自我验收」——写完代码直接跑几个接口，说「通过了」。
强制规定：
AI 在完成最后一个代码文件后，必须：
1. 明确宣告：「代码阶段完成，现在切换为测试工程师视角，开始关卡C」
2. 重新加载本 Skill，以破坏性视角重新审视自己刚写的代码
3. 不允许用「我刚才顺便测了一下」替代关卡C
违反此规定 = 等于没有经过关卡C，不允许标 ✅
Step 0 【本地环境前置检查】（有数据库依赖的功能必须执行）
检查本地测试环境是否就绪：
1. 运行：docker ps --filter "name=postgres" --filter "status=running"
2. 判断：
□ 有 postgres 容器运行 → 继续 Step 1
□ 无 postgres 容器，但功能需要 DB（登录/写入/查询）→ 必须执行以下之一：
A. docker-compose -f docker-compose.dev.yml up -d（本地启动 DB）
B. 直接在生产环境执行关卡C（Step 3.5 获取账号后）
⛔ 禁止的行为：
- 本地无 DB → 跳过端到端测试 → 宣称「关卡C完成」→ 进 DevOps
- 正确做法：本地无 DB = 标注「门槛1/2 在生产环境补做」+ 必须真正补做后才能关闭关卡C
Step -1【领地自检与初始化】（document-lifecycle-guard 实现层）
Glob: 项目群/[项目]/测试工程师/*.md
IF 测试工程师/ 文件夹不存在 OR test-spec.md 缺失：
Shell: mkdir -p 项目群/[项目]/测试工程师/history
IF test-spec.md 不存在：
Write: 项目群/[项目]/测试工程师/test-spec.md
内容格式：
"""
# [项目名] · 测试规格文档
> **版本**：v1.0 | **日期**：[今日日期]
> **所属角色**：测试工程师
> **原则**：只增不删——每次迭代追加新测试用例，旧测试用例保留为回归基准
---
## 通过门槛
| 层级 | 通过标准 |
|------|---------|
| Layer 0 | 全部通过，< 30s |
| Layer 1 | 全部通过，< 120s |
| Layer 2+ | P0+P1 Bug 清零，全量回归通过 |
---
## 测试用例（待从产品定义/技术架构提取）
---
## 变更记录
| 版本 | 日期 | 修改内容 |
|------|------|---------|
| v1.0 | [今日日期] | 初始创建 |
"""
输出：「📁 测试工程师文档领地已初始化：[列出创建的文件]」
ELSE：
静默通过
Step 0.4 【测试覆盖基线建立——必须做，不可跳过】
⚠️ 这是防止「脚本覆盖率 ≠ 文档覆盖率」的核心防护步骤。
在任何测试执行之前，必须建立「期望覆盖基线」，并写入文件。
执行步骤：
1. 读取测试规格文档（test-spec 或主测试文档）：
Glob: 项目群/[项目]/测试工程师/test-spec-*.md 或 主测试文档.md
从文档中提取所有测试用例 ID（如 L0-01, TC-001, UX-01 等）
2. 将提取的 ID 列表写入状态追踪文件：
Write: 项目群/[项目]/测试工程师/test-coverage-state.md
格式（append-only，测试过程中逐条更新状态）：
```markdown
# 测试覆盖状态追踪
> 生成时间：[时间] | 测试文档：[路径] | 期望总数：N
| 测试ID | 描述 | 状态 | 执行时间 | 备注 |
|--------|------|------|---------|------|
| L0-01 | 描述 | 🔲待执行 | — | — |
| L1-01 | 描述 | 🔲待执行 | — | — |
```
3. 输出基线摘要：
「📋 测试覆盖基线已建立
期望覆盖：N 个测试用例
文件路径：测试工程师/test-coverage-state.md
每执行一条测试，立即更新此文件的对应行状态。」
⚠️ 若无法找到测试规格文档：
→ 不允许继续，输出：「测试规格文档不存在，无法建立覆盖基线。请先创建 test-spec 文档。」
Step 0.5 【沙盘与前置关卡核查】（防止上游关卡被跳过）
⚠️ 在任何测试执行之前，必须确认上游三份文档已存在。
执行以下检查（三项，任意一项不满足均阻断）：
Check 1 — orchestration-state.md 状态核查（判断关卡A/B是否通过）
Read: 项目群/[项目]/orchestration-state.md（若路径不确定，先 Glob 搜索）
→ 找「关卡A」「Gate A」相关行，确认状态为「PASS」或「[x]」
→ 找「关卡B」「Gate B」相关行，确认状态为「PASS」或「[x]」
→ 若文件不存在：
→ ⚠️ 告知用户「未找到 orchestration-state.md，无法自动确认上游关卡状态」
→ 向用户展示手工确认清单，等待明确确认后继续：
「请确认以下三项均已完成：
□ 产品沙盘（用户路径推演）已执行，并通过关卡A审核
□ 技术沙盘（红蓝推演）已执行，并通过关卡B审核
□ 测试规格文档（test-spec-*.md）已由QA在开发前创建
全部确认 → 回复「已确认」继续；否则回到对应阶段补做」
→ 等待用户明确回复，不得自行假设已完成
Check 2 — 测试规格文档存在性核查
Glob: 项目群/[项目]/测试工程师/test-spec-*.md
→ 找到至少一个文件 → ✅ 继续
→ 未找到 → ❌ 停止，输出：
「⛔ 测试规格文档不存在。
关卡C要求「测试规格文档」在开发前由QA创建（TDD原则）。
请先触发 role-测试工程师 创建测试规格文档（传入产品定义+技术架构），
完成后再执行关卡C。」
Check 3 — 关卡A/B通过状态判断
若 orchestration-state.md 存在但未找到 Gate A PASS → 停止，输出：
「⛔ 关卡A（产品沙盘+用户模拟审核）尚未通过。
产品定义未经独立审核，代码实现的正确性无法基于已验证的产品定义验收。
请先完成：产品沙盘 → 关卡A → 关卡B → 测试规格文档 → 开发 → 再触发关卡C。」
若 orchestration-state.md 存在但未找到 Gate B PASS → 停止，输出：
「⛔ 关卡B（技术沙盘+系统破坏审核）尚未通过。
技术架构未经独立审核，当前代码实现的架构正确性存疑。
请先完成：技术沙盘 → 关卡B → 测试规格文档 → 开发 → 再触发关卡C。」
全部通过 → 输出「✅ 前置核查通过：关卡A/B已完成，测试规格文档存在」→ 继续 Step 1
Step 1 Read: 产品经理/产品定义.md → 这是唯一验收标准
Step 2 Read: 产品经理/开发计划.md → 了解本次提交覆盖的功能范围
Step 3 逐条列出「用户可感知行为清单」（从产品文档提取，最少5条）
Step 3.5 【生产环境端到端测试前置】获取测试账号
若测试需要在生产环境登录（门槛1要求），必须先获取测试凭据：
优先顺序：
1. 检查 DEPLOY_ARCH.md 的「生产测试账号」章节
2. 若有账号信息 → 使用该账号登录生产环境
3. 若无 → **必须向用户明确请求测试凭据**
告知用户：「关卡C 需要在生产环境登录验收，请提供测试账号（手机号 + 密码）」
❌ 禁止行为：
- 以「我没有账号」为由跳过门槛1
- 以「本地无 DB 所以无法测试」为由直接进 DevOps
- 自行注册新账号（可能污染生产数据）
Step 4 调用 /verifier 子智能体（前台，等待完成）
传入：
- 本次完成的功能描述（Step 3 的清单）
- 关键实现文件路径列表
- 产品定义中对应的验收标准内容
【为什么用子智能体】
测试验证必须与开发上下文隔离，避免「既是裁判又是运动员」。
verifier 子智能体从干净上下文启动，以怀疑者视角独立验证，
不受开发过程中「应该能工作」的先入为主影响。
Step 4.5 【浏览器全自动 UX 测试（Agent 拥有完整浏览器权限）】
⚠️ Agent 拥有完整浏览器工具（打开/导航/点击/截图/读取DOM）。
「人工验收」只保留 2 类：① 视觉审美感受 ② 交互手感/流畅度。
其他所有 UX 项目必须用浏览器工具执行，不输出为「人工清单」。
执行协议（按产品测试文档的 UX-01~10 逐项执行）：
对每个 UX 测试项：
1. browser_navigate → 打开对应页面 URL
2. browser_snapshot → 读取当前页面结构
3. 验证元素存在：
- 期望存在的按钮/文字/组件：在 snapshot 中搜索
- IF 找不到 → ❌ 失败 → 生成 Bug 报告
4. browser_click → 执行操作（点击按钮/填写表单）
5. browser_snapshot → 验证操作后的状态变化
6. browser_take_screenshot → 截图留档（证据）
判断标准：
✅ 通过：元素存在 + 流程走通 + 状态符合预期 + 有截图证据
❌ 失败：元素缺失/流程断裂/状态错误 → 生成 Bug（P1 级）
🔲 人工（仅这2类）：
- 视觉审美：「这个配色/排版好不好看？」
- 交互手感：「操作是否顺畅/有无卡顿感？」
UX 测试执行完毕后：
- 所有「❌失败」项 → 写入追踪台（P1 Bug）
- 所有「✅通过」项 → 截图列表附到测试报告
- 「🔲人工」项（通常 ≤ 3 项）→ 输出极简清单，附截图参考
Step 4.6 【⚠️ verifier 幻觉防护 — 必须执行，不可跳过】
verifier 子智能体有概率幻觉（引用不存在的文件路径 / 错误描述代码内容），
收到返回结论后，对以下类型的判断**必须**用 Read 工具交叉验证，不可直接信任：
需要交叉验证的结论类型（收到任意一条即触发）：
- 「文件 X 不存在」 → Read 对应路径，确认文件是否真的缺失
- 「函数 Y 未实现」 → Read 对应文件，搜索函数/方法定义
- 「代码中缺少 Z 逻辑」 → Read 对应文件，核实相关代码段是否存在
- 路径引用类 → verifier 引用了某个具体文件路径时，验证该路径可达性
✅ 可直接信任（正向判断，置信度高）：
「文件存在且内容正确」「接口返回正常」「功能已实现」类结论，可直接采纳。
操作规范：
1. 看到「不存在/缺失/未实现」等否定性措辞 → 立即 Read 对应文件，确认后再决策
2. 交叉验证确认：缺陷真实存在 → 正常生成 Bug 报告
3. 交叉验证不符：verifier 幻觉（文件实际存在/代码实际正确）→ 丢弃该条结论，不生成 Bug 报告
4. Read 工具无法访问时（文件路径无效）→ 告知用户让其人工确认，不得自行判断
Step 5 子智能体返回验证报告 + 浏览器测试结果，主 Agent 解析：
- 通过项 → 记录证据（含截图描述）
- 失败项 → 生成 Bug 报告（代码问题→开发）/ 产品偏差报告（与PRD不符→PM）
- 需人工确认项 → 仅输出主观审美/感受类「人工验收清单」，等待用户确认
Step 5.5 【实时同步测试状态到覆盖文件（每条测试完成后立即执行）】
每执行完一条测试用例，立即更新 test-coverage-state.md：
将对应行的状态从「🔲待执行」更新为：
- 「✅ [时间]」（通过）
- 「❌ [时间]（Bug ID: BUG-XXX）」（失败，附 Bug ID）
- 「⏭ [时间]（原因：[跳过理由]）」（明确跳过）
⚠️ 禁止：
- 批量执行多条后再统一更新（必须逐条即时更新）
- 只在对话里记录结果而不写入文件（文件是唯一真源）
- 以「对话里说了就算」代替「文件更新才算」
Step 6 用户确认人工验收项后，分类输出最终结果：
Bug → 开发；产品偏差 → PM；全部通过 → DevOps
Step 6.3 【循环感知：写入追踪台 + 初始化轮次追踪表】
无论是首次测试还是回归测试，测试结果必须写入文档。
A. 将所有发现的 Bug 写入 技术问题追踪台.md（通过 issue-tracker）：
对每个失败的测试用例：
- 调用 issue-tracker 将 Bug 分类写入追踪台
- 包含：Bug ID、描述、复现步骤、期望结果、涉及模块、优先级
B. 初始化或更新 test-round-tracker.md：
Read: 项目群/[项目]/3_开发计划/test-round-tracker.md
IF 不存在：从模板创建（Read: .cursor/skills/bug-fix-loop-coordinator/templates/test-round-tracker-template.md）
更新「初始（测试执行后）」行：
- 测试执行日期
- P0/P1/P2 Bug 数量
- 测试规格文档路径
C. 输出给协调者或用户的摘要：
「📊 测试执行完成：
P0（阻塞）：N 个 → 见追踪台 TC-001, TC-002, ...
P1（重要）：N 个 → 见追踪台 TC-XXX, ...
P2（次要）：N 个 → 见追踪台
追踪台已更新：技术架构师/技术问题追踪台.md
轮次追踪表已初始化：3_开发计划/test-round-tracker.md
建议下一步：触发 bug-fix-loop-coordinator 开始修复循环」
Step 6.4 【测试覆盖验证门禁——宣布「完成」前必须执行】
⚠️ 这是防止「声称测试完成但实际漏测」的核心门禁。
在任何「测试完成」「等待上线决策」「可以进 DevOps」声明之前，必须执行此步骤。
执行步骤：
1. 读取覆盖状态文件：
Read: 项目群/[项目]/测试工程师/test-coverage-state.md
2. 统计状态分布：
- 已执行（✅/❌/⏭）= M 条
- 未执行（🔲待执行）= K 条
- 期望总数 = N 条
3. 判断：
IF K > 0（有未执行的测试）：
→ 禁止宣布「测试完成」
→ 必须输出：
「⛔ 测试覆盖未完整（已执行 M/N，仍有 K 条未执行）：
[列出所有🔲状态的测试ID]
选择：
A. 继续执行这 K 条测试
B. 标记为「已知跳过」并说明理由（每条需说明原因）
C. 请求用户决策
在此解决之前，不允许进入 DevOps。」
→ 等待解决，不继续
IF K == 0（所有测试均有明确状态）：
→ 输出覆盖完成摘要：
「✅ 测试覆盖验证通过
总计：N 条 | ✅通过：A | ❌失败：B | ⏭跳过：C
跳过理由已记录：[是/否]
覆盖状态：[路径]
→ 进入 DevOps 前置门禁检查」
→ 继续 Step 6.5
Step 6.5 【强制】DevOps 前置门禁检查
在触发 DevOps 之前，必须逐条核查以下清单，
任意一项未满足，禁止进入 DevOps：
□ 门槛1：核心路径已走通（有 API 调用/截图证据）
□ 门槛1b：路径覆盖矩阵已输出（正常/错误/边界三类）
□ 门槛2：DB 写入已验证（有实际数据证据），
或已标注「部署后补做」并计划了具体时间
□ 门槛3：AI 边界场景已测试
□ 门槛4：人工验收清单已获用户明确回复「通过」
（不可将「继续执行」「按规范执行」解读为门槛4确认）
输出确认文本：
「关卡C 4条门槛逐条确认：门槛1[✅/❌] 门槛1b[✅/❌] 门槛2[✅/❌] 门槛3[✅/❌] 门槛4[✅/❌]
全部 ✅ → 进入 DevOps」
Step 6.6 【写入关卡C完成凭证（B3.8 检查所依据的状态文档）】
⚠️ 此步骤是 session-bootstrap B3.8 的数据来源。
关卡C测试完成后，test-coverage-state.md 必须无 🔲 条目，
这是 B3.8 判断「关卡C已完成」的唯一依据。
确认 Step 5.5 已将所有测试项更新为 ✅/❌/⏭（无 🔲 残留）：
Read: [项目路径]/测试工程师/test-coverage-state.md
IF 仍有 🔲 条目 → 禁止声明关卡C完成，必须继续执行或明确标注跳过理由
IF 无 🔲 条目 → 关卡C状态文档已就绪，B3.8 核查可通过
输出最终确认：
「✅ 关卡C完成凭证已写入
test-coverage-state.md 状态：[N条 ✅ / M条 ❌ / K条 ⏭]
B3.8 核查将依据此文件。下一步可触发 DevOps 或结束本轮任务。」
| 测试类型 | 验证角度 | 执行者 | 典型问题 |
|---|---|---|---|
| 功能测试 | 每个功能节点是否按产品文档实现 | AI 自动 | 接口返回码、数据写入、路由正确性 |
| 闭环测试 | 整条用户动线是否可以走通 | AI 自动 + 浏览器 | 核心路径端到端，每步确认输出 |
| AI 行为评测 | 智能体层可靠性 | AI 自动 | 回答风格、边界输入、空输入、SSE 流 |
| 体验验收 | 体验是否符合设计意图 | AI 用浏览器完全自动执行；仅「视觉审美/手感流畅度」2类留人工（≤3项） | 按钮存在/文案/空状态/错误提示/流程走通：全部浏览器自动验证+截图留档。人工只判断 AI 无法量化的主观感受 |
| 压力测试 | 系统稳定性 | 可选（本地跳过） | 并发写文件、长时运行；SaaS 产品必测 |
规则（v1.2 修订）：
- AI 拥有浏览器工具（cursor-ide-browser MCP）时，体验验收类测试必须优先用浏览器执行，不得直接跳过输出「人工验收清单」
- AI 用浏览器可验证的项目：界面元素是否存在、交互流程是否走通、错误状态是否显示、文案是否正确
- 仅以下类型保留人工判断：① 视觉审美（颜色/排版好不好看）② 交互感受（顺不顺手/有没有卡顿）
- 人工验收清单应最小化：只包含 AI 浏览器无法判断的主观感受类，不得把可自动化的项目放入清单
规则（v1.3 新增）：人工验收清单只能包含「本 Phase 已实现」的功能
❌ 禁止把「未来 Phase 才会实现」的功能放入人工验收清单，即使包装为「可待 X 实现后验证」
判断标准：
- 该功能的代码/配置已经写入本次提交 → 可以放入人工清单（等真实环境确认）
- 该功能还没有代码存在（属于下个迭代计划）→ 不得放入人工清单，应标注为「Phase N 待实现」
根因：把未实现功能放入人工清单会混淆「已完成」和「未完成」的边界，误导关卡C通过判断（2026-03-21 实战踩坑）
不满足以下任意一条，不允许标 ✅，不允许进 DevOps。
□ 门槛1：核心用户路径端到端至少走通1条完整路径
（从用户第一步输入到最终输出，每步有 API 调用证据）
⚠️ 对话/AI功能特别要求：若功能包含「用户发消息→AI响应」路径，
必须实际发送至少1条消息并等到 AI 真实回复（不能只验证界面存在或输入框可用）
「界面正常+输入框可见」≠「对话功能通过」
□ 门槛1b（F-021全量搜索）：产品定义中所有「反馈分支路径」均有测试覆盖
不只测正常路径（happy path），必须覆盖主要错误路径、边界路径
输出「路径覆盖矩阵」：
| 路径类型 | 描述 | 已测试 | 结果 |
| 正常路径 | [主流程] | ✅/❌ | 通过/Bug |
| 错误路径 | [输入错误/权限不足] | ✅/❌ | 通过/Bug |
| 边界路径 | [空状态/极限输入] | ✅/❌ | 通过/Bug |
若某路径无法在本次测试中覆盖，必须说明原因并标注「跳过」
□ 门槛2：所有文件写入/DB 写入操作有真实写入验证
（不是"代码里有写入逻辑"，而是"实际调用后文件/DB 里有数据"）
□ 门槛3：至少1个 AI 行为边界场景测试
（空输入 / 异常输入 / 越权操作 / 意图外输入，至少测其中一个）
□ 门槛4：人工验收清单已列出，用户明确确认「通过」
（体验类项目不能由 AI 自行判断通过）
⚠️ 门槛4 关键执行规则（防止最常见违规）：
- 用户说「继续执行」「按规范执行」「没问题」≠ 门槛4通过
- 门槛4 要求用户针对人工验收清单的每项，明确回复「通过」或具体反馈
- AI 必须等待用户对清单的明确回复，才能进 DevOps
- 门槛4 和 DevOps 是严格顺序依赖：人工确认 → DevOps，不可并行
□ 门槛1特例（本地无DB/生产环境未部署时）：
- 若本地无数据库导致端到端无法执行，必须在人工验收清单中明确标注：
「门槛1/2 待部署后在生产环境验收，DevOps 后需补做 API 全量测试」
- 部署到生产后，必须立即在生产环境执行完整的 API 测试，不能以「代码看起来正确」代替
- 发现 Bug → 修复 → 重新部署 → 重新测试（不允许跳过回归）
核心规定：所有验收标准应默认设计为「可 API 自测」，不依赖人工观察。
定义：可自测验收 = 自动化测试脚本（如 scripts/integration_test.py）能在固定时限内跑完并输出 PASS/FAIL，退出码非0=有失败。
| Layer | 依赖 | 测试范围 | 时限 |
|---|---|---|---|
| Layer 0（无LLM） | 直接调 Python 函数 | 纯逻辑、数据处理 | <10s |
| Layer 1（有LLM） | HTTP + SSE + logs 断言 | 完整链路（Agent调用→工具→返回） | <120s |
✅ 只验关键节点存在
示例：`read_skill` tool_call 在 logs 中存在，不验完整文本或顺序
✅ Layer 1 用例隔离
- 测试前后 DELETE /logs
- 使用带时间戳的 session_id（防测试间干扰）
❌ 禁止：验证 LLM 输出的完整文字内容（非确定性，导致测试脆弱）
❌ 禁止：验证工具调用的具体顺序（LLM 可能选择不同但等效的执行路径）
□ 每次新增能力，对应验收用例同步写入 integration_test.py（不延后）
□ 验收通过 = integration_test 自动 PASS，不是「我测了，感觉对」
□ 「需要用户实测才能验证」写进开发计划 → 必须转化为可自测用例，否则是技术债
完整执行流程。
步骤1 打开产品定义.md，找到对应功能的描述章节
步骤2 列出该章节中所有"用户可感知行为"（至少5条）
示例（双模式功能）：
□ 访问 ?mode=proxy 看到 Proxy 单栏界面和 Banner
□ Proxy 模式输入问题，收到基于认知文档的回答（不触发工作流）
□ Proxy 对话结束后，Owner 模式收件箱出现该条记录
□ 点击「→ 整合到认知库」，输入框填入「【来自访客】…」
□ 点击「分享分身」弹出包含 ?mode=proxy URL 的 popover
步骤3 对每条行为，验证实现
→ 找不到实现 → 标"未实现" → Bug 报告
→ 有代码但未接通执行路径 → 标"架构就绪但未完成" → Bug 报告
→ 实现了但与 PRD 不符 → 标"产品偏差" → 产品偏差报告（回PM）
→ 有意简化 → 标"🔧简化" → 记录差距
步骤4 对所有文件/DB 写入操作，执行一次真实测试
→ 实际调用 API，查询文件/DB 确认数据写入
→ 必须有截图或 API 响应作为证据
步骤5 走完全量用户路径（F-021全量搜索原则）
→ 主干路径（正常完成）：测试完整端到端
→ 错误路径（各类错误输入/权限不足/异常状态）：至少覆盖全部错误类型
→ 边界路径（空状态/极限值/并发等）：至少覆盖关键边界
→ 输出路径覆盖矩阵（格式见门槛1b），说明已覆盖和跳过的路径
→ 每步记录 API 请求和响应摘要
步骤6 输出「人工验收清单」给用户
→ 列出所有需要打开浏览器才能验证的体验项
→ 等待用户确认，不得跳过
步骤7 全部通过（含用户确认人工验收项）→ 可以进 DevOps
有任何未通过 → 不能进 DevOps，分类回报
见：.cursor/skills/role-测试工程师/templates/Bug报告模板.md
标准格式：
### BUG-YYYYMMDD-NN: [简短描述]
**严重程度**：P0（阻塞核心路径）/ P1（功能错误）/ P2（体验问题）
**发现于**：[功能模块]
**现象**：[用户看到了什么]
**复现步骤**：
1. [步骤1]
2. [步骤2]
3. [结果]
**期望结果**：[根据产品文档，应该发生什么]
**根因分类**：代码/逻辑错误（→ 开发修复）/ 与PRD不符（→ PM决策）
**回归要求**：修复后需验证 [具体验证点]
### DEVIATION-YYYYMMDD-NN: [简短描述]
**发现于**：[功能模块]
**产品文档要求**：[PRD 中的具体描述]
**实际实现**：[当前代码/功能的实际行为]
**差距描述**：[设计了X，实现了Y，差距是Z]
**PM 决策选项**：
- 选项A：修改实现，使其符合 PRD（影响：开发工作量 _）
- 选项B：修改 PRD，接受当前实现（影响：产品功能调整）
AI 完成自动测试后，必须用此格式向用户输出需要人工确认的项目。
## 🙋 需要你人工验收的项目
以下内容 AI 无法自动测试，需要你打开浏览器确认：
| # | 验收项 | 操作步骤 | 期望结果 |
|---|---|---|---|
| 1 | Proxy Banner 显示 | 访问 /?mode=proxy | 顶部有蓝色 Banner 显示主人名 |
| 2 | 分享分身 popover | 点击顶栏「分享分身」 | 弹出含 ?mode=proxy URL 的 popover |
| 3 | 收件箱空状态 | 无访客记录时进入收件箱 | 显示「暂无访客问题」和链接提示 |
请逐项确认，并回复「通过」或指出问题。
在你确认之前，本功能不标 ✅。
| 场景 | 步骤 | 期望结果 |
|---|---|---|
| 正常注册 | 填入手机号→发送验证码→填入验证码→填入密码→注册 | 注册成功，自动登录，跳转首页 |
| 验证码错误 | 填入错误验证码→注册 | 提示"验证码错误" |
| 手机号已注册 | 填入已注册手机号→注册 | 提示"该手机号已注册" |
| 正常登录 | 填入手机+密码→登录 | 登录成功，跳转首页 |
| 密码错误 | 填入错误密码→登录 | 提示"密码错误" |
| Token 过期 | 等待 Token 过期→访问受保护路由 | 跳转登录页，不显示未授权错误 |
| API Key 登录 | 用 oak_ 前缀 Key 调用 API | 成功，行为与 JWT 登录一致 |
| 场景 | 验证点 | 执行者 |
|---|---|---|
| 正常对话 | AI 返回有意义的回复（非空，非乱码） | AI 自动 |
| 长对话 | 第 N 轮对话后，AI 仍记得用户之前说的信息 | AI 自动 |
| 边缘输入（空消息） | 系统优雅处理，不崩溃 | AI 自动 |
| 边缘输入（超长消息） | 系统处理，或友好提示字数限制 | AI 自动 |
| SSE 流式输出 | 客户端实时收到数据，不是等全部完成再显示 | AI 自动 |
| SSE 中断 | 服务端错误时，客户端收到错误事件，不是永远转圈 | AI 自动 |
| 回答风格（Proxy 模式） | 含第三人称，不以「我认为」开头 | AI 自动 |
| 质疑/反馈输入 | 先承认访客视角，再基于认知结构回应 | 人工验收 |
□ 任何文件/DB 写入函数写完后 → 实际调用，查询确认写入（必须有文件存在或DB记录证据）
□ 任何 SSE 端点 → curl 或 requests 发真实请求，确认流式输出
□ 任何新增路由 → curl 调用，确认状态码和内容
□ 登录/认证修改后 → 走完注册→登录→受保护路由完整流程
□ 核心路径任何修改后 → 走完完整核心用户路径
□ 任何影响界面的修改 → 必须列入人工验收清单
执行关卡C 时，生产环境状态验证使用以下接口，无需 SSH：
import httpx
def ask_server(message: str) -> str:
r = httpx.post(
"https://openclaw.tashan.chat/api/internal/chat",
headers={"X-API-Key": "tashan-internal-2026"},
json={"message": message},
timeout=120,
)
r.raise_for_status()
return r.json()["reply"]
# 验收常用指令
ask_server("检查所有容器健康状态")
ask_server("查看 [项目名]-backend 最新日志，是否有错误")
ask_server("访问 https://[域名]/api/health 并返回响应")
→ 详见 _内部总控/开发规范/AI调用服务器助手接口规范.md
我接收：
我输出（三个方向，严格区分）：
技术架构师/技术问题追踪台.md产品经理/产品问题追踪台.md关键规则：
根因：在双模式+访客收件箱功能开发中，AI 在写完代码后只跑了 8 个接口测试便自称「关卡C完成」，实际上漏掉了端到端闭环测试、体验验收、边界场景测试，根本没有向用户输出人工验收清单。这是三个结构性缺陷造成的：触发机制失效（AI 自测场景）、通过标准不可量化、未区分 AI/人工测试。
修改内容：
验证结果：
已知风险：人工验收清单的「等待用户确认」会在自动化任务中造成阻塞，需要用户有意识地回复。如果用户没有回复，AI 不应自行判断通过。
Step 1 Read: 产品经理/产品定义.md → 这是唯一验收标准
Step 2 Read: 产品经理/开发计划.md → 了解本次提交覆盖的功能范围
Step 3 执行五类测试（见下方）
Step 4 分类输出结果：Bug → 开发；产品偏差 → PM；通过 → DevOps
| 测试类型 | 验证角度 | 典型问题 |
|---|---|---|
| 功能测试 | 产品使用完整性 | 每个功能节点是否按产品文档实现 |
| 闭环测试 | 主干动线完整性 | 整条用户动线是否可以走通 |
| AI 行为评测 | 智能体层可靠性 | 接口是否完备、输出是否稳定、幻觉率 |
| 体验验收 | 人层感知质量 | 体验是否符合设计意图（非代码问题）；两产品前端统一任务：必须逐页截图对比，不能只验功能 |
| 压力测试 | 系统稳定性 | 高并发、大数据量、长时间运行 |
这是测试工程师执行关卡C的完整流程。
步骤1 打开产品定义.md，找到对应功能的描述章节
步骤2 列出该章节中所有"用户可感知行为"（至少5条）
示例（账号系统）：
□ 用户可以用手机号发送验证码（收到真实短信）
□ 验证码输入框始终显示（发送前也显示）
□ 注册成功后自动登录，跳转到首页
□ 错误情况有明确的用户可读提示
□ dev_code 在响应含有时展示 15 秒
步骤3 对每条行为，验证实现
→ 找不到实现 → 标"未实现" → Bug 报告
→ 有代码但未接通执行路径 → 标"架构就绪但未完成" → Bug 报告
→ 实现了但与 PRD 不符 → 标"产品偏差" → 产品偏差报告（回PM）
→ 有意简化 → 标"🔧简化" → 记录差距
步骤4 对所有数据库写入操作，执行一次真实测试
→ 实际调用 API，在 DB 中查询确认数据写入
步骤5 走完整个核心用户路径（端到端）
→ 核心路径 = 产品定义中定义的最短完整路径
→ 每步确认输出符合产品文档的描述
步骤6 全部通过 → 可以进 DevOps
有任何未通过 → 不能进 DevOps，分类回报
见：.cursor/skills/role-测试工程师/templates/Bug报告模板.md
标准格式：
### BUG-YYYYMMDD-NN: [简短描述]
**严重程度**：P0（阻塞核心路径）/ P1（功能错误）/ P2（体验问题）
**发现于**：[功能模块]
**现象**：[用户看到了什么]
**复现步骤**：
1. [步骤1]
2. [步骤2]
3. [结果]
**期望结果**：[根据产品文档，应该发生什么]
**根因分类**：代码/逻辑错误（→ 开发修复）/ 与PRD不符（→ PM决策）
**回归要求**：修复后需验证 [具体验证点]
### DEVIATION-YYYYMMDD-NN: [简短描述]
**发现于**：[功能模块]
**产品文档要求**：[PRD 中的具体描述]
**实际实现**：[当前代码/功能的实际行为]
**差距描述**：[设计了X，实现了Y，差距是Z]
**PM 决策选项**：
- 选项A：修改实现，使其符合 PRD（影响：开发工作量 _）
- 选项B：修改 PRD，接受当前实现（影响：产品功能调整）
| 场景 | 步骤 | 期望结果 |
|---|---|---|
| 正常注册 | 填入手机号→发送验证码→填入验证码→填入密码→注册 | 注册成功，自动登录，跳转首页 |
| 验证码错误 | 填入错误验证码→注册 | 提示"验证码错误" |
| 手机号已注册 | 填入已注册手机号→注册 | 提示"该手机号已注册" |
| 正常登录 | 填入手机+密码→登录 | 登录成功，跳转首页 |
| 密码错误 | 填入错误密码→登录 | 提示"密码错误" |
| Token 过期 | 等待 Token 过期→访问受保护路由 | 跳转登录页，不显示未授权错误 |
| API Key 登录 | 用 oak_ 前缀 Key 调用 API | 成功，行为与 JWT 登录一致 |
| 场景 | 验证点 |
|---|---|
| 正常对话 | AI 返回有意义的回复（非空，非乱码） |
| 长对话 | 第 N 轮对话后，AI 仍记得用户之前说的信息 |
| 边缘输入（空消息） | 系统优雅处理，不崩溃 |
| 边缘输入（超长消息） | 系统处理，或友好提示字数限制 |
| SSE 流式输出 | 客户端实时收到数据，不是等全部完成再显示 |
| SSE 中断 | 服务端错误时，客户端收到错误事件，不是永远转圈 |
□ 任何 DB 写入函数写完后 → 实际调用，查询数据库确认写入
□ 任何 SSE 端点 → curl 或 httpx 发真实请求，确认流式输出
□ 任何新增路由 → curl 调用，确认状态码和内容
□ 登录/认证修改后 → 走完注册→登录→受保护路由完整流程
□ 核心路径任何修改后 → 走完完整核心用户路径
我接收：
我输出（三个方向，严格区分）：
关键规则：
根因：测试工程师发现 Bug 和产品偏差后，报告只在对话中输出，开发和 PM 重新激活时看不到这些未解决问题。
修改内容：
验证结果：
本节由 uto-experience-hook Rule 驱动，此处为提示性说明。
执行本 Skill 过程中，若触发以下任一信号，立即追加一行到暂存区（不中断主任务）：
暂存格式（追加到 .cursor/skills/skill-index/PENDING-EXPERIENCES.md）：
| [今日日期] | [本Skill目录名] | [信号类型] | [一句话描述经验内容] | 🔲 待处理 |
所有执行步骤完成后，检查暂存区是否有新增条目。若有，在收尾时告知用户： 「本次执行感知到 N 条经验（已暂存），任务确认跑通后可说「做一次项目复盘」处理。」
⚠️ 强制收尾——写入任务日志（不可省略，不可等用户提示）：
执行顺序铁律：先工具调用 → 确认成功 → 告知用户。禁止声称「已写入」而未实际调用工具。
1. [工具调用-读取] grep 今日 TASK-YYYYMMDD 全部条目，取最大序号 NN → 新序号 = NN+1
2. [工具调用-写入] StrReplace 追加到 `_内部总控/任务日志.md`：
本次 Skill 执行的核心操作 + 创建/修改的文件 + 用户原始需求 + 遗留事项
3. 工具调用成功 → 输出「📝 任务日志已写入 [TASK-YYYYMMDD-NN]」
工具调用报错 → 输出「⚠️ 任务日志写入失败，请手动检查任务日志.md」
当任务是「两个产品前端统一」时，体验验收不能只验功能是否可用，必须执行截图逐页对比。
强制执行条件：任务描述含「前端统一」「UI 对齐」「样式一致」「合并前端」等关键词。
截图对比清单（5项缺一不可）：
□ ①标题/标签文本一致 — 所有页面的标题、按钮文字、标签文案完全相同
□ ②整体布局结构一致 — 页面区块排列、层级结构、导航位置视觉一致
□ ③CSS 样式一致 — 输入框、按钮、间距、圆角、颜色等样式属性一致
□ ④默认值一致 — 输入框预填充值、选择器默认选项、开关默认状态一致
□ ⑤容器/外层组件一致 — 包裹页面的上层容器（Layout/Page 组件）使用同一版本
执行方式：用 cursor-ide-browser 对两个产品的同名页面各截图一张，并排对比逐项确认。
失败处理：任一项不一致 → 标记为 P2 体验 Bug，回开发修复，修复后重新截图对比验证。
根因：测试工程师（关卡C）在单 Agent 全流程中存在「开发者视角自我验收」的结构性缺陷，即使已有「强制视角切换」规则，仍然共享开发上下文。verifier 子智能体从干净上下文启动，从根本上解决上下文污染问题。
修改内容：
验证结果：
验证状态：✅ 已验证（2026-03-21 tashan-workbench Phase E 关卡C：verifier独立发现4个开发者遗漏Bug，关卡C 4条门槛全部通过）
根因：AGENT_RULES.md 新增 RULE-25。关卡C 生产环境验收时，需要查容器状态、日志、接口可达性，原流程无对应工具指引，测试工程师只能通过 SSH 或跳过验证。
经验核心：生产环境验收应优先使用服务器 AI 接口（https://openclaw.tashan.chat/api/internal/chat），无需 SSH 权限，从容器状态到接口可达性均可通过 ask_server() 查询。
修改内容：
ask_server() 示例代码及三条常用验收指令验证结果：
验证状态：🔵 待验证
根因：真实事件——Phase 2（认证系统/登录/注册/Owner模式）完整部署上线，但关卡C没有用浏览器走通登录UI主干闭环。发现根本原因：「体验验收 → 必须人工」这条规则给了AI合理逃跑理由，直接输出「人工验收清单」而不使用手头的 cursor-ide-browser MCP 工具做验证。AI能做的测试没有做，直接推给用户。
经验核心：「体验类测试必须人工」这个假设在 AI 没有浏览器工具时成立。一旦 AI 拥有浏览器工具，大部分体验类测试（界面元素存在/流程走通/错误提示正确/文案正确）应由 AI 自动执行，只有「视觉审美好不好看」「交互手感顺不顺」这类无法客观验证的主观感受才需要人工。
修改内容：
验证结果：
验证状态：✅ 已验证（2026-03-19 Phase 2 关卡C：浏览器测试发现 React P0 Bug，体验类测试 AI 用浏览器执行规范有效，人工验收清单缩短至3项主观感受类）
根因：OpenBrain v2.0 部署时，本地没有 PostgreSQL，AI 未做端到端测试就声称「关卡C通过」并触发 DevOps。P0 Bug（u.display_name 列不存在，所有平台 API 返回 500）在生产才被发现。根本原因是关卡C入口没有对「本地测试环境是否就绪」做前置阻断。
修改内容：
验证结果：
验证状态：🔵 待验证
根因：关卡C 在生产环境验收时，AI 遇到「无法登录」就停下来，或直接跳到 DevOps，而不是主动向用户请求测试凭据。用户指出测试账号本应是标准工具，应在规范中明确。
修改内容：
同步修改：DEPLOY_ARCH.md 新增「生产测试账号」章节，说明账号来源和关卡C使用说明。
验证结果：
验证状态：✅ 已验证（2026-03-20）
根因：OpenBrain v2.0 部署时，关卡C 执行到一半就触发了 DevOps。发生原因：
① 用户说「继续执行」被误解为门槛4「人工验收已确认」；
② 没有强制的 DevOps 前逐条核查清单；
③ 本地无 DB 时声称「跳过」而非「标注待补做」。
结果：P0 Bug（u.display_name 列不存在）进入了生产，在生产环境 API 测试中才发现。
修改内容：
验证结果：
验证状态：✅ 已验证（2026-03-20）
根因：F-021原则写入认知体系，关卡C步骤5仅要求测试「最短完整路径」，忽略错误路径、边界路径，测试覆盖不完整，与「全量搜索」原则矛盾。
修改内容：
验证结果：
验证状态：🔵 待验证
根因：画像系统两产品前端统一任务中，关卡C 体验验收只确认了「功能可用」而未做截图对比，导致上层容器组件（ProfileHelperPage.tsx）样式不同（tashan-world 旧版 vs TopicLab 新版）被漏过，验收后仍存在视觉不一致问题。
经验核心：「两产品前端统一」是特殊任务类型，体验验收必须升级为「截图逐页对比」——5项缺一不可：①标题/文本 ②布局结构 ③CSS样式 ④默认值 ⑤容器/外层组件。
修改内容：
验证结果：
验证状态：🔵 待验证
根因：2026-03-22 实测发现，verifier 子智能体有概率幻觉，引用不存在的文件路径或错误描述代码内容，导致「文件不存在」「函数未实现」类误报。主 Agent 若直接信任这类否定性结论并生成 Bug 报告，会产生虚假 Bug，浪费开发资源并降低测试工程师可信度。
经验核心：verifier 的正向判断（「存在/正确/通过」）置信度较高；否定性判断（「不存在/缺失/未实现」）必须用 Read 工具交叉验证后再采纳。
修改内容：
验证结果：
验证状态：🔵 待验证
备份路径：.cursor/skills/role-测试工程师/history/SKILL_v1.9_20260322.md
验证事件：tashan-workbench Phase E brain_ask 关卡C。
验证结果：
验证状态升级：Step 4（verifier 子智能体）🔵 → ✅
根因：tashan-openbrain_myagent Phase 5（TASK-20260322-104/105）实战发现：当验收标准设计为「需要用户实测」时，形成「感觉对」= 通过的主观判断闭环，无法在 CI 中复现，本质上是技术债起点。触发条件：integration_test.py 已能自动跑完链路测试，但对应验收用例未同步写入，验收仍依赖人工观察。
经验核心：可自测验收（Layer 0 纯逻辑 <10s / Layer 1 HTTP+SSE+logs <120s）+ 断言设计原则（只验关键节点存在，不验完整文本或顺序；Layer 1 用例隔离）= 让关卡C可机器复现，不依赖人工状态。
修改内容：
验证结果：
验证状态：🔵 待验证
备份路径：.cursor/skills/role-测试工程师/history/SKILL_v1.11_20260323_before_selftestable.md
根因：上一轮系统分析（TASK-20260324-64）发现：Gate C（测试工程师）激活后没有前置检查「上游沙盘/关卡A/B/测试规格文档是否存在」，导致开发流程可以在没有执行产品沙盘、技术沙盘、通过关卡A/B的情况下直接进入关卡C。这意味着验收标准（产品定义）可能没经过独立审核，技术架构可能没经过压力测试，测试规格文档可能不存在。
影响范围：仅 role-测试工程师/SKILL.md，加入一个前置检查步骤，不影响其他 Step 的逻辑。
修改内容：
验证方法：
验证状态：🔵 待验证（下次触发关卡C时验证）
备份路径：history/SKILL_v1.12_20260324_before_sandbox-precheck.md
根因：tashan-openbrain_v2 部署实战中，「上传失败」bug 花了多轮才定位，根因是两个系统性测试遗漏：① 测试只用小样本（<100KB），没用真实大文件；② 长时 SSE 测试（>2min）通过 internet tunnel 调用，被网络超时误判为失败，实际后端在正常运行。
经验核心：
修改内容：
验证状态：🟢 已验证（2026-03-23 费曼 1.5MB 上传测试实战）
适用于：文件上传接口、批量处理、SSE 流式接口、AI agent 任务
| 错误做法 | 正确做法 |
|---|---|
构造 io.BytesIO(b"# test") 小样本 | 使用实际业务文件（如 npc-content/02-richard-feynman/sources/ 全量 16 个文件） |
| 单文件测试 | 多文件并发测试（模拟用户一次选 10+ 个文件的场景） |
| 只测 HTTP 200 | 验证 count、confidence_score、files 字段值 |
必须覆盖的测试边界：
背景：AI 认知构建（build-cognition）等任务耗时可达 3-10 分钟。通过 internet（SSH tunnel + nginx proxy）调用时：
proxy_read_timeout 默认 60s（即使配置了 600s 也受网络层影响）正确测试模式：
# 在 Windows 服务器本地用 PowerShell 调用（直接访问 localhost:8100）
$resp = Invoke-WebRequest -Uri "http://localhost:8100/twin/build-cognition" `
-Method POST -Body $body -ContentType "application/json" `
-Headers $hdrs -TimeoutSec 600 -UseBasicParsing
# 在 Linux 服务器本地测试（通过 SSH 在服务器上运行脚本）
r = requests.post("http://localhost:8100/twin/build-cognition", timeout=600)
验证完成标准：收到 {"type":"done","layers":{...}} SSE 事件，AND doc-registry 文档数增加。
根因（来自对话 53b74d66 的事后分析）：
测试智能体在 753 条消息的对话里，把「执行了 run_tests.py（36个测试）」等价于「完成了主测试文档要求的所有测试（62个）」。当用户质疑时，AI 才承认漏了 Layer 3 AI质量评测、E2E完整链路、幂等性、Soak Test 等。
本质：测试完成没有门禁——没有任何机制强制 AI 在声明「完成」前验证「文档要求的每条测试是否都有明确状态」。
修改内容：
设计原理：与 Step 6.5 DevOps门禁的设计保持一致——门禁是明确的阻断，不是「建议」。
验证方法：
备份路径：history/SKILL_v1.17_20260325_before_coverage_guard.md
根因：Agent 拥有完整浏览器权限（browser_navigate/click/snapshot/screenshot），原「人工验收清单」中大量项目实际上可以被浏览器自动验证。「视觉审美」「手感流畅度」是真正无法量化的2类，其余全部应自动化。
修改内容：
验证状态：🔵 待验证
根因：role-测试工程师 测试完成后只输出 Bug 报告到对话，但 bug-fix-loop-coordinator 需要通过文档（追踪台 + 轮次追踪表）获取测试状态。没有 Step 6.3，测试结果无法被协调者感知，全自动修复循环无法启动。
修改内容：
验证方法：
验证状态：🔵 待验证
备份路径：history/SKILL_v1.14_20260324_before_sandbox-precheck.md（同批）
根因：变更管理与沙盘推演规范 §4.3 定义了含「来源字段」的测试规格文档格式，但 role-测试工程师 没有「创建测试规格文档」的执行模式，导致沙盘报告和测试规格之间的继承链路不存在——即使沙盘发现了 Critical 漏洞，也不会自动进入测试用例。
修改内容：
验证方法：
备份路径：history/SKILL_v1.12_20260324_before_sandbox-precheck.md（v1.13/v1.14 改动均在同一批次备份中）
验证状态：🔵 待验证