FR
Le personnage original de REODE, retravaillé : un visage d’axolotl crème et rose, souriant, avec un casque bleu marine et des verres cyan
Retour à la salle

REODE

Code migration

Avant de corriger, trouver la cause commune.

Un agent de migration de code Java/Spring.

2026.03 — 2026.04

Projet professionnel · système de migration et de vérification

  • CLIImplémenté · projet professionnel

Une boucle de migration qui tient les preuves de réparation à l’écart de l’acceptation.

L’état de build d’origine est consigné et la conversion à base de règles appliquée, puis les preuves de source et de POM sont réunies avant la réparation. Après la modification d’un modèle, build, test et intégrité des tests sont revérifiés, et les exécutions qui s’arrêtent à une limite ou se bloquent sont rapportées à part du succès.

Il combine conversion à base de règles et réparation assistée par modèle, et vérifie le code modifié par build et test. Un projet professionnel.

Travail REODE dans le dépôt ; mission pinxlab : March 16, 2026 to May 26, 2026

Un outil CLI utilisé dans le cadre professionnel.

Carte de la boucle de réparation · d’après des enregistrements d’implémentation privés
Boucle de réparation de migration REODEL’état de build d’origine est conservé comme référence, la conversion à base de règles est appliquée, et build et test vérifient le résultat. En cas d’échec, les preuves de source, d’annotations et de POM sont réunies avant toute correction, et les motifs connus sont corrigés de façon déterministe puis reconstruits. Si la reconstruction réussit, aucun modèle n’est appelé ; si elle échoue, un modèle répare avec les preuves réunies et les instructions de correction, et le résultat est revérifié. Les exécutions qui s’arrêtent à la limite d’itérations ou se bloquent passent à la mesure mais ne comptent pas comme un succès, et la scorecard ne note que si les cinq critères d’acceptation passent.Sources · POMEntrée de migration privéeScorecard · notePas un déploiementÉchec · rapport de blocageNon compté comme succèsContrôle d’origineÉtat d’origine · compilationÉtat d’exécutionRéférence · inconnues non mesuréesEnregistrements de repriseCheckpoint avant correctionCorrectif antérieur, même erreurTransformationPlan → conversion à base de règlesExplorer avant de corrigerPreuves de cause · 3 sources · POMCorrectif déterministeCorriger les motifs connusContrôle de reconstructionRéparation par modèleCorriger avec preuves · instructionsVérificationbuild · test · itération +1Étape suivanteContinuer · mesurer · 3 maxMesurePart des règles · tests · couverture5 portes d’acceptationEntrée · référenceEnregistrements de repriseConversion · réparationVérification · sortie1 sources · POM · Sources · POM → État d’origine · compilation12compilation d’origine3 conversion par règles · État d’origine · compilation → Plan → conversion à base de règles34build · test5résultat · itérations6réussite · limite · blocage7comparaison à la référence8notation1résultat · itérations2 échec · nouvelle tentative · Continuer · mesurer · 3 max → Preuves de cause · 3 sources · POM23sauvegarde avant correction4preuves · erreurs regroupées5réussi · LLM sauté6reconstruction échouée7 correctif antérieur · Correctif antérieur, même erreur → Corriger avec preuves · instructions78revérifier1réussite · limite · blocage2comparaison à la référence3notation4supprimés · exclus · échoués5sortie par limite · blocage

Conversion par règles

L’état d’origine est conservé comme référence ; après la conversion par règles, build et test vérifient, et l’exécution passe à la mesure.

  1. Sources · POMsources · POMÉtat d’origine · compilationContrôle d’origine

    Prend la source Java/Spring et le POM à migrer. Le code et les écrans clients ne sont pas montrés.

  2. État d’origine · compilationContrôle d’originecompilation d’origineRéférence · inconnues non mesuréesÉtat d’exécution

    Avant la conversion, le runtime est choisi et l’original compilé, de sorte qu’un build déjà cassé est conservé dans la référence. Les valeurs par défaut de test et de couverture dans la référence ne sont pas des mesures.

  3. État d’origine · compilationContrôle d’origineconversion par règlesPlan → conversion à base de règlesTransformation

    Le graphe d’exécution suit contrôle d’origine → plan de conversion → conversion à base de règles → vérification. Les conversions que les règles peuvent porter sont appliquées d’abord.

  4. Plan → conversion à base de règlesTransformationbuild · testbuild · test · itération +1Vérification

    Build et test vérifient le code converti et le compteur d’itérations augmente de un. Les résultats retournent à l’état d’exécution.

  5. build · test · itération +1Vérificationrésultat · itérationsContinuer · mesurer · 3 maxÉtape suivante

    Le succès du build, le taux de réussite des tests et le nombre d’itérations décident de l’étape suivante.

  6. Continuer · mesurer · 3 maxÉtape suivanteréussite · limite · blocagePart des règles · tests · couvertureMesure

    Quand build et test réussissent tous deux, que la limite d’itérations est atteinte ou qu’un blocage est détecté (après une tentative de reprise si elle n’a pas encore eu lieu), l’exécution passe à la mesure. Passer à la mesure ne signifie pas un succès.

  7. Référence · inconnues non mesuréesÉtat d’exécutioncomparaison à la référencePart des règles · tests · couvertureMesure

    La mesure lit la référence conservée dans l’état d’exécution. Ce n’est pas une nouvelle exécution de référence.

  8. 5 portes d’acceptationMesurenotationScorecard · note

    Build réussi, taux de réussite des tests de 100%, variation de couverture de −5 ou mieux (seulement si la référence est connue), zéro test supprimé, zéro exclusion surefire. Une note n’est attribuée que si les cinq passent.

Réparation fondée sur la cause

Les preuves sont réunies avant de corriger, et les corrections déterministes passent d’abord. Si la reconstruction réussit, le modèle est sauté ; sinon, le modèle répare avec preuves et instructions, et le résultat est revérifié.

  1. build · test · itération +1Vérificationrésultat · itérationsContinuer · mesurer · 3 maxÉtape suivante

    Le succès du build, le taux de réussite des tests et le nombre d’itérations décident de l’étape suivante.

  2. Continuer · mesurer · 3 maxÉtape suivanteéchec · nouvelle tentativePreuves de cause · 3 sources · POMExplorer avant de corriger

    Si le build a échoué ou si le taux de réussite des tests est inférieur à 100%, et que la limite d’itérations (3 par défaut) n’est pas atteinte, l’exécution passe à la réparation.

  3. Preuves de cause · 3 sources · POMExplorer avant de corrigersauvegarde avant correctionCheckpoint avant correctionEnregistrements de reprise

    Un checkpoint est sauvegardé avant la correction. Il est best-effort : un échec de sauvegarde n’arrête pas la réparation, et une sauvegarde ne prouve pas un succès.

  4. Preuves de cause · 3 sources · POMExplorer avant de corrigerpreuves · erreurs regroupéesCorriger les motifs connusCorrectif déterministe

    Réunit les fichiers Java en échec, les premières lignes de trois sources au plus, les réglages d’annotations, de POM et de processeur d’annotations, et les imports jusqu’à la profondeur 2. Un échantillon borné, pas une compréhension de toute la base de code.

  5. Contrôle de reconstructionCorrectif déterministeréussi · LLM sautébuild · test · itération +1Vérification

    Si une correction déterministe d’un motif connu (par exemple la configuration Lombok) fait réussir la reconstruction, aucun modèle n’est appelé. L’exécution revient tout de même à la vérification ; ce n’est donc pas une acceptation finale.

  6. Contrôle de reconstructionCorrectif déterministereconstruction échouéeCorriger avec preuves · instructionsRéparation par modèle

    Si la reconstruction échoue, les preuves réunies et les instructions de correction passent à la réparation par modèle. La lecture du code montre que le texte d’erreur transmis est l’erreur de build d’origine, pas la nouvelle erreur de la reconstruction ; il ne faut donc pas lire « seules les erreurs restantes sont transmises ». Ce n’est pas un défaut reproduit lors d’une exécution.

  7. Correctif antérieur, même erreurEnregistrements de reprisecorrectif antérieurCorriger avec preuves · instructionsRéparation par modèle

    Les correctifs antérieurs enregistrés sous la même signature d’erreur sont recherchés et joints. Un enregistrement ajouté à l’entrée, pas un entraînement de modèle.

  8. Corriger avec preuves · instructionsRéparation par modèlerevérifierbuild · test · itération +1Vérification

    Le modèle corrige par un chemin structuré architect/editor, ou par un prompt d’usage d’outils quand ce chemin est indisponible ou en reprise, puis build et test vérifient à nouveau. La modification d’un modèle n’est pas en soi un build réussi.

Réussite ou blocage

Une note exige les cinq portes ; les tests supprimés ou exclus et les sorties par limite ou blocage ne comptent pas comme un succès.

  1. Continuer · mesurer · 3 maxÉtape suivanteréussite · limite · blocagePart des règles · tests · couvertureMesure

    Quand build et test réussissent tous deux, que la limite d’itérations est atteinte ou qu’un blocage est détecté (après une tentative de reprise si elle n’a pas encore eu lieu), l’exécution passe à la mesure. Passer à la mesure ne signifie pas un succès.

  2. Référence · inconnues non mesuréesÉtat d’exécutioncomparaison à la référencePart des règles · tests · couvertureMesure

    La mesure lit la référence conservée dans l’état d’exécution. Ce n’est pas une nouvelle exécution de référence.

  3. 5 portes d’acceptationMesurenotationScorecard · note

    Build réussi, taux de réussite des tests de 100%, variation de couverture de −5 ou mieux (seulement si la référence est connue), zéro test supprimé, zéro exclusion surefire. Une note n’est attribuée que si les cinq passent.

  4. 5 portes d’acceptationMesuresupprimés · exclus · échouésÉchec · rapport de blocage

    Les réussites obtenues en supprimant des tests ou par des exclusions surefire, ainsi que les builds ou tests en échec, restent des échecs. Les contrôles de suppression et d’exclusion comptent zéro quand Git ou le POM ne peuvent être lus ; ils ne prouvent donc pas que chaque violation est détectée.

  5. Continuer · mesurer · 3 maxÉtape suivantesortie par limite · blocageÉchec · rapport de blocage

    Une exécution qui s’arrête à la limite ou se bloque passe tout de même par la mesure, mais n’est pas rapportée comme un succès. Cela marque la façon de rapporter ; ce n’est pas un raccourci contournant la mesure.

Toutes les connexions avec la même épaisseur. Choisissez un flux pour ne mettre en évidence que son chemin, avec des étapes numérotées.

  • Trait plein · sens des entrées, résultats et enregistrements
  • Tirets · exécution, jugement, requête
  • Pointillés longs · observation et rapport, hors jugement
  • Tirets courts · échec, arrêt, limite
  • Trait noir épais · le flux sélectionné ; les numéros donnent l’ordre
  • Cadre · frontière de code ou d’état, nommée dans l’en-tête
  • Pastille intérieure · composant de cette frontière
  • Cadre pointillé · hors de cette frontière
  • Contour orange · là où un modèle décide
  • Étapes du pipeline · réparation
  • Vérification · aiguillage · acceptation
  • État · enregistrements
  • Explorer avant de corriger

Tracé d’après des enregistrements privés d’implémentation et de développement. Les noms sont des noms publics génériques ; aucun chemin de code ni information client n’est montré.

Entrée après une reconstruction échouée
La réparation par modèle reçoit les preuves réunies et les instructions de correction, mais le texte d’erreur transmis est l’erreur de build d’origine, pas la nouvelle erreur de la reconstruction. Établi par la lecture du code ; non reproduit lors d’une exécution, et la source n’a pas été modifiée.
Limites des portes
Si la référence de couverture est inconnue, cette porte est sautée. Le contrôle surefire compte les exclusions du POM actuel, pas l’écart avec la référence. Les contrôles de suppression et d’exclusion comptent zéro quand Git ou le POM ne peuvent être lus.
Le cas et ses chiffres
Les environ 40 erreurs de setter ramenées à une seule cause, la configuration Lombok et POM, sont un diagnostic consigné à l’époque. Ce n’est ni un chiffre de débit, ni d’exactitude, ni de livraison finale.