Parallel Feature Development

# File Ownership Decision Framework

How to assign file ownership when decomposing features for parallel development.

## Ownership Decision Process

### Step 1: Map All Files

List every file that needs to be created or modified for the feature.

### Step 2: Identify Natural Clusters

Group files by:

- Directory proximity (files in the same directory)
- Functional relationship (files that import each other)
- Layer membership (all UI files, all API files)

### Step 3: Assign Clusters to Owners

Each cluster becomes one implementer's ownership boundary:

- No file appears in multiple clusters
- Each cluster is internally cohesive
- Cross-cluster dependencies are minimized

### Step 4: Define Interface Points

Where clusters interact, define:

- Shared type definitions (owned by lead or a designated implementer)
- API contracts (function signatures, request/response shapes)
- Event contracts (event names and payload shapes)

## Ownership by Project Type

### React/Next.js Frontend

```
implementer-1: src/components/{feature}/   (UI components)
implementer-2: src/hooks/{feature}/        (custom hooks, state)
implementer-3: src/api/{feature}/          (API client, types)
shared:        src/types/{feature}.ts      (owned by lead)
```

### Express/Fastify Backend

```
implementer-1: src/routes/{feature}.ts, src/controllers/{feature}.ts
implementer-2: src/services/{feature}.ts, src/validators/{feature}.ts
implementer-3: src/models/{feature}.ts, src/repositories/{feature}.ts
shared:        src/types/{feature}.ts      (owned by lead)
```

### Full-Stack (Next.js)

```
implementer-1: app/{feature}/page.tsx, app/{feature}/components/
implementer-2: app/api/{feature}/route.ts, lib/{feature}/
implementer-3: tests/{feature}/
shared:        types/{feature}.ts          (owned by lead)
```

### Python Django

```
implementer-1: {app}/views.py, {app}/urls.py, {app}/forms.py
implementer-2: {app}/models.py, {app}/serializers.py, {app}/managers.py
implementer-3: {app}/tests/
shared:        {app}/types.py              (owned by lead)
```

## Conflict Resolution

When two implementers need to modify the same file:

1. **Preferred: Split the file** — Extract the shared concern into its own file
2. **If can't split: Designate one owner** — The other implementer sends change requests
3. **Last resort: Sequential access** — Implementer A finishes, then implementer B takes over
4. **Never**: Let both modify the same file simultaneously


# Integration and Merge Strategies

Patterns for integrating parallel work streams and resolving conflicts.

## Integration Patterns

### Pattern 1: Direct Integration

All implementers commit to the same branch; integration happens naturally.

```
feature/auth ← implementer-1 commits
             ← implementer-2 commits
             ← implementer-3 commits
```

**When to use**: Small teams (2-3), strict file ownership (no conflicts expected).

### Pattern 2: Sub-Branch Integration

Each implementer works on a sub-branch; lead merges them sequentially.

```
feature/auth
  ├── feature/auth-login     ← implementer-1
  ├── feature/auth-register  ← implementer-2
  └── feature/auth-tests     ← implementer-3
```

Merge order: follow dependency graph (foundation → dependent → integration).

**When to use**: Larger teams (4+), overlapping concerns, need for review gates.

### Pattern 3: Trunk-Based with Feature Flags

All implementers commit to the main branch behind a feature flag.

```
main ← all implementers commit
     ← feature flag gates new code
```

**When to use**: CI/CD environments, short-lived features, continuous deployment.

## Integration Verification Checklist

After all implementers complete:

1. **Build check**: Does the code compile/bundle without errors?
2. **Type check**: Do TypeScript/type annotations pass?
3. **Lint check**: Does the code pass linting rules?
4. **Unit tests**: Do all unit tests pass?
5. **Integration tests**: Do cross-component tests pass?
6. **Interface verification**: Do all interface