Vérifications anti-slop

Les agents écrivent du code plausible rapidement, et une partie de ce code prend des raccourcis qu'un ingénieur méticuleux éviterait : un test ignoré pour obtenir un résultat positif, une erreur masquée, un espace réservé laissé en place, une vérification de type désactivée, ou une seconde façon d'accomplir une tâche déjà traitée par votre base de code. L' anti-slop effectue des vérifications sur chaque modification et renvoie celle-ci à l'agent développeur avant que vous ne la voyiez.

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

Ce qu'il recherche#

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

• 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.
• Build et CI — étapes de test supprimées ou neutralisées, seuils abaissés, « validation sans tests ».
• Preuves de test — résultats mis en cache présentés comme des exécutions réelles, aucun test exécuté, exécution partielle signalée comme 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é en production.
• Gestion des erreurs — erreurs masquées, solutions de repli qui dissimulent les échecs, vérifications d'autorisation en mode « autoriser tout ».
• Commentaires, Architecture, Dépendances, Portée de la modification, Sécurité, Mise en cache et le historique des actions de l'agent — le relevé des actions effectuées par l'agent, comme modifier un test juste après son échec.

La page de chaque règle dans Qualité → Vérifications → Anti-slop indique ce qu'elle concerne et pourquoi elle est importante.

Seules les constatations introduites par la modification entraînent un blocage.#

La plupart des dépôts contiennent déjà certains de ces schémas. Anti-slop classe chaque constatation en 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 issue d'une règle bloquante fait échouer la vérification. Les constatations touchées et existantes sont enregistrées pour que vous puissiez voir votre dette technique, mais elles n'empêchent jamais le travail non lié. Déplacer du code ne compte pas comme une introduction ; la copier, si.

Ajouter cette vérification à une politique#

Ouvrez une politique dans Qualité → Politiques et sélectionnez Ajouter un préréglage anti-slop. Cela ajoute cinq exigences :

1. Les tests confirment toujours la validité de la modification.
2. Rien de non terminé ou destiné uniquement aux tests n'est livré.
3. Aucune nouvelle dette structurelle n'est créée.
4. La modification reste dans la portée prévue et s'intègre bien à la base de code.
5. Les nouvelles dépendances sont réelles et fiables.

Publiez la politique, et la prochaine exécution de chaque projet associé inclura cette vérification.

Choisir une discipline de modification#

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

• Chirurgicale — uniquement ce que spécifie le cahier des charges ; les autres problèmes sont signalés, mais non corrigés.
• Équilibrée (par défaut) — corrige également de petits problèmes sur les lignes touchées par la modification.
• Restauratrice — nettoie également les constatations trouvées dans les fonctions modifiées par la modification.

L'agent applique les mêmes règles avant de soumettre sa proposition : il connaît la discipline et vos schémas mis en quarantaine dès le départ, voit les règles rapides après chaque édition, et dispose d'une seule chance de corriger les constatations bloquantes avant la phase de contrôle qualité.

Adapter cela à votre base de code#

• Redéfinitions de règles — désactiver une règle ou la faire suggérer plutôt que bloquer, dans les paramètres de la vérification.
• Paquets de règles — vos propres schémas, imports et dépendances interdits, limites de taille de fichier, ou résultats d'outils que vous utilisez déjà (SARIF). Les paquets sont versionnés ; une politique verrouille la version utilisée.
• Quarantaine — schémas que vous ne voulez plus voir copiés, chacun avec le remplaçant à utiliser. Les agents sont informés de ne pas les diffuser, et les nouvelles copies sont signalées.
• Fichier de dépôt — .coroid/anti-slop.yml dans le dépôt permet d'ajouter des règles et d'exclure les chemins générés ou externes. 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.

Constatations et dérogations#

Les constatations apparaissent dans Qualité → Constatations, filtrées par vérification. Pour accepter une constatation, renoncez-y en indiquant une raison ; cette renonciation est enregistrée pour cette constatation précise. Les agents ne peuvent pas renoncer à leurs propres constatations. Lorsqu'un agent indique qu'un test est erroné et le modifie, un réviseur doit approuver ce changement avant que la vérification ne soit validée.

Règles de jugement#

Deux règles interrogent le modèle, ligne par ligne : une vérification défensive pour détecter ce qui est impossible avec le code affiché, et un commentaire qui contredit le code voisin. Elles se contentent de donner des conseils, sans jamais bloquer. Activer les règles de jugement est activé pour une nouvelle vérification, avec une limite de décisions par exécution ; désactivez-le dans les paramètres de la vérification.

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, sur le Dette technique onglet de Qualité → Vérifications → Anti-slop, fournit la discipline de modification du projet, la quarantaine et les principales règles sous forme d'une section à coller dans les instructions de vos agents.
• Via le serveur MCP Coroid MCP server, anti_slop_rules décrit votre politique publiée et anti_slop_scan analyse une branche d'un projet synchronisé en mode lecture seule.