Verificações anti-slop

Os agentes escrevem código plausível com rapidez, e parte dele usa atalhos que um engenheiro cuidadoso não usaria: um teste ignorado para obter aprovação, um erro suprimido, um stub deixado no código, uma verificação de tipo silenciada, uma segunda forma de fazer algo que já existe no seu repositório. 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 ou bloqueia, orienta ou registra informações.

• Testes — testes focados ou ignorados, testes excluídos, asserções removidas ou enfraquecidas, testes que não podem falhar.
• Supressões — novas desativações de linter, ignorações de tipo e any conversões.
• Compilação e CI — etapas de teste removidas ou neutralizadas, limites reduzidos, 'aprovação sem testes', Ações GitHub não vinculadas a um commit.
• Evidências de teste — resultados em cache apresentados como se fossem de uma execução, zero testes executados, uma 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 suprimidos, soluções alternativas que ocultam falhas, verificações de permissão que permitem acesso irrestrito.
• Dependências — pacotes inexistentes ou marcados como maliciosos, novos pacotes com nomes semelhantes a populares, pacotes que executam código ao serem instalados, manifestos alterados sem atualização do arquivo de bloqueio.
• Segurança — segredos no código, verificações TLS desativadas, verificações de autorização removidas, scripts baixados executados diretamente da rede.
• Comentários, Arquitetura, Escopo da alteração, Cache e o registro de atividades do agente — o registro do que o agente fez, como editar um teste logo após ele falhar.

Cada regra em Regras Anti-slop, acessadas a partir da linha Anti-slop em Controle de Qualidade, mostram o que elas correspondem, por que são importantes e o que fazem na configuração padrão da organização ou de um projeto.

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

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

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

Apenas uma ocorrência introduzida de uma regra bloqueadora faz com que a verificação falhe. Ocorrências modificadas e existentes são registradas para que você possa acompanhar sua dívida técnica na Factory, em Dívida Técnica, e criar uma tarefa para corrigir as ocorrências da regra ali, mas elas nunca impedem trabalhos não relacionados. Mover código não conta como introduzi-lo; copiá-lo sim.

Limpeza semanal de dívida técnica#

A dívida existente não bloqueia, mas também não precisa permanecer. Abra um projeto em Controle de Qualidade, expanda Anti-slop e ative Limpeza semanal de dívida técnica. Uma vez por semana, o Coroid analisa o branch padrão do projeto e cria pequenas tarefas de limpeza para a dívida encontrada, poucos arquivos por vez. Ele mantém no máximo o número de tarefas de limpeza abertas conforme definido em Tarefas abertas simultaneamente (duas por padrão), para que a limpeza nunca atrapalhe o trabalho solicitado pelas pessoas. Cada alteração permite desfazer a operação.

A limpeza é configurada por projeto. Seu cronograma está listado na Factory e indica que o Controle de Qualidade gerencia isso; altere-o aqui, não lá.

O Novo trabalho costumava oferecer um modelo 'Limpeza semanal de dívida técnica'. Um cronograma criado a partir dele continua funcionando e recebe o nome indicado no toggle; pause-o na Factory se a limpeza de dívida técnica substituí-lo.

Ativando-o#

Em Controle de Qualidade, escolha a configuração padrão da organização ou um projeto e ative Anti-slop. Ele adiciona cinco expectativas:

1. Os testes ainda comprovam a alteração.
2. Nada incompleto ou apenas para teste é enviado para produção.
3. Nenhuma nova dívida estrutural é criada.
4. A alteração permanece dentro do escopo e segue o estilo do código existente.
5. Novas dependências são reais e confiáveis.

A alteração entra em vigor imediatamente: a próxima execução desse projeto, ou de todos os projetos que seguem a configuração padrão, incluirá a verificação. As configurações da linha escolhem a disciplina de alteração, que agrupa as regras de bloqueio e de avaliação, e desativá-la mantém essas configurações para a próxima vez que for ativada.

Escolhendo a disciplina de alteração#

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

• Cirúrgico — apenas o que a especificação exige; outros problemas são relatados, mas não corrigidos.
• Equilibrado (padrão) — também corrige pequenos problemas nas linhas que a alteração afeta de qualquer forma.
• Restaurador — também limpa os resultados encontrados dentro das funções que a alteração edita.

O agente trabalha seguindo as mesmas regras antes de enviar: recebe a disciplina e seus padrões em quarentena com antecedência, vê as regras rápidas após cada edição e tem uma chance para corrigir os resultados bloqueadores antes da etapa de Controle de Qualidade.

Adaptando-o ao seu repositório de código#

• Sobrescritas de regras — abra uma regra em Regras Anti-slop para definir se ela deve bloquear, aconselhar, apenas relatar ou interromper, seja para a configuração padrão da organização ou para um projeto específico.
• 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á utiliza (SARIF). Cada salvamento gera uma nova versão, e uma verificação mantém a versão selecionada.
• Quarentena — padrões que você não deseja mais copiar, cada um com a substituição a ser usada. Os agentes são instruídos a não disseminá-los, e novas cópias são sinalizadas.
• Caminhos excluídos — em Controle de Qualidade → Anti-slop, os arquivos gerados ou fornecidos que não são analisados pela verificação Anti-slop, um padrão por linha (dist/**, vendor/**). Use-os para saídas de compilação commitadas: um arquivo alterado acima do limite de 512 KiB do scanner que uma regra exige torna as verificações indisponíveis.
• Arquivo do repositório — .coroid/anti-slop.yml no repositório pode adicionar regras e excluir generated/, vendor/, node_modules/ e __generated__/ diretórios. 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.
• Arquivos de lock e catálogos de tradução — o anti-slop conta suas alterações, mas não as analisa. Os catálogos são os arquivos .coroid/i18n.json declara na base da alteração; a verificação de Globalização lê esses arquivos. Uma regra sua que os nomeie ainda os analisa.

Novas dependências#

Os Modelos às vezes sugerem um pacote que não existe, geralmente uma combinação plausível de dois nomes reais. Atacantes registram esses nomes no npm e no PyPI para que a próxima instalação execute seu código, um ataque chamado slopsquatting. A Cloud Security Alliance descreve isso: algo em torno de um em cada cinco das 2,23 milhões de amostras de código citadas na pesquisa nomearam pelo menos um pacote que não existia.

O Anti-slop consulta cada dependência que uma alteração adiciona em package.json, um arquivo de requisitos ou pyproject.toml:

• Bloqueios — um pacote que não está em seu registro público, ou um que OSV relata como malicioso. A alteração retorna ao agente desenvolvedor antes de você vê-la.
• Avisos — um pacote publicado há menos de 30 dias, com pouquíssimos downloads, cujo nome difere em uma ou duas letras de um pacote popular, ou um pacote npm que executa código durante a instalação. Um pacote PyPI com uma versão relatada como maliciosa também gera aviso, pois o Coroid não sabe qual versão uma requisição instala.

Se um registro não puder ser acessado, a verificação informará isso em seu resultado e decidirá sobre os pacotes que poderia consultar. Ela não retém a alteração.

Quais nomes o Coroid consulta#

Consultar um nome envia-o a um registro público; portanto, um proprietário ou administrador escolhe quais nomes podem sair do Coroid, em Controle de Qualidade → Anti-slop → Verificando novas dependências. A escolha se aplica a todos os projetos da organização.

• npm e PyPI públicos, a menos que o repositório indique outro registro — todas as novas dependências são consultadas, exceto quando .npmrc, um arquivo de requisitos, pip.conf, uv.toml, um Pipfile ou configurações de ferramentas Python, além do manifesto ou em uma pasta acima dele, indicam outro registro ou índice. Escolher essa opção solicita que você confirme que nenhum registro privado foi configurado fora de seus repositórios, por exemplo em configurações de usuário ou CI, e registra quando e por quem foi confirmado. Pacotes npm com escopo (@scope/name) são consultados apenas quando .npmrc indica o registro público para seu escopo.
• Apenas quando o repositório indica o registro público — o padrão. Um pacote é consultado somente quando .npmrc define registry=https://registry.npmjs.org/, seu arquivo de requisitos tem exatamente uma --index-url https://pypi.org/simple linha, ou uma dependência do Poetry usa uma fonte que aponta para pypi.org. A maioria dos repositórios não faz nada disso, portanto a maioria das novas dependências não é verificada.
• Desativado — nenhum nome é consultado, e pacotes inventados não são detectados.

Apenas os nomes das novas dependências saem do Coroid. Eles vão para registry.npmjs.org e pypi.org, para api.npmjs.org para obter contagens de download do npm, e para api.osv.dev (com a versão do npm) para relatórios de pacotes maliciosos. Seu código nunca é enviado. Os resultados são mantidos por até um dia, para que o mesmo nome não seja consultado novamente para cada alteração.

Achados e aceitação#

Os achados de uma tarefa aparecem em sua Qualidade seção na Factory. Quando o agente de desenvolvimento corrigiu os achados bloqueantes antes que a alteração chegasse à revisão, a seção abre com Capturado pelo anti-slop antes da revisão, as regras que capturaram e, em Mostrar onde e quando, o arquivo e a linha de cada achado e a verificação que o encontrou. Na Factory, em Dívida técnica, conta os atalhos capturados antes da revisão nos últimos 30 dias e mostra aos proprietários e administradores os projetos que ainda não os verificam, com Ativar anti-slop.

Para aceitar um achado, informe um motivo e um prazo de validade; a aceitação é registrada para aquele achado específico. Os agentes não podem aceitar seus próprios achados. Quando um agente diz que um teste estava incorreto e o altera, um revisor deve aprovar essa alteração antes que a verificação seja aprovada.

Avaliar regras#

Duas regras consultam um modelo, linha por linha: uma verificação defensiva para algo que o código exibido torna impossível e um comentário que contradiz o código ao lado dele. Elas apenas aconselham, nunca bloqueiam. Ativar regras de avaliação está 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:

• Baixar trecho de AGENTS.md, em Anti-slop configurações de um projeto em Controle de Qualidade, fornece 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 do Coroid, anti_slop_rules descreve sua política publicada e anti_slop_scan analisa um ramo de um projeto sincronizado, em modo somente leitura.