SKILL.md 全文

Frontmatter

name	t4-test-execution-analyzer
description	|
version	2.0.21
trust_tier_default	T1
trust_tier_critical_domain	T2
cost_cap_usd	5.0
duration_cap_min	60
audit_log	true
upstream
downstream	发布上线（流程外，人类强制）
shared_resources

⚡ 跨工具适配

兼容 Kiro / Cursor / Qoder / Trae / Claude Code。Kiro 通过 .kiro/steering/ 加载；其他工具粘贴正文或 @ 引用。

T4 · 功能测试结果智能分析器

好的 Skill = 定场景 + 立目标 + 理规则 + 给示例 + 划边界

📐 架构约定（省 token 的关键）

本 Skill 采用 **规则层（本文档）+ 渲染层（scripts/*.py）** 分离：

• 本 SKILL.md 只承载规则与数据契约，不含任何 HTML / CSS / JS / 渲染 Python 代码。
• 所有报告的 HTML 结构、CSS 样式、JS 交互（画廊/录屏/API 弹窗/全程录屏/可编辑状态列）、以及 base64 内联预处理逻辑，全部实现在 scripts 模板里，AI 不得复述或重写：
• scripts/uat_report_template_html.py — API/UI 功能报告引擎（NOAH_CSS + gallery_js + lightbox_html + MAIN 预处理）
• scripts/perf_report_template_html.py — 性能报告引擎（9 章）
• scripts/manifest_to_testdata.py — 执行清单适配器（把 T3 产出的 t4_manifest.json 映射为 TEST_DATA，Mode C 快通道用）
• AI 唯一需要做的是填 TEST_DATA 字典（见附录 F 数据契约），执行 python -X utf8 generate_*.py，然后删除生成脚本。
• 需要看具体实现时，直接读对应 scripts/*.py，不要在本文档里找代码。

---

一、WHEN · 定场景（什么时候用？）

正触发（✓ 调用本 Skill）

| # | 场景 | 说明 | |---|---|---| | 1 | 用户说「跑测试」「测试报告」 | T1/T2/T3 齐备，需要执行测试并出报告 | | 2 | 用户说「UAT 验收」 | 需要生成 UAT 签字材料（HTML） | | 3 | 用户说「测试结果分析」「失败用例分析」 | 已有执行结果，需 AI 初判失败原因 | | 4 | 用户说「跑回归」 | BLOCK 修复后需重跑验证 | | 5 | CI/CD 产出 JUnit XML / pytest JSON | 自动触发结果分析 | | 7 | 存在 T3 执行清单 t4_manifest.json | 走 Mode C 快通道，直接消费渲染（免重跑） | | 6 | 用户说「性能测试报告」「压测报告」 | JMeter/JTL 结果 → 性能报告（perf 模板） |

反触发（✗ 不调用本 Skill）

| # | 场景　　　　　　　　　　　　　　| 应转交　　　　　　　| | -----| ---------------------------------| ---------------------| | 1 | 用户要做安全渗透测试　　　　　　| 安全测试 Skill　　　| | 2 | 用户要直接发布上线　　　　　　　| 人工操作（T3 红线） | | 3 | 上游未就绪（T1/T2/T3 任一缺失） | 回退上游 Skill　　　| | 4 | 用户要写测试用例或脚本　　　　　| T1 / T3 Skill　　　 | ---

二、WHAT · 立目标（解决什么问题？）

一句话目标： 获取测试执行结果 → AI 智能分析失败原因 → 输出 UAT 验收报告（HTML）+ 发布建议。

具体成果物

| 产出　　　　　　 | 格式　　　　　　 | 度量标准　　　　　　　　　　　　　　　　　　　| | ------------------| ------------------| -----------------------------------------------| | UAT 测试执行报告 | HTML（诺亚色调） | 章节完整、签字栏可打印　　　　　　　　　　　　| | 失败用例 AI 初判 | JSON　　　　　　 | 每个失败用例有根因假设 + 置信度 + 建议指派人　| | 发布建议　　　　 | YAML　　　　　　 | APPROVE / REQUEST_CHANGES / BLOCK，含判定依据 |

3 大核心能力

| 能力　　　　　　　　　　　| 描述　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　| | ---------------------------| -----------------------------------------------------------------------| | A. 获取测试结果（三模式） | 模式 C：消费 T3 执行清单 t4_manifest.json（快通道，首选，免重跑）；模式 A：接收用户提供的结果；模式 B：本地执行 pytest（运行后刷新清单转模式 C） | | B. 失败用例 AI 初判　　　 | 错误类型 + stack trace + 关联近期 git log + 历史缺陷匹配 + 建议指派人 | | C. UAT 签字材料生成　　　 | HTML 格式报告 + 发布建议判定　　　　　　　　　　　　　　　　　　　　　| ---

三、HOW · 理规则（怎么执行？）

Step -1：读取记忆层（每次执行前必做）

执行 T4 前，必须先读取 memory/execution_lessons.md（如存在），了解历史踩坑记录并规避已知问题。 执行结束后，如遇到新问题（执行失败、环境异常、流程偏差等），必须追加到 memory/execution_lessons.md，格式：

## 问题 #N：简短标题
发生日期： YYYY-MM-DD
项目： 项目名
现象： 用户看到了什么
根因： 为什么会这样
解决方式： 怎么修的
已修复： ✅/❌ 是否已在 SKILL 或模板中修复

Step 0：上游校验（前置门禁）

简化规则：直接检查对应目录是否存在数据文件，不依赖 handoff 对象。

IF T1_测试用例/ 目录为空或不存在 → BLOCK + 提示 T1 未就绪
IF T2_测试数据/ 目录为空或不存在 → WARN（可降级继续，脚本用占位数据）
IF T3_自动化脚本/ 目录为空或不存在 → BLOCK + 提示 T3 未就绪

一致性交叉校验（可选，非阻塞）：T1 用例数 vs T3 脚本数（容差 ±10%）；T2 数据文件覆盖 T1 所需实体；26 强制场景 ⊆ T3 脚本。校验结果呈现给用户确认后 → 进入 Step 0.5。

Step 0.5：T2 数据注入 T3 脚本（数据与脚本会合）

T2（测试数据）和 T3（自动化脚本）并行生成，T4 是两者会合点。执行测试前必须完成数据注入。 1. 定位 T2 数据文件：扫描 T2_测试数据/ 下的 .csv / .sql / .json 2. 定位 T3 脚本数据目录：扫描 T3_自动化脚本/ 下各项目的 data/ 子目录 3. 执行数据注入：将 T2 输出文件复制到 T3 脚本的 data/ 目录，替换占位文件 4. 验证注入完整性：文件非空 ✓ / 不含 PLACEHOLDER ✓ / CSV 行数 > 1 ✓ 5. 配置环境变量：确认 .env 已配置（base_url / token / 账号等） 兜底策略： | 情况 | 处理 | |------|------| | T2 数据文件不存在 | WARN + 脚本使用占位数据运行（部分用例可能 FAIL） | | T3 脚本中无 data/ 目录 | 自动创建 data/ 目录并注入 | | T2 字段与 T3 fixture 列名不匹配 | WARN + 列出不匹配列名供用户确认 | | .env 不存在但 .env.example 存在 | 自动复制 .env.example → .env（WARN + 提示填真实值） | | .env 和 .env.example 均不存在 | BLOCK + 提示手动创建 .env（API_BASE_URL / API_AUTH_TOKEN） |

Step 1：确认执行范围

向用户确认：执行范围（冒烟 5min / 标准 1-2h / 全量含性能 4-6h / 回归夜间全量）、三方对账（是/否）、WARN 处理（继续 / 回退修复）。

Step 2：获取测试结果（三模式自动判定）

IF 存在 T3 执行清单（T3_自动化脚本/*/output/t4_manifest.json 且为本次运行的新鲜产物）
    → 模式 C（快通道：直接消费清单，免重跑、免再解析）★ 首选
ELIF 用户已提供测试结果 → 模式 A（直接分析）
ELIF T3 脚本的 output/ 目录无数据（无 png / manifest 等执行产物） → 模式 B（本地执行 pytest）
ELIF T3 脚本可用 AND 网络连通 AND 依赖已装 → 模式 B（本地执行 pytest）
ELSE → 降级为模式 A + 提示用户手动执行后提供结果

★ 模式 C（快通道 · 强烈推荐，解决 T4 重跑慢/卡住的核心手段）： T3 生成的 API/UI 项目已集成执行清单采集器（conftest_result_collector.py），每次 pytest 运行都会在 output/t4_manifest.json 落盘一份机器可读清单（状态/优先级/TC编号/耗时/错误位置 + API 真实请求响应 + UI 截图录屏路径）。T4 检测到该文件即走快通道： 1. 定位清单：扫描 T3_自动化脚本/*/output/t4_manifest.json（API-AUTO-TEST / UI-AUTO-TEST 各一份）。 2. 新鲜度判断：清单 generated_at 与用户预期一致即用；若用户要求「重新跑」或清单明显过期 → 转模式 B 重跑（重跑同样刷新清单）。 3. 映射 TEST_DATA：用 scripts/manifest_to_testdata.py 的 build_test_data(manifest_path, ENRICHMENT) 把清单映射为 TEST_DATA——AI 不再手搓 test_cases/summary/priority_results/api_request，只提供一小段 ENRICHMENT（封面信息 + 失败用例 AI 初判 + 发布建议）。 4. AI 只做增值部分：对 status==FAIL 的用例做 Step 3 初判（根因假设/置信度/指派人），填进 ENRICHMENT.failed_analysis（按 case_id 索引）；发布建议可留空由适配器按 Step 4 规则自动判定。 5. 进入 Step 5 渲染。

模式 C 下禁止重跑测试（清单已是权威结果）；也禁止再去解析 allure-results / JUnit XML（清单已聚合）。

核心规则： 当用户说「生成 UAT 执行报告」时，先查 t4_manifest.json（模式 C）；无清单且 output/ 为空时才采用模式 B 执行测试。 模式 B 前置条件（任一不满足 → 自动降级模式 A）： T3 脚本在本地 ✓ / T2 数据已注入 ✓ / pip install -r requirements.txt 成功 ✓ / UI 脚本额外 playwright install chromium ✓ / 网络连通测试环境 ✓ / .env 已配置 ✓。运行 pytest 后同样会刷新 output/t4_manifest.json，随后按模式 C 消费清单渲染。 模式 B · UI 自动化执行序列：

pip install -r requirements.txt
playwright install chromium   # 仅 UI 自动化脚本需要（检测到 playwright / browser fixture 时）
pytest tests/ -v

录屏保存规则（T3 conftest 层 · Windows 兼容）： T3 UI 脚本 conftest 保存录屏必须用 video.save_as(dest)，禁止 video.path() + shutil.move()（Windows 下 page.close() 后 Chromium 仍持文件锁，move 失败）。约束：save_as() 必须在 page.close() 之后调用，video 引用必须在 close 之前获取；context fixture 只配置 record_video_dir。具体 conftest 代码属 T3 职责，不在本文档展开。

Step 3：失败用例 AI 初判（5 步分析法）

对每个失败用例： 1. 错误类型识别：AssertionError / TimeoutError / ConnectionError / ... 2. stack trace 解析：定位失败代码 文件:行号 3. 关联近期变更：查最近 7 天 git log，匹配涉及的方法/类 4. 历史缺陷匹配：有缺陷库 → 搜索；无缺陷库 → 搜 git history 中 fix/bugfix commit 5. 建议优先级 + 指派人：CRITICAL / HIGH / MEDIUM / LOW + 最近修改该文件的开发者 约束： 置信度 ≥ 0.5 → 输出根因假设；< 0.5 → 仅列原始错误，不输出假设。

Step 4：发布建议判定

| 条件 | 判定 | |---|---| | P0 通过率 = 100% 且无 CRITICAL 失败 | APPROVE | | P0 = 100% 但 P1/P2 有失败 | REQUEST_CHANGES | | 任一 P0 用例失败 | BLOCK | | 任一失败用例优先级 = CRITICAL | BLOCK | | 性能不达标但功能 OK | REQUEST_CHANGES（PM 决策） | | 全部通过但 AI 初判置信度 < 0.5 | APPROVE + 附注建议人工 review |

Step 5：生成报告（HTML · 全部走 scripts 模板）

1. 确定输出路径：按附录 C.2 规则判定（用户指定路径 > 分目录默认路径） 2. 定位模板文件（⚠️ P0 强制路径规则）：

• 模板位于 Skill 安装目录 ~/.kiro/skills/t4-test-execution-analyzer/scripts/
• Windows 展开：C:\Users\{username}\.kiro\skills\t4-test-execution-analyzer\scripts\
• ❌ 禁止用工作区文件搜索（file_search / grep_search）查找模板 — 模板不在工作区内
• ✅ 必须通过绝对路径（HOME + .kiro/skills/t4-test-execution-analyzer/scripts/）直接读取并复制
• 模板不存在 → BLOCK + 提示「T4 Skill 模板未找到，请检查 Skill 安装」

3. 复制模板到输出目录：

• API/UI 功能报告 → uat_report_template_html.py → {输出目录}/generate_uat_{project}.py
• 性能测试报告 → perf_report_template_html.py → {输出目录}/generate_perf_{project}.py
• 模式 C 额外复制 manifest_to_testdata.py 到同一输出目录（供 generate 脚本 import）

4. 填入 TEST_DATA 字典（附录 F 数据契约）— 唯一允许修改的部分

• 模式 C（推荐）：不手搓 test_cases。在 generate 脚本里改为

from manifest_to_testdata import build_test_data + TEST_DATA = build_test_data(r"…/output/t4_manifest.json", ENRICHMENT)， ENRICHMENT 只含封面信息 + failed_analysis（按 case_id 的 AI 初判）+ 可选发布建议。

• 模式 A/B：按契约手工填 TEST_DATA。

5. 执行 python -X utf8 generate_*.py → 生成 HTML + JSON + YAML（终端在 IDE 内置 Terminal 或系统终端运行） 6. 删除生成脚本，保留输出文件 多层级报告： 项目含 API + UI + PERF 时，每层级独立执行一次模板流程；API/UI 用 uat_report_template_html.py，PERF 用 perf_report_template_html.py；每层级 TEST_DATA 仅含该层级用例；各自输出到子目录（API_Report / UI_Report / PERF_Report），互相独立。 ⚠️ 强制约束：

• ❌ 禁止自行编写 HTML 渲染逻辑，必须用对应模板
• ❌ 禁止重写或替代模板的 CSS / JS / RENDERING ENGINE / MAIN 预处理
• ✅ 唯一允许修改的是 TEST_DATA 字典（标记 # FILL 的部分）
• ✅ 遇编码问题用 python -X utf8 参数，不得绕路重写

模板选择： | 报告类型 | 模板文件 | 章节结构 | |---------|---------|---------| | API 功能测试 | scripts/uat_report_template_html.py | 6 章（执行总览→优先级→场景验证→AI初判→发布建议→签字栏） | | UI 功能测试 | scripts/uat_report_template_html.py | 同上 | | 性能压测 | scripts/perf_report_template_html.py | 9 章（总览→信息→场景→错误→基线→有效请求→结论→建议→清单） |

Step 6：重跑（仅当 BLOCK 后修复重跑时）

重跑范围：失败用例 + P0 全量回归；报告编号递增 TR-{project}-{date}-R1；前次 BLOCK 记录保留在 final_report.yaml 的 history 字段。 ---

四、REFERENCE · 给示例

正例 ✓：模式 A 结果分析

用户输入： 「测试结果分析：总用例 25 / 通过 23 / 失败 2（TC-09 会员等级判定 AssertionError，TC-12 费率计算 TimeoutError）」 AI 输出要点： 执行总览 92% 通过率；TC-09 根因假设「等级判定 v2.1 重构后未处理 VIP 续费」置信度 0.85 关联 commit abc123（张三）优先级 HIGH；TC-12「费率服务超时，疑与索引变更相关」置信度 0.62；发布建议 BLOCK（P0 用例 TC-09 失败）。

正例 ✓：模式 B 本地执行

「跑回归，T3 脚本在 tests/ 目录」→ 校验上游 → 确认范围 → pip install → playwright install chromium（检测到 UI）→ pytest tests/ -v → 解析结果 → AI 初判 → 生成 UAT 报告 HTML。

反例 ✗

• 「跑测试报告」但 T2 未就绪 → ❌ 无法启动 T4：T2 测试数据未就绪。请先完成 T2。
• 「帮我做安全渗透测试」→ ⚠️ 不在 T4 范围。T4 处理功能/API/性能测试结果分析与报告。建议联系安全团队。

---

五、LIMITS · 划边界

不支持的能力

| # | 不做什么 | 原因 | |---|---|---| | 1 | 不做安全渗透测试 | 需专业安全工具和人员 | | 2 | 不直接发布上线 | T3 红线，AI 绝不允许 | | 3 | 不替代 UAT 签字 | 业务方必须人工签字 | | 4 | 不接触 prod 环境 | T4 只操作测试环境 | | 5 | 不在上游未就绪时强行执行 | 必须 T1/T2/T3 齐备 |

禁止行为

• ❌ 置信度 < 0.5 时不输出根因假设（仅列原始错误）
• ❌ 不伪造测试结果 / 不跳过上游校验 / 不暴露敏感数据（脱敏审计字段、Auth Token 等）

异常处理 · 兜底策略

| 触发条件 | 兜底动作 | |---|---| | 模式 B 网络不通 / 依赖安装失败 / Token 缺失 | 自动降级模式 A，提示手动执行后提供结果 | | 测试结果收集超时 | 自动重试 3 次，仍失败转人工 | | AI 初判置信度全 < 0.5 | 不输出假设，仅列原始错误 + 建议人工 review | | 无历史缺陷库 | 退化为搜索 git history 中 fix/bugfix commit | | 测试用例清单缺失 | 提示用户提供，或从 T1 目录扫描提取 | | 上游有 WARN 用户选择回退 | 返回上游 Skill 修复后重试 | 信息不足时先追问，不硬答不猜测： 无测试结果且模式 B 不可用 → 追问结果格式；未指定执行范围 → 追问范围。 ---

附录

A. 输入 Schema

upstream_inputs:
  upstream:
    t1_desc / t1_dir     # os.walk() 递归检测 → READY/EMPTY/MISSING
    t2_desc / t2_dir
    t3_desc / t3_dir
    d5_desc              # 可选，无则不展示
  # 上游数据通过目录扫描获取，无需 handoff 对象
t3_execution_manifest:   # 模式 C 输入（首选）
  path: T3_自动化脚本/{API|UI}-AUTO-TEST/output/t4_manifest.json
  produced_by: T3 conftest_result_collector（每次 pytest 运行自动刷新）
  schema: 见 T3 handoff-schema.md「执行清单 Schema」；字段与本文档附录 F TEST_DATA 1:1 对齐
  adapter: scripts/manifest_to_testdata.py → build_test_data(path, ENRICHMENT)
test_execution_results:  # 模式 A 输入
  format: junit-xml | pytest-json | testng-xml | custom-json | manual
  path: T3_自动化脚本/UI-AUTO-TEST/output/

H. 模式 C 清单 → TEST_DATA 映射（适配器 manifest_to_testdata.py 自动完成）： | 清单字段 | TEST_DATA 字段 | AI 是否需补 | |---------|---------------|-----------| | summary / priority_results / test_cases（含 api_request/response、screenshot_dir、video_path） | 同名字段 | 否（直接映射） | | test_cases[status==FAIL] + error | failed_cases[] 骨架 | 是：补 hypothesis/confidence/suggested_action/assignee（填 ENRICHMENT.failed_analysis[case_id]） | | —（AI 提供） | project_name/version/tester/execution_scope/... + upstream | 是：填 ENRICHMENT 封面信息 | | —（可自动判定） | release_recommendation | 可选：留空则按 Step 4 规则自动判定 |

B. 输出 Schema（failed_case_analysis）

failed_case_analysis:
  case_id / failure_type / expected / actual / stack_trace_location
  ai_root_cause_hypothesis: {confidence: 0.0-1.0, hypothesis: string}
  related_recent_changes: [{commit, author, date, file, summary}]
  historical_similar_defects: [{defect_id, similarity, summary}]
  suggested_action: {priority: CRITICAL|HIGH|MEDIUM|LOW, next_step, assignee_suggestion}

C. 输出文件

C.1 报告分目录存放（所有项目统一规则）：

T4_执行报告_UAT/
├── API_Report/   # UAT_测试执行报告_{project}_API_{version}_{date}.html + failed_cases_analysis.json + final_report.yaml
├── UI_Report/    # UAT_测试执行报告_{project}_UI_{version}_{date}.html + ...
└── PERF_Report/  # 性能测试报告_{project}_{version}_{date}.html + perf_summary.json + final_report.yaml

C.2 用户自定义输出路径： 用户指定路径 > 默认路径。识别关键词「存放在」「保存到」「输出到」「放到」+ 路径；支持绝对/相对路径，不存在自动创建；一条指令可同时指定多层级路径。 ⚠️ 强制规则：所有项目所有层级，报告一律输出到类型子目录（API_Report / UI_Report / PERF_Report），禁止输出到 T4_执行报告_UAT/ 根目录。

D. Trust Tier 分级

普通业务测试 → T1（测试经理）；金融核心域（account / fund_flow / transaction）→ T2（架构师 + 合规）；发布上线 → T3（AI 绝不允许，人类强制）。

E. 与上下游关系

[T1 测试用例] [T2 测试数据] [T3 自动化脚本]
        \          |           /
         \─────────┼──────────/
                   ↓  T4（本 SKILL）
   Step 0 上游校验 → Step 0.5 T2 注入 T3 data/ → Step 1~6 执行+分析+报告
                   ↓
   [UAT 报告 + AI 初判 + 发布建议] → 人工 UAT 签字 → 发布上线

F. TEST_DATA 数据契约（AI 唯一需填写的部分）

所有渲染由 scripts/*.py 完成。AI 只填字段值；标 可选 的字段留空即对应功能不展示。字段的 CSS/JS/HTML 呈现细节全部在模板中，本文档不重复。

F.1 功能报告（uat_report_template_html.py）TEST_DATA 顶层字段： | 字段 | 必填 | 说明 | |------|------|------| | project_name / project_desc / version / tester / execution_scope / execution_time / ci_pipeline / code_branch / run_id | ✓ | 封面基本信息（DFX 深蓝渐变风格由模板渲染） | | upstream | ✓ | {t1_desc,t1_dir,t2_desc,t2_dir,t3_desc,t3_dir,d5_desc?}；模板用 os.walk 递归判 READY/EMPTY/MISSING | | summary | ✓ | {total,passed,failed,skipped,duration} | | priority_results | ✓ | [{priority,total,passed,failed,skipped}]，状态列由 failed/skipped 自动出 PASS/FAIL/SKIP badge | | test_cases | ✓ | 见 F.2 | | full_session_video_path | 可选 | 全程录屏 .webm 或 playlist .json 绝对路径；空则不显示「🎥 全程录屏」按钮 | | failed_cases | ✓（无失败则空数组） | 见 F.3 | | release_recommendation | ✓ | {decision,confidence,reasons[],blockers[],next_steps[]} | | history | 可选 | 重跑历史 [{run_id,result,blockers}] | F.2 test_cases[] 每个用例字段： | 字段 | 适用 | 说明 | |------|------|------| | id / name / priority / status | 全部 | status 只用 PASS/FAIL/SKIP（broken/failed 统一为 FAIL；ID 列渲染为可编辑下拉框；name 不含 id 前缀） | | screenshot_dir | UI 报告 | 截图目录绝对路径；模板扫描 *.png 排序后 base64 内联，ID 列出 📷 画廊（PASS+FAIL 全量内联） | | video_path | UI 报告 | 单用例录屏 .webm 绝对路径；ID 列出 🎬（受 INLINE_VIDEO 控制） | | api_request / api_response | API 报告 | 所有非 SKIP 用例强制填写；ID 列出 🔗 请求详情弹窗；headers 用 headers_display 传脱敏后的值 |

互斥：API 用例出 🔗；UI 用例出 📷 + 🎬。同一用例不同时出 🔗 和 📷。SKIP 用例无任何图标。

F.3 failed_cases[] 字段： case_id,case_name,priority,failure_type,expected,actual,stack_trace_location,hypothesis,confidence,related_changes[],historical_defects[],suggested_priority,suggested_action,assignee。置信度 ≥ 0.5 才渲染根因假设卡片。 F.4 性能报告（perf_report_template_html.py）章节与判定规则： 9 章：执行总览 / 测试基本信息 / 各场景性能统计 / 错误分析 / 性能基线对比 / 有效请求性能分析 / 测试结论 / 改进建议 / 检查清单。 | 规则 | 阈值 | |------|------| | 错误率 badge | 0% 绿 / 0~5% 黄 / >5% 红 | | 基线判定 | 实测 ≤ 目标=通过绿；> 目标但受环境限制=待验证黄；> 目标×3 且环境正常=不达标红 | | 综合评估 | 全基线通过+错误率<1%=APPROVE；部分待验证/环境受限=REQUEST_CHANGES；核心不达标+不稳定=BLOCK | 封面橙色 badge 文案 性能压测 · 测试执行报告；标准字段 8 项：文档密级 / 报告编号 / 版本 / 执行范围 / 测试工具 / 测试环境 / 执行方式 / 日期。

G. 报告体积与内联开关（省磁盘/加速打开）

报告是自包含 HTML，模板通过环境变量控制资源内联，避免动辄数百 MB： | 环境变量 | 默认 | 作用 | |---------|------|------| | INLINE_VIDEO | true | 录屏是否 base64 内联进 HTML。默认内联（自包含，确保报告在任意目录打开录屏均可播放）；设 false 改为外链引用（需报告与 output/video/ 同目录交付） |

• 截图默认全量内联（PASS+FAIL），保证报告转发后可查看；如需减小体积可降低截图分辨率（缩小 viewport），但不得跳过内联导致画廊空白。
• 录屏默认内联（单个 1~3MB，29 用例约 30~60MB）。若报告体积过大（>200MB），可设 INLINE_VIDEO=false 改为外链，但此时必须确保报告文件与 output/video/ 在同一父目录下。
• 全程录屏可通过降低录屏分辨率（VIDEO_WIDTH=960 VIDEO_HEIGHT=540）进一步减小。
• ❌ 禁止用 file:/// 绝对路径引用媒体（浏览器安全策略拦截）；外链一律用相对路径。
• ⚠️ AI 生成报告时必须设置 $env:INLINE_VIDEO="true"（或不设置，依赖默认值），确保录屏可播放。

---

版本历史已移至 [CHANGELOG.md](CHANGELOG.md)（不进 AI 运行时上下文）。当前版本见 front matter version。

END · SKILL.md