Verificações anti-slop

Os agentes escrevem código plausível com rapidez, e parte dele utiliza atalhos que um engenheiro cuidadoso não adotaria: um teste pulado para obter aprovação, um erro ignorado, um stub deixado para trás, uma verificação de tipo silenciada, ou uma segunda forma de fazer algo que já existe no seu código-fonte. O anti-slop verifica esses casos em cada alteração e envia a alteração de volta ao agente desenvolvedor antes que você a veja.

É uma verificação dentro da sua política de qualidade, não uma pontuação separada. Uma alteração passa nela quando não introduz nada que bloqueie o processo.

O que ele verifica#

As regras são agrupadas em famílias. Cada regra bloqueia, orienta ou registra informações.

• Testes — testes focados ou pulados, testes excluídos, asserções removidas ou enfraquecidas, testes que não podem falhar.
• Supressões — novas desativações de linter, ignorações de tipos e any conversões.
• Compilação e CI — etapas de teste removidas ou neutralizadas, limites reduzidos, "aprovação sem testes".
• Evidência de teste — resultados em cache apresentados como execução real, zero teste executado, execução parcial relatada como completa.
• Código de produção — vestígios de depuração, placeholders, dados fictícios, anotações para humanos, código de teste enviado para produção.
• Tratamento de erros — erros ignorados, soluções alternativas que ocultam falhas, verificações de permissão que permitem acesso mesmo em caso de falha.
• Comentários, Arquitetura, Dependências, Escopo da alteração, Segurança, Cache e o registro de atividades do agente — o registro do que o agente fez, como editar um teste logo após ele falhar.

A página de cada regra em Qualidade → Verificações → Anti-slop mostra o que ela corresponde e por que é importante.

Apenas o que a alteração introduziu pode bloquear a verificação.#

A maioria dos repositórios já contém alguns desses padrões. O anti-slop classifica cada achado em três grupos:

• Introduzido — novo nesta alteração.
• Modificado — já existente, em uma linha ou função que a alteração edita.
• Existente — em outro lugar do repositório.

Apenas um achado introduzido de uma regra bloqueante faz a verificação falhar. Achados modificados e existentes são registrados para que você possa ver sua dívida técnica, mas eles nunca impedem trabalhos não relacionados. Mover código não conta como introdução; copiar sim.

Adicionando-o a uma política#

Abra uma política em Qualidade → Políticas e selecione Adicionar preset anti-slop. Ele adiciona cinco expectativas:

1. Os testes ainda comprovam a alteração.
2. Nada incompleto ou apenas para teste será enviado para produção.
3. Nenhuma nova dívida estrutural será criada.
4. A alteração permanecerá no escopo e terá a mesma aparência do seu código-fonte.
5. Novas dependências serão reais e confiáveis.

Publique a política, e a próxima execução de cada projeto associado incluirá a verificação.

Escolhendo a disciplina de alteração#

A disciplina informa ao agente desenvolvedor até onde uma alteração pode ir:

• Cirúrgico — apenas o necessário conforme a especificação; outros problemas são reportados, mas não corrigidos.
• Equilibrado (padrão) — também corrige pequenos problemas nas linhas que a alteração modifica.
• Restaurador — também limpa os achados dentro das funções que a alteração edita.

O agente segue as mesmas regras antes de submeter: recebe a disciplina e seus padrões em quarentena antecipadamente, vê as regras rápidas após cada edição e tem uma chance de corrigir achados bloqueantes antes da fase de QA.

Adaptando-o ao seu código-fonte#

• Sobrescritas de regra — desative uma regra ou faça com que ela oriente em vez de bloquear, nas configurações da verificação.
• Pacotes de regras — seus próprios padrões, importações e dependências proibidas, limites de tamanho de arquivo ou resultados de ferramentas que você já usa (SARIF). Os pacotes são versionados; uma política fixa a versão utilizada.
• Quarentena — padrões que você não deseja mais copiar, cada um com a substituição recomendada. Os agentes são instruídos a não disseminá-los, e novas cópias são sinalizadas.
• Arquivo do repositório — .coroid/anti-slop.yml no repositório pode adicionar regras e excluir caminhos gerados ou fornecidos. Ele é lido a partir da base da alteração, portanto uma alteração não pode afrouxar suas próprias regras, e editá-lo requer aprovação.

Achados e dispensas#

Os achados aparecem em Qualidade → Achados, filtrados por verificação. Para aceitar um, rejeite-o com um motivo; a rejeição é registrada vinculada a esse achado específico. Os agentes não podem rejeitar seus próprios achados. Quando um agente afirma que um teste está incorreto e o altera, um revisor deve aprovar essa mudança antes que a verificação seja considerada aprovada.

Regras de avaliação#

Duas regras consultam o modelo, uma linha por vez: uma verificação defensiva para algo que o código exibido torna impossível, e um comentário que contradiz o código ao seu lado. Elas apenas dão recomendações, nunca bloqueiam. Ativar regras de avaliação fica ativado para uma nova verificação, com um limite de decisões por execução; desative-o nas configurações da verificação.

Seus próprios agentes#

As mesmas regras podem orientar os agentes que você executa localmente:

• Baixar trecho de código de AGENTS.md, na Dívida técnica aba de Qualidade → Verificações → Anti-slop, apresenta a disciplina de alterações do projeto, a quarentena e as principais regras como uma seção para colar nas instruções dos seus agentes.
• Por meio do servidor MCP Coroid, anti_slop_rules descreve sua política publicada e anti_slop_scan examina um branch de um projeto sincronizado, em modo somente leitura.