# タスク分解知識

## 分解の可否判断

タスクを複数パートに分解する前に、責務、共有状態、依存順序、検証可能性から分解が適切かを判断する。ここではその背景を説明する。

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


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

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

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

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

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

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

## 失敗パターン

### パート重複

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

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

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

### 共有契約の不整合

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

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

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