Thought Experiment ver 0.6.0 alpha — Audits et corrections rigoureux de scénarios de défaillance
Déclencheur : l'expression « thought experiment », et uniquement cette expression — pas d'équivalents inférés. Ne s'exécute jamais sans demande explicite et cible claire — c'est délibéré, pas autonome.
Périmètre : indifférent à la cible. Un fichier unique, un projet entier, une configuration, un contrat API, une infrastructure — tout ce qui fait des affirmations (sur son propre comportement, sa structure ou sur quelque chose dont il dépend) qui pourraient être erronées.
Ce qui le rend différent d'une revue normale : deux choses. D'abord, il produit des scénarios concrets — « étant donné cette entrée/cet état, voici exactement ce qui casse et pourquoi » — et non des suggestions vagues du style « cela pourrait être plus propre ». Ensuite, il chasse spécifiquement les affirmations que la cible fait sur le comportement de quelque chose d'extérieur à elle-même, car cette catégorie d'affirmation est la plus susceptible d'être silencieusement erronée de mémoire plutôt qu'attrapée en lisant la logique propre de la cible.
Vérification de commit pré-cycle (barrière de sécurité) : demander fermement, et recommander, un commit/push de toutes les modifications non commitées existantes avant de s'engager dans un cycle. Un point de contrôle propre avant signifie que le cycle lui-même peut toujours y être annulé s'il cause des dommages.
Processus
- Lire la cible à l'état réel. Récupérer son état actuel et réel — fichiers, configurations, tout ce qu'elle contient — ne pas se fier au contexte antérieur sur ce qu'elle est censée contenir.
- Énumérer ses dépendances. Tout ce que la cible considère comme vérité de base en dehors d'elle-même : pour un script — les bibliothèques importées, les API appelées, les outils CLI et leurs options, les hypothèses d'environnement/configuration ; pour un service ou une configuration cloud — les autres services auxquels il parle, les autorisations/IAM, le DNS, les certificats, les API tierces, les chemins réseau ; pour un document — chaque affirmation factuelle qu'il fait sur le comportement de quelque chose d'autre. Construire cette liste délibérément — l'étape 4 la vérifie, et une dépendance manquée est une occasion manquée d'attraper un vrai bug. Lorsque la cible est spécifiquement destinée au déploiement, vérifier également : sécurité de rollback, parité de configuration dev/prod, gestion des secrets, la ligne de base de compatibilité déclarée, et les performances en conditions réelles/première charge par rapport aux tests uniquement en dev — ceux-ci n'émergent pas toujours d'un scan de dépendances purement générique. Pour la documentation appariée (un README et son SKILL.md, ou des docs et le code/la configuration qu'elles décrivent), traiter les affirmations de chaque fichier sur ce que l'autre dit ou fait comme une dépendance à vérifier — et séparément, vérifier si les conventions de formatage établies (gras/majuscules des valeurs énumérées, style de titre) sont appliquées de manière cohérente au sein de la cible et entre ses fichiers frères, uniquement là où une telle convention existe effectivement pour servir de référence.
- Construire des expériences de pensée concrètes de scénarios de défaillance. Entrées ou états spécifiques qui conduisent à une sortie erronée spécifique, un crash ou une faille de sécurité — pas des impressions générales. Ne pas fixer un nombre de scénarios à l'avance ; continuer à en générer jusqu'à ce que la surface de risque réelle de la cible semble couverte, et non jusqu'à ce qu'un nombre arbitraire soit atteint.
- Vérifier toute affirmation de comportement de dépendance sur laquelle repose un scénario auprès d'une source en direct ou faisant autorité — docs réelles, une réponse API réelle, la sortie réelle de l'outil — plutôt que de se fier à la mémoire. Cette étape est généralement celle où se trouvent les découvertes de la plus haute valeur.
- Demander comment les corrections doivent être autorisées, une seule fois, avant d'en appliquer — options CRUD. La lecture est toujours librement accordée, jamais bloquée ; seules les opérations Créer/Mettre à jour/Supprimer font l'objet d'une autorisation. Globale (chaque constat confirmé, sans autre demande), processus (confirmer une fois par cycle, pas par fichier à l'intérieur de celui-ci), fichier (confirmer avant de passer aux corrections du fichier suivant), ou chaque étape CRUD (confirmer chaque modification individuelle) — celle que l'utilisateur choisit s'applique pour le reste de l'exécution. Globale couvre les constats confirmés de routine, pas un override inconditionnel : un constat vraiment surprenant ou à plus haut risque que ce que l'utilisateur avait en tête en l'accordant est toujours mis en pause et fait l'objet d'une question.
- Appliquer les corrections pour les constats confirmés, à la granularité autorisée.
- Ré-exécuter ce même processus sur l'état corrigé. Une correction peut introduire son propre nouveau problème — une correction de précision qui rend autre chose incohérent, une affirmation corrigée qui casse une autre hypothèse ailleurs. La boucle n'est pas terminée tant qu'un passage ne révèle rien de nouveau.
- Rapporter. Énoncer clairement la réussite/l'échec de chaque scénario. Ne fournir des détails complets que pour les échecs confirmés, ou lorsque les détails sont explicitement demandés — une réussite nette n'a pas besoin d'un essai à son sujet. Étiqueter chaque échec comme bloquant (doit être corrigé avant le déploiement/la livraison) ou non bloquant (peut être livré, corriger après) afin que le rapport serve également d'entrée go/no-go, et pas seulement de liste de constats. Conclure chaque exécution par un résumé énuméré consolidé, pas seulement des mentions scénario par scénario dispersées tout au long du processus — adapté au périmètre : une exécution multi-cibles (plusieurs fichiers, plusieurs compétences) obtient une section par cible ; une cible unique propre obtient une ligne de verdict unique, pas de cérémonie inutile.
Nouvelle ligne, conclure chaque rapport par thought experiment.