実装タスクを分析し、分解が適切なら複数パートに分けて並列実行してください。

**重要:** 計画レポートを参照してください: {report:plan.md}

**やること:**

1. 分解の可否を判断する
   - 変更対象ファイルを特定し、ファイル間の依存関係を確認する
   - 横断的関心事（共有型・ID・イベント）がある場合は分解せず1パートで実装する
   - 変更ファイル数が少ない場合、リファクタ・リネーム系の場合も1パートで実装する

2. 分解する場合: フロントエンドとバックエンドでの分割を優先的に検討する
   - **デザイン参照があり、バックエンド変更が明示要件でない場合は分解しない。** UI の見た目・構造・文言・間隔は相互依存が強く、分割すると忠実再現を壊しやすいため、1パートでまとめて実装する
   - **デザイン参照がある場合、同一画面を構成する UI コンポーネント群は同じパートにまとめる。** ヘッダー・フィルタ・カード・バナー・モーダルなど、見た目の整合性に関わる要素を別パートへ分散しない
   - フロントエンド（UI・コンポーネント・スタイル）とバックエンド（API・ロジック・データ層）で分けるのが最も自然な分割軸
   - API契約（リクエスト/レスポンスの型）が決まっている場合は並列実装に適している
   - API契約が未確定の場合はバックエンドを先に1パートで実装し、フロントエンドは後続にする
   - フロントエンドのみ、バックエンドのみのタスクの場合はレイヤー/モジュール単位でグループ化する
   - 型・インターフェースの依存がある場合は、依存元と依存先を同じグループにまとめる
   - 1つのファイルを複数のパートに割り当てない
   - テストファイルと実装ファイルは同じパートにまとめる

3. 各パートに排他的なファイル担当を割り当てる
   - 各パートの instruction に以下を必ず明記する：
     - **担当ファイル**（作成・変更する対象ファイルのパス一覧）
     - **参照専用ファイル**（変更禁止、読み取りのみ可）
     - **実装内容**（何をどのように実装するか）
     - **完了基準**（担当ファイルの実装が完了したこと）
   - デザイン参照がある場合、各パートの instruction に以下も必ず明記する：
     - **参照デザイン**（どのファイルを一次情報として使うか）
     - **照合対象要素**（レイアウト、文言、色、間隔、導線）
   - テスト済みの場合は「既存テストがパスするよう実装する」と明記する
   - 品質ゲート（Quality Gates）を参照し、必要な検証は専用の単独パートとして計画する
   - 並列の実装パートには、全体ビルド・全体テストを重複して実行させない

**制約:**
- テストやビルドが必要な場合は、他パートの変更が揃った後に、単独の検証パートで実行する
- 担当外のファイルを変更しない（コンフリクトの原因になる）
