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

Faire lire d’abord la configuration à l’agent de réparation

L’agent qui tentait des corrections setter par setter est l’agent de réparation intégré au produit REODE ; le développement a modifié son entrée. Le code et les informations clients sont privés.

Légende complète

Mode de lecture · une même grammaire pour chaque cas

  • Les colonnes indiquent qui a agi ; de haut en bas, le temps
  • Trait plein : une passation consignée ou une étape suivante
  • ↩ lapis épais : un constat qui a renvoyé le travail
  • Tirets : pas une exécution consignée (une règle écrite, un conseil sans autorité, une frontière non vérifiée)
  • Rectangle : une action
  • Arrondi : un état observé ou un constat
  • Coin plié : un artefact ou une preuve
  • Colonne hachurée : parties du produit en développement (pas les agents qui ont servi à le construire)

March 21, 2026

Groupes d’erreurs, build d’origine et configuration Lombok sont devenus l’entrée de la réparation

  1. En développementAgent de réparation REODE

    Observation · constatCorrections individuelles tentées pour environ 40 erreurs de setter · @Data / POM non examinés

  2. PersonneDéveloppeur

    ActionLire la source et la configuration de build avant de corriger

    • passationEntrée de réparation modifiée→ Construire la référence d’origine · regrouper les erreurs de même motif (Changements de développement)

  3. Session de travailChangements de développement

    ActionConstruire la référence d’origine · regrouper les erreurs de même motif

    • passation→ Réunir les preuves : chemins · 3 échantillons de sources · annotations · POM (Changements de développement)

  4. Règle écritePolitique des contributeurs

    Règle · non vérifiéePlan de tâches · worktree détenu

    • pas une exécution consignéeExigé par la politique→ Construire la référence d’origine · regrouper les erreurs de même motif (Changements de développement)

  5. Session de travailChangements de développement

    ActionRéunir les preuves : chemins · 3 échantillons de sources · annotations · POM

    • passation→ Correctif Lombok déterministe d’abord · LLM sauté si la reconstruction réussit (Changements de développement)

  6. Règle écritePolitique des contributeurs

    Règle · non vérifiéeRevue sans contexte : plan ↔ diff

    • pas une exécution consignéeExigé par la politique→ Réunir les preuves : chemins · 3 échantillons de sources · annotations · POM (Changements de développement)

  7. Session de travailChangements de développement

    ActionCorrectif Lombok déterministe d’abord · LLM sauté si la reconstruction réussit

    • passationReconstruction échouée→ Si la reconstruction échoue, réparation par modèle avec preuves et instructions de correction (Agent de réparation REODE)

  8. En développementAgent de réparation REODE

    Observation · constatSi la reconstruction échoue, réparation par modèle avec preuves et instructions de correction

    • passationSignaux de vérification→ Scorecard : build · test · tests supprimés · exclusions surefire (Artefacts)

  9. ArtefactsArtefacts

    ArtefactScorecard : build · test · tests supprimés · exclusions surefire

  10. Session de travailChangements de développement

    ActionLes échecs restants retournent à la collecte de preuves

Contexte
L’agent de réparation tentait de corriger une à une environ 40 erreurs setMsg() not found sans regarder @Data ni la version de Lombok dans pom.xml. Une entrée déjà cassée n’était pas distinguée des erreurs introduites par la migration.
Résultat
La scorecard lit les résultats de build et de test avec le nombre de tests supprimés et d’exclusions surefire, et saute l’item couverture quand la référence est inconnue. Réussir en supprimant des tests reste un échec.
Limite
La collecte de preuves échantillonne jusqu’à trois sources ; ce n’est donc pas une compréhension de toute la base de code. Rien n’indique que le worktree, la revue indépendante ou la file de fusion develop de la politique se soient réellement appliqués à ce cas, et l’agent de code et le modèle de ce cas ne sont pas confirmés. Il n’existe pas de résultats finaux de tests ou de couverture chez le client.
Sources et limites restantes
  • La tâche de référence et la tâche d’exploration avant correction sont passées de en cours à terminé, et des commits d’implémentation existent. Aucun résultat récent de contrôle GitHub n’a été récupéré.
  • La politique de ce dépôt prévoit une file de fusion feature → develop → main, mais la même procédure n’est pas appliquée aux autres projets.
  • Les agents de validation optionnels sont un mécanisme de l’implémentation, pas la preuve qu’ils ont servi à chaque livraison. Les chiffres comme la taille ou les ratios de livraison ne figurent pas, faute d’avoir pu confirmer leurs preuves d’origine.
  • Quand la reconstruction échoue, la réparation par modèle reçoit toujours l’erreur de build d’origine, pas la nouvelle erreur de la reconstruction.