Antithesis 测试运行后需要汇总运行…

在 Antithesis 运行完成或出现失败后，通过 snouty/jq 预检、发现 run、triage properties、下载分析日志、诊断 incomplete run，并给出后续 skill 建议。

适用场景

解决思路

1. 不要预先读取 `references/` 下所有参考文件；只在流程明确需要时读取对应参考文件（每个文件在需要处点名）。
2. 开始前确认已安装 `snouty`；若未安装，按 https://raw.githubusercontent.com/antithesishq/snouty/refs/heads/main/README.md 安装，不继续。
3. 用 `snouty --version` 确认 `snouty` 版本至少为 0.6.0；低于则用 `snouty update` 更新，未达标不继续。
4. 确认已安装 `jq`；若未安装，按 https://jqlang.org/download/ 安装，不继续。
5. 执行 `snouty doctor --json` 预检，验证 API 连通性并查看 snouty 解析后的配置。
6. 仅当顶层 `ok` 为 `true` 且 `api_key` 检查的 `status` 为 `ok` 时继续；否则转述失败检查的 `message`/`notes` 并停止；若 `api_key` 失败，告诉用户设置 `ANTITHESIS_API_KEY`。
7. 从 `snouty doctor --json` 的 `settings` 数组读取 snouty 解析参数；可用 `snouty doctor --json | jq -r '.settings[] | select(.name == "tenant") | .value'` 查已解析 tenant。
8. 开始前收集租户名（Tenant Name，必填）：从 `snouty doctor --json` 读取已解析 tenant 并信任该值；仅当 `doctor` 显示 tenant 未设置时才询问用户。
9. 开始前问清用户想要知道什么：是特定 run 的所有失败、某个具体失败、总体概览，还是比较 run；据此选择工作流。
10. 获取 run 信息的主要方法：使用 `snouty runs <OPTION> --json`；该选项返回按行分隔 JSON，字段随 option 变化。同一命令不加 `--json` 返回较少字段的表格，适合人读。
11. 获取 RUN_ID：阅读 `references/run-discovery.md` 学习如何拿到 `run_id`。
12. 总结最近运行：阅读 `references/run-discovery.md` 获取最近 run 列表，然后写成报告总结。
13. 查看特定 run/report：阅读 `references/run-info.md`，再按需继续其他工作流。
14. Triage 一个 run：若 run 状态为 `incomplete`，转到“诊断 incomplete run”步骤。
15. Triage 步骤 1：阅读 `references/run-info.md` 加载该 run 的信息。
16. Triage 步骤 2：若 run-info 输出中 `links.triage_report` 为 null/缺失，说明未生成 triage report（常见于 `cancelled` 以及部分 `unknown`/`starting` 状态）；报告该 run 不可 triage——这些 run 的 properties 和 logs 端点会返回 404。
17. Triage 步骤 3：阅读 `references/properties.md` 加载 properties。
18. Triage 步骤 4：检查 passed/failed 计数。
19. Triage 步骤 5：检查 instrumentation setup 信号——`Software was instrumented` 和 `Symbols were uploaded` 属性；阅读 `references/instrumentation.md` 解释它们。
20. Triage 步骤 6：构建详细 run 总结，包括审查所有失败并标记新失败；总结中包括 instrumentation 状态。
21. 调查失败 property 步骤 1：阅读 `references/properties.md`；使用 `snouty runs --json properties` 提取 properties 及其 examples，并学习如何下载日志。
22. 调查失败 property 步骤 2：阅读 `references/logs.md` 学习如何理解日志。
23. 对每个要调查的 property：
24. a. 挑选第一个 failing example。
25. b. 找到 moment。如果 counterexample 没有 `moment` 字段（telemetry/meta properties，见 `references/properties.md`），报告 counterexample 值作为证据，并跳过步骤 c–e。
26. c. 按 `references/logs.md` 指导下载该 example 的日志。
27. d. 本地分析下载的日志。
28. e. 如果不确定问题原因，考虑下载同一 property 其他 counterexamples 和 examples 的日志；比较每次发生，寻找能解释失败的相似点或差异；通过的 examples 日志可用于对比成功与失败案例差异。
29. 搜索更多 property 失败日志时，先使用：`snouty runs --json events ${RUN_ID} ${PROPERTY_NAME}`。
30. 该命令返回该 run 中 property 通过/失败的 SOME（不一定全部）案例；`PROPERTY_NAME` 应匹配正在调查 property 数据中的 `name` 字段；将返回的 `hit` 和 `condition` 字段与你试图找更多 examples/counterexamples 进行匹配；已知 examples/counterexamples 很可能也在返回列表中；用 `snouty runs events` 返回的 moment 与已下载 examples/counterexamples 中的 moment 对比。
31. 调查失败 property 步骤 4：重要——如果你能访问，将日志与 SUT 和工作负载的源代码交叉引用。
32. 调查失败 property 步骤 5：深入调查失败，建立对导致该失败（及可能造成它）的事件时间线的理解。
33. 调查失败 property 步骤 6：报告发现。
34. 重要：仅凭 property 状态和断言文本不够；日志提供理解失败所需的实际运行时上下文。
35. 验证 instrumentation：要验证 SUT 和 workload 已插桩且其符号已注册，阅读 `references/instrumentation.md`。
36. 诊断 `incomplete` run：若特定 run 的 `status` 为 `incomplete`，可能有错误日志要检查。步骤：
37. 执行 `snouty runs --json show ${RUN_ID}`。
38. 查看返回 JSON 中的 `failure_moment` 结构；如果存在，使用 `failure_moment` 中的 `input_hash` 和 `vtime` 按 `references/logs.md` 指导下载日志。
39. 尝试获取 build logs，尤其在没有 failure moment 时，使用 `snouty runs --json build-logs ${RUN_ID}`，并在 build 中查找错误。
40. 关于 `links.triage_report` 的注意：对 incomplete run，per-property `properties` 和 `logs` 端点通常返回 404，但 `links.triage_report` 和 `failure_moment` 在 `show` 中仍可能被填充；报告 `show` 实际包含的内容——不要在该字段为 null 之前声称 triage_report 链接缺失；incomplete run 的 triage 工作流是 `failure_moment` + `build-logs`，无论是否存在 report URL。
41. 通用指导：在失败下结论前先审查日志；当 failed property 有带 moment 的 examples 时，在宣布根因前下载并分析日志；有些 property 没有 examples 或日志——这些情况下状态本身是证据。
42. 通用指导：对 property 失败，如果提供 `details` 部分要考虑；这些是 property 作者提供的、用于阐明失败时系统状态的精选字段。
43. 通用指导：清晰呈现结果；报告 property 状态时用表格或列表；报告日志发现时包含 virtual timestamp、source、container 和 log text。
44. 通用指导：在浏览器中提供报告，不要粘贴签名 URL；用户想看完整 triage report 时，建议 `snouty runs show <RUN_ID> --web`，而不是打印很长的 `links.triage_report` URL；`--web` 仅在 triage report 存在时可用；见 `references/run-info.md`。
45. 建议后续 skills：在 triage 总结末尾加简短“next steps”部分，当有帮助时点名后续 skill 或额外 triage 工作流；把这些当作给用户的建议，不要自动执行；让用户或其编排决定何时调用；如果用户明确要求串联 skills（例如“run triage and then debug any failing property”），遵循其指示并继续执行串联。
46. 可根据 triage 发现建议 `antithesis-research`：用于映射代码库以暴露更好的可测试 properties；当失败指向覆盖系统性缺口而不是离散 bug 时有用。
47. 建议 `antithesis-workload`：扩展或细化 assertions、test commands 和 logs；当所有 properties 都通过时建议用它增量改进 workload，或当 properties 因 workload 不够强而不可达时；也可用于增加更多日志或修复 properties 以协助根因分析。
48. 建议 `antithesis-debug`：对特定失败打开 multiverse debugger，检查失败时刻的容器状态或探索其他历史；当仅靠日志分析无法解释失败时有用；需要 agent-browser，可能需要在浏览器交互式登录。
49. 建议 `antithesis-mutation-testing`：通过为每个 property 注入一个现实 bug 并确认每个都会触发，证明 properties 确实能失败；仅当 run 全绿（无 failing properties，因此没有 SUT bug 要先追）且没有迹象表明 catalog 已经 mutation tested 时建议——检查 scratchbook 的 property evidence 文件中是否有 `## Falsification` 部分，或是否存在 `antithesis/scratchbook/mutation-testing/` 目录；全绿报告正是无法区分“防护良好系统”和“永远不会注意到问题的 catalog”的情况。
50. 建议 `antithesis-query-logs`：跨所有 timelines 搜索排序和因果问题（例如“事件 A 是否总是先于失败 B？”、“没有前置 fault 时失败是否仍会发生？”）；当失败看起来与另一事件或 fault 相关，或你只检查了众多历史中的一个时有用；需要 agent-browser，可能需要在浏览器交互式登录。
51. 在建议下一个 skill 时，包含其所需数据（run_id、property name、moment 等），以便用户无需重新发现上下文即可调用。
52. Self-review：在宣布完成前，对照标准审查工作；该 skill 输出是对话式的（总结、表格、分析），在当前上下文中审查；重读本文件指导，然后逐项检查下面的答案和分析。
53. Review criterion：报告的每一个 property 状态（passed、failed、unfound）都从实际 properties fetch 中提取，不是推断或假设的。
54. Review criterion：Findings 引用 properties 数据中的具体数据——property names、assertion text、log lines、timestamps。
55. Review criterion：带可用日志的 failed properties 包含可操作上下文：assertion text、相关 log lines、timeline context；有日志时关于失败的结论基于日志证据。
56. Review criterion：总结区分报告显示的内容与你解释或建议的内容。
57. Review criterion：如果比较 runs，差异基于两个 report 的数据，而不仅是其中一个。
58. Review criterion：声称某个 binary 未插桩时遵循 `references/instrumentation.md`，不要仅依赖 `Software was instrumented` property 的去重 examples。

适用边界 · 注意事项

• 未安装 `snouty` 或 `jq`、`snouty` 版本低于 0.6.0、或 `snouty doctor --json` 未通过（顶层 `ok` 不为 `true` 或 `api_key` 检查不为 `ok`）时，不要继续执行 triage。
• run 没有生成 triage report（`links.triage_report` 为 null/缺失，常见于 `cancelled` 及部分 `unknown`/`starting`）时，不要走常规 properties/logs triage；`incomplete` run 改用 `failure_moment` + `build-logs`。
• failed property 没有 examples 或日志、且没有 `moment` 时，不要把状态/断言文本当成完整根因证据；有日志和 moment 时也不要在分析日志前直接下根因结论。