Como usar a IA para investigar um bug
Forneça um caso reproduzível, encontre o domínio responsável e comprove a causa antes de alterar código.
Substitua os valores entre colchetes antes de enviar. Forneça os arquivos públicos relevantes da release alvo exata; use exemplos sintéticos e deixe credenciais, campanhas privadas e material proprietário fora do contexto.
O que você vai construir
Investigue uma falha observável, como um token que volta de posição após uma edição rejeitada. Diferencie conflito no servidor, negação de permissão e problema de renderização.
Contexto para fornecer à IA
Versões do host/pacote, navegador/SO e reprodução mínima com dados sintéticos.
Resultado esperado e observado, error.code, status de rede e horários sem dados privados.
docs/pt-BR/code-map.md, architecture.md e serviço/testes do domínio responsável.
Passo a passo
Reproduza em instalação isolada e registre a menor sequência que falha.
Peça hipóteses e evidências para diferenciá-las antes de solicitar o patch.
Acompanhe a entrada pelo transporte, validação do serviço, persistência e apresentação.
Corrija na camada responsável e confira o caso original mais o limite relevante de permissão/conflito.
Copie e adapte este prompt
Repositório: [checkout local ou repositório público]
Release alvo do host: [versão instalada/solicitada; preserve-a]
Escopo e autorização: [o que pode ser alterado/publicado]
Investigue este bug: [passos mínimos, resultado esperado, resultado observado]. Release alvo: [versão].
Leia AGENTS.md, examine git status e preserve alterações pendentes. Use o mapa de código para encontrar o domínio responsável.
Reproduza com dados sintéticos e diferencie IDs de operação/revisões, respostas do transporte e estado renderizado. Examine error.code em vez do texto traduzido.
Mostre as evidências da causa antes de implementar a menor correção. Mantenha regras/autorização nos serviços e notificações após commit.
Não force sucesso trocando revisão esperada silenciosamente, ocultando erros, removendo asserts ou contornando permissões.
Execute validação focada e informe comandos, resultados e incertezas restantes. Não publique logs, credenciais nem dados de campanhas.
Examine os arquivos reais e APIs suportadas antes de propor código. Não invente comandos, campos, endpoints ou capacidades de pacotes.
Use dados de teste descartáveis e ferramentas/caches locais à instalação. Explique requisitos sem suporte e valide o resultado com as ferramentas reais do projeto.
Entregue arquivos ou passos concretos no editor, verificações realizadas e limitações pendentes.Como validar
Confirme que a reprodução original agora tem o resultado esperado.
Teste a condição negada/expirada/desatualizada pertinente à causa, além do caminho de sucesso do GM.
Revise o diff procurando mudanças sem relação, gravações indevidas e asserts enfraquecidos.
Pronto quando
A falha possui causa demonstrada, correção focada e evidência de que o caso original e seus limites relevantes funcionam.
Continue pela referência de módulos, API pública e guia de testes.