903111dd74
- knowledge/task-decomposition.md: 分解の可否判断基準、ファイル排他原則、 失敗パターン（パート重複・共有契約不整合）をドメイン知識として追加 - team-leader-implement instruction: 分解前に可否を判断するステップを追加。 横断的関心事・少ファイル・リファクタ系は1パートで実装するよう指示 - takt-default-team-leader.yaml: implement movement に task-decomposition ナレッジを追加
30 lines
1.9 KiB
Markdown
30 lines
1.9 KiB
Markdown
実装タスクを分析し、分解が適切なら複数パートに分けて並列実行してください。
|
||
|
||
**重要:** 計画レポートを参照してください: {report:plan.md}
|
||
|
||
**やること:**
|
||
|
||
1. 分解の可否を判断する
|
||
- 変更対象ファイルを特定し、ファイル間の依存関係を確認する
|
||
- 横断的関心事（共有型・ID・イベント）がある場合は分解せず1パートで実装する
|
||
- 変更ファイル数が少ない場合、リファクタ・リネーム系の場合も1パートで実装する
|
||
|
||
2. 分解する場合: ファイルをレイヤー/モジュール単位でグループ化する
|
||
- 凝集度の高い単位でグループを作る（例: ドメイン層 / インフラ層 / API層）
|
||
- 型・インターフェースの依存がある場合は、依存元と依存先を同じグループにまとめる
|
||
- 1つのファイルを複数のパートに割り当てない
|
||
- テストファイルと実装ファイルは同じパートにまとめる
|
||
|
||
3. 各パートに排他的なファイル担当を割り当てる
|
||
- 各パートの instruction に以下を必ず明記する：
|
||
- **担当ファイル**（作成・変更する対象ファイルのパス一覧）
|
||
- **参照専用ファイル**（変更禁止、読み取りのみ可）
|
||
- **実装内容**（何をどのように実装するか）
|
||
- **完了基準**（担当ファイルの実装が完了したこと）
|
||
- テスト済みの場合は「既存テストがパスするよう実装する」と明記する
|
||
- ビルドチェックは指示しない（他パートのファイルが揃ってから全体でまとめて確認するため）
|
||
|
||
**制約:**
|
||
- 各パートはテスト実行を行わない（後続ムーブメントで実施する）
|
||
- 担当外のファイルを変更しない（コンフリクトの原因になる）
|