workflow-execute

ワークフローの実行

承認済みのチケットを、各チケットの検証が完了するまで実装し、その後、機能全体をレビューします。

隣接する ../workflow/ から、「Always」リストを含む共通ポリシーを読み込みます。見つからない場合は停止してください。インストール済みの別のコピーで代用してはいけません。

着手前に、以下を確認します。

• ルールが次のチケットを対象としていること（workflow/RULES.md）。
• チェックポイントの Approval が承認済みであること、またはレガシー扱いであるか、これらのチケットを対象とする明示的な免除があること。合意だけでは、コード作成は決して許可されません。workflow-specify に進んでください。
• チケットに依存関係、受け入れ基準、境界、スコープがあること（ない場合は workflow-specify）。
• チケットが指定する任意のスペシャリスト（workflow/SPECIALISTS.md）がインストールされていること。不在の場合、そのチケットのみがブロックされます。
• git status と差分が記録されていること（workflow/TASK-FOLDER.md）。
• UI チケットでは、その ui-design の権限が記録されていること。記録されていない場合は保留します。UI チケットに着手する前に ../ui-design/SKILL.md のステップ 4 を読んでください。

不足している権限、重大な変更、またはブロッカーがある場合に限り、再確認します。

ループ

チケットの準備が整っており、オーナーから停止、一時停止、キャンセルの指示がない間は繰り返します（その場合は workflow/TASK-FOLDER.md の「Stop, pause and cancel」に従ってください）。承認済みのワーカー数／チェック予算を使用してください。有償の評価では、VISUAL-REVIEW.md の明示的な予算ルールにも従います。並行作業には、独立したチケットと別々のファイルが必要です。実行する数を伝えてください。未使用の枠を埋めてはいけません。

1. 選択。 現在のファイル上で V-ID を使って依存関係が検証されているチケットは、準備が整っています。ブロックされたチケットがブロックするのは、その依存チケットだけです。
2. チェックポイント。 チケット、そのファイル、チェックを保存します。変更を加える前に、計画したベースラインチェックを実行するか、入力が現在も一致するベースラインを再利用します（TASK-FOLDER「Baseline before this change」）。各失敗テストの名前と最初のエラー行を記録し、件数だけにしないでください。
3. ルートの選択。 小規模ルート：チケットは1つ、指定ファイルのみ、インターフェース、依存関係、データ、セキュリティの変更はありません。ここで実装し、その旨を伝えてください。サブエージェントを使わない場合は、すべてのチケットをここで実装します。それ以外の場合は、チケット、受け入れ条件、境界、許可されたファイル、ルール、UI の権限、出力フォルダー、開始時の git status を伝えた新しいワーカーに各チケットを引き継ぎます。ワーカーは証拠を返し、記録はあなたが作成します。未記載のファイル、2つ目の呼び出し元、インターフェースまたはデータの変更、無関係な失敗、重大な指摘、ユーザーの判断が発生したチケットは、小規模ルートから外して再評価します。「人間の対応が必要」な手順は、1つの依頼にまとめてください。
4. 実装。 TDD チケット：最初のテストの前に ../tdd/SKILL.md を読み、合意した境界で従ってください。赤／緑のループはこの文書が定めます。ドキュメントまたは設定のチケット：指定された契約を確認し、実際には行っていない赤／緑を報告してはいけません。動作はその所有者のもとに置き、AUDIT.md の必要性チェックを適用し、指定されたドキュメントを更新し、チケットで置き換えるものは削除してください。
5. 検証。 チケットのチェックを実行し、コマンド、結果、制限事項を含む V-ID を記録します。UI チケットでは ui-design の VERIFY.md も実行してください。デザインの受け入れ確認は別に行います。長い出力は一度だけ保存して検索し、必要な失敗の証拠を ARTIFACTS.md に従って保持します。すべての再試行を無期限に保持してはいけません。workflow/scripts/compare_failures.py で失敗を名前ごとに比較します（1行につき id<TAB>first error line を1つ）：同じテストが同じ形で失敗した場合に限り、既存の失敗とします。環境による失敗はそのように明記してください。テストを弱めて合格させてはいけません。
6. レビュー。 Standards と Spec を分けてレビューします。レビュアーには workflow/AUDIT.md が選ぶものを使います。コードには ../code-review/SKILL.md（ホストに組み込まれている同名の機能は使わないでください）、スキル、指示、ドキュメントには ../writing-for-agents/SKILL.md と AUDIT のカテゴリを使います。ホストがサブエージェントに対応している場合は、新しいサブエージェント1つが該当ファイルを読んで両方の観点をレビューします。サブエージェントがいない場合に限り自己レビューを行い、その旨を明記します。前回のレビュー以降に変更されていない差分を再レビューしてはいけません。
7. 修正。 範囲内で指摘事項を修正します。コードまたはテストの修正は、修正差分のみを同じレビュアーに再レビューしてもらいます。記録または文言の修正は、自分で確認して記録します。レビュアーがユーザーの判断を必要とするとする指摘、または承認済みの方針やユーザーが気づく内容を変更する修正は、リリース前にユーザーに確認します。それ以外のチケットは続行します。新たな権限が必要な指摘、進展のない修正が2回続いた場合、またはレビュアーが2回失敗した場合は、その理由を添えてチケットをブロック状態にします。
8. 完了。 最後の修正後、必須のデバイス／人間によるチェックを含め、現在の受け入れチェックをすべて検証します。証拠が不足している場合は、検証保留のままにします。ステータスは簡潔にし、証拠へのリンクを付けます。削除した作業には判断の記録が必要であり、テスト合格のラベルを付けてはいけません。
9. 統合。 依存チケットを開始する前に、検証済みチケットグループの統合チェックを実行します。

機能全体のレビュー

すべてのチケットが検証済み、または合格なしで明示的にクローズされたら、同じレビュアー選定に加え、他の呼び出し元、失敗時の経路、クリーンアップ、記録に関する AUDIT のチェックを用いて、変更全体を合意内容と照らし合わせてレビューします。ループと同様に修正し、再確認します。チケットごとのレビューはこのレビューの代わりにはなりません。最後のチケットのレビュー時にこれらのチェックについて説明しておけば、そのレビュー後に他のチケットが変更されていない限り、全体レビューも兼ねます。

承認済みで実行可能なものが何もない場合は、ブロッカーを添えて部分的な成果を提出します。待機中は検証済みではありません。レビューと修正のループを再開しないでください。

途中で変更が見つかった場合

動作、スコープ、インターフェース、依存関係、リスク、または保護対象領域に重要な変更があった場合、影響を受けるチケットのみを一時停止します。動作は workflow-clarify に戻し、チケットは workflow-specify に戻します。それ以外のチケットは続行します。インフラが不足している場合はブロッカーとし、自分でインストールしないでください。

次のステップ

続いて、チケット一覧、V-ID、レビュー、ブロック中のチケットを添えて workflow-deliver を呼び出します。停止、一時停止、キャンセルの場合も、部分的な成果としてラベルを付けて workflow-deliver に渡し、オーナーから続行を求められない限り、ここには戻りません。workflow-deliver が実行された時点でのみ、実行は完了です。

Implement Spec をローカルに適用するものであり、その呼び出し方を変更するものではありません。別途権限がない限り、Git／トラッカーの操作や専門家による編集は行いません。