Disponibilidade de Material de Apoio

Esta cópia do catálogo contém as orientações inline abaixo, mas não inclui os seguintes caminhos de suporte. Eles são pré-requisitos externos, não arquivos empacotados:

• <support-root>/references/definition-of-done.md

Obtenha o material necessário da fonte upstream declarada ou de uma instalação fornecida pelo usuário dessa fonte. Resolva cada caminho em relação a essa instalação, inspecione seu conteúdo e verifique quaisquer licenças aplicáveis e pré-requisitos de execução. Não execute um comando nem afirme que um procedimento referenciado foi seguido até que seu arquivo necessário exista. Não fabrique os scripts ausentes nem trate um arquivo não relacionado com o mesmo nome como equivalente. Etapas independentes totalmente documentadas aqui podem prosseguir dentro do escopo autorizado do usuário; relate qualquer etapa dependente como indisponível.

Planejamento e Quebra de Tarefas

Visão Geral

Decomponha o trabalho em tarefas pequenas e verificáveis com critérios de aceitação explícitos. Uma boa quebra de tarefas é a diferença entre um agente que conclui 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 muito grande ou vaga 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, não 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:

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

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

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

**Verification:**
- [ ] Tests pass: `npm test -- --grep "feature-name"`
- [ ] Build succeeds: `npm run build`
- [ ] 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 de forma que:

1. As dependências sejam satisfeitas (construa a base primeiro)
2. Cada tarefa deixe o sistema em 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 (falhar rapidamente)

Adicione pontos de verificação explícitos:

## 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 Dimensionamento de Tarefas

…