903111dd74
- knowledge/task-decomposition.md: 分解の可否判断基準、ファイル排他原則、 失敗パターン（パート重複・共有契約不整合）をドメイン知識として追加 - team-leader-implement instruction: 分解前に可否を判断するステップを追加。 横断的関心事・少ファイル・リファクタ系は1パートで実装するよう指示 - takt-default-team-leader.yaml: implement movement に task-decomposition ナレッジを追加
2.5 KiB
2.5 KiB
Task Decomposition Knowledge
Decomposition Feasibility
Before splitting a task into multiple parts, assess whether decomposition is appropriate. When decomposition is unsuitable, implementing in a single part is more efficient.
| Criteria | Judgment |
|---|---|
| Changed files clearly separate into layers | Decompose |
| Shared types/IDs span multiple parts | Single part |
| Broad rename/refactoring | Single part |
| Fewer than 5 files to change | Single part |
| Same file needs editing by multiple parts | Single part |
Detecting Cross-Cutting Concerns
When any of the following apply, independent parts cannot maintain consistency. Consolidate into a single part.
- A new ID, key, or type is generated in one module and consumed in another
- Both the event emitter and event receiver need changes
- An existing interface signature changes, requiring updates to all call sites
File Exclusivity Principle
When decomposing into multiple parts, each part's file ownership must be completely exclusive.
| Criteria | Judgment |
|---|---|
| Same file edited by multiple parts | REJECT (causes conflicts) |
| Type definition and consumer in different parts | Consolidate into the type definition part |
| Test file and implementation file in different parts | Consolidate into the same part |
Grouping Priority
- By dependency direction — keep dependency source and target in the same part
- By layer — domain layer / infrastructure layer / API layer
- By feature — independent functional units
Failure Patterns
Part Overlap
When two parts own the same file or feature, sub-agents overwrite each other's changes, causing repeated REJECT in reviews.
// NG: part-2 and part-3 own the same file
part-2: taskInstructionActions.ts — instruct confirmation dialog
part-3: taskInstructionActions.ts — requeue confirmation dialog
// OK: consolidate into one part
part-1: taskInstructionActions.ts — both instruct/requeue confirmation dialogs
Shared Contract Mismatch
When part A generates an ID that part B consumes, both parts implement independently, leading to mismatches in ID name, type, or passing mechanism.
// NG: shared contract across independent parts
part-1: generates phaseExecutionId
part-2: consumes phaseExecutionId
→ part-1 uses string, part-2 expects number → integration error
// OK: single part for consistent implementation
part-1: implements phaseExecutionId from generation to consumption