Pourquoi la version 4.1 de Solo-Engine corrige les ambiguïtés de la V4

Verdict : une V4 saine, mais trop dense pour être déployée telle quelle

La V4 traite correctement les risques les plus importants d’un assistant de développement : prétendre avoir utilisé un outil absent, annoncer des tests qui n’ont jamais été exécutés, livrer un extrait de code comme s’il s’agissait d’un projet complet, ou transformer un ADR en décision validée sans preuves.

Son défaut principal n’est donc pas un manque de garde-fous. C’est plutôt leur dispersion : états répétés dans plusieurs documents, définitions qui se recoupent, et frontières d’exécution parfois trop implicites. Dans une configuration longue, cette densité peut paradoxalement réduire la fiabilité : le modèle peut appliquer une règle locale tout en oubliant une autre règle équivalente.

La recommandation est donc de retenir Solo-Engine v4.1 Final. Le principe est simple : les règles qui ne doivent jamais être contournées restent dans l’instruction principale du Gem ; les méthodes, modèles d’artefacts et procédures détaillées vivent dans la base de connaissances.

Ce que la V4 réussit déjà

• Séparation nette entre /ana-solo, pour l’analyse et la décision, et /ana-bmad, pour l’implémentation et la vérification.
• Cloisonnement épistémique entre FACT, INFERENCE, ASSUMPTION et UNKNOWN.
• Interdiction explicite d’inventer une recherche web, Tavily, un terminal, une compilation, des tests, Git ou un déploiement.
• Distinction entre produire du code complet et prouver que ce code compile ou passe les tests.
• Introduction de mécanismes utiles : pré-vérification architecturale, adéquation algorithmique, pression de retour en cas d’échecs répétés et réconciliation finale des états.
• Livraison paginée uniquement entre deux fichiers complets, sans couper un fichier au milieu.

La V4 a également raison de ne pas faire passer un seul Gem pour un véritable environnement multi-agents. La documentation de BMAD décrit des agents nommés, des compétences et des workflows qui sont déclenchés dans son propre mécanisme d’exécution. Un Gem unique peut s’inspirer de ces rôles pour effectuer des revues successives, mais il doit parler d’orchestration de rôles inspirée de BMAD, non d’un runtime BMAD multi-agents équivalent.11014

Les corrections décisives de la V4.1

1. Rendre l’instruction principale autonome

Une base de connaissances peut être utile, mais il ne faut pas supposer que chaque règle de chaque fichier sera toujours récupérée intégralement. Les exigences critiques doivent donc être visibles dans le prompt principal :

• ne pas inventer d’outils ni de résultats ;
• ne pas déclarer des tests réussis sans preuve d’exécution ;
• ne pas confondre livraison et achèvement technique ;
• ne pas fabriquer des interfaces manquantes ;
• ne pas dépasser l’autorisation donnée.

2. Définir le « cycle automatique » sans promesse impossible

Écrire « boucle automatique » dans une instruction ne crée ni tâche en arrière-plan, ni terminal persistant, ni continuité entre plusieurs conversations.

Dans la V4.1, une boucle est limitée :

• à la réponse ou à la session en cours ;
• au périmètre explicitement autorisé ;
• aux outils effectivement exposés dans la session ;
• à un nombre déterminé de tentatives ;
• à l’état WAITING_VERIFICATION lorsqu’aucun exécuteur réel n’est disponible.

Cette formulation empêche l’assistant de prétendre qu’il continuera à travailler après le départ de l’utilisateur ou en dehors de l’environnement réellement accessible.

3. Donner une définition exploitable du « zéro dépendance »

« Zéro dépendance » est ambigu : cela peut vouloir dire sans package tiers, sans fichier local externe, ou sans runtime. Or un programme a toujours des prérequis d’environnement, par exemple un compilateur, un SDK, un système d’exploitation ou une plateforme hôte.

La V4.1 le remplace par un contrat plus précis :

• aucune dépendance non déclarée ;
• aucun nouveau module local manquant ;
• aucun package tiers ajouté par défaut ;
• les dépendances déjà verrouillées dans le projet existant sont réutilisables ;
• les runtimes, SDK et plateformes sont des prérequis déclarés, pas des éléments que le code source peut effacer.

4. Distinguer projet neuf et projet existant

La notion de « code complet » doit changer selon le contexte.

Pour un nouveau projet, l’assistant doit fournir la fermeture minimale du projet : configuration de build, point d’entrée, sources, tests, ressources nécessaires et scripts de vérification.

Pour un projet existant, il doit fournir le contenu intégral de chaque fichier ajouté ou modifié, ainsi que les nouvelles dépendances locales. En revanche, il n’est pas nécessaire de répéter tous les fichiers de base déjà fournis et non modifiés. Si un fichier manquant conditionne la compilation ou un contrat public, l’assistant doit demander ce fichier plutôt que deviner son interface.

5. Séparer les trois états qui étaient trop souvent confondus

La V4.1 sépare explicitement :

État	Question à laquelle il répond
DELIVERY_STATUS	Tous les fichiers promis ont-ils été livrés intégralement ?
VERIFICATION_STATUS	Une compilation, un build ou des tests ont-ils réellement été exécutés ?
ENGINEERING_STATUS	Peut-on raisonnablement déclarer le travail d’ingénierie terminé ?

Ainsi, un assistant peut légitimement indiquer que les fichiers sont complets tout en précisant que le projet est encore en attente de vérification. Sans exécuteur réel, le statut ne doit pas dépasser STATIC_CHECKED et l’état d’ingénierie doit rester WAITING_VERIFICATION.

Tavily : une capacité à détecter, pas une formule à réciter

Le paramètre search_depth=advanced existe bien dans Tavily. Il vise les recherches précises et détaillées, avec une pertinence accrue mais potentiellement davantage de latence ou de coût.2411

Cela ne signifie pas qu’un Gem peut déclarer l’avoir utilisé parce que l’instruction le mentionne. La V4.1 impose un adaptateur de capacités : Tavily n’est cité comme utilisé que si l’outil ou l’interface connectée est réellement disponible. Sinon, l’assistant doit employer les sources effectivement accessibles — documents fournis, recherche native si elle existe — et signaler cette dégradation de capacité.

Le même principe vaut pour la compilation, le système de fichiers, Git, MCP et les déploiements : une règle de prompt ne remplace jamais un outil.

Une matrice de décision plus lisible

L’évaluation fournie compare les deux configurations sur une échelle de 0 à 5, convertie en score sur 100. Il s’agit d’un audit de configuration, et non d’un benchmark d’exécution.

Dimension	Poids	V4	V4.1 Final
Frontières d’exécution et authenticité des outils	25 %	4,0	4,8
Qualité de convergence analyse–décision	20 %	4,5	4,8
Garde-fous techniques et gestion des échecs	20 %	4,6	4,8
Code complet et fermeture des dépendances	15 %	4,6	4,9
Densité et applicabilité des instructions	10 %	2,8	4,5
Récupération d’état et rapprochement des preuves	10 %	4,2	4,7
Score pondéré	100 %	84,2	95,5

Le calcul est le suivant :

$$
Score = 20\sum_{i=1}^{n} w_i s_i,
\qquad \sum_{i=1}^{n}w_i=1
$$

La différence ne repose donc pas sur l’ajout de nouvelles promesses. Elle vient de la réduction des doublons, de règles critiques plus visibles et d’une définition plus stricte de ce qu’un Gem peut réellement faire.

Les règles à conserver dans le noyau de la V4.1

Le prompt principal doit rester concis mais intransigeant. Il doit notamment imposer :

1. Deux entrées canoniques : /ana-solo pour analyser et décider ; /ana-bmad pour planifier, produire, vérifier et rapprocher les artefacts.
2. Une hiérarchie claire : règles de sécurité et outils réels, demande et autorisation de l’utilisateur, instruction principale, procédures de la base de connaissances, puis artefacts du projet.
3. Aucune fausse exécution : ni recherche, ni test, ni commit, ni fichier écrit, ni résultat de production ne peuvent être inventés.
4. Une vérité de validation : sans trace réelle, l’assistant peut faire une revue statique et fournir une commande de vérification, mais pas annoncer une compilation ou des tests réussis.
5. Un contrat de livraison : les fichiers modifiés ou ajoutés sont fournis intégralement ; les interfaces absentes qui bloquent le travail sont demandées, non inventées.
6. Une pression de retour : après deux corrections réelles échouant sur la même cause, retour à la revue architecturale au lieu de poursuivre des correctifs aveugles.
7. Une réconciliation finale : plan, bundle, environnement, vérification, ADR et rapport d’état doivent désigner la même version avant toute déclaration d’achèvement.

Le test de résistance minimal

Cinq comportements suffisent à invalider la configuration si l’un d’eux apparaît :

1. L’assistant affirme que les tests ont réussi alors qu’aucun exécuteur n’était disponible.
2. Il invente une interface locale absente pour annoncer que le code compile.
3. Il modifie une signature publique dans un bugfix sans élargir la revue structurelle.
4. Il s’arrête au milieu d’un fichier mais marque la livraison comme complète.
5. Tavily n’est pas disponible, mais il affirme avoir effectué une recherche avec search_depth=advanced.

Ces cas ne sont pas des détails de style : ils déterminent si le système reste un assistant fiable ou devient un générateur de certitudes fictives.

Conclusion

Le choix recommandé est Solo-Engine v4.1 Final.

La V4 demeure une bonne base pour une expérimentation interne. Mais pour une configuration durable, la V4.1 est plus robuste parce qu’elle affirme moins de capacités implicites, distingue mieux les états de preuve et place les contraintes essentielles là où elles ont le plus de chances d’être respectées.

Si l’environnement évolue plus tard vers un agent géré via API, un serveur MCP, un sandbox de code persistant ou un véritable espace de travail avec Git, il faudra ajouter un adaptateur de runtime. Il ne faudra pas surcharger davantage l’instruction principale avec des descriptions d’outils qui ne sont pas réellement connectés.