903111dd74
- knowledge/task-decomposition.md: 分解の可否判断基準、ファイル排他原則、 失敗パターン（パート重複・共有契約不整合）をドメイン知識として追加 - team-leader-implement instruction: 分解前に可否を判断するステップを追加。 横断的関心事・少ファイル・リファクタ系は1パートで実装するよう指示 - takt-default-team-leader.yaml: implement movement に task-decomposition ナレッジを追加
67 lines
2.5 KiB
Markdown
67 lines
2.5 KiB
Markdown
# 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
|
|
|
|
1. **By dependency direction** — keep dependency source and target in the same part
|
|
2. **By layer** — domain layer / infrastructure layer / API layer
|
|
3. **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
|
|
```
|