Planejamento e Detalhamento de Tarefas

Visão Geral

Decomponha o trabalho em tarefas pequenas e verificáveis com critérios de aceitação explícitos. Um bom detalhamento de tarefas é a diferença entre um agente que completa o trabalho de forma confiável e um que produz uma bagunça emaranhada. Cada tarefa deve ser pequena o suficiente para ser implementada, testada e verificada em uma única sessão focada.

Quando Usar

• Você tem uma especificação e precisa dividi-la em unidades implementáveis
• Uma tarefa parece grande ou vaga demais para começar
• O trabalho precisa ser paralelizado entre vários agentes ou sessões
• Você precisa comunicar o escopo a um humano
• A ordem de implementação não é óbvia

Quando NÃO usar: Alterações em um único arquivo com escopo óbvio, ou quando a especificação já contém tarefas bem definidas.

O Processo de Planejamento

Etapa 1: Entrar no Modo de Planejamento

Antes de escrever qualquer código, opere em modo somente leitura:

• Leia a especificação e as seções relevantes da base de código
• Identifique padrões e convenções existentes
• Mapeie dependências entre componentes
• Anote riscos e incertezas

NÃO escreva código durante o planejamento. A saída é um documento de plano salvo em tasks/plan.md e uma lista de tarefas registrada no destino da lista de tarefas (veja Arquivos de Saída; padrão tasks/todo.md), não a implementação.

Etapa 2: Identificar o Grafo de Dependência

Mapeie o que depende do quê:

Database schema
    │
    ├── API models/types
    │       │
    │       ├── API endpoints
    │       │       │
    │       │       └── Frontend API client
    │       │               │
    │       │               └── UI components
    │       │
    │       └── Validation logic
    │
    └── Seed data / migrations

A ordem de implementação segue o grafo de dependência de baixo para cima: construa as bases primeiro.

Etapa 3: Fatiar Verticalmente

Em vez de construir todo o banco de dados, depois toda a API, depois toda a interface do usuário — construa um caminho de funcionalidade completo de cada vez:

Ruim (fatiamento horizontal):

Task 1: Build entire database schema
Task 2: Build all API endpoints
Task 3: Build all UI components
Task 4: Connect everything

Bom (fatiamento vertical):

Task 1: User can create an account (schema + API + UI for registration)
Task 2: User can log in (auth schema + API + UI for login)
Task 3: User can create a task (task schema + API + UI for creation)
Task 4: User can view task list (query + API + UI for list view)

Cada fatia vertical entrega funcionalidade funcional e testável.

Etapa 4: Escrever Tarefas

Cada tarefa segue esta estrutura, quer caia na lista de tarefas em markdown ou como um item em um rastreador externo (veja Arquivos de Saída):

## Task [N]: [Short descriptive title]

**Description:** One paragraph explaining what this task accomplishes.

**Acceptance criteria:**
- [ ] [Specific, testable condition]
- [ ] [Specific, testable condition]

**Verification:**
- [ ] Tests pass: [the repository's focused-test command]
- [ ] Build succeeds: [the repository's build command]
- [ ] Manual check: [description of what to verify]

**Dependencies:** [Task numbers this depends on, or "None"]

**Files likely touched:**
- `src/path/to/file.ts`
- `tests/path/to/test.ts`

**Estimated scope:** [Small: 1-2 files | Medium: 3-5 files | Large: 5+ files]

Etapa 5: Ordenar e Pontuar

Organize as tarefas para que:

1. As dependências sejam satisfeitas (construa a base primeiro)
2. Cada tarefa deixe o sistema em um estado funcional
3. Pontos de verificação de verificação ocorram após cada 2-3 tarefas
4. Tarefas de alto risco sejam feitas cedo (falhe rápido)

Adicione pontos de verificação explícitos ao destino da lista de tarefas:

## Checkpoint: After Tasks 1-3
- [ ] All tests pass
- [ ] Application builds without errors
- [ ] Core user flow works end-to-end
- [ ] Review with human before proceeding

Diretrizes de Tamanho de Tarefa

Se uma tarefa for L ou maior, ela deve ser dividida em tarefas menores. Um agente tem melhor desempenho em tarefas S e M.

Quando dividir uma tarefa ainda mais:

• Levaria mais de uma sessão focada (aproximadamente 2+ horas de trabalho do agente)
• Você não consegue descrever os critérios de aceitação em 3 ou menos marcadores
• Toca em dois ou mais subsistemas independentes (por exemplo, autenticação e faturamento)

…