workflow-deliver

ワークフローの納品

依頼内容、実装内容、検証内容（不足事項を含む）を報告します。納品の段階では修正、ビルド、承認は行いません。不具合は該当するフェーズに戻します。

共有ポリシーは兄弟ディレクトリの ../workflow/ から読み込みます（見つからない場合は中止して、その旨を報告してください。他のスキルルートにあるコピーは使用しないでください）。その「Always」リストもここに適用されます。

開始前に、次を確認してください。PLAN チェックポイントに合意事項と承認、または簡易リクエストが記載されていること（記載がない場合は不足事項を報告し、権限を推測して補わないでください）。書き込み中のワーカーがいないこと。タスクが停止、一時停止、キャンセル、または簡易対応でない限り、execute に全機能のレビューが記録されていること（workflow/TASK-FOLDER.md）。そうでない場合は workflow-execute に差し戻し、ここでは実行しないでください。再実行するチェックが workflow/RULES.md のルールに準拠していること。準拠していない場合、そのチェックは未検証のままにしてください。

サブエージェントを使う場合、作業を実装していない新しいエージェントが照合を行います。簡易ルートでは、チケットのレビュー担当者が照合してもかまいませんが、その旨を明記してください。それ以外の場合は、自分で行ったと報告してください。TODO のチェックマークと要約には、根拠が必要です。

1. 状態を固定する

読み取り専用で、開始時の git status と照らし合わせて、HEAD とステージ済み、未ステージ、未追跡の変更を記録します。すべての判定はこの状態を対象とします。

2. 要件

合意された各要件、受け入れ項目、担当者ごとの項目、前提条件、および承認された変更について、関連チケット、V-ID、判定を1つずつ記録します。合意内容を記載どおりに解釈しない場合は、workflow-clarify に差し戻すべき不足事項であり、判定にはできません。

判定（報告値）	必要条件
検証済み（verified）	実際に実行され、変更されていないファイルを対象としたチェックに合格しており、未解決のレビュー指摘がないこと
部分的（partial）	一部を確認できており、不足事項が明記されていること
失敗（failed）	チェックに失敗していること
未検証（unverified）	チェックがない、古いチェック（チェックを stale として報告）、または実行環境がないこと。理由も記載すること
免除（waived）	ユーザーの決定が記録されていること。合格として示してはならない
上書きまたは対象外（superseded）	置き換えた決定が記録されていること。チェックを根拠として記載しないこと

3. チェック

必要なチェックごとに、実行の有無、対象となった状態、結果を報告します。古いチェックまたは未実施のチェックを再実行できるのは、作業が進行中であり、その実行が承認され、安全で、workflow/ARTIFACTS.md の制限内にある場合に限ります。停止、一時停止、またはキャンセル後はチェックを開始せず、不足事項として記録してください。必要なチェックを省略したり、基準を緩めたりしてはなりません。

4. ファイル

変更されたすべてのファイルをチケットに対応付けます。説明のつかない変更、変更されていないままの実装予定ファイル、残存する足場コードを報告してください。

5. レビュー

各チケットのレビューと全機能のレビューが存在し、Standards と Spec を対象とし、最終ファイルに対して実施され、すべての指摘が解決済みまたは制限事項として明記されていることを確認します。レビューがない場合、または自分だけで行ったレビューの場合は報告してください。

6. 記録

TODO の状態、チェックポイント、台帳が一致していることを確認します（workflow/scripts/open_items.py は根拠のないチェックマークを一覧表示します）。DECISIONS で by: agent と記載された項目をすべてユーザーに一覧で示します。両方のゲートが記録されているか、レガシー、免除、または簡易対応として分類されている必要があります。

7. 不具合を差し戻す

不一致はすべて、担当者を割り当てた指摘事項にします。コード、テスト、レビューの不具合は workflow-execute に、合意内容の不足は workflow-clarify に、チケットの不足は workflow-specify に差し戻します。ここでは修正しません。タスクが停止、一時停止、またはキャンセルされている場合は、残件として一覧表示します。コードまたはテストを修正した後は再度照合し、記録のみを修正した後は該当する記録を再確認します。ユーザーが現状のまま納品するよう求めた場合、またはタスクを停止した場合は、部分的な納品として扱います。

すべての要件、必要なチェック、変更ファイル、レビューについて、固定した状態を対象とする判定が得られた時点で完了です。

8. 提供結果を記録する

workflow/scripts/record.py を使って、PLAN の ## Outcome を記述し、チェックポイントを更新します。記録する内容：質問されたこと、合意したこと、構築したもの、チケットと状態、変更したファイル、チェックと結果、2つのレビュー観点、受け入れ判定、UI の場合は使用した各クラスとその定義ファイル、および差分で「CSS を追加していない」ことを確認した結果、制限事項、保持した証拠と残っている作業メモ、次に安全に行える作業。

続いて、../simple-english/SKILL.md に従って、現時点で動作すること、動作しないことまたは未確認のこと、ユーザーに受け入れてもらう必要があることを伝え、その後に証拠を示します。会話に参加していなかった人が、目標、変更内容、変更されなかった内容、ユーザーに求めること、確認方法を理解できるか、初見の読者の視点で確認します。オーナーまたはデザインの受け入れ記録は、ユーザーが行います。

完了とみなすには、次の3つがすべて必要です。PLAN の Outcome、タスクに HTML レポートがある場合はデリバリーのスナップショットまたはユーザーによる「スナップショットなし」の記録、そしてチャットでの報告です。スナップショットのパスを報告に記載します。変更のない照合では既存のデリバリーのスナップショットを再利用し、状態のみの変更は記録にとどめます。初回の結果、または実質的に新しい結果（判定、チェック、ファイル、完了状況の変更）には、新しい日付付きスナップショットを作成し、以前のスナップショットは上書きしません。codebase-map/scripts/task_report.py scaffold <approved review.json> <new delivery.json> を実行し、記録に基づいてすべての FILL: テキストと状態を記入します。表示内容に変更がある場合、安全であれば、構築した結果を実際にキャプチャします。保持方針：workflow/VISUAL-REVIEW.md。

軽微な編集：実際の規模に合わせて対応します。チェック内容、1つのレビュー、変更ファイルを1行の台帳に記録し、簡潔に報告します。チケットや機能全体のレビューは不要で、HTML スナップショットも作成しません。

ステージング、コミット、プッシュ、デプロイ、公開は一切行いません。