# タスク分解ポリシー

並列パートの分解品質を保証する。

## 原則

| 原則 | 基準 |
|------|------|
| 分解可否の明示判断 | 分解前にナレッジの基準テーブルを評価し、判定結果を明記する |
| ファイル排他 | 1ファイルは1パートのみが担当する。例外なし |
| 依存の方向 | パート間に依存がある場合は同一パートにまとめる |
| テストと実装の同居 | テストファイルと対応する実装ファイルは同じパートに割り当てる |
| 品質ゲートは集約パート | ビルド・テスト実行は全パートの成果を集約するパートで行う |

## ファイル排他

同一ファイルを複数パートが編集すると、サブエージェントが互いの変更を上書きする。

| 基準 | 判定 |
|------|------|
| 同一ファイルが複数パートの担当に含まれる | REJECT |
| 型定義ファイルと利用側ファイルが別パート | REJECT（型定義側のパートにまとめる） |
| 担当ファイルが「失敗時に必要に応じて触る」等の不定表現 | REJECT（事前に確定する） |
| テストファイルと実装ファイルが別パート | REJECT |
| ワイルドカード指定（`src/**/*`）で他パートの担当と重複する | REJECT |

## 分解不可の条件

以下に該当する場合は1パートで実装する。分解してはならない。

| 基準 | 判定 |
|------|------|
| 広範囲のリネーム・リファクタ | 1パートで実装 |
| 共有する型・IDが複数パートをまたぐ | 1パートで実装 |
| 変更ファイル数が5未満 | 1パートで実装 |
| 既存インターフェースのシグネチャ変更 + 全呼び出し元の更新 | 1パートで実装 |

## 品質ゲートパート

ビルド・テスト実行を担当するパートは、実装パートとは異なるルールに従う。

| 基準 | 判定 |
|------|------|
| 品質ゲートパートが実装パートのファイルを担当に含む | REJECT |
| 品質ゲートが複数パートに分かれている | REJECT（1パートにまとめる） |
| 品質ゲートパートの修正範囲が「何でも触る」 | REJECT（修正対象ファイルを事前に限定する） |

## 禁止事項

- **分解可否判断のスキップ** - ナレッジの基準テーブルを評価せず分解する
- **同一ファイルの複数パート割り当て** - ワイルドカード指定を含む
- **依存関係のある変更の分離** - 型定義と利用側、イベント発火側と受信側を別パートにする
- **担当ファイル不定のパート** - 「失敗時に触る」「必要に応じて修正」等の曖昧な割り当て

## task-decomposition 判定基準

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

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