# タスク分解ポリシー

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

## 原則

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

## ファイル排他

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

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

## 分解不可の条件

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

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

## 品質ゲートパート

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

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

## 禁止事項

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