cut

/cut

/cut は、Mold と Cook の間にある外側から内側へ進むエビデンスのフェーズです。承認済みの観測可能な動作が現在のプロジェクトで GREEN であることを証明し、その後、宣言された証人に対して宣言された外側の継ぎ目で失敗させます。動作を実装することはありません。レシートが永続的な境界となり、レシートに記載されたテストファイルとフィクスチャファイルは、本番コードの編集から保護されます。

契約

cut(spec_ref, reproduction? = null, auto = false) -> GateReceipt

すべてのバリデーター呼び出しは、 references/gate-workflow.md § パッケージ化されたコマンドの 解決に従って解決してください。単独の red-gate バイナリはインストールされていません。

Cut は、明示的に、Mold の承認済み red-required ハンドオフから、または有効なレシートがない Cook の事前確認から起動します。永続化された仕様とそのゲートメタデータを読み、説明文から適用可否を推測しないでください。動作項目には少なくとも 1 つのテスト契約が必要です。テーブルのないレガシー仕様は、新たな承認なしで進められますが、Cut は結果として得られるすべての契約に contract_source: inferred を証拠として記録する必要があります。

Cut が所有するのはテスト側のファイルのみです。外側のトレーサー、機械的に正当化された契約マトリックスのケース、フィクスチャ、テスト専用のハーネスサポートが該当します。ユーザーまたは Pasteurize による条件を満たす再現ケースは、承認済みの継ぎ目、argv、cwd、証人に合わせて正規化したうえで採用できます。採用したケースには producer: cut と origin: adopted を付け、生成したケースには origin: generated を付けます。

フロー

1. 解決して分類します。 仕様を読み、次に red-gate contracts <spec> を実行します。承認済みのインターフェイス、継ぎ目、期待される失敗、モードは正確に維持します。レガシー仕様からの推論は返される計画に表示され、再承認は不要です。ランナーを選択する前に gate_applicability を検証します。

2. N/A を早期に確定します。 Mold が承認した、閉じたクラス（docs-only、refactor-only、test-only、appearance-only のいずれか）に対する not-applicable 宣言では、空でない理由を記録し、RED 契約、ベースラインチェック、ケース、保護対象ファイル、ガード、レシートレベルのモードを一切設けません。それでも red-gate issue は実行します。

3. 継ぎ目を選び、フェーズを宣言します。 プロジェクト既存のランナーと規約を再利用します。機能 UI では、宣言済みのブラウザー／E2E の継ぎ目を再利用します。プロジェクトのランナーも標準ライブラリのランナーも利用できない場合は、ハーネスに関する判断を明示して停止します。サードパーティーのランナーをインストールしたり、独自に作成したりしてはいけません。.cheese/cut/ に厳密なフェーズ計画を作成し、schema_version、producer、work_id、project_key、Cook が変更できるプロジェクト相対の production_paths、および id、argv、プロジェクト相対の cwd のみを含むベースライン項目を記述します。Cut が保護対象のテストファイルとして追加するものを除き、それらのルート以外はすべて不変のオラクル依存関係です。

4. オラクルより先に開始します。 新しいオラクルを作成または採用する前に、次を呼び出します。

   red-gate begin .cheese/cut/<slug>.plan.json --out .cheese/cut/<slug>.phase.json
   

   begin は広範なベースラインを順番に実行し、終了コード 0 を要求して、 プロジェクト全体のスナップショットを固定します。出力された phase_token_ref と phase_token_sha256 は必須の候補フィールドです。ベースラインの欠落、安全でない argv、ゼロ以外の終了コード、古い出力パス、または検査不能なファイルシステムが あれば、トークンを発行せずに停止します。フェーズトークンを手書きしたり、再利用したり してはいけません。

5. ベースラインの証拠を固定します。 トークンのベースラインコマンド識別情報を 正確に候補にコピーし、観測された各終了コードを 0 として記録します。 ベースラインの argv は、保護対象の RED オラクルパスを除外するか、オラクルが存在しても 成功する必要があります。レシート検証では、オラクル作成後にこれらが再実行されるためです。 オラクルを書き込んだ後にベースラインを再取得してはいけません。

6. オラクルのみを書き込みます。 動作上のカードごとに外側のトレーサーを 1 つ追加します。 または、承認済みのバージョン管理されたインターフェースから名前付きの全行を機械的に 導出できる場合に限り、完全なマトリックスを追加します。マトリックス契約では interface_version と一意な matrix_rows を宣言し、レシートでは各行に契約ケースを 1 つだけ対応付けます。製品ファイルを変更したり、製品用スタブやアダプターを追加したり、 コミットを必須にしたりしてはいけません。

7. RED を証明します。 宣言された argv を使って（シェル評価は決して行わず）選択した 各ケースを再実行します。ケースは、そのアサーションの証拠によって失敗する必要があります。 収集、インポート、依存関係、フィクスチャ、構文、その他ハーネスに起因する失敗は、 動作上の RED ではありません。実行後に製品ツリーのフィンガープリントを再確認します。 アサーション起点の証明が利用できるのは、直接実行する Python スクリプト／-c、 python -m pytest、および python -m unittest のみです。これらのプロファイルに 該当しない既存ランナーでは、明示的なハーネス判断が必要です。表示されたトレースバックや 終了テキストから RED を推測してはいけません。

8. 正規の証拠を発行します。 固定済みの Cut 前の baseline_checks、フェーズトークンの ref とダイジェスト、保護対象テストのダイジェスト、初期値が 0 のガードを含めて、 .cheese/cut/candidates/ の下に候補を作成し、次のコマンドを正確に呼び出します。

   red-gate issue <candidate> --token .cheese/cut/<slug>.phase.json --out .cheese/cut/<slug>.json
   

   red-gate issue だけがレシートを書き込みます。再実行の前に、トークン発行後の プロジェクト変更がすべて、保護対象のテスト側パスに正確に該当することを検証します。 GateReceipt JSON を手書きしたり、公開したりしてはいけません。製品ツリーの変更、 ハーネスのみの失敗、古いダイジェストやトークン、ベースラインの欠落、安全でない argv、 または証拠の不一致がある場合、成功したレシートは発行されません。

9. 引き渡し。 issue の成功後、小さな引き渡し用プロジェクションを書き込み、レシートを Cook に渡します。--auto では、そのレシートを使って Cook を 1 回だけ呼び出します。 同期 Cook の事前チェックでは、レシートを呼び出し元に返し、Cook を再帰的に呼び出しては いけません。

イベントの詳細な順序、候補フィールド、拒否ルール、ダーティーツリーのフィンガープリントについては、 references/gate-workflow.md を参照してください。

レシートの不変条件

RED レシートでは、producer: cut、空でないコントラクト、Cut 前に凍結された baseline_checks、RED ケース、および保護されたテスト側ファイルのダイジェストが必要です。各 baseline_checks エントリーは、オラクルの実行前に記録されたプロジェクト全体の結果です。 その id、argv、cwd、observed_exit_code は不変のレシート 証拠であり、Cook が再取得するものではありません。またレシートには、オラクルの実行前に出力された正確な phase_token_ref と phase_token_sha256 も含まれます。Cook は発行時のスナップショットを信頼するのではなく、そのエントリーの証明を 検証します。初期 Cut レシートの guard_receipt_refs: [] は、ガードが後続の Press の証拠に属することを示します。 各通常の振る舞いのカードは、それぞれ 1 つのトレーサーを持ちます。契約マトリックスを使用できるのは、承認済み／バージョン管理されたインターフェースに限られます。コントラクトには、空でない interface_version と一意な matrix_rows が記録され、RED の証拠には、名前が指定された各 matrix_row に対して kind: contract のケースがちょうど 1 つ含まれます。モードは各 Test Contract に属するため、1 つのレシートでトレーサーモードとマトリックスモードを混在させることができます。有効なケースの起点は引き続き generated または adopted です。

作業ツリーが汚れていても安全です。既存の差分を保持し、オラクルのファイルのみを追加して、RED 専用のコミットは作成しないでください。本番ダイジェストの変更、ハーネスのみの失敗、または GREEN ベースラインの欠落がある場合、発行はブロックされます。ランナーが利用できない場合は、サードパーティ依存関係を追加するのではなく、ハーネスに関する判断を求めてブロックします。

引き継ぎ

正規レシートが存在する場合に限り、次の最小限の形式で .cheese/cut/<slug>.md を作成します。

status: ok
next: cook
artifact: .cheese/cut/<slug>.json

正規レシートは、引き継ぎにおけるベースラインの保持元です。Cook は、凍結された baseline_checks をそのまま使用し、上書きしたり再取得したりしてはなりません。

概要の行では、選択したコントラクトとランナーを説明できます。ブロックされた試行では halt: <reason> を使用し、next: cook としてはなりません。

規律

鉄則： GREEN ベースラインと、red-gate issue によって発行されたテスト専用の保護された RED オラクルがなければ、Cut の RED レシートを成功扱いで作成しないでください。

危険信号 — 次のことに気づいたら停止してください。

• トレーサーの作成中に本番コードが変更された；
• 最初の実行が、テスト収集、インポート、フィクスチャのセットアップ、または依存関係の読み込みで失敗する；
• ベースラインの記録前にテストが失敗している；
• ランナーの不足を依存関係の追加で解決しようとしている；
• RED 専用のコミットが提案されている；
• 候補を公開用レシートとして直接シリアライズしようとしている；
• Cut の事前チェックから同期的に Cook を再帰呼び出ししようとしている。

正当化	問題点	必要な対応
「Cook が実装した後で外側のテストを追加できます。」	実装前の失敗を示す独立した証拠が失われます。	オラクルを作成する前に GREEN を確認し、その後 RED を証明してから、本番コードを編集してください。
「テスト収集のクラッシュも RED とほぼ同じです。」	ハーネスの失敗では、承認された振る舞いや証拠対象をテストできません。	ハーネスを修正または報告し、何も発行しないでください。
「ランナーがないので、都合のよいフレームワークをインストールします。」	Cut が対象プロジェクトのツールチェーンを無断で変更することはできません。	明示的なハーネス判断を求めて停止してください。
「作業ツリーはすでに汚れているので、コミットすればレシートがより安全になります。」	レシートはダイジェストを保護します。RED 専用のコミットはコントラクトに含まれません。	既存の差分のフィンガープリントを記録し、履歴には手を加えないでください。
「手書きのレシートにも必要なフィールドはすべてあります。」	生の JSON では、再実行、ダイジェスト、ガード、正規化のチェックを回避できてしまいます。	すべての候補を red-gate issue に通してください。
「Cook が Cut を呼び出したので、Cut も Cook を呼び返すべきです。」	再帰的な連鎖はループを引き起こす可能性があり、事前チェックの境界の所有権も損ないます。	レシートを同期的に返してください。Cook をディスパッチするのは --auto だけです。

プレッシャーゲート

このワークフローを永続的なものとして扱う前に、スキル適用前に失敗するプレッシャー実行が必要です。 シナリオとオラクル感度の変更は references/pressure-eval.md にあり、AC-12 は tests/python/test_cut_pressure_eval.py でカバーされています。

Pipeline

culture → mold → **cut** → cook → press → age → cure → plate