DA
Den oprindelige REODE-figur, bearbejdet: et smilende creme- og lyserødt axolotl-ansigt med marineblåt headset og cyanfarvede linser
Tilbage til salen

REODE

Code migration

Før rettelsen: den fælles årsag først.

En agent til kodemigrering af Java/Spring.

2026.03 — 2026.04

Arbejdsprojekt · migrerings- og verifikationssystem

  • CLIImplementeret · arbejdsprojekt

En migreringsløkke, der holder reparationsbelæg adskilt fra accept.

Den oprindelige build-tilstand registreres, og regelbaseret konvertering anvendes, hvorefter belæg fra kilde og POM indsamles før reparation. Efter en models ændring kontrolleres build, test og testintegritet igen, og kørsler, der ender ved en grænse eller går i stå, rapporteres adskilt fra succes.

Den kombinerer regelbaseret konvertering med modelassisteret reparation og kontrollerer den ændrede kode med build og test. Et arbejdsprojekt.

REODE-arbejde i repositoryet; opgave for pinxlab 16. marts 2026 til 26. maj 2026

Et CLI-værktøj, der bruges på arbejdet.

Kort over reparationsløkken · ud fra private implementeringslogs
REODE's reparationsløkke for migreringDen oprindelige build-tilstand bevares som baseline, regelbaseret konvertering anvendes, og build og test verificerer resultatet. Ved fejl indsamles belæg fra kilde, annotationer og POM før enhver rettelse, og kendte mønstre rettes deterministisk og bygges igen. Hvis det nye build består, kaldes ingen model; hvis det fejler, reparerer en model med det indsamlede belæg og rettelsesinstrukser, og resultatet verificeres igen. Kørsler, der ender ved iterationsgrænsen eller går i stå, går videre til måling, men tælles ikke som succes, og scorecardet giver kun karakter, når alle fem acceptgates er bestået.Kilde · POMPrivat migreringsinputScorecard · karakterIkke en udrulningRapport om fejl · stilstandTælles ikke som succesKontrol af originalOprindelig tilstand · compileKørselstilstandBaseline · ukendte værdier ikke måltGendannelseslogsCheckpoint før rettelseTidligere rettelse, samme fejlKonverteringPlan → regelbaseret konverteringUdforsk før rettelseBelæg for årsag · 3 kilder · POMDeterministisk rettelseRet kendte mønstreKontrol af nyt buildModelreparationRet med belæg · instrukserVerifikationbuild · test · iteration +1Næste trinFortsæt · mål · højst 3MålingRegelandel · tests · dækning5 acceptgatesInput · baselineGendannelseslogsKonvertering · reparationVerifikation · afslutning1kilde · POM2oprindelig compile3 regelkonvertering · Oprindelig tilstand · compile → Plan → regelbaseret konvertering34build · test5resultat · iterationer6bestået · grænse · stilstand7sammenligning med baseline8 karaktergivning · 5 acceptgates → Scorecard · karakter81resultat · iterationer2 fejlet · nyt forsøg · Fortsæt · mål · højst 3 → Belæg for årsag · 3 kilder · POM23gem før rettelse4belæg · grupperede fejl5bestået · LLM sprunget over6nyt build fejlede7 tidligere rettelse · Tidligere rettelse, samme fejl → Ret med belæg · instrukser78verificér igen1bestået · grænse · stilstand2sammenligning med baseline3 karaktergivning · 5 acceptgates → Scorecard · karakter34slettet · udelukket · fejlet5afslutning ved grænse · stilstand

Regelkonvertering

Den oprindelige tilstand bevares som baseline; efter regelkonvertering verificerer build og test, og kørslen går videre til måling.

  1. Kilde · POMkilde · POMOprindelig tilstand · compileKontrol af original

    Tager den Java/Spring-kilde og POM, der skal migreres. Kundens kode og skærme vises ikke.

  2. Oprindelig tilstand · compileKontrol af originaloprindelig compileBaseline · ukendte værdier ikke måltKørselstilstand

    Før konverteringen vælges runtimen, og originalen kompileres, så et build, der allerede var i stykker, bevares i baseline. Standardværdier for test og dækning i baseline er ikke målinger.

  3. Oprindelig tilstand · compileKontrol af originalregelkonverteringPlan → regelbaseret konverteringKonvertering

    Kørselsgrafen går kontrol af original → konverteringsplan → regelbaseret konvertering → verifikation. Konverteringer, som regler kan bære, anvendes først.

  4. Plan → regelbaseret konverteringKonverteringbuild · testbuild · test · iteration +1Verifikation

    Build og test verificerer den konverterede kode, og iterationstallet stiger med én. Resultaterne vender tilbage til kørselstilstanden.

  5. build · test · iteration +1Verifikationresultat · iterationerFortsæt · mål · højst 3Næste trin

    Vellykket build, beståelsesrate for tests og iterationstallet afgør næste trin.

  6. Fortsæt · mål · højst 3Næste trinbestået · grænse · stilstandRegelandel · tests · dækningMåling

    Når både build og test består, iterationsgrænsen nås, eller der registreres stilstand (efter ét gendannelsesforsøg, hvis det ikke er prøvet endnu), går kørslen til måling. At gå til måling betyder ikke succes.

  7. Baseline · ukendte værdier ikke måltKørselstilstandsammenligning med baselineRegelandel · tests · dækningMåling

    Målingen læser den baseline, der er bevaret i kørselstilstanden. Det er ikke en ny baseline-kørsel.

  8. 5 acceptgatesMålingkaraktergivningScorecard · karakter

    Vellykket build, en beståelsesrate for tests på 100%, en ændring i dækning på −5 eller bedre (kun når baseline er kendt), nul slettede tests, nul surefire-udelukkelser. En karakter gives kun, når alle fem består.

Årsagsbaseret reparation

Belæg indsamles før rettelse, og deterministiske rettelser kommer først. Hvis det nye build består, springes modellen over; ellers reparerer modellen med belæg og instrukser, og resultatet verificeres igen.

  1. build · test · iteration +1Verifikationresultat · iterationerFortsæt · mål · højst 3Næste trin

    Vellykket build, beståelsesrate for tests og iterationstallet afgør næste trin.

  2. Fortsæt · mål · højst 3Næste trinfejlet · nyt forsøgBelæg for årsag · 3 kilder · POMUdforsk før rettelse

    Hvis build fejlede, eller beståelsesraten for tests er under 100%, og iterationsgrænsen (som standard 3) ikke er nået, går kørslen til reparation.

  3. Belæg for årsag · 3 kilder · POMUdforsk før rettelsegem før rettelseCheckpoint før rettelseGendannelseslogs

    Et checkpoint gemmes før rettelsen. Det er best-effort: en mislykket lagring stopper ikke reparationen, og en lagring er ikke belæg for succes.

  4. Belæg for årsag · 3 kilder · POMUdforsk før rettelsebelæg · grupperede fejlRet kendte mønstreDeterministisk rettelse

    Indsamler de fejlende Java-filer, de første linjer af op til tre kilder, indstillinger for annotationer, POM og annotation processor samt imports til dybde 2. En afgrænset prøve, ikke en forståelse af hele kodebasen.

  5. Kontrol af nyt buildDeterministisk rettelsebestået · LLM sprunget overbuild · test · iteration +1Verifikation

    Hvis en deterministisk rettelse af et kendt mønster (for eksempel Lombok-opsætningen) får det nye build til at bestå, kaldes ingen model. Kørslen vender stadig tilbage til verifikation, så dette er ikke endelig accept.

  6. Kontrol af nyt buildDeterministisk rettelsenyt build fejledeRet med belæg · instrukserModelreparation

    Hvis det nye build fejler, går det indsamlede belæg og rettelsesinstrukserne til modelreparation. Læsning af koden viser, at den fejltekst, der sendes med, er den oprindelige build-fejl, ikke det nye builds fejl, så det må ikke læses som »kun de resterende fejl sendes videre«. Ikke en defekt, der er reproduceret i en kørsel.

  7. Tidligere rettelse, samme fejlGendannelseslogstidligere rettelseRet med belæg · instrukserModelreparation

    Tidligere rettelser registreret under samme fejlsignatur slås op og vedhæftes. En log, der føjes til inputtet, ikke modeltræning.

  8. Ret med belæg · instrukserModelreparationverificér igenbuild · test · iteration +1Verifikation

    Modellen retter via en struktureret architect/editor-sti, eller via en tool-use-prompt, når den sti ikke er tilgængelig eller er under gendannelse, og build og test verificerer igen. En models ændring er ikke i sig selv et bestået build.

Bestået kontra stilstand

En karakter kræver alle fem gates; slettede eller udelukkede tests og afslutninger ved grænse eller stilstand tælles ikke som succes.

  1. Fortsæt · mål · højst 3Næste trinbestået · grænse · stilstandRegelandel · tests · dækningMåling

    Når både build og test består, iterationsgrænsen nås, eller der registreres stilstand (efter ét gendannelsesforsøg, hvis det ikke er prøvet endnu), går kørslen til måling. At gå til måling betyder ikke succes.

  2. Baseline · ukendte værdier ikke måltKørselstilstandsammenligning med baselineRegelandel · tests · dækningMåling

    Målingen læser den baseline, der er bevaret i kørselstilstanden. Det er ikke en ny baseline-kørsel.

  3. 5 acceptgatesMålingkaraktergivningScorecard · karakter

    Vellykket build, en beståelsesrate for tests på 100%, en ændring i dækning på −5 eller bedre (kun når baseline er kendt), nul slettede tests, nul surefire-udelukkelser. En karakter gives kun, når alle fem består.

  4. 5 acceptgatesMålingslettet · udelukket · fejletRapport om fejl · stilstand

    Bestået opnået ved at slette tests eller ved surefire-udelukkelser samt fejlede builds eller tests forbliver fejl. Kontrollerne for sletning og udelukkelse tæller nul, når Git eller POM ikke kan læses, så de er ikke bevis for, at enhver overtrædelse fanges.

  5. Fortsæt · mål · højst 3Næste trinafslutning ved grænse · stilstandRapport om fejl · stilstand

    En kørsel, der ender ved grænsen eller går i stå, går stadig gennem måling, men rapporteres ikke som succes. Det markerer, hvordan den rapporteres; det er ikke en genvej uden om måling.

Alle forbindelser med samme tykkelse. Vælg et flow for kun at fremhæve dets vej med nummererede trin.

  • Fuldt optrukket · retning for input, resultater og logs
  • Stiplet · kørsel, vurdering, anmodning
  • Lange prikker · observation og rapportering, adskilt fra vurdering
  • Korte streger · fejl, stop, grænse
  • Kraftig sort linje · det valgte flow; tal angiver rækkefølgen
  • Boks · kode- eller tilstandsgrænse, navngivet i overskriften
  • Indre chip · en komponent inden for grænsen
  • Prikket boks · uden for grænsen
  • Orange kontur · hvor en model træffer beslutninger
  • Pipelinetrin · reparation
  • Verifikation · routing · accept
  • Tilstand · logs
  • Udforsk før rettelse

Tegnet ud fra private implementerings- og udviklingslogs. Navnene er generiske offentlige navne; der vises ingen kodestier eller kundeoplysninger.

Input efter et fejlet nyt build
Modelreparationen modtager det indsamlede belæg og rettelsesinstrukserne, men den fejltekst, der sendes med, er den oprindelige build-fejl, ikke det nye builds fejl. Fastslået ved læsning af koden; ikke reproduceret i en kørsel, og kilden blev ikke ændret.
Gatenes begrænsninger
Hvis baseline for dækning er ukendt, springes den gate over. Surefire-kontrollen tæller udelukkelserne i den aktuelle POM, ikke forskellen fra baseline. Kontrollerne for sletning og udelukkelse tæller nul, når Git eller POM ikke kan læses.
Casen og dens tal
At omkring 40 setter-fejl blev sporet til én årsag, opsætningen af Lombok og POM, er en diagnose registreret dengang. Det er ikke et tal for gennemløb, nøjagtighed eller endelig levering.