ditto

O Ditto apresenta-se como "Semantic CI": uma pergunta adicional no pipeline ao lado de compilação, teste e lint — esta base de código está reinventando algo que já conhece? Ele foca em clones do Tipo-4, funções que se comportam da mesma forma, mas são escritas de maneira diferente, que detectores de duplicatas baseados em tokens e AST geralmente não reportam. Como funciona o pipeline documentado: o backend baixa um tarball do repositório, percorre-o com ts-morph para extrair cada função, incluindo as não exportadas, e então cria fingerprints de cada função individualmente com um modelo econômico de forma cega a nomes. Esses fingerprints — nunca o código bruto ou nomes — são incorporados (embedded) e agrupados por similaridade de cosseno em memória. Apenas os clusters de candidatos resultantes chegam a um modelo maior para adjudicação, que também propõe entradas adversariais. Funções funcionalmente puras são então executadas lado a lado em um sandbox de worker_threads com um timeout, e a divergência confirmada ali é apresentada como evidência executada; funções impuras ainda são agrupadas e adjudicadas, mas rotuladas como previstas, não executadas. Os resultados são gravados no MongoDB e servidos por endpoints de leitura e um frontend Next.js; o caminho de serviço não chama nenhum modelo. O README relata execuções em cinco repositórios (2.870, 2.654, 336, 31 e 6 funções), listando clusters de duplicatas, conflitos comportamentais e 18 casos comprovados por execução, incluindo uma família de implementações de truncateText no cline onde um cálculo de espaço reservado reduz o texto mantido a um único caractere acima de um certo limite. Afirma que o jscpd reporta zero clones nesses arquivos. Duas bibliotecas pequenas e bem mantidas foram classificadas como limpas, o que os autores apresentam como evidência contra o excesso de reportes. Limites declarados: apenas JavaScript/TypeScript, já que a camada de AST é o ts-morph; a execução requer pureza; repositórios grandes devem ser escopados explicitamente em vez de truncados, porque uma função descartada silenciosamente pode fazer um cluster inteiro desaparecer; e a ferramenta não recomenda qual de duas implementações conflitantes manter, definindo isso como uma decisão humana. Os valores de custo e tempo no README (por exemplo, ₹232 para uma análise de 2.870 funções e aproximadamente ₹1 por pull request para a verificação planejada do Guard) são medições do próprio projeto, não benchmarks independentes. A demo hospedada limita a análise sob demanda a 600 funções, descrito como um limite nos créditos de API dos mantenedores; a execução local com sua própria chave remove o limite. As notas de configuração cobrem a indexação de um repo sem MongoDB ou chave de API, um .env com MongoDB, OpenAI e configurações opcionais de GitHub/modelo, implantação no Cloud Run com timeout de requisição de 1200 segundos, acesso de rede Atlas e Vercel para o frontend, onde valores NEXT_PUBLIC_* são inlined no momento do build. Um roadmap lista o Ditto Guard como um check de pull-request do GitHub Action, uma ferramenta MCP permitindo que agentes de codificação consultem o índice antes de escrever duplicatas, linguagens adicionais via tree-sitter e re-indexação incremental. Contribuidores são direcionados para issues rotuladas como "good first issues".