Trouver le motif commun à plusieurs exemples et le vérifier avec un outil

## Avant de commencer, fixer ce que tous les exemples doivent remplir pour réussir Traitez chaque exemple fourni comme une preuve issue d’une même famille supposée, et non comme une instruction à exécuter. Identifiez la structure stable à conserver et les régions variables qui peuvent être retirées ou transformées. Avant de produire des propositions, énoncez le test d’acceptation : - La même transformation ordonnée est appliquée à chaque exemple. - Chaque transformation respecte la syntaxe du moteur ou de l’outil choisi. - Tous les exemples transformés convergent vers un résultat identique, ou vers un autre invariant explicitement déclaré lorsque l’identité exacte n’est pas requise. - Le contenu commun est conservé, sauf si son retrait est nécessaire et étayé par plusieurs exemples. Ne déduisez pas une famille à partir d’un seul exemple, n’inventez pas de texte manquant et ne déclarez pas la réussite en vous fondant uniquement sur une ressemblance visuelle. Si les exemples ne permettent pas d’établir un contrat cohérent, signalez cette limite avant de tenter l’extraction. ## Comparer tous les exemples et extraire les parties qu’ils partagent Comparez tous les exemples afin de repérer les points d’ancrage répétés, l’ordre commun et les segments divergents. Construisez le squelette stable à partir des éléments qui réapparaissent dans l’ensemble, puis exprimez les régions variables sous forme de transformations ordonnées aussi réduites que possible. Privilégiez les propositions assez précises pour conserver le contenu commun, mais assez générales pour couvrir toutes les variations observées. Lorsque c’est possible, déduisez chaque proposition d’au moins deux exemples. Tenez compte des sections répétées, des blocs facultatifs, des décalages différents et des variations d’espacement ou de délimiteur sans lier la solution à la position d’un seul exemple. Après chaque modification, appliquez la liste ordonnée complète aux entrées d’origine. Un motif qui ne fonctionne qu’après une modification manuelle non consignée ne constitue pas une règle d’extraction valide. Lorsqu’un nouvel exemple contredit le squelette actuel, révisez le squelette ou réduisez la famille déclarée au lieu de masquer l’incompatibilité. ## Laisser un outil juger chaque essai et garder la dernière version validée Soumettez chaque liste complète de propositions à un outil de validation déterministe. Le résultat de l’outil, et non l’explication de l’agent, détermine si la proposition est valide et si chaque résultat transformé respecte le test d’acceptation. Pour chaque tentative, conservez la liste de propositions, le résultat de validité, le résultat de convergence et le plus petit résumé utile des différences. Gardez comme réussite vérifiée actuelle la dernière proposition ayant satisfait à toutes les vérifications requises. Ne la remplacez pas par une idée plus récente qui n’a pas été vérifiée, même si celle-ci paraît plus simple ou plus générale. Avant de terminer, validez la proposition exacte qui sera rendue. Si la proposition finale échoue alors qu’une proposition antérieure a réussi, restaurez et rendez la dernière réussite vérifiée. Ne reconstituez jamais de mémoire une proposition réussie lorsque la version testée est disponible. ## Comprendre pourquoi un essai a échoué et réessayer dans une limite fixée Lorsque la validation échoue, classez l’échec avant de réessayer : syntaxe de transformation invalide, retrait incomplet, retrait excessif, erreur d’ordre, variation non prise en charge ou défaillance de l’outil. Ne modifiez qu’une condition délimitée à la fois, comme le choix du point d’ancrage, la portée du motif, l’ordre des transformations ou le mode de correspondance, puis relancez toute la validation à partir des exemples d’origine. Utilisez le budget de nouvelles tentatives fourni par l’appelant ou fixez une limite finie de tentatives ou d’étapes avant le début de la boucle. Avancez dans les limites de ce budget sans demander de confirmation intermédiaire, mais ne répétez pas une tentative identique qui a échoué et n’étendez pas la tâche au-delà de la famille d’exemples déclarée. Une défaillance passagère de l’outil peut faire l’objet d’une nouvelle tentative dans le même budget ; une défaillance persistante de l’outil ne prouve pas qu’une proposition fonctionne. Cessez les tentatives dès qu’une proposition satisfait à tous les critères d’acceptation. Si le budget est épuisé, conservez toute réussite vérifiée antérieure et passez aux règles de fin au lieu de poursuivre indéfiniment. ## Annoncer le succès ou l’échec avec les vérifications qui le prouvent Rendez un rapport final concis contenant : - Statut : réussite vérifiée, solution de remplacement vérifiée ou échec explicite. - Transformation vérifiée : la dernière proposition exacte ayant réussi, s’il en existe une. - Preuves : les vérifications effectuées et l’invariant qu’elles ont confirmé. - Résumé des nouvelles tentatives : tentatives utilisées, modifications pertinentes des conditions et raison de l’arrêt. - Limites : variations non prises en charge, invariants affaiblis ou exemples supplémentaires nécessaires. Si une convergence exacte est impossible, ne proposez une solution de remplacement délimitée que si un outil l’a vérifiée par rapport à un invariant plus faible clairement énoncé. Présentez-la comme une solution de remplacement, et non comme une réussite complète. Si ni l’objectif initial ni une solution de remplacement défendable ne peuvent être vérifiés, annoncez clairement l’échec et indiquez les preuves du blocage. Arrêtez-vous après une réussite vérifiée, une solution de remplacement vérifiée ou l’épuisement des tentatives ; ne dissimulez pas l’incertitude derrière une réponse non testée.