cook

/cook

契約

cook(spec_ref, correction = false) -> handoff(next = age | mold | done)。

仕様に不備がある場合、Cook は next: mold を返します。 ファン実行でも、修正スコープが停滞している場合、カードが合格しない場合、またはカバレッジが不完全な場合は next: mold を返します。

Cook は、先に失敗するテストを用意する必要はなく、ゲートの受領記録も読み込みません。 動作に関する作業では、Press の前に Cook が最初の受け入れカバレッジを担当します。詳しくは references/tdd-loop.md § Inner TDD を参照してください。 これは報告対象の義務であり、ゲートではありません。 ドキュメント、リファクタリング、テスト、外観に関する作業では、対象を変更して直接検証してください。 correction = true は、Press で対応中の指摘または coverage_gap に限って使用してください。詳しくは references/press-loop.md を参照してください。 既存のテストを弱めないでください。

フェーズ開始

python3 skills/cook/scripts/cook.pyz wheypoint-resolve --ref <slug> を実行します。 authoritative の場合は記録を使用します。その working_context は、最初に一括取得する tilth_read です。 not-found の場合は予備情報なしで進みます。legacy の場合は、その出典とスラッグを表示してから進みます。 gated、ambiguous、error の場合は停止し、ペイロードを表示します。 助言的な stale-commit と grounded-path-missing の指摘を表示します。 その record.revision_id を <base> として保持します（§ ベースリビジョン）。

入力

貼り付けられた仕様または課題、明確な受け入れ基準、あるいは曖昧さのないタスクを受け付けます。 明示された仕様のパスは、そのまま読み込みます。 単独のスラッグは、python3 skills/cook/scripts/cook.pyz artifact-path specs <slug> で path に解決します。 Mold の仕様パスまたは確定済みの直接入力は、§ Mold-to-Cook ingress から受け入れます。 フラグ：

• --auto は、Cook 内の Press ループの後に /age → /cure を連続して実行します。
• --prototype は、計画 → スパイク → 確認のループを実行してから安定化します。詳細は references/prototype-mode.md を参照してください。
• --hard は /plate に引き継がれます。
• --open-pr を指定すると、終端の /plate が公開できるようになります。自動モードではこのフラグは追加されません。
• --resume <slug> は、型付きファンハンドオフと、そこで参照されている成果物を再開します。
• --result <path> は、準備が整った Mold の結果を実行します。
• --spec <spec-path> は、選択した Mold の仕様を指定します。dependencies が landing.layers をまたぐ計画は、コーダーへの振り分け前に拒否されます。

任意のコンテキストペイロード：

• handoff_context.wiki_hits には、リポジトリの Wiki コーパスから取得した {page, line, why} エントリを含めます。 このキーは省略可能で、既定値では存在しません。 page、line、why のいずれかが欠けているエントリは拒否してください。 ユーザーが古い判断に異議を唱えられるよう、Contract ステップで採用したすべてのヒットを表示してください。独自の方法を考案するより、これらの判断を優先してください。 ../cheese/references/handoff-gate.md でペイロードを定義しています。

これらのポリシーについては、references/auto-mode.md、references/fan-pathway.md、../cheese/references/formatting.md を参照してください。

単独実行の高速経路

入力、出力、スコープ、検証方法が明確な場合に限り、/cook は /mold を省略します。 タスクでは、1～2 個のファイルに関するバグまたは呼び出し箇所を指定し、失敗するテストまたは期待出力のチェックを用意する必要があります。 レバレッジのトリガーが一つも発生してはなりません。詳しくは ../cheese/references/routing-policy.md § Leverage triggers を参照してください。 スラッグを導き出し、契約をあらためて提示します。 曖昧さの確認に失敗した場合は、タスクを /mold に振り分けます。

フロー

1. コントラクト — 動作、対象外、範囲、ゲートを確認します。 Contract 内に ../mold/references/shape-check.md の形状チェックブロックを出力するか、shape-check.md の「スキップするタイミング」に従って shape check skipped: single-module change の行を出力します。ブロックがなければ、コードもありません。 .cheese/glossary/<slug>.md が存在する場合は、そこに記載された正式用語を使用します。
2. 実装 — 適切な場合は、まずテストを作成します。ゲートで必須とされていない場合は、テストを作成する必要はありません。 動作に関わらない作業では、該当する箇所のみを変更します。
3. 検証 — 関連する品質ゲートを再度実行します。 ゲートの出力をすべて確認します。動作に関わらない作業では、要求されたパスを検証します。
4. 味見 — 複数ファイルまたは公開インターフェースに関わる差分は、新しいコンテキストでレビューします。 それ以外の場合は、インラインレビューを2ラウンドまで行います。 詳細は references/tdd-loop.md を参照してください。
5. プレスループ — 動作に関わる作業では、Cook が新しいコンテキストの Press エージェントをディスパッチします。メニューはありません。 references/press-loop.md を参照してください。 動作に関わらない作業では、このステップをスキップします。
6. 引き継ぎ — パッケージレポートとスラッグを記述し、/age → /cure にルーティングします。

ファン経路

/cook は、型付きプランナーの結果から3つの形状のいずれかを選択します。 トポロジーとライフサイクルについては、references/fan-pathway.md を参照してください。

ファストパス。 影響範囲が小さい、または中程度のカード1件には、単一コーダーの経路を使用します。

カード分割あり。 ready 状態の Mold 最終化で確定した spec_ref、planner_result_ref、plan_ref、および正確な MoldCookCoverage が必要です。ホストは、execute_bound_plan がライターをディスパッチする前にこれらを検証します。 確認済みの診断と CureDiagnosisBinding を使って、進捗対応型のファン状態マシンでクリーン、停滞、またはブロックの状態になるまで cook(CurdPlan) → reviewer(age) を実行します。 各カードの Cook ループでは、それぞれ独自の Press ループを実行します。 バリアでは、マージ後の先端に対して Cook の統合受け入れチェックを実行します。 マージ後に全体を対象とする Press は実行しません。 ファン作業が未完了の場合は next: press を出力しません。停滞した場合は、Mold の修復計画にルーティングします。

カード分割なし。 小規模な作業には単一コーダーの経路を使用します。 大規模な作業では、--auto が指定されていない場合、「12件のAC → 5件のカード、2つのウェーブ、最大25回のエージェントディスパッチです。進めますか？」と確認します。 ウェーブは最大4つまでとします。

クリーンアップには python3 skills/cook/scripts/cook.pyz worktree teardown を使用します。 ディスパッチされた各フェーズに --auto を引き継ぎます。

ベースラインの記録

ファンモードでは、いずれかのカードを調理する前に品質負債の比較を記録します。ベアモードでは、変更前のツリーで記録します。 references/quality-gates.md では、記録方法、分類、意図的なREDの除外、ベースラインアーティファクトのルールを正確に定義しています。

ソースを変更する場合は、code-intelligence-routing.md と harness-portability.md に従います。 slash commands are host renderings, not the control model。同等のインストール済み機能を呼び出します。

品質ゲート

既存のプロジェクトコマンドのみを実行します。 変更箇所に最も関連するテストを実行します。 プロジェクトで定義されている場合は、リンター、型チェック、ビルドの各コマンドも実行します。 変更を通すために、無関係なテストを削除、スキップ、または弱体化しないでください。

ゲートが失敗した場合は、ベースラインを使用します。 references/quality-gates.md では、ポリシー、分類用語、ベースラインアーティファクトを定義しています。

references/writer-views.md は、ライタービューのペイロード用スキーマをインラインで生成します。 normalize および validate CLI は、エージェントが作成したJSONがホスト所有の識別子に渡される前に、これらのスキーマを適用します。

出力

../cheese/references/formatting.md のプロジェクト標準スタイルを使用します。 ファイル、理由、チェック、リスク、次のスキルを報告するには、references/package-report.md を使用します。

Handoff slug

.cheese/cook/<slug>.md の先頭に、最小形式の handoff slug を記述します。 レポートにも同じファイルを使用し、2つ目のファイルは作成しないでください。 次のスキーマを使用します。

status: <canonical status field>
next: mold | age | done
artifact: <path to the upstream artifact this run consumed, or empty>
taste_test: inline-pass | dispatched-pass | revised | deferred-to-orchestrator
durable_flags: none | <one line per flag: what durable knowledge changed -> target wiki page>
baseline: none | <path to the baseline artifact — shape in references/quality-gates.md § Baseline block shape>
<one-line orientation: what cook changed>

handback contract では、ok と halt を含む正規の status: 文法を定義します。 next: と追加のキー付き行のみがフェーズ固有です。

artifact: には、この実行で使用した上流の成果物を指定します。 Mold ルートでは、承認済みの仕様パスを使用します。 この実行で上流の成果物を使用していない場合は、artifact: を空のままにします。 artifact: にこの Cook レポートを指定しないでください。

型付きの fan 結果について、この handoff を出力するときは正規の境界ライターを使用します。 結果スキーマを明示的に引き継ぎます。

python3 skills/cook/scripts/cook.pyz write-handoff-artifact \
  --slug <slug> --status <status> --phase cook --next age [--base <base>] \
  --artifact <artifact-path> --orientation "<one-line orientation>" \
  --payload-schema https://schemas.easy-cheese.dev/curd-result \
  --grounded <path[#start-end]> \
  --body-file <path to the package report body>

ライターは対象ファイルを置き換えます。 パッケージレポートを同じファイルに保持するには、--body-file を渡します。 このフラグを指定しない場合、ライターはプリアンブルのみを出力し、レポートを削除します。

再計画または仕様の失敗では、https://schemas.easy-cheese.dev/planner-request ペイロードとともに --next mold を使用します。 references/fan-pathway.md では、失敗クラスごとのリクエスト種別を定義しています。 これらの phase と next の値は、レガシー handoff ファイルのルーティングにのみ使用されます。 検証済みの CurdPlan と正規化済みの CurdResult は、引き続き有効な fan 状態です。

fan 実行では、各フェーズの handoff slug ファイルをディスクから読み込みます。 stdout から handoff を推測しないでください。

next: には、次に実行可能なフェーズを指定します。 Press ループが green を返した後、および振る舞いに関係しない作業の後は age を指定します。 next: press や next: cook は絶対に公開しないでください。needs-context は親が所有する同一フェーズの再試行です。 仕様の失敗後は mold を指定します。 実際に完了した場合のみ done を指定します。 コストゲートが適用されない場合は、taste_test: を省略します。

デフォルトで durable_flags: には none を指定します。 アーキテクチャ、プロトコル、規約、または根拠に対する永続的な変更のみを記録します。 各変更について、対象の wiki ページを記録します。 baseline: には、Cook の任意の比較用成果物のパスを指定します。 この成果物には、ベースラインと同一の負債、および現在の広範なゲートで発生した新規または変更された失敗が含まれます。 references/quality-gates.md にある形式を使用します。 プリアンブルでは各キーに物理行を1行ずつ割り当てる必要があるため、マッピングを1行にまとめないでください。

Handoff

パイプライン： culture → mold → cook（⇄ press）→ age → cure → plate

レポートと slug を書いた後、共通の handoff ゲートを使用します。 ../cheese/references/handoff-gate.md にある 標準の次ステップメニュー を読みます。 メニューに Press は含まれません。 振る舞いに関する作業では、Press ループが green を返した後にのみこのゲートに進みます。 各選択肢は動詞から始めます。 振る舞いに関する作業と、それ以外の作業には次の選択肢を使用します。

• 変更をレビューする（推奨）— /age <slug>。
• Plate に進む — /age <slug> --auto --open-pr：残りのレビュー工程を実行し、その後 /plate がトポロジーを解決して公開します。
• チェックポイントを作成して停止する — /wheypoint。
• 停止する — 何もディスパッチしません。

選択される前にディスパッチしてはいけません。 選択されたコマンドを直ちに実行します。 ユーザーが --auto を指定した場合、このゲートを省略します。 /age へのルートを直接進みます。

自動モード

自動モードを開始する前に references/auto-mode.md を読みます。 検証、フェーズチェーン、早期停止、Cure の制限、公開の責任範囲、fan の分離、失敗処理について記載されています。 各停止レポートとその理由を提示し、結果を決して格下げしないでください。 直線的なチェーンでは、Cook は /plate を呼び出しません。 fan 経路では、Cook オーケストレーターが終端の /plate ディスパッチを自ら管理します。 次のアクションは、レガシーなフェーズテーブルではなく、fan の進行状態に基づいて決定します。

チェーン分離の指示

起動されたフェーズエージェントは、それ自体では次のフェーズに進みません。チェーンはオーケストレーターが制御します。

終端の Age を公開できるのは、next: done の場合のみです。 next: cure が指定されている場合、または next がない場合は、チェーンを停止します。

ルール

• 変更範囲は、承認された契約に限定します。
• 既存の依存関係とパターンを優先します。
• 初回からレビューしやすい形で実装します：references/tdd-loop.md § レビューしやすい実装。
• ../cheese/references/sliced-bread.md に従い、インポートの方向と境界の整合性を保ちます。
• 新しい境界エクスポート、内部要素のスライス間インポート、または仕様に記載のないスキーマや契約の変更が必要になったら、作業を止めてユーザーに確認します。
• 仕様ですでに却下されたアーキテクチャを考案しません。
• 実装中に、仕様で答えられていない設計上の決定が明らかになったら、作業を止めてユーザーに確認します。
• 仕様またはファストパスの依頼に誤った前提が含まれている場合は、コードを書く前に作業を止め、誤った前提を示します。
• 依頼を文字どおり満たすために、誤った方法を使いません。
• ../age/references/voice.md の共通ボイスカーネルを適用します。レポートは回答から始め、契約内で読み込んだ前提を明示します。
• 残存リスクには certain | speculating | don't know のいずれかを付けます。
• status: ok とする前の検証： ゲートコマンドを特定し、現在のターンで実行して、完全な出力を読んでから主張します。
• should、probably、I think は使いません。
• ゲートの出力が示す内容を明記します。

エージェントの選定

agent-resolution.md に従って選定します。 実装にはコーダーを使います。 テイストテストにはレビュアーを使います。 Harvest と plate は親が担当します。

作業	優先するタイプ	権限／分離	最小能力	労力	フォールバック
仕様の分解	planner、general	write（マニフェストのみ）、fresh-context	powerful	high	対応可能な planner、次に general
ループの反復	coder	write（テストのみ）、fresh-context を優先	default	medium	general、次に Cook セッション内で直接実行（degraded: true）

ハンドオフには agent_resolution ブロックが含まれます。 next: done を含む場合に限り、終端 Age を公開します。 next: cure を含む場合、または next を含まない場合は停止します。

生成済みバンドルのコマンド一覧：references/commands.md。

Mold から Cook へのインジェスト

保存された Mold 仕様は実行権限ではありません。ユーザーが選択したスコープとルートをリクエストした場合に限り、Cook を開始します。 --spec 単独の場合も含め、単独タスクでは最終処理を省略できます。 仕様保留による拒否：フロントマターに execution_holds、または request_directive に do-not-implement か do-not-proceed が含まれる --spec の実行は拒否します。 --result ファイルが ready でない場合は拒否します。ready の場合は、execute_bound_plan の前に cook.pyz validate-result を実行します。 references/fan-pathway.md § Mold から Cook への直接インジェストに従います。 この境界を変更する場合は、references/evals.md に記載された新規エージェントの回帰シナリオを実行します。