acceptance-contract は何をしますか？
実装前に、ブリーフ、チケット、メール、README、ZIPバンドル、または証拠パケットを実行可能な受理基準に変換する必要がある場合にこれを使用します。
実装作業の最初のコマンド：
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レシートには、percent、checks、outstanding、next_stepsを含むacceptance_contract.progress.v1メーターが含まれます。ensureがstatus=PASSを返し、進捗メーターが残りの作業を示すまで、ブリーフから実装を開始しないでください。
クライアントブリーフ、ZIPバンドル、または意図的にステージングされた仕様ディレクトリを入力として渡します。CLIはデフォルトでリポジトリルートを拒否するため、実装ファイルが静かに受理ソースになることはありません。--allow-repoは、人間が明示的にリポジトリ全体の契約を要求した場合にのみ使用します。
高リスクのクライアントブリーフの場合は、実装前にブリーフ/ZIPとacceptance_bundle.jsonに対してセカンドラインの$askラウンドテーブルレビューを実行します。利用可能な場合は、レビューアの1人としてWebGPTを含めます。「これらの契約要件は正しいですか？何か見落としていますか？」と率直に尋ねます。レビューアには、凍結契約からクライアント義務が欠落していないか、特に表現クラス、型付き値、境界条件、失格となる障害モードを確認するよう要求します。レビューは助言的証拠であり、決定論的ゲートが依然としてPASS/FAILを所有します。oai-trialのレビューでは、型付きスカラーカバレッジは正準等価性も要求する必要があることがわかりました。フォーマット済みポリシー文字列、数字のみの数値スカラー、10進形式、科学的記数法、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内の1つ以上のジェネレーターケースIDにマッピングします。これらのマッピングされたケースが、ファズまたは契約外の攻撃がクレジットされる前に合格しなければならない契約フロアです。Battleに要件を発明させないでください。