Vérifications anti-slop

Les agents écrivent du code plausible rapidement, et certaines parties empruntent des raccourcis qu'un ingénieur prudent éviterait : un test ignoré pour obtenir un résultat positif, une erreur masquée, un stub laissé en place, une vérification de type désactivée, ou une autre manière de faire ce que votre base de code fait déjà. Anti-slop Cette vérification détecte ces cas dans chaque modification et renvoie la modification à l'agent développeur avant que vous ne la voyiez.

Il s'agit d'une simple vérification au sein de votre politique de qualité, et non d'un score séparé. Une modification la passe si elle n'introduit rien qui bloque son intégration.

Ce qu'elle recherche#

Les règles sont regroupées par familles. Chaque règle soit bloque, suggère ou enregistre des informations.

• Tests — tests ciblés ou ignorés, tests supprimés, assertions retirées ou affaiblies, tests incapables de générer une erreur.
• Suppressions — nouvelles désactivations de linteurs, ignorances de types et any conversions de type.
• Compilation et CI — étapes de test supprimées ou neutralisées, seuils abaissés, « passage avec aucun test », Actions GitHub non liées à un commit.
• Preuves de test — résultats mis en cache présentés comme une exécution réelle, aucun test exécuté, une exécution partielle déclarée complète.
• Code de production — restes de mode débogage, espaces réservés, données fictives, notes destinées aux humains, code de test livré.
• Gestion des erreurs — erreurs masquées, solutions de repli qui dissimulent les échecs, vérifications d'autorisation en mode permissif.
• Dépendances — paquets inexistants ou signalés comme malveillants, nouveaux paquets portant le nom d'un paquet populaire, paquets exécutant du code lors de leur installation, manifestes modifiés sans mise à jour du fichier de verrouillage.
• Sécurité — secrets présents dans le code, vérifications TLS désactivées, vérifications d'autorisation supprimées, scripts téléchargés exécutés directement depuis le réseau.
• Commentaires, Architecture, Portée de la modification, Mise en cache et le historique de l'agent — le relevé des actions de l'agent, comme modifier un test juste après son échec.

Chaque règle dans Règles Anti-slop, accessible depuis la ligne Anti-slop dans Contrôle qualité, indique ce qu'elle correspond, pourquoi elle est importante et son effet dans la configuration par défaut de l'organisation ou d'un projet.

Seule la modification introduite peut bloquer la vérification.#

La plupart des dépôts contiennent déjà certains de ces schémas. Anti-slop classe chaque constatation dans l'une de ces trois catégories :

• Introduite — nouvelle dans cette modification.
• Touchée — déjà présente sur une ligne ou dans une fonction modifiée par la modification.
• Existante — présente ailleurs dans le dépôt.

Seule une constatation introduite d'une règle bloquante fait échouer la vérification. Les constatations touchées et existantes sont enregistrées afin que vous puissiez suivre votre dette technique dans Usine, sous l'onglet Dette, et y créer une tâche pour corriger les constatations de la règle ; elles n'empêchent jamais le travail non lié. Le déplacement de code ne compte pas comme une introduction ; la copie si.

Nettoyage hebdomadaire de la dette#

La dette existante ne bloque pas l'intégration, mais elle n'a pas à persister. Ouvrez un projet dans Contrôle qualité, développez Anti-slop et activez Nettoyage hebdomadaire de la dette. Une fois par semaine, Coroid analyse la branche par défaut du projet et crée de petites tâches de nettoyage pour la dette trouvée, quelques fichiers à la fois. Le nombre maximal de tâches de nettoyage ouvertes correspond à ce que indique Tâches ouvertes simultanément (deux par défaut) ; ainsi, le nettoyage n'occupe jamais l'espace réservé au travail demandé. Chaque modification propose une option Annuler.

Le nettoyage est configuré par projet. Son calendrier est listé dans Usine et précise que Contrôle qualité le gère ; modifiez-le ici, pas là-bas.

Nouveau travail proposait autrefois un modèle « Nettoyage hebdomadaire de la dette technique ». Un planning créé à partir de celui-ci continue de fonctionner et porte le nom indiqué près du commutateur ; mettez-le en pause dans Usine si le nettoyage de la dette le remplace.

L'activer#

Dans Contrôle qualité, sélectionnez la configuration par défaut de l'organisation ou un projet et activez Anti-slop. Cela ajoute cinq exigences :

1. Les tests continuent de valider la modification.
2. Rien d'inachevé ou de réservé aux tests n'est livré.
3. Aucune nouvelle dette structurelle n'est créée.
4. La modification reste dans sa portée et respecte les conventions de cette base de code.
5. Les nouvelles dépendances sont réelles et fiables.

La modification s'applique immédiatement : la prochaine exécution de ce projet, ou de tous les projets suivant la configuration par défaut, inclut cette vérification. Les paramètres de la ligne choisissent la discipline de modification, qui regroupe les règles bloquantes et les règles de jugement ; la désactiver conserve ces paramètres pour la prochaine activation.

Choisir une discipline de modification#

La discipline indique à l'agent développeur jusqu'où une modification peut aller :

• Chirurgical — uniquement ce que la spécification requiert ; les autres problèmes sont signalés, mais non corrigés.
• Équilibré (par défaut) — corrige également les petits problèmes sur les lignes touchées par la modification.
• Restauratif — nettoie également les anomalies trouvées dans les fonctions modifiées par la modification.

L'agent applique les mêmes règles avant de soumettre : il connaît à l'avance la discipline et vos motifs mis en quarantaine, consulte les règles rapides après chaque édition, et dispose d'une seule chance pour corriger les anomalies bloquantes avant le Contrôle qualité.

Adapter à votre base de code#

• Surcharges de règles — ouvrez une règle dans les règles anti-slop pour la configurer afin qu'elle bloque, conseille, ne fasse que signaler ou s'arrête, que ce soit pour la configuration par défaut de l'organisation ou pour un projet spécifique.
• Packs de règles — vos propres motifs, importations et dépendances interdites, limites de taille de fichier, ou résultats des outils que vous utilisez déjà (SARIF). Chaque enregistrement constitue une nouvelle version, et une vérification conserve la version sélectionnée.
• Quarantaine — motifs que vous ne souhaitez plus voir copiés, chacun avec le remplaçant à utiliser. Les agents sont informés de ne pas les diffuser, et de nouvelles copies sont signalées.
• Chemins exclus — dans Contrôle qualité → Anti-slop, les fichiers générés ou externes que la vérification anti-slop n'analyse pas, un motif par ligne (dist/**, vendor/**). Utilisez-les pour les sorties de compilation validées : un fichier modifié dépassant la limite de 512 Ko du scan, nécessaire à une règle, rend les vérifications indisponibles.
• Fichier de dépôt — .coroid/anti-slop.yml dans le dépôt peut ajouter des règles et exclure generated/, vendor/, node_modules/ et __generated__/ dossiers. Il est lu depuis la racine de la modification, donc une modification ne peut pas assouplir ses propres règles, et son édition nécessite une approbation.
• Fichiers de verrouillage et catalogues de traduction — anti-slop compte leurs modifications mais ne les analyse pas. Les catalogues sont les fichiers .coroid/i18n.json déclare au niveau de la racine de la modification ; la vérification de Globalisation les lit. Une règle personnalisée les mentionnant les lit tout de même.

Nouvelles dépendances#

Les Modèles suggèrent parfois un paquet qui n'existe pas, souvent une combinaison plausible de deux noms réels. Les attaquants enregistrent de tels noms sur npm et PyPI afin que l'installation suivante exécute leur code, une attaque appelée slopsquatting. La Cloud Security Alliance le décrit: près d'un échantillon sur cinq parmi les 2,23 millions d'échantillons de code étudiés cite au moins un paquet inexistant.

Anti-slop recherche chaque dépendance ajoutée par une modification dans package.json, un fichier de dépendances ou pyproject.toml:

• Blocs — un paquet absent de son registre public, ou un paquet que OSV identifie comme malveillant. La modification est renvoyée à l'agent développeur avant que vous ne la voyiez.
• Conseils — un paquet publié il y a moins de 30 jours, ayant très peu de téléchargements, dont le nom diffère d'un ou deux caractères d'un paquet populaire, ou un paquet npm qui exécute du code lors de son installation. Un paquet PyPI dont la publication est signalée comme malveillante génère également des conseils, car Coroid ne sait pas quel paquet sera installé par la dépendance.

Si un registre ne peut pas être contacté, la vérification l'indique dans son résultat et décide des paquets qu'elle peut rechercher. Elle ne retient pas la modification.

Quels noms Coroid recherche-t-il ?#

La recherche d'un nom l'envoie vers un registre public ; ainsi, un propriétaire ou administrateur choisit quels noms peuvent quitter Coroid, dans Contrôle qualité → Anti-slop → Vérifier les nouvelles dépendances. Ce choix s'applique à tous les projets de l'organisation.

• npm et PyPI publics, sauf si le dépôt indique un autre registre — toutes les nouvelles dépendances sont recherchées, sauf si .npmrc, un fichier de dépendances, pip.conf, uv.toml, un Pipfile ou les paramètres d'outil Python, à côté du manifeste ou dans un dossier parent, indiquent un autre registre ou index. Le choix vous demande de confirmer qu'aucun registre privé n'est configuré en dehors de vos dépôts, par exemple dans les paramètres utilisateur ou CI, et enregistre quand et par qui la confirmation a été faite. Les paquets npm à portée restreinte (@scope/name) ne sont recherchés que là où .npmrc indique le registre public pour leur portée.
• Uniquement si le dépôt indique le registre public — la valeur par défaut. Un paquet n'est recherché que si .npmrc définit registry=https://registry.npmjs.org/, son fichier de dépendances contient exactement une --index-url https://pypi.org/simple ligne, ou une dépendance Poetry utilise une source pointant vers pypi.org. La plupart des dépôts ne respectent aucune de ces conditions, donc la plupart des nouvelles dépendances ne sont pas vérifiées.
• Désactivé — aucun nom n'est recherché, et les paquets inventés ne sont pas détectés.

Seuls les noms des nouvelles dépendances quittent Coroid. Ils sont envoyés à registry.npmjs.org et pypi.org, à api.npmjs.org pour les comptes de téléchargement npm, et à api.osv.dev (avec la version npm) pour les rapports de paquets malveillants. Votre code n'est jamais envoyé. Les résultats sont conservés jusqu'à un jour, afin que le même nom ne soit pas recherché à nouveau pour chaque modification.

Constatations et acceptation#

Les constatations d'une tâche apparaissent dans sa Qualité section de l'Usine. Lorsque l'agent développeur a corrigé les constatations bloquantes avant que la modification n'arrive en phase de révision, la section s'ouvre avec Détecté par anti-slop avant la révision, les règles qu'il a détectées et, sous Afficher où et quand, le fichier et la ligne de chaque constatation ainsi que le contrôle qui l'a trouvée. Dans l'Usine, sous Dette, compte le nombre de raccourcis détectés avant la révision au cours des 30 derniers jours, et montre aux propriétaires et administrateurs les projets qui n'effectuent pas encore ce type de vérification, avec Activer anti-slop.

Pour accepter une constatation, indiquez une raison et une date d'expiration ; l'acceptation est enregistrée pour cette constatation précise. Les agents ne peuvent pas accepter leurs propres constatations. Lorsqu'un agent affirme qu'un test est erroné et le modifie, un réviseur doit approuver cette modification avant que le contrôle ne soit validé.

Évaluer les règles#

Deux règles interrogent un modèle, une ligne à la fois : un contrôle défensif pour détecter quelque chose d'impossible selon le code affiché, et un commentaire qui contredit le code adjacent. Elles ne font qu'offrir des conseils, sans jamais bloquer. Activer les règles d'évaluation est activé pour un nouveau contrôle, avec une limite de décisions par exécution ; désactivez-le dans les paramètres du contrôle.

Vos propres agents#

Les mêmes règles peuvent guider les agents que vous exécutez vous-même :

• Télécharger le extrait AGENTS.md, dans les Anti-slop paramètres d'un projet dans Contrôle qualité, fournit la discipline de modification du projet, la quarantaine et les règles principales sous forme d'une section à coller dans les instructions de vos agents.
• Via le serveur MCP Coroid, anti_slop_rules décrit votre politique publiée et anti_slop_scan analyse une branche d'un projet synchronisé, en mode lecture seule.