TheElephantCoder/pesquisa-primeiro

Pesquisa primeiro

Não codifique baseado no que você acha que a API é. Verifique primeiro.

Você precisa fazer isso antes de qualquer edit ou write que não seja trivial:

1. Pesquise: research/findings/<tópico>.md

• Verifique research/findings/ primeiro. Se alguém já pesquisou, reutilize.
• Depois, faça grep no código-fonte. Em seguida, pesquise na web se precisar de documentação externa. Use 2026 ao pesquisar para obter documentação atual.
• Cite o que encontrou. Se a documentação não existir, escreva um pequeno reprodutor para verificar a hipótese.
• Salve em research/findings/<slug>.md para que a próxima sessão não refaça o trabalho.

Modelo:

# Descobertas: <tópico>

Data: 2026-09-04
Fontes: [url, url]
Código existente: `caminho:linha`: o que encontramos

## Veredito

Abordagem recomendada: ...
Alternativas: ...
Riscos: ...

2. Planeje: research/plans/<tarefa>.md

# Plano: <tarefa>

Pesquisa: research/findings/<tópico>.md
Abordagem: ...
Arquivos a alterar: [lista]
Testes: ...
Rollback: ...

3. Aprovação

Mostre o plano ao usuário. Não comece a codificar até que ele diga ok. Para edições pequenas de único arquivo, o instinto de autoaprovação pode permitir que você passe.

4. Implemente e verifique

Construa o plano, execute os testes, harness bench --quick e depois harness memory sync para que a próxima sessão lembre o que funcionou.

Notas

• Se as descobertas já existirem, não as refaça.
• Leia os arquivos para obter fatos, não adivinhe. Se o que você encontrar contradizer o que esperava, diga e confie no arquivo.
• Depois de terminar, atualize as descobertas com o que realmente funcionou.

Não faça isso

• edit antes de read ou grep
• adivinhar assinaturas de API
• pular o plano porque "é pequeno" quando você está prestes a mexer em 3+ arquivos