验收合同 是做什么的？
在实现之前，当简报、工单、电子邮件、README、压缩包或证据文件需要转化为可执行的验收标准时使用。
实现工作的第一条命令：
skills/acceptance-contract/run.sh ensure <zip|directory|file> \
--out /tmp/acceptance-contract \
--project-name oai-trial \
--goal-mode create
ensure 是机械守卫：它验证已有的 acceptance_bundle.json，在缺少时自动提取，并在所提供的源包自冻结合同编写以来发生变更时闭失败。其 JSON 收据包含一个 acceptance_contract.progress.v1 计量器，包含 percent、checks、outstanding 和 next_steps。在 ensure 返回 status=PASS 且进度计量器指明剩余工作之前，不得从简报实现。
作为输入传入客户简报、压缩包或特意准备的规范目录。CLI 默认拒绝仓库根目录，这样实现文件就不能悄无声息地成为验收来源。仅在人类明确要求全仓库合同时才使用 --allow-repo。
对于高风险客户简报，在实现前对简报/压缩包加上 acceptance_bundle.json 运行第二道 $ask 圆桌评审。当 WebGPT 可用时将其作为评审者之一加入。直接询问：“这些合同需求是否正确，我们是否遗漏了什么？”要求评审者检查冻结的合同中是否缺少任何客户义务，特别是表示类、类型化值、边界条件和失去资格故障模式。评审是建议性证据；确定性门控仍然拥有 PASS/FAIL 的所有权。oai-trial 评审发现，类型化标量覆盖也必须要求典范等价：格式化的策略字符串、纯数字标量、十进制形式、科学记数法和 SQLite 数值不能是彼此独立的验收宇宙。
功能说明
skills/acceptance-contract/run.sh extract <zip|directory|file> \
--out /tmp/acceptance-contract \
--project-name oai-trial \
--goal-mode create
输出：
acceptance_bundle.json— pydantic 验证的真相源acceptance_report.json—create_report.report.v1JSONacceptance_report.md— 通过$create-report渲染IMMUTABLE_GOAL.draft.md— 目标草稿文本或修改建议
命令：
extract始终根据所提供的源编写全新的草稿包/报告。ensure验证或创建冻结的包，并拒绝过期的源哈希。validate仅验证已有的acceptance_bundle.json并打印进度计量器。status读取已有的acceptance_bundle.json并仅打印机器可读的进度计量器。
目标策略
默认行为是草稿，不修改。
--goal-mode create写入一个新的不可变目标草稿。--goal-mode amend写入一个修改建议，而非静默编辑。--goal-mode none提取需求而不生成目标文本。
真正的不可变目标应在人类批准后才创建或修改。此规则存在是因为当以实现定义的测试代替客户简报时，oai-trial 失败了。
边界
此技能从提供的本地文件中提取清晰的、有源可查的需求。当源包存在歧义时，它不声明提取的合同是完整的。歧义会变成 open_questions[] 和一份“需要更改”的报告。默认拒绝仓库根目录，因为当代码形状的检查代替了交付的简报时，oai-trial 失败了。
对于 Battle，将生成的 acceptance_bundle.json 作为竞技场 acceptance_floor 传递，并将每个 acceptance_cases[].id 映射到 Battle 活动配置文件中 required_case_ids 中的一个或多个生成器案例 ID。这些映射案例是合同底线，在授予模糊测试或超越合同攻击的信用之前必须通过。不要让 Battle 凭空发明需求。