AgentTeam

Audite o repositório inteiro como o desenvolvedor sênior que acabou de herdá-lo e será acionado quando algo quebrar. Ordem de importância: correto, seguro, suporta carga, testado, rápido, enxuto. Enxuto ainda importa: cada linha extra terá que ser lida, testada e corrigida depois. Este é um relatório que o usuário pediu, então forneça-o por completo.

1. Mapeie primeiro

• Audite o que o usuário nomear: uma pasta, um pacote ou o repositório inteiro. Nada nomeado: o repositório inteiro.
• Leia o README, a configuração de deploy e build, a lista de dependências, os pontos de entrada (main, rotas, handlers, jobs, comandos CLI) e os testes.
• Descubra a carga esperada: uma pessoa executando um script, ou muitos usuários e processos ao mesmo tempo. Julgue a escala com base nisso e diga qual carga você assumiu.
• Trace os fluxos principais de ponta a ponta: de onde os dados vêm, o que é armazenado, o que sai. Leia esses caminhos por completo: entrada de usuários, dinheiro, autenticação, gravações de dados, jobs em segundo plano, qualquer coisa compartilhada entre processos.
• Repositório grande: vá fundo onde um erro custa mais caro, não arquivo por arquivo. Diga quais partes você não leu.

2. Procure por

1. Bug: resultado errado, crash, caso de borda perdido (vazio, zero, último item, arredondamento, fusos horários), chamadores que discordam do que uma função retorna, a mesma regra aplicada de forma diferente em dois lugares.
2. Risco: falhas de segurança (injeção, aleatoriedade fraca, segredos no código, verificações ausentes em entrada de usuários), perda de dados (erros engolidos, gravações na ordem errada, sem transação).
3. Escala: bom para um usuário, ruim para muitos: condições de corrida de verificar-depois-escrever, o mesmo trabalho feito por todo processo, memória ou listas que só crescem, uma consulta por item, O(n²) em entrada grande, estado por processo que precisa ser compartilhado.
4. Teste ausente: lógica arriscada (um branch, um parser, dinheiro, segurança, gravações de dados) sem um teste que falhe quando ela quebrar. Um bom teste, não cobertura.
5. Velocidade: grandes lentidões são problemas. Pequenas vitórias (trabalho repetido em um loop quente) são sugestões; alguns softwares contam cada milissegundo.
6. Enxuto: código que não deveria existir ou deveria ser menor.
   • remover: código morto, opções não utilizadas, flags e configurações, recursos especulativos
   • reutilizar: dois helpers fazendo a mesma coisa (mantenha um, nomeie o caminho)
   • stdlib / nativo: a biblioteca padrão ou plataforma já faz isso; uma dependência fazendo o que algumas linhas ou a plataforma podem fazer
   • yagni: interface com uma implementação, factory com um produto, wrapper que só passa chamadas adiante
   • mesclar: cópias quase iguais que precisam mudar juntas
   • dividir: uma função ou classe fazendo vários trabalhos não relacionados, dificultando a leitura ou teste. Divida por trabalho, nunca por contagem de linhas, e nunca em helpers que existem apenas para encurtar uma função.

3. Verifique antes de relatar

• Cada achado precisa de um caso concreto: "esta entrada ou situação leva a este resultado errado". Sem caso, sem achado.
• Antes de chamar código de não utilizado, pesquise em toda a árvore, incluindo testes, fixtures, configuração e referências dinâmicas ou em strings.
• Um atalho marcado com um comentário shortcut: (ou ponytail:, mais antigo) que nomeia seu limite é uma decisão, não um achado, a menos que a carga esperada já o ultrapasse.
• Proponha a menor correção que funciona. Prefira correções que removem código. Nunca adicione camadas, frameworks ou configuração que o problema não precisa.
• Sem gosto de estilo, sem "considere", sem preocupações vagas.

4. Saída

Inglês muito simples: frases curtas, palavras do dia a dia. Explique um termo técnico na primeira vez que usá-lo. O leitor pode nunca ter visto este código.

Comece com What this repo does: em duas ou três frases e a carga que você assumiu.

Em seguida, os achados em três grupos, mais importante primeiro, pule grupos vazios:

• Must fix: bug, segurança, perda de dados, quebra na carga esperada.
• Should fix: código arriscado sem um teste, lentidão real, duplicação, uma função que mistura tarefas, código que não deveria existir.
• Nice to have: pequenas acelerações, formas mais curtas.

Numere os achados em todos os grupos, para que o usuário possa dizer "corrija 2 e 5". No máximo 20 achados; se você deixou menores de fora, diga quantos. Cada achado tem todas as quatro partes, cada uma com uma ou duas frases curtas:

2. Orders land on the wrong day (billing/close_day.py:L40-52)
   • What this is: At midnight this job closes the day and bills all orders of that day.
   • Problem: It takes "today" from the server clock, which runs in UTC. An order placed at 00:30 in Berlin is billed on the day before.
   • Fix: Compute the day once in the shop's time zone: datetime.now(ZoneInfo("Europe/Berlin")).date(). One line, nothing else changes.
   • If we skip it: Late orders show the wrong date, and accounting fixes them by hand.

Termine com:

• Verdict: uma linha: saudável, ou o que corrigir primeiro.
• Lean: -<N> lines, -<M> dependencies possible. quando existirem achados de enxugamento.
• Not checked: as partes que você não leu ou não conseguiu executar.

Nada encontrado: What this repo does:, então Healthy. Nothing to fix. e uma linha sobre o que você verificou.

Relatório único, não altera código.