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

Un ciclo di migrazione che tiene le prove della riparazione separate dall’accettazione.

Lo stato della build originale viene registrato e si applica la conversione basata su regole, poi prima della riparazione si raccolgono prove da sorgenti e POM. Dopo la modifica di un modello, build, test e integrità dei test vengono ricontrollati, e le esecuzioni che terminano a un limite o in stallo sono riportate separatamente dal successo.

Combina la conversione basata su regole con la riparazione assistita da un modello e verifica il codice modificato con build e test. Un progetto di lavoro.

Lavoro su REODE nel repository; incarico presso pinxlab dal March 16, 2026 al May 26, 2026

Uno strumento CLI usato per lavoro.

Mappa del ciclo di riparazione · da registri privati di implementazione
Ciclo di riparazione della migrazione REODELo stato della build originale viene conservato come baseline, si applica la conversione basata su regole, e build e test verificano il risultato. In caso di fallimento, prima di qualsiasi correzione si raccolgono prove da sorgenti, annotazioni e POM, e i pattern noti vengono corretti in modo deterministico e ricompilati. Se la rebuild passa, non si chiama alcun modello; se fallisce, un modello ripara con le prove raccolte e le istruzioni di correzione, e il risultato viene verificato di nuovo. Le esecuzioni che terminano al limite di iterazioni o in stallo passano alla misurazione ma non contano come successo, e la scorecard assegna un voto solo quando passano tutti e cinque i gate di accettazione.Sorgenti · POMInput di migrazione privatoScorecard · votoNon è un deploymentRapporto di fallimento · stalloNon contato come successoVerifica dell’originaleStato originale · compilazioneStato dell’esecuzioneBaseline · valori ignoti non misuratiRegistri di ripristinoCheckpoint prima della correzioneCorrezione precedente, stesso erroreConversionePiano → conversione basata su regoleEsplorare prima di correggereProve della causa · 3 sorgenti · POMCorrezione deterministicaCorrezione dei pattern notiVerifica della rebuildRiparazione del modelloCorrezione con prove · istruzioniVerificabuild · test · iterazione +1Passo successivoContinua · misura · max 3MisurazioneQuota di regole · test · copertura5 gate di accettazioneIngresso · baselineRegistri di ripristinoConversione · riparazioneVerifica · uscita1 sorgenti · POM · Sorgenti · POM → Stato originale · compilazione12compilazione originale3 conversione a regole · Stato originale · compilazione → Piano → conversione basata su regole34build · test5risultato · iterazioni6superato · limite · stallo7confronto con la baseline8 valutazione · 5 gate di accettazione → Scorecard · voto81risultato · iterazioni2 fallito · nuovo tentativo · Continua · misura · max 3 → Prove della causa · 3 sorgenti · POM23salvataggio prima della correzione4prove · errori raggruppati5superato · LLM saltato6rebuild fallita7 correzione precedente · Correzione precedente, stesso errore → Correzione con prove · istruzioni78nuova verifica1superato · limite · stallo2confronto con la baseline3 valutazione · 5 gate di accettazione → Scorecard · voto34eliminati · esclusi · falliti5limite · uscita per stallo

Conversione a regole

Lo stato originale viene conservato come baseline; dopo la conversione a regole, build e test verificano e l’esecuzione prosegue fino alla misurazione.

  1. Sorgenti · POMsorgenti · POMStato originale · compilazioneVerifica dell’originale

    Riceve i sorgenti Java/Spring e il POM da migrare. Codice e schermate dei clienti non sono mostrati.

  2. Stato originale · compilazioneVerifica dell’originalecompilazione originaleBaseline · valori ignoti non misuratiStato dell’esecuzione

    Prima della conversione si sceglie il runtime e si compila l’originale, così una build già rotta resta nella baseline. I valori predefiniti di test e copertura nella baseline non sono misurazioni.

  3. Stato originale · compilazioneVerifica dell’originaleconversione a regolePiano → conversione basata su regoleConversione

    Il grafo dell’esecuzione procede verifica dell’originale → piano di conversione → conversione basata su regole → verifica. Le conversioni che le regole possono gestire vengono applicate per prime.

  4. Piano → conversione basata su regoleConversionebuild · testbuild · test · iterazione +1Verifica

    Build e test verificano il codice convertito e il conteggio delle iterazioni sale di uno. I risultati tornano nello stato dell’esecuzione.

  5. build · test · iterazione +1Verificarisultato · iterazioniContinua · misura · max 3Passo successivo

    Esito della build, tasso di superamento dei test e numero di iterazioni decidono il passo successivo.

  6. Continua · misura · max 3Passo successivosuperato · limite · stalloQuota di regole · test · coperturaMisurazione

    Quando build e test passano entrambi, si raggiunge il limite di iterazioni o si rileva uno stallo (dopo un tentativo di ripristino, se non ancora fatto), l’esecuzione passa alla misurazione. Passare alla misurazione non significa successo.

  7. Baseline · valori ignoti non misuratiStato dell’esecuzioneconfronto con la baselineQuota di regole · test · coperturaMisurazione

    La misurazione legge la baseline conservata nello stato dell’esecuzione. Non è una nuova esecuzione della baseline.

  8. 5 gate di accettazioneMisurazionevalutazioneScorecard · voto

    Build riuscita, tasso di superamento dei test al 100%, variazione della copertura di −5 o migliore (solo se la baseline è nota), zero test eliminati, zero esclusioni surefire. Un voto viene assegnato solo se tutti e cinque passano.

Riparazione basata sulla causa

Prima di correggere si raccolgono prove e le correzioni deterministiche vengono prima. Se la rebuild passa, il modello viene saltato; altrimenti il modello ripara con prove e istruzioni e il risultato viene verificato di nuovo.

  1. build · test · iterazione +1Verificarisultato · iterazioniContinua · misura · max 3Passo successivo

    Esito della build, tasso di superamento dei test e numero di iterazioni decidono il passo successivo.

  2. Continua · misura · max 3Passo successivofallito · nuovo tentativoProve della causa · 3 sorgenti · POMEsplorare prima di correggere

    Se la build è fallita o il tasso di superamento dei test è sotto il 100%, e il limite di iterazioni (3 per impostazione predefinita) non è raggiunto, l’esecuzione passa alla riparazione.

  3. Prove della causa · 3 sorgenti · POMEsplorare prima di correggeresalvataggio prima della correzioneCheckpoint prima della correzioneRegistri di ripristino

    Prima della correzione si salva un checkpoint. È best-effort: un salvataggio fallito non ferma la riparazione, e un salvataggio non è prova di successo.

  4. Prove della causa · 3 sorgenti · POMEsplorare prima di correggereprove · errori raggruppatiCorrezione dei pattern notiCorrezione deterministica

    Raccoglie i file Java in errore, le prime righe di un massimo di tre sorgenti, le impostazioni di annotazioni, POM e annotation processor, e gli import fino a profondità 2. Un campione delimitato, non una comprensione dell’intera codebase.

  5. Verifica della rebuildCorrezione deterministicasuperato · LLM saltatobuild · test · iterazione +1Verifica

    Se la correzione deterministica di un pattern noto (per esempio la configurazione di Lombok) fa passare la rebuild, non si chiama alcun modello. L’esecuzione torna comunque alla verifica, quindi non è l’accettazione finale.

  6. Verifica della rebuildCorrezione deterministicarebuild fallitaCorrezione con prove · istruzioniRiparazione del modello

    Se la rebuild fallisce, le prove raccolte e le istruzioni di correzione passano alla riparazione del modello. La lettura del codice mostra che il testo d’errore trasmesso è l’errore di build originale, non quello nuovo della rebuild, quindi non va letto come «vengono passati solo gli errori rimanenti». Non è un difetto riprodotto in un’esecuzione.

  7. Correzione precedente, stesso erroreRegistri di ripristinocorrezione precedenteCorrezione con prove · istruzioniRiparazione del modello

    Le correzioni precedenti registrate con la stessa firma d’errore vengono recuperate e allegate. Un registro aggiunto all’input, non un addestramento del modello.

  8. Correzione con prove · istruzioniRiparazione del modellonuova verificabuild · test · iterazione +1Verifica

    Il modello corregge tramite un percorso strutturato architect/editor, o con un prompt di tool use quando quel percorso non è disponibile o è in ripristino, e build e test verificano di nuovo. La modifica di un modello non è di per sé una build superata.

Superamento contro stallo

Un voto richiede tutti e cinque i gate; test eliminati o esclusi e uscite per limite o stallo non contano come successo.

  1. Continua · misura · max 3Passo successivosuperato · limite · stalloQuota di regole · test · coperturaMisurazione

    Quando build e test passano entrambi, si raggiunge il limite di iterazioni o si rileva uno stallo (dopo un tentativo di ripristino, se non ancora fatto), l’esecuzione passa alla misurazione. Passare alla misurazione non significa successo.

  2. Baseline · valori ignoti non misuratiStato dell’esecuzioneconfronto con la baselineQuota di regole · test · coperturaMisurazione

    La misurazione legge la baseline conservata nello stato dell’esecuzione. Non è una nuova esecuzione della baseline.

  3. 5 gate di accettazioneMisurazionevalutazioneScorecard · voto

    Build riuscita, tasso di superamento dei test al 100%, variazione della copertura di −5 o migliore (solo se la baseline è nota), zero test eliminati, zero esclusioni surefire. Un voto viene assegnato solo se tutti e cinque passano.

  4. 5 gate di accettazioneMisurazioneeliminati · esclusi · fallitiRapporto di fallimento · stallo

    I superamenti ottenuti eliminando test o con esclusioni surefire, e le build o i test falliti, restano fallimenti. I controlli su eliminazioni ed esclusioni contano zero quando Git o il POM non possono essere letti, quindi non provano che ogni violazione venga intercettata.

  5. Continua · misura · max 3Passo successivolimite · uscita per stalloRapporto di fallimento · stallo

    Un’esecuzione che termina al limite o in stallo passa comunque per la misurazione ma non viene riportata come successo. Questo distingue il modo di riportare; non è una scorciatoia che salta la misurazione.

Tutte le connessioni con lo stesso peso. Scegliendo un flusso se ne evidenzia solo il percorso, con passi numerati.

  • Continua · direzione di input, risultati e registri
  • Tratteggiata · esecuzione, giudizio, richiesta
  • Punti lunghi · osservazione e resoconto, separati dal giudizio
  • Tratteggio corto · fallimento, arresto, limite
  • Linea nera spessa · il flusso scelto; i numeri danno l’ordine
  • Riquadro · confine di codice o di stato, nominato nell’intestazione
  • Chip interno · un componente di quel confine
  • Riquadro punteggiato · fuori da quel confine
  • Contorno arancione · dove decide un modello
  • Passi della pipeline · riparazione
  • Verifica · instradamento · accettazione
  • Stato · registri
  • Esplorare prima di correggere

Disegnato da registri privati di implementazione e sviluppo. I nomi sono denominazioni pubbliche generiche; percorsi del codice e informazioni dei clienti non sono mostrati.

Input dopo una rebuild fallita
La riparazione del modello riceve le prove raccolte e le istruzioni di correzione, ma il testo d’errore trasmesso è l’errore di build originale, non quello nuovo della rebuild. Accertato leggendo il codice; non riprodotto in un’esecuzione, e i sorgenti non sono stati modificati.
Limiti dei gate
Se la baseline della copertura è ignota, quel gate viene saltato. Il controllo surefire conta le esclusioni nel POM attuale, non la differenza rispetto alla baseline. I controlli su eliminazioni ed esclusioni contano zero quando Git o il POM non possono essere letti.
Il caso e i suoi numeri
Che circa 40 errori di setter risalissero a una sola causa, la configurazione di Lombok e del POM, è una diagnosi registrata all’epoca. Non è un dato di throughput, accuratezza o consegna finale.