# タスク分解知識

## 分解の可否判断

タスクを複数パートに分解する前に、分解が適切かを判断する。分解不可の条件と REJECT 基準はタスク分解ポリシーで定義されている。ここではその背景を説明する。

### 判断基準テーブル（背景説明）

| 観点 | 検出パターン | 推奨判定 | 背景（なぜ） |
|------|--------------|----------|--------------|
| 共有契約（ID/型） | あるパートで新規ID・型を定義し、別パートで参照する | 分解しない（1パート） | 生成側と利用側で型・命名・受け渡しの不整合が発生しやすい |
| イベント連鎖 | 発火側と受信側を同時に変更する必要がある | 分解しない（1パート） | 双方向の前提がずれると実行時不整合を起こす |
| インターフェース変更 | 既存シグネチャ変更 + 複数呼び出し元更新が必要 | 分解しない（1パート） | 呼び出し元の更新漏れが起きるとビルド/実行時エラーになる |
| ファイル担当の重複 | 同一ファイルを複数パートが担当している | 分解しない（設計を再編） | 変更の上書き競合によりレビューで反復REJECTになりやすい |
| 層の独立性 | API/Domain/Infra が明確に分かれ、依存方向が単方向 | 分解してよい | 変更境界が明確でパート間結合が低い |

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

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

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

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

分解する場合、ファイルをどうグループ化するかの判断基準。

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 の生成から消費まで一貫して実装
```
