903111dd74
- knowledge/task-decomposition.md: 分解の可否判断基準、ファイル排他原則、 失敗パターン（パート重複・共有契約不整合）をドメイン知識として追加 - team-leader-implement instruction: 分解前に可否を判断するステップを追加。 横断的関心事・少ファイル・リファクタ系は1パートで実装するよう指示 - takt-default-team-leader.yaml: implement movement に task-decomposition ナレッジを追加
67 lines
2.7 KiB
Markdown
67 lines
2.7 KiB
Markdown
# タスク分解知識
|
||
|
||
## 分解の可否判断
|
||
|
||
タスクを複数パートに分解する前に、分解が適切かを判断する。分解が不適切なケースでは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 の生成から消費まで一貫して実装
|
||
```
|