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. 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 e pré-requisitos de execução aplicáveis. 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.

Implementação Incremental

Visão Geral

Construa em fatias verticais finas — implemente uma parte, teste-a, verifique-a e, em seguida, expanda. Evite implementar um recurso inteiro de uma vez. Cada incremento deve deixar o sistema em um estado funcional e testável. Esta é a disciplina de execução que torna recursos grandes gerenciáveis.

Quando Usar

• Implementando qualquer alteração em vários arquivos
• Construindo um novo recurso a partir de uma divisão de tarefas
• Refatorando código existente
• Sempre que você for tentado a escrever mais de ~100 linhas antes de testar

Quando NÃO usar: Alterações em um único arquivo, em uma única função, onde o escopo já é mínimo.

O Ciclo de Incremento

┌──────────────────────────────────────┐
│                                      │
│   Implement ──→ Test ──→ Verify ──┐  │
│       ▲                           │  │
│       └───── Commit ◄─────────────┘  │
│              │                       │
│              ▼                       │
│          Next slice                  │
│                                      │
└──────────────────────────────────────┘

Para cada fatia:

1. Implemente a menor peça de funcionalidade completa
2. Teste — execute o conjunto de testes (ou escreva um teste se nenhum existir)
3. Verifique — confirme se a fatia funciona como esperado (testes passam, compilação bem-sucedida, verificação manual)
4. Commite — salve seu progresso com uma mensagem descritiva (veja git-workflow-and-versioning para orientação sobre commits atômicos)
5. Passe para a próxima fatia — avance, não reinicie

Estratégias de Fatiamento

Fatias Verticais (Preferencial)

Construa um caminho completo através da pilha:

Slice 1: Create a task (DB + API + basic UI)
    → Tests pass, user can create a task via the UI

Slice 2: List tasks (query + API + UI)
    → Tests pass, user can see their tasks

Slice 3: Edit a task (update + API + UI)
    → Tests pass, user can modify tasks

Slice 4: Delete a task (delete + API + UI + confirmation)
    → Tests pass, full CRUD complete

Cada fatia entrega funcionalidade ponta a ponta funcional.

Fatiamento Baseado em Contrato (Contract-First)

Quando backend e frontend precisam se desenvolver em paralelo:

Slice 0: Define the API contract (types, interfaces, OpenAPI spec)
Slice 1a: Implement backend against the contract + API tests
Slice 1b: Implement frontend against mock data matching the contract
Slice 2: Integrate and test end-to-end

Fatiamento Baseado em Risco (Risk-First)

Aborde a peça mais arriscada ou incerta primeiro:

Slice 1: Prove the WebSocket connection works (highest risk)
Slice 2: Build real-time task updates on the proven connection
Slice 3: Add offline support and reconnection

Se a Fatia 1 falhar, você a descobrirá antes de investir nas Fatias 2 e 3.

Regras de Implementação

Regra 0: Simplicidade Primeiro

Antes de escrever qualquer código, pergunte: "Qual é a coisa mais simples que pode funcionar?"

Após escrever o código, revise-o em relação a estas verificações:

• Isso pode ser feito em menos linhas?
• Essas abstrações estão justificando sua complexidade?
• Um engenheiro sênior olharia para isso e diria "por que você não fez simplesmente..."?
• Estou construindo para requisitos futuros hipotéticos ou para a tarefa atual?

SIMPLICITY CHECK:
✗ Generic EventBus with middleware pipeline for one notification
✓ Simple function call

✗ Abstract factory pattern for two similar components
✓ Two straightforward components with shared utilities

✗ Config-driven form builder for three forms
✓ Three form components

Três linhas de código semelhantes são melhores do que uma abstração prematura. Implemente a versão ingênua e obviamente correta primeiro. Otimize apenas após a correção ser comprovada com testes.

Regra 0.5: Disciplina de Escopo

Toque apenas no que a tarefa exige.

…