タスクを分析し、設計を含めた実装方針を立ててください。

**注意:** Previous Responseがある場合は差し戻しのため、
その内容を踏まえて計画を見直してください（replan）。

**小規模タスクの判断基準:**
- 1-2ファイルの変更のみ
- 設計判断が不要
- 技術選定が不要

小規模タスクの場合は設計セクションを省略してください。

{{include:instructions/planning-path-check}}
{{include:instructions/change-contract-traceability}}

{{include:instructions/requirement-source-discipline}}

**やること:**
1. **参照資料の読み込み（必須・最初に実行）**
   - タスク指示書の「参照資料」セクションに記載されたファイル・ディレクトリを **Read/Glob で実際に開いて内容を確認する**
   - ディレクトリが指定されている場合は中身を列挙し、該当ファイルを特定してから読む
   - 参照資料が存在しない・見つからない場合はその旨を報告し、推測で代用しない
   - **指示書に明記されていない別ファイルを「参照資料の代わり」として使うことは禁止**
2. **適用基準の反映**
   - 共通手順で `適用` に分類した制約と避けるべきアンチパターンを、実装アプローチと Coder 向け実装ガイドラインへ反映する
3. タスクの要件を理解する
   - **明示された目的・制約・受入条件を固定し、実装しやすい別問題へ読み替えない。例示された手段は、要求が方法を固定しているのか、達成方法の候補なのかを区別する**
   - 参照資料の内容と現在の実装を突き合わせて差分を特定する
   - **参照資料が外部実装を指す場合、「バグ修正の手がかり」か「採用すべき設計アプローチ」かを判断する。スコープを参照資料の意図より狭める場合は判断根拠を計画レポートに含めること**
   - **要件ごとに「変更要/不要」を判定する。「不要」の場合は現行コードの該当箇所（ファイル:行）を根拠として示すこと。根拠なしの「既に正しい」は禁止**
4. コードを調査して不明点を解決する
   - ファイル参照は作業ディレクトリからの相対パスで記載し、ホームディレクトリやworktreeの絶対パスを回答・レポートへ含めない
5. 影響範囲を特定する
   - 各契約IDの実装箇所と検証箇所を特定する。影響経路を持つ契約だけ、生成元から最終消費元までの関係する経路を列挙する
   - 対象機能がシステム内で担う役割と、入口、信頼境界、状態・権限・副作用の所有者を確認する
   - 利用者・外部入力、認可、機密情報、外部実行、永続化、再試行、並行実行が実際に関係する場合だけ、その検証・拒否・失敗時処理を影響範囲に含める。関係しない観点を機械的に追加しない
6. ファイル構成・設計パターンを決定する（必要な場合）
7. 実装アプローチを決める
   - 判断基準・判断材料が提供されている場合は、共通手順で `適用` に分類したものだけを照合する
   - 差分を小さくすることと、必要な本番処理を省くことを混同しない。要件成立に必要な検証、認可、状態更新、エラー処理、後片付けは、関係する実行経路へ組み込む
   - 利用者向け機能の追加や変更がある場合、利用者がその機能へ到達する条件・入口・起動経路を固定する
8. Coder向けの実装ガイドラインに以下を含めること:
   - 参照すべき既存実装パターン（ファイル:行）。同種の処理が既にある場合は必ず示す
   - 変更の影響範囲。特に新しいパラメータを追加する場合、配線が必要な全箇所を列挙する
   - このタスクで特に注意すべきアンチパターン（該当するものがあれば）
   - 利用者向け機能の追加や変更がある場合、到達経路・呼び出し元・起動条件に関する変更箇所