IT
Il personaggio originale di REODE, rifinito: un volto di axolotl sorridente color crema e rosa con cuffie blu navy e lenti ciano
Torna alla sala

REODE

Code migration

Prima di correggere, trovare la causa comune.

Un agente di migrazione di codice Java/Spring.

2026.03 — 2026.04

Progetto di lavoro · sistema di migrazione e verifica

  • CLIImplementato · progetto di lavoro

Far leggere prima la configurazione all’agente di riparazione

L’agente che tentava correzioni setter per setter è l’agente di riparazione all’interno del prodotto REODE; lo sviluppo ne ha cambiato l’input. Codice e informazioni dei clienti sono privati.

Legenda completa

Come leggere · una grammatica per ogni caso

  • Le colonne indicano chi ha agito; dall’alto in basso scorre il tempo
  • Continua: un passaggio di consegne registrato o un passo successivo
  • Linea lapislazzuli spessa ↩: un rilievo che ha rimandato indietro il lavoro
  • Tratteggiata: non un’esecuzione registrata (una regola scritta, un consiglio senza autorità, un confine non verificato)
  • Rettangolo: un’azione
  • Arrotondato: uno stato osservato o un rilievo
  • Angolo piegato: un artefatto o una prova
  • Colonna a righe oblique: parti del prodotto in sviluppo (non gli agenti usati per costruirlo)

March 21, 2026

Gruppi di errori, la build originale e la configurazione di Lombok sono diventati l’input della riparazione

  1. In sviluppoAgente di riparazione di REODE

    Osservazione · rilievoTentate correzioni singole per circa 40 errori di setter · @Data / POM non esaminati

  2. PersonaSviluppatore

    AzioneLeggere sorgenti e configurazione di build prima di correggere

    • consegnaInput della riparazione cambiato→ Build della baseline originale · raggruppare errori con lo stesso pattern (Modifiche di sviluppo)

  3. Sessione di lavoroModifiche di sviluppo

    AzioneBuild della baseline originale · raggruppare errori con lo stesso pattern

    • consegna→ Raccolta delle prove: percorsi · 3 campioni di sorgenti · annotazioni · POM (Modifiche di sviluppo)

  4. Regola scrittaRegole per i contributori

    Regola · non verificataPiano dell’attività · worktree di proprietà

    • non un’esecuzione registrataRichiesto dalla regola→ Build della baseline originale · raggruppare errori con lo stesso pattern (Modifiche di sviluppo)

  5. Sessione di lavoroModifiche di sviluppo

    AzioneRaccolta delle prove: percorsi · 3 campioni di sorgenti · annotazioni · POM

    • consegna→ Prima la correzione deterministica di Lombok · LLM saltato se la rebuild passa (Modifiche di sviluppo)

  6. Regola scrittaRegole per i contributori

    Regola · non verificataRevisione zero-context: piano ↔ diff

    • non un’esecuzione registrataRichiesto dalla regola→ Raccolta delle prove: percorsi · 3 campioni di sorgenti · annotazioni · POM (Modifiche di sviluppo)

  7. Sessione di lavoroModifiche di sviluppo

    AzionePrima la correzione deterministica di Lombok · LLM saltato se la rebuild passa

    • consegnaRebuild fallita→ Se la rebuild fallisce, riparazione del modello con prove e istruzioni di correzione (Agente di riparazione di REODE)

  8. In sviluppoAgente di riparazione di REODE

    Osservazione · rilievoSe la rebuild fallisce, riparazione del modello con prove e istruzioni di correzione

    • consegnaSegnali di verifica→ Scorecard: build · test · test eliminati · esclusioni surefire (Artefatti)

  9. ArtefattiArtefatti

    ArtefattoScorecard: build · test · test eliminati · esclusioni surefire

  10. Sessione di lavoroModifiche di sviluppo

    AzioneI fallimenti rimanenti tornano alla raccolta delle prove

Contesto
L’agente di riparazione cercava di correggere uno alla volta circa 40 errori setMsg() not found senza guardare @Data o la versione di Lombok in pom.xml. L’input già rotto non veniva distinto dagli errori introdotti dalla migrazione.
Esito
La scorecard legge i risultati di build e test insieme al numero di test eliminati e di esclusioni surefire, e salta la voce della copertura quando la baseline è ignota. Passare eliminando test resta un fallimento.
Limite
La raccolta delle prove campiona al massimo tre sorgenti, quindi non è una comprensione dell’intera codebase. Non c’è registro che worktree, revisione indipendente o merge queue develop previsti dalla regola siano stati effettivamente applicati a questo caso, e l’agente di programmazione e il modello di questo caso non sono confermati. Non esistono risultati finali di test o copertura dei clienti.
Fonti e limiti residui
  • L’attività di baseline e quella di esplorazione prima della correzione sono passate da in corso a completate, e ci sono commit di implementazione. Non sono stati recuperati nuovi risultati dei controlli GitHub.
  • La regola di questo repository fissa una merge queue feature → develop → main, ma la stessa procedura non viene applicata ad altri progetti.
  • Gli agenti di validazione attivabili su richiesta sono un meccanismo dell’implementazione, non la prova che siano stati usati in ogni consegna. Dati come dimensioni o rapporti delle consegne non sono inclusi perché le loro prove originali non hanno potuto essere confermate.
  • Quando la rebuild fallisce, la riparazione del modello riceve comunque l’errore di build originale, non quello nuovo della rebuild.