HU
Az eredeti REODE-figura finomítva: mosolygó, krém- és rózsaszínű axolotlarc sötétkék fejhallgatóval és ciánkék lencsékkel
Vissza a terembe

REODE

Code migration

Javítás előtt a közös ok.

Java/Spring kódmigrációs ágens.

2026.03 — 2026.04

Munkaprojekt · migrációs és ellenőrzési rendszer

  • CLIMegvalósítva · munkaprojekt

Migrációs ciklus, amely a javítás bizonyítékait elkülöníti az elfogadástól.

Rögzíti az eredeti buildállapotot és alkalmazza a szabályalapú átalakítást, majd a javítás előtt forrás- és POM-bizonyítékot gyűjt. Egy modell szerkesztése után a buildet, a tesztet és a tesztek integritását újra ellenőrzi, a korlátnál vagy elakadással záruló futtatásokat pedig a sikertől elkülönítve jelenti.

A szabályalapú átalakítást modellsegítette javítással kapcsolja össze, a megváltoztatott kódot pedig builddel és teszttel ellenőrzi. Munkaprojekt.

REODE-munka a tárolóban; a pinxlab-megbízás időtartama 2026. március 16. – 2026. május 26.

Munkahelyi használatú CLI-eszköz.

Javítási ciklus térképe · nem nyilvános megvalósítási feljegyzések alapján
A REODE migrációs javítási ciklusaAz eredeti buildállapot alapvonalként megmarad, a szabályalapú átalakítás lefut, a build és a teszt pedig ellenőrzi az eredményt. Hiba esetén bármilyen javítás előtt forrás-, annotációs és POM-bizonyítékot gyűjt, az ismert mintákat determinisztikusan javítja és újraépíti. Ha az újraépítés sikerül, nem hív modellt; ha elbukik, egy modell az összegyűjtött bizonyítékokkal és javítási utasításokkal javít, és az eredményt újra ellenőrzi. Az iterációs korlátnál vagy elakadással záruló futtatások továbbmennek a mérésre, de nem számítanak sikernek, a scorecard pedig csak akkor ad minősítést, ha mind az öt elfogadási kapu teljesül.Forrás · POMNem nyilvános migrációs bemenetScorecard · minősítésNem telepítésHiba · elakadási jelentésNem számít sikernekEredeti ellenőrzéseEredeti állapot · fordításFuttatási állapotAlapvonal · ismeretlenek méretlenülHelyreállítási feljegyzésekEllenőrzőpont javítás előttKorábbi javítás, ugyanaz a hibaÁtalakításTerv → szabályalapú átalakításFeltárás javítás előttOkbizonyíték · 3 forrás · POMDeterminisztikus javításIsmert minták javításaÚjraépítés ellenőrzéseModelljavításJavítás bizonyítékokkal · utasításokkalEllenőrzésbuild · teszt · iteráció +1Következő lépésFolytatás · mérés · max. 3MérésSzabályarány · tesztek · lefedettség5 elfogadási kapuBemenet · alapvonalHelyreállítási feljegyzésekÁtalakítás · javításEllenőrzés · kilépés1forrás · POM2eredeti fordítás3 szabályalapú átalakítás · Eredeti állapot · fordítás → Terv → szabályalapú átalakítás34build · test5eredmény · iterációk6siker · korlát · elakadás7összevetés az alapvonallal8minősítés1eredmény · iterációk2 sikertelen · újrapróbálás · Folytatás · mérés · max. 3 → Okbizonyíték · 3 forrás · POM23mentés javítás előtt4bizonyítékok · csoportosított hibák5sikeres · LLM kihagyva6az újraépítés elbukott7 korábbi javítás · Korábbi javítás, ugyanaz a hiba → Javítás bizonyítékokkal · utasításokkal78újbóli ellenőrzés1siker · korlát · elakadás2összevetés az alapvonallal3minősítés4törölve · kizárva · elbukott5kilépés korlátnál · elakadáskor

Szabályalapú átalakítás

Az eredeti állapot alapvonalként megmarad; a szabályalapú átalakítás után a build és a teszt ellenőriz, a futtatás pedig továbbmegy a mérésig.

  1. Forrás · POMforrás · POMEredeti állapot · fordításEredeti ellenőrzése

    A migrálandó Java/Spring forrást és POM-ot veszi át. Ügyfélkód és -képernyők nem jelennek meg.

  2. Eredeti állapot · fordításEredeti ellenőrzéseeredeti fordításAlapvonal · ismeretlenek méretlenülFuttatási állapot

    Az átalakítás előtt kiválasztja a futtatókörnyezetet, és lefordítja az eredetit, így a már eleve hibás build az alapvonalban marad. Az alapvonal alapértelmezett teszt- és lefedettségi értékei nem mérések.

  3. Eredeti állapot · fordításEredeti ellenőrzéseszabályalapú átalakításTerv → szabályalapú átalakításÁtalakítás

    A futtatási gráf menete: eredeti ellenőrzése → átalakítási terv → szabályalapú átalakítás → ellenőrzés. Előbb a szabályokkal megoldható átalakítások kerülnek alkalmazásra.

  4. Terv → szabályalapú átalakításÁtalakításbuild · testbuild · teszt · iteráció +1Ellenőrzés

    A build és a teszt ellenőrzi az átalakított kódot, az iterációszám pedig eggyel nő. Az eredmények visszakerülnek a futtatási állapotba.

  5. build · teszt · iteráció +1Ellenőrzéseredmény · iterációkFolytatás · mérés · max. 3Következő lépés

    A build sikere, a tesztsikerességi arány és az iterációszám határozza meg a következő lépést.

  6. Folytatás · mérés · max. 3Következő lépéssiker · korlát · elakadásSzabályarány · tesztek · lefedettségMérés

    Ha a build és a teszt is sikeres, eléri az iterációs korlátot, vagy elakadást észlel (egy helyreállítási kísérlet után, ha még nem történt), a futtatás a méréshez kerül. A mérésre kerülés nem jelent sikert.

  7. Alapvonal · ismeretlenek méretlenülFuttatási állapotösszevetés az alapvonallalSzabályarány · tesztek · lefedettségMérés

    A mérés a futtatási állapotban tárolt alapvonalat olvassa. Ez nem új alapvonal-futtatás.

  8. 5 elfogadási kapuMérésminősítésScorecard · minősítés

    Sikeres build, 100%-os tesztsikerességi arány, −5 vagy jobb lefedettségváltozás (csak ismert alapvonalnál), nulla törölt teszt, nulla surefire-kizárás. Minősítés csak mind az öt teljesülésekor jár.

Okalapú javítás

Javítás előtt bizonyítékgyűjtés történik, és a determinisztikus javítások jönnek előbb. Ha az újraépítés sikerül, a modell kimarad; ha nem, a modell bizonyítékokkal és utasításokkal javít, és az eredmény újra ellenőrzésre kerül.

  1. build · teszt · iteráció +1Ellenőrzéseredmény · iterációkFolytatás · mérés · max. 3Következő lépés

    A build sikere, a tesztsikerességi arány és az iterációszám határozza meg a következő lépést.

  2. Folytatás · mérés · max. 3Következő lépéssikertelen · újrapróbálásOkbizonyíték · 3 forrás · POMFeltárás javítás előtt

    Ha a build elbukott vagy a tesztsikerességi arány 100% alatt van, és az iterációs korlát (alapértelmezés szerint 3) nincs elérve, a futtatás javításra kerül.

  3. Okbizonyíték · 3 forrás · POMFeltárás javítás előttmentés javítás előttEllenőrzőpont javítás előttHelyreállítási feljegyzések

    Javítás előtt ellenőrzőpont mentődik. Ez nem garantált: a sikertelen mentés nem állítja le a javítást, és a mentés nem bizonyítja a sikert.

  4. Okbizonyíték · 3 forrás · POMFeltárás javítás előttbizonyítékok · csoportosított hibákIsmert minták javításaDeterminisztikus javítás

    Összegyűjti a hibás Java-fájlokat, legfeljebb három forrás kezdősorait, az annotációs, POM- és annotációfeldolgozó-beállításokat, valamint az importokat 2-es mélységig. Korlátozott minta, nem a teljes kódbázis megértése.

  5. Újraépítés ellenőrzéseDeterminisztikus javítássikeres · LLM kihagyvabuild · teszt · iteráció +1Ellenőrzés

    Ha egy ismert minta (például a Lombok-beállítás) determinisztikus javítása után az újraépítés sikerül, nem hív modellt. A futtatás így is visszatér az ellenőrzéshez, tehát ez nem végső elfogadás.

  6. Újraépítés ellenőrzéseDeterminisztikus javításaz újraépítés elbukottJavítás bizonyítékokkal · utasításokkalModelljavítás

    Ha az újraépítés elbukik, az összegyűjtött bizonyítékok és javítási utasítások a modelljavításhoz kerülnek. A kódból kiderül, hogy a továbbadott hibaszöveg az eredeti buildhiba, nem az újraépítés új hibája, ezért nem értelmezhető úgy, hogy „csak a fennmaradó hibák kerülnek tovább”. Ez nem futtatásban reprodukált hiba.

  7. Korábbi javítás, ugyanaz a hibaHelyreállítási feljegyzésekkorábbi javításJavítás bizonyítékokkal · utasításokkalModelljavítás

    Az ugyanazon hibaszignatúra alatt rögzített korábbi javításokat kikeresi és csatolja. Ez a bemenethez adott feljegyzés, nem modelltanítás.

  8. Javítás bizonyítékokkal · utasításokkalModelljavításújbóli ellenőrzésbuild · teszt · iteráció +1Ellenőrzés

    A modell strukturált architect/editor úton javít, vagy ha ez nem érhető el, illetve helyreállítás közben, eszközhasználati prompttal, majd a build és a teszt újra ellenőriz. Egy modell szerkesztése önmagában nem sikeres build.

Siker és elakadás

A minősítéshez mind az öt kapu kell; a törölt vagy kizárt tesztek, illetve a korláttal vagy elakadással zárult kilépések nem számítanak sikernek.

  1. Folytatás · mérés · max. 3Következő lépéssiker · korlát · elakadásSzabályarány · tesztek · lefedettségMérés

    Ha a build és a teszt is sikeres, eléri az iterációs korlátot, vagy elakadást észlel (egy helyreállítási kísérlet után, ha még nem történt), a futtatás a méréshez kerül. A mérésre kerülés nem jelent sikert.

  2. Alapvonal · ismeretlenek méretlenülFuttatási állapotösszevetés az alapvonallalSzabályarány · tesztek · lefedettségMérés

    A mérés a futtatási állapotban tárolt alapvonalat olvassa. Ez nem új alapvonal-futtatás.

  3. 5 elfogadási kapuMérésminősítésScorecard · minősítés

    Sikeres build, 100%-os tesztsikerességi arány, −5 vagy jobb lefedettségváltozás (csak ismert alapvonalnál), nulla törölt teszt, nulla surefire-kizárás. Minősítés csak mind az öt teljesülésekor jár.

  4. 5 elfogadási kapuMéréstörölve · kizárva · elbukottHiba · elakadási jelentés

    A tesztek törlésével vagy surefire-kizárással elért siker, valamint a sikertelen build vagy teszt hiba marad. A törlési és kizárási ellenőrzés nullát számol, ha a Git vagy a POM nem olvasható, így nem bizonyítja, hogy minden szabálysértést elkap.

  5. Folytatás · mérés · max. 3Következő lépéskilépés korlátnál · elakadáskorHiba · elakadási jelentés

    A korlátnál vagy elakadással záruló futtatás így is áthalad a mérésen, de nem jelentik sikerként. Ez a jelentés módját jelöli, nem a mérés megkerülését.

Minden kapcsolat azonos vastagsággal. Válasszon egy folyamatot, hogy csak annak útvonala emelődjön ki, számozott lépésekkel.

  • Folytonos · a bemenet, az eredmények és a feljegyzések iránya
  • Szaggatott · futtatás, megítélés, kérés
  • Hosszú pontozott · megfigyelés és jelentés, a megítéléstől elkülönítve
  • Rövid szaggatott · hiba, leállás, korlát
  • Vastag fekete vonal · a kiválasztott folyamat; a számok a sorrendet jelzik
  • Doboz · kód- vagy állapothatár, nevével a fejlécben
  • Belső chip · a határ egy komponense
  • Pontozott doboz · a határon kívül
  • Narancssárga körvonal · ahol egy modell dönt
  • Folyamatlépések · javítás
  • Ellenőrzés · irányítás · elfogadás
  • Állapot · feljegyzések
  • Feltárás javítás előtt

Nem nyilvános megvalósítási és fejlesztési feljegyzések alapján rajzolva. A nevek általános nyilvános nevek; kódútvonalak és ügyfélinformációk nem szerepelnek.

Bemenet sikertelen újraépítés után
A modelljavítás megkapja az összegyűjtött bizonyítékokat és javítási utasításokat, a továbbadott hibaszöveg azonban az eredeti buildhiba, nem az újraépítés új hibája. Ez a kód olvasásából derült ki; futtatásban nem reprodukálták, és a forrást sem módosították.
A kapuk korlátai
Ha a lefedettség alapvonala ismeretlen, ez a kapu kimarad. A surefire-ellenőrzés a jelenlegi POM kizárásait számolja, nem az alapvonalhoz képesti különbséget. A törlési és kizárási ellenőrzés nullát számol, ha a Git vagy a POM nem olvasható.
Az eset és számai
Az, hogy mintegy 40 setter-hiba egyetlen okra, a Lombok- és POM-beállításra vezethető vissza, akkor rögzített diagnózis. Nem áteresztőképességi, pontossági vagy végső szállítási adat.