{{include:instructions/task-decomposition-boundary}}
{{include:instructions/team-leader-part-error-completion}}

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

**重要:** 元のタスク、入力に明示された上流成果物、以下で engine が渡す前ステップの応答を一次情報として使用してください。親 Team Leader 自身はツールを使わず、これらにない事実を補完しません。

{previous_response}

**やること:**

1. 分解の可否を判断する
   - 変更対象ファイルを特定し、ファイル間の依存関係を確認する
   - まず並行可能な責務境界を探す
   - 横断的関心事（共有型・ID・イベント）がある場合は、依存する作業を1つの part にまとめる
   - 変更ファイル数が少ない場合、リファクタ・リネーム系の場合も1パートで実装する
   - `parts.length === 1` になる場合も、独立に実行できる責務境界がないか先に検討する
   - 「実装と検証」のような巨大な単一 part は避ける

2. 分解する場合: ファイルをレイヤー/モジュール単位でグループ化する
   - 凝集度の高い単位でグループを作る（例: ドメイン層 / インフラ層 / API層）
   - 型・インターフェースの依存がある場合は、依存元と依存先を同じグループにまとめる
   - 1つのファイルを複数のパートに割り当てない
   - テストファイルと実装ファイルは同じパートにまとめる
   - 同じバッチ内の各 part は単独で実行可能にする

3. 各パートに排他的なファイル担当を割り当てる
   - 各パートの instruction に以下を必ず明記する：
     - **担当ファイル**（作成・変更する対象ファイルのパス一覧）
     - **参照専用ファイル**（変更禁止、読み取りのみ可）
     - **実装内容**（何をどのように実装するか）
     - **完了基準**（担当ファイルの実装が完了したこと）
     - **上流の完了義務と証拠条件**（担当範囲に必要な内容を本文で渡し、入力に既存IDがあればその意味とIDを維持する。partへの親計画の自動継承は前提にしない）
   - テスト済みの場合は「既存テストがパスするよう実装する」と明記する
   - 品質ゲート（Quality Gates）を参照し、必要な検証は後続の feedback batch で計画する
   - 並列の実装パートには、全体ビルド・全体テストを重複して実行させない
   - npm test / npm run test:e2e:mock は各実装 part に重複して持たせない

**制約:**
- 同じバッチ内で別の part に依存する part を作らない。scheduler は独立に実行可能な part を開始し、現在のバッチ完了後にだけ次のバッチを要求する
- テストやビルドが必要な場合は、実装結果がそろった後の feedback batch で要求する
- 担当外のファイルを変更しない（コンフリクトの原因になる）