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

Agent naprawczy najpierw czyta konfigurację

Agent, który próbował poprawiać setter po setterze, to agent naprawczy wewnątrz produktu REODE; rozwój zmienił jego wejście. Kod i informacje o kliencie są niepubliczne.

Pełna legenda

Jak czytać · jedna gramatyka dla każdego przypadku

  • Kolumny to ten, kto działał; z góry na dół biegnie czas
  • Linia ciągła: zapisane przekazanie lub kolejny krok
  • Gruba lapisowa ↩: ustalenie, które odesłało pracę
  • Linia przerywana: nie zapisane wykonanie (spisana reguła, rada bez uprawnień, niezweryfikowana granica)
  • Prostokąt: działanie
  • Zaokrąglony: zaobserwowany stan lub ustalenie
  • Zagięty róg: artefakt lub dowód
  • Kreskowana kolumna: części rozwijanego produktu (nie agenci użyci do jego budowy)

March 21, 2026

Grupy błędów, oryginalny build i konfiguracja Lombok stały się wejściem naprawy

  1. W trakcie rozwojuAgent naprawczy REODE

    Obserwacja · ustaleniePróby pojedynczych poprawek około 40 błędów setterów · @Data / POM niesprawdzone

  2. CzłowiekDeweloper

    DziałanieCzytać źródła i konfigurację builda przed poprawką

    • przekazanieZmienione wejście naprawy→ Build oryginalnego baseline · grupowanie błędów o tym samym wzorcu (Zmiany deweloperskie)

  3. Sesja roboczaZmiany deweloperskie

    DziałanieBuild oryginalnego baseline · grupowanie błędów o tym samym wzorcu

    • przekazanie→ Zbieranie dowodów: ścieżki · 3 próbki źródeł · adnotacje · POM (Zmiany deweloperskie)

  4. Spisana regułaZasady dla współtwórców

    Reguła · niezweryfikowanePlan zadania · własny worktree

    • nie zapisane wykonanieWymagane przez zasady→ Build oryginalnego baseline · grupowanie błędów o tym samym wzorcu (Zmiany deweloperskie)

  5. Sesja roboczaZmiany deweloperskie

    DziałanieZbieranie dowodów: ścieżki · 3 próbki źródeł · adnotacje · POM

    • przekazanie→ Najpierw deterministyczna poprawka Lombok · LLM pomijany, jeśli ponowny build przejdzie (Zmiany deweloperskie)

  6. Spisana regułaZasady dla współtwórców

    Reguła · niezweryfikowanePrzegląd bez kontekstu: plan ↔ diff

    • nie zapisane wykonanieWymagane przez zasady→ Zbieranie dowodów: ścieżki · 3 próbki źródeł · adnotacje · POM (Zmiany deweloperskie)

  7. Sesja roboczaZmiany deweloperskie

    DziałanieNajpierw deterministyczna poprawka Lombok · LLM pomijany, jeśli ponowny build przejdzie

    • przekazaniePonowny build nieudany→ Jeśli ponowny build zawiedzie, naprawa przez model z dowodami i instrukcjami poprawek (Agent naprawczy REODE)

  8. W trakcie rozwojuAgent naprawczy REODE

    Obserwacja · ustalenieJeśli ponowny build zawiedzie, naprawa przez model z dowodami i instrukcjami poprawek

    • przekazanieSygnały weryfikacji→ Karta wyników: build · testy · usunięte testy · wykluczenia surefire (Artefakty)

  9. ArtefaktyArtefakty

    ArtefaktKarta wyników: build · testy · usunięte testy · wykluczenia surefire

  10. Sesja roboczaZmiany deweloperskie

    DziałaniePozostałe awarie wracają do zbierania dowodów

Kontekst
Agent naprawczy próbował poprawiać pojedynczo około 40 błędów setMsg() not found, nie patrząc na @Data ani na wersję Lombok w pom.xml. Wejście, które już wcześniej było zepsute, nie było odróżniane od błędów wprowadzonych przez migrację.
Wynik
Karta wyników czyta wyniki builda i testów razem z liczbą usuniętych testów i wykluczeń surefire, a pozycję pokrycia pomija, gdy baseline jest nieznany. Zaliczenie przez usunięcie testów pozostaje porażką.
Ograniczenie
Zbieranie dowodów obejmuje próbkę najwyżej trzech źródeł, więc nie jest zrozumieniem całej bazy kodu. Nie ma zapisu, że worktree, niezależny przegląd czy kolejka scaleń develop z zasad faktycznie dotyczyły tego przypadku, a agent kodujący i model w tym przypadku nie są potwierdzone. Nie ma końcowych wyników testów ani pokrycia u klienta.
Źródła i pozostałe ograniczenia
  • Zadanie baseline i zadanie eksploracji przed poprawką przeszły ze stanu w toku do ukończonego, a commity z implementacją istnieją. Nie pobierano świeżych wyników kontroli GitHub.
  • Zasady tego repozytorium ustalają kolejkę scaleń feature → develop → main, ale ta sama procedura nie jest stosowana w innych projektach.
  • Opcjonalnie włączane agenty walidacyjne to mechanizm w implementacji, a nie dowód, że użyto ich przy każdej dostawie. Wartości takie jak wielkość dostawy czy proporcje nie są podane, bo nie udało się potwierdzić ich oryginalnych dowodów.
  • Gdy ponowny build zawodzi, naprawa przez model nadal otrzymuje oryginalny błąd builda, a nie nowy błąd z ponownego builda.