Task Planning

# Task Dependency Patterns

## Overview

Dependencies define task execution order and identify parallelization opportunities. Proper dependency modeling prevents race conditions and validates components exist before they're used.

## Dependency Types

### Sequential Dependencies

**Definition**: Task B cannot start until Task A completes

**When to Use**:
- Task B modifies output from Task A
- Task B requires interfaces/types defined in Task A
- Task B tests functionality implemented in Task A
- Tasks affect the same file(s)

**Example**:
```markdown
### TASK-002 - Define Task data model
**Dependencies**: TASK-001
**Files**: src/models/task.py

### TASK-003 - Implement task validation
**Dependencies**: TASK-002
**Files**: src/models/task.py, src/validators/task.py
```

**Reasoning**: Task validation requires the Task model to exist first. Both affect task.py, requiring sequential execution.

### Parallel Dependencies [P]

**Definition**: Tasks can execute concurrently with no conflicts

**When to Use**:
- No shared dependencies beyond a common foundation
- Operate on different files
- Independent feature implementations
- Separate test suites

**Marker**: Suffix task with `[P]`

**Example**:
```markdown
### TASK-004 - Implement user authentication [P]
**Dependencies**: TASK-001
**Files**: src/services/auth.py, tests/test_auth.py

### TASK-005 - Implement task storage [P]
**Dependencies**: TASK-001
**Files**: src/services/storage.py, tests/test_storage.py
```

**Reasoning**: Both depend on TASK-001 setup but operate on different files and can run concurrently.

### Fan-Out Pattern

**Definition**: Multiple tasks depend on single foundation task

**Pattern**:
```
TASK-001 (Foundation)
    ├─> TASK-002 [P]
    ├─> TASK-003 [P]
    └─> TASK-004 [P]
```

**Use Case**: After creating data models, implement multiple independent services

**Example**:
```markdown
### TASK-001 - Define API schemas
**Dependencies**: None
**Files**: src/types/api.ts

### TASK-002 - Implement user endpoints [P]
**Dependencies**: TASK-001
**Files**: src/routes/users.ts

### TASK-003 - Implement task endpoints [P]
**Dependencies**: TASK-001
**Files**: src/routes/tasks.ts

### TASK-004 - Implement project endpoints [P]
**Dependencies**: TASK-001
**Files**: src/routes/projects.ts
```

### Fan-In Pattern

**Definition**: Single task depends on multiple prerequisites

**Pattern**:
```
TASK-002 [P] ─┐
TASK-003 [P] ─┼─> TASK-005
TASK-004 [P] ─┘
```

**Use Case**: Integration task requiring multiple components

**Example**:
```markdown
### TASK-002 - Implement auth service [P]
**Dependencies**: TASK-001
**Files**: src/services/auth.py

### TASK-003 - Implement storage service [P]
**Dependencies**: TASK-001
**Files**: src/services/storage.py

### TASK-004 - Implement notification service [P]
**Dependencies**: TASK-001
**Files**: src/services/notifications.py

### TASK-005 - Integrate services in workflow
**Dependencies**: TASK-002, TASK-003, TASK-004
**Files**: src/workflow/coordinator.py
```

## File Coordination Rules

### Same-File Modification

**Rule**: Tasks modifying the same file must execute sequentially

**Example**:
```markdown
### TASK-006 - Add base Task class
**Files**: src/models/task.py

### TASK-007 - Add Task validation methods
**Dependencies**: TASK-006
**Files**: src/models/task.py
```

**Reasoning**: Prevents merge conflicts and validates clean incremental changes.

### Same-Directory Independence

**Rule**: Tasks creating different files in same directory can run in parallel

**Example**:
```markdown
### TASK-008 - Create user model [P]
**Files**: src/models/user.py

### TASK-009 - Create task model [P]
**Files**: src/models/task.py
```

**Reasoning**: No file conflicts, different models, independent implementations.

### Test-Implementation Pairing

**Rule**: Implementation and its tests are typically sequential

**Example**:
```markdown
### TASK-010 - Implement resolver logic
**Files**: src/services/resolver.py

### TASK-011 - Add resolver i