用途
Antithesis Setup 用于脚手架化（scaffold）启动 Antithesis 所需的 antithesis/ harness，使被测系统（SUT）能够以基本空闲、就绪的状态在 Antithesis 中运行。该技能专注于基础设施与就绪准备，不负责定义工作负载本身。
前置条件
- 必须有研究产物。开始前需检查 antithesis/scratchbook/ 是否存在并包含研究输出（至少 sut-analysis.md 和 deployment-topology.md）。若 scratchbook 缺失或为空，应停止并提示用户先运行 antithesis-research 技能。
- 需验证研究来源（provenance）。读取 sut-analysis.md 与 deployment-topology.md 中存在的 provenance frontmatter 字段，并用平实语言向用户描述，然后确认目标系统是否仍然是当前系统。若用户回答否，不得继续，应让其重新运行 antithesis-research。
- snouty 必须已安装，否则不得继续。安装选项见官方 README：https://raw.githubusercontent.com/antithesishq/snouty/refs/heads/main/README.md
文档依据
通过 antithesis-documentation 技能访问以下页面，优先使用 snouty 文档：
- Docker Compose 设置指南：https://antithesis.com/docs/getting_started/setup_guide/docker_compose.md
- Docker 最佳实践：https://antithesis.com/docs/best_practices/docker_best_practices.md
- 覆盖插桩：https://antithesis.com/docs/reference/instrumentation/coverage_instrumentation.md
- 断言编目：https://antithesis.com/docs/reference/sdk/assertion_cataloging.md
- 处理外部依赖：https://antithesis.com/docs/reference/dependencies.md
- 故障注入：https://antithesis.com/docs/product/fault_injection.md
工作流程
该技能拆分为多个步骤，每个步骤位于不同的参考文件中，需逐个读取并实现。每完成一步后，检查新获得的信息是否推翻了先前步骤的决策。插桩决策（步骤 2）是开始在步骤 3 构建镜像后最常需要修改的部分。
- references/directory-init.md：从 assets/antithesis/ 初始化或合并 antithesis/ 目录
- references/instrumentation.md：决定每个 SUT 服务如何插桩、SDK 如何安装、符号如何交付，以及引导属性位于何处
- references/docker-images.md：为 SUT 组件创建或调整 Dockerfile
- references/docker-compose.md：编写 antithesis/config/docker-compose.yaml
- references/config-dir.md：了解哪些内容属于 antithesis/config/
- references/submit-and-test.md：本地测试并提交首次运行
通用指引
- 与现有 antithesis/ 内容合并，而不是覆盖。
- 使用 compose CLI 与 snouty doctor 报告的容器运行时在本地构建和测试，参见 references/submit-and-test.md。
- 尽可能将 Antithesis 专属脚手架保留在 antithesis/ 下。
- 将相关 Antithesis SDK 安装进 SUT 并添加一个最小引导断言，是 setup 的一部分，而不是推迟到工作负载阶段。
- 若 antithesis/test/ 尚不存在，可创建后续工作负载所需的目录结构，但真实测试模板与断言留给 antithesis-workload。
- 将插桩与符号化视为引导工作。直到相关镜像按语言正确暴露 /opt/antithesis/catalog/ 或 /symbols/，setup 才算完成。
- 首次提交前必须进行本地测试。
- 使用 antithesis-launch 技能提交运行，不要直接运行 snouty launch。若 antithesis-launch 不存在，则直接使用 snouty launch。提交前先运行 compose build 以确保镜像最新。
- 除非部署明确要求，不要在 antithesis/config/ 下添加单独的 Dockerfile。
- 在每个容器中禁用颜色/ANSI 输出。Antithesis 存储原始字节且不渲染转义码，颜色输出在日志与排查中是无用内容。通过 docker-compose.yaml 的 environment 块或 Dockerfile 的 ENV 指令在所有服务上设置 NO_COLOR=1，并在需要处添加工具特定标志（如 FORCE_COLOR=0）。
自我审查
宣布技能完成前，按以下标准审查工作。若智能体支持生成子智能体，创建一个全新上下文的智能体执行审查，给它该技能文件路径并让它读取所有输出产物；全新上下文的审查者能发现上下文内审查遗漏的盲点。若不支持，则自行审查：重读文件顶部的成功标准，然后逐项检查以下内容与实际输出：
- antithesis/config/docker-compose.yaml 存在，且每个服务的 build:（本地镜像）或 image:（公共镜像）配置正确
- docker-compose.yaml 中每个服务都包含 platform: linux/amd64
- 每个服务的 hostname: 与其 container_name: 匹配，且二者都不含下划线（使用连字符——下划线不是合法的 DNS 标签字符）
- 每个服务设置 init: true，避免服务进程以 pid 1 运行
- 跨服务依赖使用 depends_on 配合 condition: service_healthy 对应已定义的 healthcheck，而非普通 depends_on
- 运行时 compose 不设置自定义 logging: driver，不配置任何 internal: true 网络，也不设置 pull_policy:
- references/instrumentation.md 中的插桩清单已完全实现：每个服务已插桩、仅编目，或明确记录为未插桩
- 相关 Antithesis SDK 已安装进 SUT 依赖图
- 引导属性存在于简单、保证会运行的代码路径中（不位于罕见行为之后）
- 每个服务的语言都正确暴露 /opt/antithesis/catalog/ 或 /symbols/
- setup_complete 信号已接入至少一个入口点
- 对 antithesis/config/ 运行 snouty validate 成功
- 所有构建镜像均面向 amd64（通过 snouty 所选引擎上的 image inspect 验证）
- 构建使用了 compose CLI 和 snouty doctor 报告的引擎
- 每个服务都在其环境中设置了 NO_COLOR=1（通过 docker-compose.yaml 和/或 Dockerfile），防止容器输出中出现 ANSI 转义码
- harness 已为 antithesis-workload 技能就绪——测试模板目录已存在或已为后续使用接线
- 若用户要求启动运行，应使用 antithesis-launch 技能，而不是直接运行 snouty launch
- 已向用户描述 sut-analysis.md 与 deployment-topology.md 中存在的任何研究来源，并在脚手架开始前确认（来源 frontmatter 格式定义于 antithesis-research 技能 references/scratchbook-setup.md）
技能版本
2026-09-23 a8fe900
限制
实际测试模板与断言定义不属于本技能范围，由 antithesis-workload 负责；运行提交由 antithesis-launch 负责。运行前需已具备研究产物与 snouty 环境，缺失时应先完成前置步骤。