NO
Den opprinnelige REODE-figuren, bearbeidet: et smilende krem- og rosafarget axolotlansikt med marineblått headset og cyanfargede linser
Tilbake til salen

REODE

Code migration

Før rettingen: den felles årsaken først.

En agent for kodemigrering av Java/Spring.

2026.03 — 2026.04

Arbeidsprosjekt · migrerings- og verifiseringssystem

  • CLIImplementert · arbeidsprosjekt

En migreringsløkke som holder reparasjonsbelegg atskilt fra aksept.

Den opprinnelige byggtilstanden registreres og regelbasert konvertering brukes, og deretter samles belegg fra kilde og POM inn før reparasjon. Etter en modells endring kontrolleres build, test og testintegritet på nytt, og kjøringer som ender ved en grense eller stopper opp, rapporteres atskilt fra suksess.

Den kombinerer regelbasert konvertering med modellassistert reparasjon og kontrollerer den endrede koden med build og test. Et arbeidsprosjekt.

REODE-arbeid i repositoryet; oppdrag for pinxlab 16. mars 2026 til 26. mai 2026

Et CLI-verktøy som brukes i arbeidet.

Kart over reparasjonsløkken · ut fra private implementeringslogger
REODEs reparasjonsløkke for migreringDen opprinnelige byggtilstanden beholdes som baseline, regelbasert konvertering brukes, og build og test verifiserer resultatet. Ved feil samles belegg fra kilde, annotasjoner og POM inn før enhver retting, og kjente mønstre rettes deterministisk og bygges på nytt. Hvis det nye bygget består, kalles ingen modell; hvis det feiler, reparerer en modell med det innsamlede belegget og rettingsinstrukser, og resultatet verifiseres på nytt. Kjøringer som ender ved iterasjonsgrensen eller stopper opp, går videre til måling, men telles ikke som suksess, og scorecarden gir bare karakter når alle fem akseptportene er bestått.Kilde · POMPrivat migreringsinputScorecard · karakterIkke en utrullingRapport om feil · stillstandTelles ikke som suksessKontroll av originalOpprinnelig tilstand · compileKjøretilstandBaseline · ukjente verdier ikke måltGjenopprettingsloggerCheckpoint før rettingTidligere retting, samme feilKonverteringPlan → regelbasert konverteringUtforsk før rettingBelegg for årsak · 3 kilder · POMDeterministisk rettingRett kjente mønstreKontroll av nytt byggModellreparasjonRett med belegg · instrukserVerifiseringbuild · test · iterasjon +1Neste stegFortsett · mål · maks 3MålingRegelandel · tester · dekning5 akseptporterInput · baselineGjenopprettingsloggerKonvertering · reparasjonVerifisering · avslutning1kilde · POM2opprinnelig compile3 regelkonvertering · Opprinnelig tilstand · compile → Plan → regelbasert konvertering34build · test5resultat · iterasjoner6bestått · grense · stillstand7sammenligning med baseline8 karaktersetting · 5 akseptporter → Scorecard · karakter81resultat · iterasjoner2 feilet · nytt forsøk · Fortsett · mål · maks 3 → Belegg for årsak · 3 kilder · POM23lagre før retting4belegg · grupperte feil5bestått · LLM hoppet over6nytt bygg feilet7 tidligere retting · Tidligere retting, samme feil → Rett med belegg · instrukser78verifiser på nytt1bestått · grense · stillstand2sammenligning med baseline3 karaktersetting · 5 akseptporter → Scorecard · karakter34slettet · unntatt · feilet5avslutning ved grense · stillstand

Regelkonvertering

Den opprinnelige tilstanden beholdes som baseline; etter regelkonvertering verifiserer build og test, og kjøringen går videre til måling.

  1. Kilde · POMkilde · POMOpprinnelig tilstand · compileKontroll av original

    Tar Java/Spring-kilden og POM-en som skal migreres. Kundens kode og skjermer vises ikke.

  2. Opprinnelig tilstand · compileKontroll av originalopprinnelig compileBaseline · ukjente verdier ikke måltKjøretilstand

    Før konverteringen velges runtimen og originalen kompileres, slik at et bygg som allerede var ødelagt, beholdes i baselinen. Standardverdier for test og dekning i baselinen er ikke målinger.

  3. Opprinnelig tilstand · compileKontroll av originalregelkonverteringPlan → regelbasert konverteringKonvertering

    Kjøregrafen går kontroll av original → konverteringsplan → regelbasert konvertering → verifisering. Konverteringer som regler kan bære, brukes først.

  4. Plan → regelbasert konverteringKonverteringbuild · testbuild · test · iterasjon +1Verifisering

    Build og test verifiserer den konverterte koden, og iterasjonstallet øker med én. Resultatene går tilbake til kjøretilstanden.

  5. build · test · iterasjon +1Verifiseringresultat · iterasjonerFortsett · mål · maks 3Neste steg

    Vellykket bygg, beståttandel for tester og iterasjonstallet avgjør neste steg.

  6. Fortsett · mål · maks 3Neste stegbestått · grense · stillstandRegelandel · tester · dekningMåling

    Når både build og test består, iterasjonsgrensen nås eller det oppdages stillstand (etter ett gjenopprettingsforsøk hvis det ikke er prøvd ennå), går kjøringen til måling. Å gå til måling betyr ikke suksess.

  7. Baseline · ukjente verdier ikke måltKjøretilstandsammenligning med baselineRegelandel · tester · dekningMåling

    Målingen leser baselinen som er beholdt i kjøretilstanden. Det er ikke en ny baseline-kjøring.

  8. 5 akseptporterMålingkaraktersettingScorecard · karakter

    Vellykket bygg, en beståttandel for tester på 100%, en endring i dekning på −5 eller bedre (bare når baselinen er kjent), null slettede tester, null surefire-unntak. En karakter gis bare når alle fem består.

Årsaksbasert reparasjon

Belegg samles inn før retting, og deterministiske rettinger kommer først. Hvis det nye bygget består, hoppes modellen over; ellers reparerer modellen med belegg og instrukser, og resultatet verifiseres på nytt.

  1. build · test · iterasjon +1Verifiseringresultat · iterasjonerFortsett · mål · maks 3Neste steg

    Vellykket bygg, beståttandel for tester og iterasjonstallet avgjør neste steg.

  2. Fortsett · mål · maks 3Neste stegfeilet · nytt forsøkBelegg for årsak · 3 kilder · POMUtforsk før retting

    Hvis bygget feilet eller beståttandelen for tester er under 100%, og iterasjonsgrensen (3 som standard) ikke er nådd, går kjøringen til reparasjon.

  3. Belegg for årsak · 3 kilder · POMUtforsk før rettinglagre før rettingCheckpoint før rettingGjenopprettingslogger

    Et checkpoint lagres før rettingen. Det er best-effort: en mislykket lagring stopper ikke reparasjonen, og en lagring er ikke belegg for suksess.

  4. Belegg for årsak · 3 kilder · POMUtforsk før rettingbelegg · grupperte feilRett kjente mønstreDeterministisk retting

    Samler inn de feilende Java-filene, de første linjene i opptil tre kilder, innstillinger for annotasjoner, POM og annotation processor samt imports til dybde 2. En avgrenset prøve, ikke en forståelse av hele kodebasen.

  5. Kontroll av nytt byggDeterministisk rettingbestått · LLM hoppet overbuild · test · iterasjon +1Verifisering

    Hvis en deterministisk retting av et kjent mønster (for eksempel Lombok-oppsettet) får det nye bygget til å bestå, kalles ingen modell. Kjøringen går likevel tilbake til verifisering, så dette er ikke endelig aksept.

  6. Kontroll av nytt byggDeterministisk rettingnytt bygg feiletRett med belegg · instrukserModellreparasjon

    Hvis det nye bygget feiler, går det innsamlede belegget og rettingsinstruksene til modellreparasjon. Lesing av koden viser at feilteksten som sendes med, er den opprinnelige build-feilen, ikke feilen fra det nye bygget, så dette må ikke leses som «bare de gjenværende feilene sendes videre». Ikke en defekt som er reprodusert i en kjøring.

  7. Tidligere retting, samme feilGjenopprettingsloggertidligere rettingRett med belegg · instrukserModellreparasjon

    Tidligere rettinger registrert under samme feilsignatur slås opp og legges ved. En logg som legges til inputen, ikke modelltrening.

  8. Rett med belegg · instrukserModellreparasjonverifiser på nyttbuild · test · iterasjon +1Verifisering

    Modellen retter via en strukturert architect/editor-sti, eller via en tool-use-prompt når den stien ikke er tilgjengelig eller er under gjenoppretting, og build og test verifiserer på nytt. En modells endring er ikke i seg selv et bestått bygg.

Bestått kontra stillstand

En karakter krever alle fem porter; slettede eller unntatte tester og avslutninger ved grense eller stillstand telles ikke som suksess.

  1. Fortsett · mål · maks 3Neste stegbestått · grense · stillstandRegelandel · tester · dekningMåling

    Når både build og test består, iterasjonsgrensen nås eller det oppdages stillstand (etter ett gjenopprettingsforsøk hvis det ikke er prøvd ennå), går kjøringen til måling. Å gå til måling betyr ikke suksess.

  2. Baseline · ukjente verdier ikke måltKjøretilstandsammenligning med baselineRegelandel · tester · dekningMåling

    Målingen leser baselinen som er beholdt i kjøretilstanden. Det er ikke en ny baseline-kjøring.

  3. 5 akseptporterMålingkaraktersettingScorecard · karakter

    Vellykket bygg, en beståttandel for tester på 100%, en endring i dekning på −5 eller bedre (bare når baselinen er kjent), null slettede tester, null surefire-unntak. En karakter gis bare når alle fem består.

  4. 5 akseptporterMålingslettet · unntatt · feiletRapport om feil · stillstand

    Bestått oppnådd ved å slette tester eller ved surefire-unntak, og mislykkede bygg eller tester, forblir feil. Kontrollene for sletting og unntak teller null når Git eller POM ikke kan leses, så de er ikke bevis for at alle brudd fanges opp.

  5. Fortsett · mål · maks 3Neste stegavslutning ved grense · stillstandRapport om feil · stillstand

    En kjøring som ender ved grensen eller stopper opp, går likevel gjennom måling, men rapporteres ikke som suksess. Det markerer hvordan den rapporteres; det er ikke en snarvei forbi målingen.

Alle forbindelser med samme tykkelse. Velg en flyt for å fremheve bare dens vei, med nummererte steg.

  • Heltrukket · retning for input, resultater og logger
  • Stiplet · kjøring, vurdering, forespørsel
  • Lange prikker · observasjon og rapportering, atskilt fra vurdering
  • Korte streker · feil, stopp, grense
  • Kraftig svart linje · den valgte flyten; tallene angir rekkefølgen
  • Boks · kode- eller tilstandsgrense, navngitt i overskriften
  • Indre chip · en komponent innenfor grensen
  • Prikket boks · utenfor grensen
  • Oransje kontur · der en modell tar beslutninger
  • Pipelinesteg · reparasjon
  • Verifisering · ruting · aksept
  • Tilstand · logger
  • Utforsk før retting

Tegnet ut fra private implementerings- og utviklingslogger. Navnene er generiske offentlige navn; ingen kodestier eller kundeopplysninger vises.

Input etter et mislykket nytt bygg
Modellreparasjonen mottar det innsamlede belegget og rettingsinstruksene, men feilteksten som sendes med, er den opprinnelige build-feilen, ikke feilen fra det nye bygget. Fastslått ved lesing av koden; ikke reprodusert i en kjøring, og kildekoden ble ikke endret.
Portenes begrensninger
Hvis baselinen for dekning er ukjent, hoppes den porten over. Surefire-kontrollen teller unntakene i den gjeldende POM-en, ikke forskjellen fra baselinen. Kontrollene for sletting og unntak teller null når Git eller POM ikke kan leses.
Caset og tallene
At rundt 40 setter-feil ble sporet til én årsak, oppsettet av Lombok og POM, er en diagnose registrert den gangen. Det er ikke et tall for gjennomstrømning, nøyaktighet eller endelig levering.