done

/do からマニフェストのパスと、各受け入れ基準およびグローバル不変条件が満たされていると判断した根拠を受け取ります。

自律的に下した重要な判断とその理由を含めてください。これには、Appetite の変更と、追加される複雑さや保守コストを上回る利点があった理由も含みます。/do が提示する草案の Taste エントリーがあれば、ユーザーに確認を求める質問も含めて、そのまま引き継いでください。

ユーザーが決めること。 同じ証拠を持つ慎重な人同士でも合理的に異なる判断を下し得て、その違いがユーザーにとって重要である場合、その判断はユーザーが決めることです。重要な判断はすべて、この文に照らして検討してください。自分の確信度だけで決めてはいけません。ユーザーが決めることについては、まず明示的に維持された判断、または該当する委任を尊重します。次に、読み込んだメモリファイルの ## Taste セクションにある、承認済みの好みであるユーザーの Taste エントリーを確認します。その種の判断に明確に当てはまり、かつ従うことで選択が変わるエントリーに限り、適用してください。たとえば、労力や費用の削減のように、ほぼすべての判断を左右する一般的な傾向は、それだけでは該当しません。それ以外は証拠に基づいて判断してください。判断を報告するときは、まず実行中に再検討した各判断記録を挙げ、保留にした理由と、判断を覆す場合のコストを示してください。次に、ユーザーが決めることをそれぞれ挙げ、採用しなかった代替案と、判断を決めたもの（従ったエントリー、または該当するエントリーがなかったこと）を示してください。

完了サマリーは平文で記述してください。何を構築したか、主な変更点（ファイルと、単なるパスではなく動作への影響）、従わなかった Process Guidance、Initial Approach または Deliverable の順序から逸脱した場合はその内容と理由、作業の着地に関する特記事項を記載してください。各ゲートの根拠は、/do が提示したとおりに正確に示してください。/do が引き継ぐ負債は、提示された項目ごとに列挙し、対応を希望する場合は ticket-up を提案してください。サーフェスに残された演習の証拠へのリンクも示してください。受け入れず人による対応に回した提案（セットアッププロジェクトの更新や ticket-up への引き継ぎなど）を、実行中に挙げたものか、マニフェストの ASM-* エントリーに記載されたものかを問わず、すべて列挙してください。実行中のエージェントを決定者として記録された判断記録もすべて列挙してください。各提案と判断記録について、受け入れまたはレビューによって何が変わるかを説明してください。作業中に修正した問題と、無用または同義反復的なため削除したテストがあれば、その理由も示してください。/do が引き継ぐ負債は、実行中に修正できなかったものに限ります。つまり、独自のプロジェクトとして取り組む必要がある問題（検討すべき設計判断、リポジトリのコード範囲を超える移行やロールアウト、変更を埋もれさせてしまうレビュー）とその理由、ユーザーが保持するアクセス権限、権限または判断を必要とするもの（対応が必要な ask-first 実行など）、プロジェクト独自のルールによりプルリクエストの対象外となる無関係な問題、および新たな抑制に限ります。ゲートの基準を下回る指摘や、実行中に修正した既存の問題を、引き継ぐ負債として挙げてはいけません。ユーザーに確認できないまま基準が疑わしいと判断したゲートがあれば、そのゲートと、その基準未満のラウンドで判明した内容を記載してください。これらは、実行ログにすでに記録されている場合も含め、すべて記載してください。サマリーを読むだけで、どの助言を見送ったか、計画をどう変更したかがわかるようにしてください。詳しさは作業の複雑さに合わせてください。小さな修正なら数文、複数の成果物を伴うリファクタリングなら段落を一、二つ記載します。複数リポジトリのマニフェストでは、マニフェスト全体を対象とするサマリーを一つ作成し、どのリポジトリの成果物を検証したかを明記してください。

すべての受け入れ基準とグローバル不変条件が、新しい証拠に基づいて満たされ、未検証、失敗、古い状態、対応可能なブロック、エスカレーション待ちが一つもない場合にのみ到達できます。末尾には、必須の次の行を記載してください。完了後もマニフェストが唯一の信頼できる情報源であるため、これは観察的な記述ではなく指示です。

次のメッセージが変更または新しい要件を示している場合（単なる質問を除く）、/define <this-manifest-path> を実行して変更してください。単なる質問にはその場で回答します。