PL
Dopracowana oryginalna postać REODE: uśmiechnięta kremowo-różowa twarz aksolotla w granatowym headsecie z cyjanowymi soczewkami
Powrót do sali

REODE

Code migration

Przed poprawką znaleźć wspólną przyczynę.

Agent migracji kodu Java/Spring.

2026.03 — 2026.04

Projekt zawodowy · system migracji i weryfikacji

  • CLIZaimplementowane · projekt zawodowy

Pętla migracji, która oddziela dowody naprawy od akceptacji.

Zapisywany jest stan oryginalnego builda i stosowana konwersja oparta na regułach, a przed naprawą zbierane są dowody ze źródeł i POM. Po edycji przez model build, testy i integralność testów są sprawdzane ponownie, a przebiegi kończące się na limicie lub utknięciem są raportowane oddzielnie od sukcesu.

Łączy konwersję opartą na regułach z naprawą wspomaganą przez model i sprawdza zmieniony kod przez build i testy. Projekt zawodowy.

Praca nad REODE w repozytorium; współpraca z pinxlab od March 16, 2026 do May 26, 2026

Narzędzie CLI używane w pracy.

Mapa pętli naprawy · z niepublicznych zapisów implementacji
Pętla naprawy migracji REODEStan oryginalnego builda zostaje zachowany jako baseline, stosowana jest konwersja oparta na regułach, a build i testy weryfikują wynik. Przy porażce przed jakąkolwiek poprawką zbierane są dowody ze źródeł, adnotacji i POM, a znane wzorce są poprawiane deterministycznie i budowane ponownie. Jeśli ponowny build przejdzie, model nie jest wywoływany; jeśli zawiedzie, model naprawia z zebranymi dowodami i instrukcjami poprawek, a wynik jest weryfikowany ponownie. Przebiegi kończące się na limicie iteracji lub utknięciem przechodzą do pomiaru, ale nie są liczone jako sukces, a karta wyników wystawia ocenę tylko po spełnieniu wszystkich pięciu kryteriów akceptacji.Źródła · POMNiepubliczne wejście migracjiKarta wyników · ocenaTo nie wdrożenieRaport awarii · utknięciaNie liczy się jako sukcesKontrola oryginałuStan oryginału · kompilacjaStan przebieguBaseline · nieznane wartości niezmierzoneZapisy przywracaniaCheckpoint przed poprawkąWcześniejsza poprawka, ten sam błądKonwersjaPlan → konwersja oparta na regułachEksploracja przed poprawkąDowody przyczyny · 3 źródła · POMPoprawka deterministycznaPoprawa znanych wzorcówKontrola ponownego buildaNaprawa przez modelPoprawka z dowodami · instrukcjamiWeryfikacjabuild · test · iteracja +1Następny krokKontynuacja · pomiar · najwyżej 3PomiarUdział reguł · testy · pokrycie5 kryteriów akceptacjiWejście · baselineZapisy przywracaniaKonwersja · naprawaWeryfikacja · wyjście1źródła · POM2kompilacja oryginału3 konwersja regułowa · Stan oryginału · kompilacja → Plan → konwersja oparta na regułach34build · test5wynik · iteracje6zaliczenie · limit · utknięcie7porównanie z baseline8ocena1wynik · iteracje2 porażka · ponowienie · Kontynuacja · pomiar · najwyżej 3 → Dowody przyczyny · 3 źródła · POM23zapis przed poprawką4dowody · pogrupowane błędy5zaliczone · LLM pominięty6ponowny build nieudany7 wcześniejsza poprawka · Wcześniejsza poprawka, ten sam błąd → Poprawka z dowodami · instrukcjami78ponowna weryfikacja1zaliczenie · limit · utknięcie2porównanie z baseline3ocena4usunięte · wykluczone · nieudane5wyjście na limicie · utknięciu

Konwersja regułowa

Stan oryginału zostaje zachowany jako baseline; po konwersji regułowej build i testy weryfikują wynik, a przebieg przechodzi do pomiaru.

  1. Źródła · POMźródła · POMStan oryginału · kompilacjaKontrola oryginału

    Przyjmuje źródła Java/Spring i POM do migracji. Kod i ekrany klienta nie są pokazywane.

  2. Stan oryginału · kompilacjaKontrola oryginałukompilacja oryginałuBaseline · nieznane wartości niezmierzoneStan przebiegu

    Przed konwersją wybierane jest środowisko wykonawcze i kompilowany oryginał, więc build, który już był zepsuty, zostaje zachowany w baseline. Domyślne wartości testów i pokrycia w baseline nie są pomiarami.

  3. Stan oryginału · kompilacjaKontrola oryginałukonwersja regułowaPlan → konwersja oparta na regułachKonwersja

    Graf przebiegu idzie: kontrola oryginału → plan konwersji → konwersja oparta na regułach → weryfikacja. Najpierw stosowane są konwersje, które da się przeprowadzić regułami.

  4. Plan → konwersja oparta na regułachKonwersjabuild · testbuild · test · iteracja +1Weryfikacja

    Build i testy weryfikują przekonwertowany kod, a licznik iteracji rośnie o jeden. Wyniki wracają do stanu przebiegu.

  5. build · test · iteracja +1Weryfikacjawynik · iteracjeKontynuacja · pomiar · najwyżej 3Następny krok

    O następnym kroku decydują powodzenie builda, odsetek zaliczonych testów i liczba iteracji.

  6. Kontynuacja · pomiar · najwyżej 3Następny krokzaliczenie · limit · utknięcieUdział reguł · testy · pokryciePomiar

    Gdy build i testy przejdą, osiągnięty zostanie limit iteracji albo wykryte zostanie utknięcie (po jednej próbie przywrócenia, jeśli jeszcze jej nie było), przebieg przechodzi do pomiaru. Przejście do pomiaru nie oznacza sukcesu.

  7. Baseline · nieznane wartości niezmierzoneStan przebieguporównanie z baselineUdział reguł · testy · pokryciePomiar

    Pomiar odczytuje baseline zachowany w stanie przebiegu. To nie jest nowy przebieg baseline.

  8. 5 kryteriów akceptacjiPomiarocenaKarta wyników · ocena

    Udany build, 100% zaliczonych testów, zmiana pokrycia −5 lub lepsza (tylko gdy baseline jest znany), zero usuniętych testów, zero wykluczeń surefire. Ocena jest wystawiana tylko po spełnieniu wszystkich pięciu kryteriów.

Naprawa oparta na przyczynie

Dowody są zbierane przed poprawką, a deterministyczne poprawki idą najpierw. Jeśli ponowny build przejdzie, model jest pomijany; jeśli nie, model naprawia z dowodami i instrukcjami, a wynik jest weryfikowany ponownie.

  1. build · test · iteracja +1Weryfikacjawynik · iteracjeKontynuacja · pomiar · najwyżej 3Następny krok

    O następnym kroku decydują powodzenie builda, odsetek zaliczonych testów i liczba iteracji.

  2. Kontynuacja · pomiar · najwyżej 3Następny krokporażka · ponowienieDowody przyczyny · 3 źródła · POMEksploracja przed poprawką

    Jeśli build się nie powiódł lub odsetek zaliczonych testów jest niższy niż 100%, a limit iteracji (domyślnie 3) nie został osiągnięty, przebieg przechodzi do naprawy.

  3. Dowody przyczyny · 3 źródła · POMEksploracja przed poprawkązapis przed poprawkąCheckpoint przed poprawkąZapisy przywracania

    Przed poprawką zapisywany jest checkpoint. Działa w trybie best-effort: nieudany zapis nie zatrzymuje naprawy, a zapis nie jest dowodem sukcesu.

  4. Dowody przyczyny · 3 źródła · POMEksploracja przed poprawkądowody · pogrupowane błędyPoprawa znanych wzorcówPoprawka deterministyczna

    Zbiera błędne pliki Java, początkowe wiersze najwyżej trzech źródeł, ustawienia adnotacji, POM i procesora adnotacji oraz importy do głębokości 2. To ograniczona próbka, a nie zrozumienie całej bazy kodu.

  5. Kontrola ponownego buildaPoprawka deterministycznazaliczone · LLM pominiętybuild · test · iteracja +1Weryfikacja

    Jeśli deterministyczna poprawka znanego wzorca (na przykład konfiguracji Lombok) sprawi, że ponowny build przejdzie, model nie jest wywoływany. Przebieg i tak wraca do weryfikacji, więc nie jest to końcowa akceptacja.

  6. Kontrola ponownego buildaPoprawka deterministycznaponowny build nieudanyPoprawka z dowodami · instrukcjamiNaprawa przez model

    Jeśli ponowny build zawiedzie, zebrane dowody i instrukcje poprawek trafiają do naprawy przez model. Z lektury kodu wynika, że przekazywany tekst błędu to oryginalny błąd builda, a nie nowy z ponownego builda, więc nie należy tego czytać jako „przekazywane są tylko pozostałe błędy”. To nie defekt odtworzony w przebiegu.

  7. Wcześniejsza poprawka, ten sam błądZapisy przywracaniawcześniejsza poprawkaPoprawka z dowodami · instrukcjamiNaprawa przez model

    Wcześniejsze poprawki zapisane pod tą samą sygnaturą błędu są wyszukiwane i dołączane. To zapis dodawany do wejścia, a nie trening modelu.

  8. Poprawka z dowodami · instrukcjamiNaprawa przez modelponowna weryfikacjabuild · test · iteracja +1Weryfikacja

    Model poprawia kod przez ustrukturyzowaną ścieżkę architect/editor albo, gdy ta ścieżka jest niedostępna lub trwa przywracanie, przez prompt z użyciem narzędzi, a build i testy weryfikują ponownie. Edycja modelu nie jest sama w sobie udanym buildem.

Zaliczenie a utknięcie

Ocena wymaga spełnienia wszystkich pięciu kryteriów; usunięte lub wykluczone testy oraz wyjścia na limicie lub przez utknięcie nie są liczone jako sukces.

  1. Kontynuacja · pomiar · najwyżej 3Następny krokzaliczenie · limit · utknięcieUdział reguł · testy · pokryciePomiar

    Gdy build i testy przejdą, osiągnięty zostanie limit iteracji albo wykryte zostanie utknięcie (po jednej próbie przywrócenia, jeśli jeszcze jej nie było), przebieg przechodzi do pomiaru. Przejście do pomiaru nie oznacza sukcesu.

  2. Baseline · nieznane wartości niezmierzoneStan przebieguporównanie z baselineUdział reguł · testy · pokryciePomiar

    Pomiar odczytuje baseline zachowany w stanie przebiegu. To nie jest nowy przebieg baseline.

  3. 5 kryteriów akceptacjiPomiarocenaKarta wyników · ocena

    Udany build, 100% zaliczonych testów, zmiana pokrycia −5 lub lepsza (tylko gdy baseline jest znany), zero usuniętych testów, zero wykluczeń surefire. Ocena jest wystawiana tylko po spełnieniu wszystkich pięciu kryteriów.

  4. 5 kryteriów akceptacjiPomiarusunięte · wykluczone · nieudaneRaport awarii · utknięcia

    Zaliczenia uzyskane przez usunięcie testów lub wykluczenia surefire oraz nieudane buildy czy testy pozostają porażkami. Kontrole usunięć i wykluczeń liczą zero, gdy nie da się odczytać Git lub POM, więc nie dowodzą, że każde naruszenie zostanie wychwycone.

  5. Kontynuacja · pomiar · najwyżej 3Następny krokwyjście na limicie · utknięciuRaport awarii · utknięcia

    Przebieg, który kończy się na limicie lub utyka, nadal przechodzi przez pomiar, ale nie jest raportowany jako sukces. To oznaczenie sposobu raportowania, a nie skrót omijający pomiar.

Każde połączenie z tą samą wagą. Wybór przepływu wyróżnia tylko jego ścieżkę z ponumerowanymi krokami.

  • Linia ciągła · kierunek wejścia, wyników i zapisów
  • Linia przerywana · uruchomienie, rozstrzygnięcie, żądanie
  • Długie kropki · obserwacja i raportowanie, oddzielnie od rozstrzygnięcia
  • Krótkie kreski · awaria, zatrzymanie, limit
  • Gruba czarna linia · wybrany przepływ; liczby podają kolejność
  • Ramka · granica kodu lub stanu, nazwana w nagłówku
  • Wewnętrzny element · komponent tej granicy
  • Kropkowana ramka · poza tą granicą
  • Pomarańczowy obrys · miejsce, w którym decyduje model
  • Kroki potoku · naprawa
  • Weryfikacja · kierowanie · akceptacja
  • Stan · zapisy
  • Eksploracja przed poprawką

Narysowano na podstawie niepublicznych zapisów implementacji i rozwoju. Nazwy są ogólnymi nazwami publicznymi; ścieżek kodu ani informacji o kliencie nie pokazano.

Wejście po nieudanym ponownym buildzie
Naprawa przez model otrzymuje zebrane dowody i instrukcje poprawek, ale przekazywany tekst błędu to oryginalny błąd builda, a nie nowy z ponownego builda. Ustalone przez lekturę kodu; nie odtworzono tego w przebiegu, a kodu źródłowego nie zmieniono.
Granice kryteriów
Jeśli baseline pokrycia jest nieznany, to kryterium jest pomijane. Kontrola surefire liczy wykluczenia w obecnym POM, a nie różnicę względem baseline. Kontrole usunięć i wykluczeń liczą zero, gdy nie da się odczytać Git lub POM.
Przypadek i jego liczby
Około 40 błędów setterów sprowadzonych do jednej przyczyny, konfiguracji Lombok i POM, to diagnoza zapisana w tamtym czasie. Nie jest to wartość przepustowości, trafności ani końcowej dostawy.