用途：从某个具体功能出发，产出一个能测试该功能的 Antithesis 工作负载。适用于功能已完成（源码可用、完整分析与断言应通过）或功能开发中（负载含 TDD 风格桩，断言随代码落地转绿）两种起点，两者走同一流程，差别只是首轮通过断言数量。
主要能力：完成系统定位与功能理解；发现功能属性（不变量、可达行为、失效模式）；评估哪些故障注入类型对该功能有意义；构建含双模式断言的负载；在本地迭代后可选迁移到 Antithesis 运行与验证。
使用方式：先读 references/feature-analysis.md 定位系统、理解功能、发现属性，并将结果记录到 antithesis/feature-workloads/<feature-slug>/analysis.md；再读 self-driving-workload、assertions、interesting-values，从边界值与配置上限族构建取值菜单，构建自驱动程序、docker-compose.yml 用于本地运行；本地运行后先检查 reach claims 是否触发，再迭代调整负载、断言、SUT 配置或属性。迁移 Antithesis 时用 antithesis-setup 准备基础设施，用 antithesis-launch 提交运行，用 antithesis-triage 以功能视角分析，用 antithesis-debug 深查失败。功能演进时按“Update workload for feature changes”更新负载。
适用场景：需要针对单一功能做定向覆盖而非全系统广泛覆盖；需要 reach claims 证明负载触及关键状态；需要验证功能不变量。
限制与前置：需有功能（源码、规格或描述）、SUT 源码、本地运行的 Docker Compose v2 与容器引擎（Docker 或 Podman）；迁移 Antithesis 运行需安装 snouty CLI。一次只处理一个功能。发现失败需按 references/verification.md 核实机制，属性失败只是候选缺陷。其余收费、价格等信息暂未提供。