ditto

Ditto se présente comme une « CI Sémantique » : une question supplémentaire dans le pipeline, aux côtés de la compilation, des tests et du lint — ce codebase est-il en train de réinventer quelque chose qu'il connaît déjà ? Il cible les clones de Type-4, des fonctions qui se comportent de la même manière mais sont écrites différemment, que les détecteurs de doublons basés sur les tokens et l'AST ne signalent généralement pas. Fonctionnement du pipeline documenté : le backend télécharge une archive du dépôt, l'explore avec ts-morph pour extraire chaque fonction, y compris celles qui ne sont pas exportées, puis crée l'empreinte de chaque fonction une par une avec un modèle peu coûteux, de manière aveugle aux noms. Ces empreintes — jamais le code brut ou les noms — sont intégrées (embedded) et regroupées par similitude cosinus en mémoire. Seuls les clusters de candidats résultants parviennent à un modèle plus large pour arbitrage, lequel propose également des entrées adverses. Les fonctions purement fonctionnelles sont ensuite exécutées côte à côte dans un sandbox worker_threads avec un délai d'expiration, et la divergence confirmée est présentée comme preuve d'exécution ; les fonctions impures sont toujours regroupées et arbitrées, mais étiquetées comme prédites et non exécutées. Les résultats sont écrits dans MongoDB et servis par des points de terminaison en lecture seule ainsi qu'un frontend Next.js ; le chemin de service n'appelle aucun modèle. Le README rapporte des exécutions sur cinq dépôts (2 870, 2 654, 336, 31 et 6 fonctions), listant les clusters de doublons, les conflits comportementaux et 18 cas prouvés par exécution, notamment une famille d'implémentations de truncateText dans cline où un calcul d'espace réservé réduit le texte conservé à un seul caractère au-dessus d'une certaine limite. Il précise que jscpd ne signale aucun clone dans ces fichiers. Deux petites bibliothèques bien entretenues ont été jugées propres, ce que les auteurs présentent comme une preuve contre le sur-signalement. Limites déclarées : JavaScript/TypeScript uniquement, car la couche AST est ts-morph ; l'exécution nécessite la pureté ; les grands dépôts doivent être définis explicitement plutôt que tronqués, car une fonction supprimée silencieusement peut faire disparaître tout un cluster ; et l'outil ne recommande pas laquelle des deux implémentations conflictuelles conserver, présentant cela comme une décision humaine. Les chiffres de coût et de timing dans le README (par exemple 232 ₹ pour une analyse de 2 870 fonctions, et environ 1 ₹ par pull request pour le contrôle Guard prévu) sont les mesures propres au projet, et non des benchmarks indépendants. La démo hébergée limite l'analyse à la demande à 600 fonctions, décrite comme une limite des crédits API des mainteneurs ; l'exécution locale avec sa propre clé supprime cette limite. Les notes de configuration couvrent l'indexation d'un dépôt sans MongoDB ni clé API, un fichier .env avec MongoDB, OpenAI et des paramètres GitHub/modèle optionnels, un déploiement Cloud Run avec un timeout de requête de 1200 secondes, l'accès réseau Atlas, et Vercel pour le frontend où les valeurs NEXT_PUBLIC_* sont intégrées au moment du build. Une feuille de route liste Ditto Guard comme un contrôle de pull-request GitHub Action, un outil MCP permettant aux agents de codage d'interroger l'index avant d'écrire des doublons, des langages supplémentaires via tree-sitter et une ré-indexation incrémentale. Les contributeurs sont orientés vers les tickets étiquetés « good first issues ».