Auditoria de CI e testes do REA
Estabeleça quais verificações ainda detectam regressões reais e quais custos podem ser removidos sem perder essa proteção. O resultado pode ser uma correção verificada, uma recomendação baseada em evidências ou uma decisão explícita de parar.
Siga o AGENTS.md do checkout, o guia de testes
e as regras de contribuição. Use os comandos atuais
e a toolchain fixada, em vez de comandos lembrados de uma auditoria anterior.
Preserve o escopo solicitado: a investigação por si só não autoriza edições;
este skill não concede permissão para publicar issues, fazer push ou merge.
A autorização existente do usuário ainda se aplica. Mantenha notas de auditoria e
resultados brutos fora da árvore rastreada, normalmente em um diretório /tmp
específico da tarefa.
Estabelecer a linha de base executada
Busque quando o usuário pedir o main mais recente. Fixe o SHA da linha de base e a revisão do workflow inspecionada; use uma worktree isolada ao alterar ou comparar código. Não modifique o checkout de outra tarefa. Registre alterações sujas e o comando exato, toolchain, host, testes selecionados, instrumentação e pré-requisitos. Uma execução antiga é evidência para sua revisão executada, mesmo que o main avance.
Rastreie gatilhos de workflow, seleção de caminhos alterados, dependências de jobs, ações reutilizáveis, scripts de pacote, descoberta de testes, produtores de artefatos e portões de relatório até os comandos que realmente executam. Inclua scripts, dados gerados, registro em tempo de execução e limites de subprocessos ausentes nos gráficos de importação. Verifique caminhos de seleção positivos e negativos: arquivos exigidos devem ser descobertos uma vez por configuração de teste pretendida; repeti- ções deliberadas de plataforma/configuração são cobertura separada. Um teste explícito ausente ou um relatório exigido ausente não deve ficar verde. Lanes opcionais podem pular; preserve seus pré-requisitos declarados.
Use artefatos de temporização e falha existentes para selecionar famílias suspeitas. Execute verificações relevantes para estabelecer uma linha de base; reserve uma suíte local completa para diagnósticos amplos de CI ou incerteza que verificações focadas não possam resolver. Não reconstrua ou reexecute uma suíte completa inalterada após cada edição de documentação.
Provar a falha ou proteção
Para cada candidato, declare o comportamento observável esperado e seu proprietário, depois construa a menor reprodução contra o comportamento de produção. Siga o produtor e os consumidores afetados antes de decidir onde corrigi-lo.
- Para desvio, compare fixtures com os requisitos de admissão atuais, respostas de protocolo, contratos nomeados, versões de ferramentas e entrypoints públicos reais. Um mock plausível pode falhar antes do comportamento que seu teste alega cobrir. Pesquise toda a família de fixtures afetada, incluindo outras strings de versão. Preserve fixtures intencionalmente malformadas e teste sua rejeição pretendida.
- Para um teste verde suspeito, perturbe o comportamento relevante em uma cópia isolada ou injete uma falha controlada. Verifique se a asserção ou portão existente a detecta. Um teste pode apenas repetir seu mock, importar código abandonado ou ocultar uma falha de subprocesso/verificador. Restaure mutações após o experimento.
- Para setup compartilhado ou poda, mapeie asserções distintas para seus cenários retidos. Preserve entradas malformadas, cancelamento, falha de limpeza, permissões, capacidade, identidade e interações de concorrência significativas. Uma execução mais rápida que pula um caso ou enfraquece seu oráculo não é uma melhoria.
- Para cobertura de provedor, separe evidências de produtor falso, limite e motor real. Inspecione skips e pré-requisitos nomeados; fixtures não estabelecem comportamento real de Ghidra, LLDB, navegador ou outro provedor.
Classifique descobertas como defeitos reproduzidos, custos suportados, hipóteses ou evidências indisponíveis. Registre o comando de linha de base, saída/status de saída observados, resultado esperado, escopo afetado e explicação concorrente. Uma falha no main pode ser preexistente; isso por si só não a torna irrelevante para uma auditoria de CI. Atribua falhas de PR usando a revisão executada e uma linha de base limpa, não apenas sua semelhança com uma falha anterior. Repita apenas para testar uma explicação transitória específica; retenha a falha original e pare quando a repetição não dicionar evidência. Uma nova tentativa bem-sucedida não estabelece uma causa raiz ou uma correção.
Avaliar eficiência sem perder o portão
Leia medida e verificações de CI ao investigar lentidão, cache, esperas de runner, artefatos compartilhados ou ruído de log. Compare trabalho equivalente concluído antes de alegar aceleração. Distinga tempo de setup/build, execução de teste, instrumentação de cobertura, esperas de dependência e agendamento de runner; declare quais custos permanecem não medidos.
Prefira remover preparação duplicada comprovada, reutilizar setup imutável e reduzir trabalho repetido de subprocesso antes de encolher a cobertura de corretude. Preserve sessões independentes onde o ciclo de vida ou concorrência é o oráculo. Mantenha testes ativos frescos; uma aprovação anterior em cache não pode validar host atual, conteúdo do provedor instalado, permissões ou estado externo.
Corrigir, verificar e repassar dentro do escopo
Se a implementação for autorizada, faça a menor alteração estrutural no limite do proprietário e adicione uma regressão que falhe na linha de base pelo motivo certo. Reteste consumidores afetados e caminhos negativos significativos; verifique a invalidação de cache ou descoberta quando esses mecanismos mudarem. Leia a documentação do Turbo instalada antes de alterar sua configuração ou comandos.
Execute as verificações aplicáveis do repositório e inspecione resultados completos de CI do head atual antes de um merge autorizado. Preserve portões de cobertura e descoberta exigidos. Não suprima uma falha, adicione novas tentativas genéricas, aumente timeouts ou exclua asserções distintas apenas para deixar o CI verde. Alterações nesses controles precisam de sua própria razão demonstrada e detecção de falha retida.
Reporte cada problema confirmado com revisão exata, reprodução, consequência, correção proposta e limites de validação. Reporte desempenho com carga de trabalho e medidas, não apenas uma porcentagem. Use registros de issue/PR em inglês quando solicitado; siga as preferências de atribuição, identidade de commit, revisão e merge do usuário sem assumi-las para outros usuários. Abra PRs prontos para revisão apenas quando esse ciclo de vida for autorizado. Resolva descobertas de revisão necessárias e verifique o main final contra a árvore testada após o merge.
Pare quando o trabalho autorizado for verificado, os benefícios restantes não forem comprovados ou mais alterações trocarem corretude por velocidade especulativa. Liste incertezas genuínas sem transformá-las em rodadas de otimização adicionais.