Оновлений оригінальний персонаж REODE: усміхнене кремово-рожеве обличчя аксолотля в темно-синій гарнітурі й блакитних лінзах
Назад до зали

REODE

Code migration

Перш ніж виправляти, знайти спільну причину.

Агент міграції коду Java/Spring.

2026.03 — 2026.04

Робочий проєкт · система міграції й верифікації

  • CLIРеалізовано · робочий проєкт

Агент виправлення спершу читає конфігурацію

Агент, що пробував виправляти setter по одному, — це агент виправлення всередині продукту REODE; розробка змінила його вхідні дані. Код і інформація про клієнтів закриті.

Повна легенда

Як читати · одна граматика для всіх випадків

  • Стовпці — хто діяв; згори донизу — час
  • Суцільна: записана передача чи наступний крок
  • Товста лазуритова ↩: зауваження, що повернуло роботу
  • Штрихова: не записане виконання (письмове правило, порада без повноважень, неперевірена межа)
  • Прямокутник: дія
  • Заокруглений: спостережений стан чи зауваження
  • Загнутий кут: артефакт чи доказ
  • Заштрихований стовпець: частини продукту, що розробляється (не агенти, якими його створюють)

March 21, 2026

Групи помилок, оригінальна збірка й налаштування Lombok стали вхідними даними виправлення

  1. У розробціАгент виправлення REODE

    Спостереження · зауваженняСпроби окремих виправлень для близько 40 помилок setter · @Data / POM не перевірено

  2. ЛюдинаРозробник

    ДіяЧитати джерело й конфігурацію збірки до виправлення

    • передачаВхідні дані виправлення змінено→ Зібрати оригінальну базову лінію · згрупувати помилки одного шаблону (Зміни в розробці)
  3. Робоча сесіяЗміни в розробці

    ДіяЗібрати оригінальну базову лінію · згрупувати помилки одного шаблону

    • передача→ Збір доказів: шляхи · 3 вибірки джерел · анотації · POM (Зміни в розробці)
  4. Письмове правилоПолітика для контриб’юторів

    Правило · не перевіреноПлан завдання · власний worktree

    • не записане виконанняВимагає політика→ Зібрати оригінальну базову лінію · згрупувати помилки одного шаблону (Зміни в розробці)
  5. Робоча сесіяЗміни в розробці

    ДіяЗбір доказів: шляхи · 3 вибірки джерел · анотації · POM

    • передача→ Спершу детерміноване виправлення Lombok · LLM пропускається, якщо повторна збірка проходить (Зміни в розробці)
  6. Письмове правилоПолітика для контриб’юторів

    Правило · не перевіреноРев’ю з нульовим контекстом: план ↔ diff

    • не записане виконанняВимагає політика→ Збір доказів: шляхи · 3 вибірки джерел · анотації · POM (Зміни в розробці)
  7. Робоча сесіяЗміни в розробці

    ДіяСпершу детерміноване виправлення Lombok · LLM пропускається, якщо повторна збірка проходить

    • передачаПовторна збірка не пройшла→ Якщо повторна збірка не проходить, модель виправляє з доказами й інструкціями (Агент виправлення REODE)
  8. У розробціАгент виправлення REODE

    Спостереження · зауваженняЯкщо повторна збірка не проходить, модель виправляє з доказами й інструкціями

    • передачаСигнали верифікації→ Картка оцінок: збірка · тести · видалені тести · виключення surefire (Артефакти)
  9. АртефактиАртефакти

    АртефактКартка оцінок: збірка · тести · видалені тести · виключення surefire

  10. Робоча сесіяЗміни в розробці

    ДіяЗалишкові збої повертаються до збору доказів

Контекст
Агент виправлення намагався виправити близько 40 помилок setMsg() not found по одній, не дивлячись на @Data чи версію Lombok у pom.xml. Вхідні дані, що вже були зламані, не відрізнялися від помилок, внесених міграцією.
Результат
Картка оцінок читає результати збірки й тестів разом із кількістю видалених тестів і виключень surefire та пропускає пункт покриття, коли базова лінія невідома. Проходження через видалення тестів лишається збоєм.
Межа
Збір доказів бере вибірку не більше ніж із трьох джерел, тож це не розуміння всієї кодової бази. Немає запису, що worktree, незалежне рев’ю чи черга злиття develop з політики справді застосовувалися до цього випадку, а агента для програмування й модель для цього випадку не підтверджено. Остаточних результатів тестів чи покриття від клієнта немає.
Джерела й залишкові обмеження
  • Завдання базової лінії й завдання «дослідити перед виправленням» перейшли з «у роботі» до «готово», і коміти реалізації існують. Нових результатів перевірок GitHub не отримували.
  • Політика цього репозиторію задає чергу злиття feature → develop → main, але ту саму процедуру не застосовано до інших проєктів.
  • Опційні агенти валідації — механізм у реалізації, а не доказ, що їх використовували в кожній поставці. Показники на кшталт обсягу поставки чи часток не наведено, бо їхні первинні докази не вдалося підтвердити.
  • Коли повторна збірка не проходить, виправлення моделлю все одно отримує початкову помилку збірки, а не нову помилку повторної збірки.