# タスク分解知識

## 分解の可否判断

タスクを複数パートに分解する前に、分解が適切かを判断する。分解が不適切なケースでは1パートで実装する方が効率的。

| 基準 | 判定 |
|------|------|
| 変更ファイルが明確にレイヤー分離できる | 分解可 |
| 共有する型・IDが複数パートをまたぐ | 1パートで実装 |
| 広範囲のリネーム・リファクタ | 1パートで実装 |
| 変更ファイル数が5未満 | 1パートで実装 |
| 同一ファイルを複数パートが触る必要がある | 1パートで実装 |

### 横断的関心事の検出

以下に該当する場合、独立パートでは整合性を保てない。1パートにまとめる。

- 新しいID・キー・型を生成し、別のモジュールで消費するフロー
- イベント発火側と受信側の両方を変更する
- 既存インターフェースのシグネチャを変更し、全呼び出し元を更新する

## ファイル排他の原則

複数パートに分解する場合、各パートの担当ファイルは完全に排他的でなければならない。

| 基準 | 判定 |
|------|------|
| 同一ファイルを複数パートが編集 | REJECT（コンフリクトの原因） |
| 型定義と利用側が別パート | 型定義側のパートにまとめる |
| テストファイルと実装ファイルが別パート | 同じパートにまとめる |

### グループ化の優先順位

1. **依存方向で分ける** — 依存元と依存先は同じパートに
2. **レイヤーで分ける** — ドメイン層 / インフラ層 / API層
3. **機能で分ける** — 独立した機能単位

## 失敗パターン

### パート重複

2つのパートが同じファイルや同じ機能を担当すると、サブエージェントが互いの変更を上書きし、レビューで繰り返しREJECTされる。

```
// NG: part-2 と part-3 が同じファイルを担当
part-2: taskInstructionActions.ts — instruct機能の確認ダイアログ
part-3: taskInstructionActions.ts — requeue機能の確認ダイアログ

// OK: 1パートにまとめる
part-1: taskInstructionActions.ts — instruct/requeue両方の確認ダイアログ
```

### 共有契約の不整合

パートAが生成するIDをパートBが消費する設計では、両パートが独立に実装するため、ID名・型・受け渡し方法に不整合が生じる。

```
// NG: 独立パートで共有契約
part-1: phaseExecutionId を生成
part-2: phaseExecutionId を受け取って使う
→ part-1 は string、part-2 は number を期待 → 統合エラー

// OK: 1パートで一貫実装
part-1: phaseExecutionId の生成から消費まで一貫して実装
```