SV
Den ursprungliga REODE-figuren, bearbetad: ett leende gräddvitt och rosa axolotlansikte med marinblått headset och cyanfärgade linser
Tillbaka till salen

REODE

Code migration

Före rättningen: den gemensamma orsaken först.

En agent för kodmigrering av Java/Spring.

2026.03 — 2026.04

Arbetsprojekt · migrerings- och verifieringssystem

  • CLIImplementerad · arbetsprojekt

En migreringsloop som håller reparationsbelägg åtskilda från acceptans.

Det ursprungliga byggtillståndet registreras och regelbaserad konvertering tillämpas, och sedan samlas belägg från källa och POM in före reparation. Efter en modells ändring kontrolleras build, test och testintegritet igen, och körningar som slutar vid en gräns eller stannar rapporteras skilda från framgång.

Den kombinerar regelbaserad konvertering med modellassisterad reparation och kontrollerar den ändrade koden med build och test. Ett arbetsprojekt.

REODE-arbete i repositoryt; uppdrag hos pinxlab 16 mars 2026 till 26 maj 2026

Ett CLI-verktyg som används i arbetet.

Karta över reparationsloopen · utifrån privata implementationsloggar
REODE:s reparationsloop för migreringDet ursprungliga byggtillståndet behålls som baslinje, regelbaserad konvertering tillämpas och build och test verifierar resultatet. Vid fel samlas belägg från källa, annoteringar och POM in före varje rättning, och kända mönster rättas deterministiskt och byggs om. Om det nya bygget klarar sig anropas ingen modell; om det misslyckas reparerar en modell med de insamlade beläggen och rättningsinstruktioner, och resultatet verifieras igen. Körningar som slutar vid iterationsgränsen eller stannar går vidare till mätning men räknas inte som framgång, och scorecarden sätter betyg bara när alla fem acceptansgrindar har klarats.Källa · POMPrivat migreringsindataScorecard · betygIngen driftsättningRapport om fel · stilleståndRäknas inte som framgångKontroll av originalUrsprungligt tillstånd · compileKörningstillståndBaslinje · okända värden inte uppmättaÅterställningsloggarCheckpoint före rättningTidigare rättning, samma felKonverteringPlan → regelbaserad konverteringUtforska före rättningBelägg för orsak · 3 källor · POMDeterministisk rättningRätta kända mönsterKontroll av nytt byggeModellreparationRätta med belägg · instruktionerVerifieringbuild · test · iteration +1Nästa stegFortsätt · mät · högst 3MätningRegelandel · tester · täckning5 acceptansgrindarIndata · baslinjeÅterställningsloggarKonvertering · reparationVerifiering · avslut1källa · POM2ursprunglig compile3 regelkonvertering · Ursprungligt tillstånd · compile → Plan → regelbaserad konvertering34build · test5resultat · iterationer6godkänt · gräns · stillestånd7jämförelse med baslinje8 betygssättning · 5 acceptansgrindar → Scorecard · betyg81resultat · iterationer2 misslyckades · nytt försök · Fortsätt · mät · högst 3 → Belägg för orsak · 3 källor · POM23spara före rättning4belägg · grupperade fel5godkänt · LLM överhoppad6nytt bygge misslyckades7 tidigare rättning · Tidigare rättning, samma fel → Rätta med belägg · instruktioner78verifiera igen1godkänt · gräns · stillestånd2jämförelse med baslinje3 betygssättning · 5 acceptansgrindar → Scorecard · betyg34raderat · undantaget · misslyckat5avslut vid gräns · stillestånd

Regelkonvertering

Det ursprungliga tillståndet behålls som baslinje; efter regelkonvertering verifierar build och test, och körningen går vidare till mätning.

  1. Källa · POMkälla · POMUrsprungligt tillstånd · compileKontroll av original

    Tar den Java/Spring-källkod och POM som ska migreras. Kundens kod och skärmar visas inte.

  2. Ursprungligt tillstånd · compileKontroll av originalursprunglig compileBaslinje · okända värden inte uppmättaKörningstillstånd

    Före konverteringen väljs runtimen och originalet kompileras, så ett bygge som redan var trasigt behålls i baslinjen. Standardvärden för test och täckning i baslinjen är inte mätningar.

  3. Ursprungligt tillstånd · compileKontroll av originalregelkonverteringPlan → regelbaserad konverteringKonvertering

    Körgrafen går kontroll av original → konverteringsplan → regelbaserad konvertering → verifiering. Konverteringar som regler kan bära tillämpas först.

  4. Plan → regelbaserad konverteringKonverteringbuild · testbuild · test · iteration +1Verifiering

    Build och test verifierar den konverterade koden och iterationsräknaren ökar med ett. Resultaten återgår till körningstillståndet.

  5. build · test · iteration +1Verifieringresultat · iterationerFortsätt · mät · högst 3Nästa steg

    Lyckat bygge, andel godkända tester och iterationsantalet avgör nästa steg.

  6. Fortsätt · mät · högst 3Nästa steggodkänt · gräns · stilleståndRegelandel · tester · täckningMätning

    När både build och test klaras, iterationsgränsen nås eller stillestånd upptäcks (efter ett återställningsförsök om det inte redan prövats), går körningen till mätning. Att gå till mätning betyder inte framgång.

  7. Baslinje · okända värden inte uppmättaKörningstillståndjämförelse med baslinjeRegelandel · tester · täckningMätning

    Mätningen läser den baslinje som behållits i körningstillståndet. Det är ingen ny baslinjekörning.

  8. 5 acceptansgrindarMätningbetygssättningScorecard · betyg

    Lyckat bygge, 100% godkända tester, en täckningsförändring på −5 eller bättre (bara när baslinjen är känd), noll raderade tester, noll surefire-undantag. Ett betyg ges bara när alla fem klaras.

Orsaksbaserad reparation

Belägg samlas in före rättning och deterministiska rättningar kommer först. Om det nya bygget klarar sig hoppas modellen över; annars reparerar modellen med belägg och instruktioner och resultatet verifieras igen.

  1. build · test · iteration +1Verifieringresultat · iterationerFortsätt · mät · högst 3Nästa steg

    Lyckat bygge, andel godkända tester och iterationsantalet avgör nästa steg.

  2. Fortsätt · mät · högst 3Nästa stegmisslyckades · nytt försökBelägg för orsak · 3 källor · POMUtforska före rättning

    Om bygget misslyckades eller andelen godkända tester är under 100%, och iterationsgränsen (3 som standard) inte har nåtts, går körningen till reparation.

  3. Belägg för orsak · 3 källor · POMUtforska före rättningspara före rättningCheckpoint före rättningÅterställningsloggar

    En checkpoint sparas före rättningen. Det är best-effort: en misslyckad sparning stoppar inte reparationen, och en sparning är inget belägg för framgång.

  4. Belägg för orsak · 3 källor · POMUtforska före rättningbelägg · grupperade felRätta kända mönsterDeterministisk rättning

    Samlar in de felande Java-filerna, de första raderna i upp till tre källor, inställningar för annoteringar, POM och annotation processor samt imports till djup 2. Ett avgränsat prov, inte en förståelse av hela kodbasen.

  5. Kontroll av nytt byggeDeterministisk rättninggodkänt · LLM överhoppadbuild · test · iteration +1Verifiering

    Om en deterministisk rättning av ett känt mönster (till exempel Lombok-uppsättningen) får det nya bygget att klara sig anropas ingen modell. Körningen återgår ändå till verifiering, så detta är inte slutlig acceptans.

  6. Kontroll av nytt byggeDeterministisk rättningnytt bygge misslyckadesRätta med belägg · instruktionerModellreparation

    Om det nya bygget misslyckas går de insamlade beläggen och rättningsinstruktionerna till modellreparation. En läsning av koden visar att feltexten som skickas med är det ursprungliga byggfelet, inte det nya byggets fel, så det får inte läsas som ”bara de återstående felen skickas vidare”. Ingen defekt som reproducerats i en körning.

  7. Tidigare rättning, samma felÅterställningsloggartidigare rättningRätta med belägg · instruktionerModellreparation

    Tidigare rättningar som registrerats under samma felsignatur slås upp och bifogas. En logg som läggs till indata, inte modellträning.

  8. Rätta med belägg · instruktionerModellreparationverifiera igenbuild · test · iteration +1Verifiering

    Modellen rättar via en strukturerad architect/editor-väg, eller via en tool-use-prompt när den vägen inte är tillgänglig eller är under återställning, och build och test verifierar igen. En modells ändring är inte i sig ett godkänt bygge.

Godkänt kontra stillestånd

Ett betyg kräver alla fem grindar; raderade eller undantagna tester och avslut vid gräns eller stillestånd räknas inte som framgång.

  1. Fortsätt · mät · högst 3Nästa steggodkänt · gräns · stilleståndRegelandel · tester · täckningMätning

    När både build och test klaras, iterationsgränsen nås eller stillestånd upptäcks (efter ett återställningsförsök om det inte redan prövats), går körningen till mätning. Att gå till mätning betyder inte framgång.

  2. Baslinje · okända värden inte uppmättaKörningstillståndjämförelse med baslinjeRegelandel · tester · täckningMätning

    Mätningen läser den baslinje som behållits i körningstillståndet. Det är ingen ny baslinjekörning.

  3. 5 acceptansgrindarMätningbetygssättningScorecard · betyg

    Lyckat bygge, 100% godkända tester, en täckningsförändring på −5 eller bättre (bara när baslinjen är känd), noll raderade tester, noll surefire-undantag. Ett betyg ges bara när alla fem klaras.

  4. 5 acceptansgrindarMätningraderat · undantaget · misslyckatRapport om fel · stillestånd

    Godkännanden som uppnåtts genom att radera tester eller genom surefire-undantag, samt misslyckade byggen eller tester, förblir misslyckanden. Kontrollerna för radering och undantag räknar noll när Git eller POM inte kan läsas, så de är inget bevis för att varje överträdelse fångas.

  5. Fortsätt · mät · högst 3Nästa stegavslut vid gräns · stilleståndRapport om fel · stillestånd

    En körning som slutar vid gränsen eller stannar går ändå genom mätning men rapporteras inte som framgång. Det markerar hur den rapporteras; det är ingen genväg förbi mätningen.

Alla kopplingar med samma tjocklek. Välj ett flöde för att bara markera dess väg, med numrerade steg.

  • Heldragen · riktning för indata, resultat och loggar
  • Streckad · körning, bedömning, begäran
  • Långa prickar · observation och rapportering, skilt från bedömning
  • Korta streck · fel, stopp, gräns
  • Kraftig svart linje · det valda flödet; siffrorna anger ordningen
  • Ruta · kod- eller tillståndsgräns, namngiven i rubriken
  • Inre chip · en komponent inom gränsen
  • Prickad ruta · utanför gränsen
  • Orange kontur · där en modell fattar beslut
  • Pipelinesteg · reparation
  • Verifiering · routning · acceptans
  • Tillstånd · loggar
  • Utforska före rättning

Ritad utifrån privata implementations- och utvecklingsloggar. Namnen är generiska offentliga namn; inga kodvägar eller kunduppgifter visas.

Indata efter ett misslyckat nytt bygge
Modellreparationen får de insamlade beläggen och rättningsinstruktionerna, men feltexten som skickas med är det ursprungliga byggfelet, inte det nya byggets fel. Fastställt genom läsning av koden; inte reproducerat i en körning, och källkoden ändrades inte.
Grindarnas begränsningar
Om baslinjen för täckning är okänd hoppas den grinden över. Surefire-kontrollen räknar undantagen i den aktuella POM-filen, inte skillnaden mot baslinjen. Kontrollerna för radering och undantag räknar noll när Git eller POM inte kan läsas.
Fallet och dess siffror
Att ett 40-tal setter-fel spårades till en orsak, uppsättningen av Lombok och POM, är en diagnos som registrerades då. Det är ingen siffra för genomströmning, träffsäkerhet eller slutleverans.