{{include:instructions/repair-plan-path-check}}
{{include:instructions/fix-root-cause-analysis}}
{{include:instructions/fix-plan-validity}}

**やること:**
1. 全修正対象と受入条件を列挙し、各指摘を漏れなく1つの修正または後続確認へ対応付けてください
2. 独立した問題、同じ原因を共有する問題、現在の環境では実証できない事項を分けてください。環境要因として実装修正から除外できるのは、タスクに除外条件が示され、その全条件を満たす場合だけです
3. 適用中のポリシーは表示が途中で切られています。修正境界と持ち越しを判断する前に、示されたパスのポリシーファイルを先頭から末尾まで読み、修正境界・持ち越し・除外に関する規則を確認してください
4. 各問題について、原因、破られる観測可能な条件、受入条件、条件を定める箇所、実際に影響する経路を確認してください。実在する入口から観測結果までコードを追い、独立して成否を確認できる経路は代表例で代用せず分けてください。同じ原因で変更が必要な経路は1つの修正として扱い、隣接する別契約と区別してください
5. 修正後も同じ問題が残った場合は、前回確認しなかった経路、誤った原因判断、局所的すぎた変更、検証不足のどれがあったかを確認してください。共通の定義元や検証箇所を直す必要がコードから確認できる場合は、場所ごとの追加修正ではなく、そこで問題を防ぐ計画にしてください
6. 修正間の依存順と完了条件を定め、定義元の変更、利用側の移行、不要になった経路の削除を途中で分断しないでください
7. 各修正方法が原因と受入条件に合うか確認してください
   - 受入条件に関わる結果ごとに、その結果が使う入力や状態をすべて挙げる
   - 入力や状態がそれぞれ単独で結果を変えられるなら、同じ結果につながっていても別の経路にする
   - 各経路について、入力や状態がどこで決まり、入口から結果までどの関数を通るかを書く
   - 具体的な入力または状態と期待結果を、確認する値を省略せず書く
   - その経路が使う入力または状態を1つだけ変え、同じ入口から見える結果も変わることを、変更前後で書く。これを反例とする
   - すべての経路に成立例と反例を1組ずつ用意する。別の経路だけを変えた確認や、成立例の繰り返しは反例にしない
   確認できない経路が残っている場合は、その経路を計画内の具体的な調査と、その結果に応じた安全な修正・検証として実行できる形にしてください。現行の要求・範囲・方法では調査も後続作業も実行できない場合だけ、計画を確定しないでください。品質ゲートのコマンドは計画に列挙せず、実装時に提供される指示へ従ってください
8. 実装方法を確定する前に、その方法が前提とする原因を確認してください。計画確定時に原因を確定できない場合は、固定条件、比較する1条件、観測対象、実行方法、結果に応じた修正・検証を最初の修正単位として具体化してください。確認できた事実、原因の候補、採用した原因の根拠、否定した原因を分けてください。並行実行、共有資源、実行タイミングを原因とする場合は、条件を揃えた反復、1条件だけを変えた比較、失敗した処理の追跡、ログまたは計測で切り分けてください。単独実行の成功や、問題を避ける変更後の成功だけでは原因を確定しないでください
9. 並行度、タイムアウト、再試行、テスト対象、公開契約を変える方法は、原因との関係と受入条件上の必要性を確認できる場合だけ採用してください。問題を避けるだけの変更を根本修正にしないでください
10. 原因または安全な修正方法を計画内の調査で確認できる場合は、その調査を最初の修正単位に含めてください。調査方法を定義できない、または調査結果から安全な修正・検証へ進めず、計画変更で具体的なプロジェクト内作業が可能になる場合だけ計画を確定せず、必要な判断を示してください