GSD-Lite : Une machine à états pour le code Claude qui impose le TDD et empêche le contournement des tests

GSD-Lite est un serveur MCP open-source qui se greffe à Claude Code et fait passer les projets par une machine de workflow à 12 états. L'outil est sous licence MIT et comprend environ 15 fichiers source au total.

Fonctionnement

Après avoir planifié ce qu'il faut construire en conversation avec Claude, GSD-Lite prend automatiquement le relais : écrire le code, le revoir, le vérifier, passer à la phase suivante. La boucle d'exécution suit ce schéma :

• L'orchestrateur choisit la tâche suivante
• L'exécuteur écrit le code (TDD, point de contrôle)
• Le réviseur vérifie (contexte séparé, spécifications + qualité)
• Accepté ? Tâche suivante. Rejeté ? Retravailler.
• Toutes les tâches terminées ? Vérification de la porte de phase
• La porte passe ? Phase suivante
• Toutes les phases terminées ? C'est fini

Fonctionnalités clés

Application du TDD : La "Loi de fer" est intégrée à chaque distribution de tâche : pas de code de production sans un test en échec au préalable. L'invite liste les rationalisations exactes que Claude utilise pour sauter les tests ("Ce n'est qu'un changement de configuration", "Les tests existants couvrent déjà cela") et les signale comme des excuses connues.

Contextes d'agents séparés : Les revues s'exécutent dans un contexte d'agent séparé où le réviseur ne voit jamais le raisonnement de l'exécuteur—seulement le diff et les spécifications de la tâche. Cela évite les approbations automatiques et aide à détecter les vrais bugs.

Agent débogueur : Lorsqu'une tâche échoue 3 fois, au lieu d'une autre tentative, un agent débogueur est envoyé. Cet agent séparé reproduit l'échec, formule des hypothèses, les teste, identifie où la correction doit aller, puis fournit ses conclusions à l'exécuteur.

Suivi des dépendances : Si une tâche modifie la signature d'une API, tout ce qui en dépend est invalidé et remis en file d'attente automatiquement.

Détails techniques

Le système utilise 6 commandes, 4 agents et 11 outils MCP. L'état est géré dans un fichier JSON avec validation de schéma et les conflits de version gérés via un contrôle de concurrence optimiste.

Pourquoi pas la version originale

La première version avait 32 commandes, 12 agents, plus de 100 fichiers source et un installateur de 2400 lignes. L'auteur l'a jetée et a tout réécrit à partir de zéro car la plupart de cette complexité brûlait la fenêtre de contexte sans apporter de valeur.

Découvertes inattendues

L'approche anti-rationalisation fonctionne—lister des phrases spécifiques que Claude utilise pour sauter des étapes directement dans l'invite de l'agent a réduit le taux de saut. L'auteur note que les exemples négatifs semblent mieux guider le modèle que de simplement dire "toujours écrire des tests". La persistance de session a été le défi d'implémentation le plus difficile.