ID
Karakter REODE asli yang disempurnakan: wajah axolotl krem-merah muda yang tersenyum dengan headset biru dongker dan lensa sian
Kembali ke ruang pamer

REODE

Code migration

Sebelum memperbaiki, temukan penyebab bersama.

Agen migrasi kode Java/Spring.

2026.03 — 2026.04

Proyek kerja · sistem migrasi dan verifikasi

  • CLIDiimplementasikan · proyek kerja

Loop migrasi yang memisahkan bukti perbaikan dari penerimaan.

Status build asli dicatat dan konversi berbasis aturan diterapkan, lalu bukti sumber dan POM dikumpulkan sebelum perbaikan. Setelah model mengedit, build, test, dan integritas test diperiksa lagi, dan eksekusi yang berakhir di batas atau macet dilaporkan terpisah dari keberhasilan.

Agen ini memadukan konversi berbasis aturan dengan perbaikan berbantuan model dan memeriksa kode yang berubah dengan build dan test. Proyek kerja.

Pekerjaan REODE di repositori; keterlibatan dengan pinxlab March 16, 2026 hingga May 26, 2026

Alat CLI yang dipakai di tempat kerja.

Peta loop perbaikan · dari catatan implementasi privat
Loop perbaikan migrasi REODEStatus build asli disimpan sebagai baseline, konversi berbasis aturan diterapkan, dan build serta test memverifikasi hasilnya. Bila gagal, bukti sumber, anotasi, dan POM dikumpulkan sebelum perbaikan apa pun, dan pola yang dikenal diperbaiki secara deterministik lalu di-build ulang. Bila build ulang lolos, tidak ada model yang dipanggil; bila gagal, model memperbaiki dengan bukti yang dikumpulkan dan instruksi perbaikan, lalu hasilnya diverifikasi lagi. Eksekusi yang berakhir di batas iterasi atau macet tetap lanjut ke pengukuran tetapi tidak dihitung sebagai keberhasilan, dan scorecard hanya memberi nilai bila kelima gerbang penerimaan lolos.Sumber · POMInput migrasi privatScorecard · nilaiBukan deploymentLaporan kegagalan · macetTidak dihitung sebagai keberhasilanPemeriksaan asliStatus asli · compileStatus eksekusiBaseline · yang tidak diketahui tidak diukurCatatan pemulihanCheckpoint sebelum perbaikanPerbaikan sebelumnya, kesalahan samaKonversiRencana → konversi berbasis aturanEksplorasi sebelum memperbaikiBukti penyebab · 3 sumber · POMPerbaikan deterministikPerbaiki pola yang dikenalPemeriksaan build ulangPerbaikan modelPerbaiki dengan bukti · instruksiVerifikasibuild · test · iterasi +1Langkah berikutnyaLanjut · ukur · maks 3PengukuranPorsi aturan · test · cakupan5 gerbang penerimaanInput · baselineCatatan pemulihanKonversi · perbaikanVerifikasi · keluar1 sumber · POM · Sumber · POM → Status asli · compile12compile asli3 konversi aturan · Status asli · compile → Rencana → konversi berbasis aturan34build · test5hasil · iterasi6lolos · batas · macet7perbandingan baseline8 pemberian nilai · 5 gerbang penerimaan → Scorecard · nilai81hasil · iterasi2 gagal · coba ulang · Lanjut · ukur · maks 3 → Bukti penyebab · 3 sumber · POM23simpan sebelum perbaikan4bukti · kesalahan dikelompokkan5lolos · LLM dilewati6build ulang gagal7 perbaikan sebelumnya · Perbaikan sebelumnya, kesalahan sama → Perbaiki dengan bukti · instruksi78verifikasi lagi1lolos · batas · macet2perbandingan baseline3 pemberian nilai · 5 gerbang penerimaan → Scorecard · nilai34dihapus · dikecualikan · gagal5keluar karena batas · macet

Konversi aturan

Status asli disimpan sebagai baseline; setelah konversi aturan, build dan test memverifikasi, dan eksekusi lanjut ke pengukuran.

  1. Sumber · POMsumber · POMStatus asli · compilePemeriksaan asli

    Menerima sumber Java/Spring dan POM yang akan dimigrasikan. Kode dan layar pelanggan tidak ditampilkan.

  2. Status asli · compilePemeriksaan aslicompile asliBaseline · yang tidak diketahui tidak diukurStatus eksekusi

    Sebelum konversi, runtime dipilih dan sumber asli di-compile, sehingga build yang sudah rusak sejak awal tetap tercatat di baseline. Nilai bawaan test dan cakupan di baseline bukan hasil pengukuran.

  3. Status asli · compilePemeriksaan aslikonversi aturanRencana → konversi berbasis aturanKonversi

    Graf eksekusi berjalan pemeriksaan asli → rencana konversi → konversi berbasis aturan → verifikasi. Konversi yang dapat ditangani aturan diterapkan lebih dahulu.

  4. Rencana → konversi berbasis aturanKonversibuild · testbuild · test · iterasi +1Verifikasi

    Build dan test memverifikasi kode hasil konversi dan jumlah iterasi bertambah satu. Hasilnya kembali ke status eksekusi.

  5. build · test · iterasi +1Verifikasihasil · iterasiLanjut · ukur · maks 3Langkah berikutnya

    Keberhasilan build, tingkat kelulusan test, dan jumlah iterasi menentukan langkah berikutnya.

  6. Lanjut · ukur · maks 3Langkah berikutnyalolos · batas · macetPorsi aturan · test · cakupanPengukuran

    Bila build dan test sama-sama lolos, batas iterasi tercapai, atau kemacetan terdeteksi (setelah satu upaya pemulihan bila belum dicoba), eksekusi menuju pengukuran. Menuju pengukuran tidak berarti berhasil.

  7. Baseline · yang tidak diketahui tidak diukurStatus eksekusiperbandingan baselinePorsi aturan · test · cakupanPengukuran

    Pengukuran membaca baseline yang disimpan di status eksekusi. Ini bukan eksekusi baseline baru.

  8. 5 gerbang penerimaanPengukuranpemberian nilaiScorecard · nilai

    Build berhasil, tingkat kelulusan test 100%, perubahan cakupan −5 atau lebih baik (hanya bila baseline diketahui), nol test yang dihapus, nol pengecualian surefire. Nilai hanya diberikan bila kelimanya lolos.

Perbaikan berbasis penyebab

Bukti dikumpulkan sebelum memperbaiki dan perbaikan deterministik didahulukan. Bila build ulang lolos, model dilewati; bila tidak, model memperbaiki dengan bukti dan instruksi lalu hasilnya diverifikasi lagi.

  1. build · test · iterasi +1Verifikasihasil · iterasiLanjut · ukur · maks 3Langkah berikutnya

    Keberhasilan build, tingkat kelulusan test, dan jumlah iterasi menentukan langkah berikutnya.

  2. Lanjut · ukur · maks 3Langkah berikutnyagagal · coba ulangBukti penyebab · 3 sumber · POMEksplorasi sebelum memperbaiki

    Bila build gagal atau tingkat kelulusan test di bawah 100%, dan batas iterasi (bawaan 3) belum tercapai, eksekusi menuju perbaikan.

  3. Bukti penyebab · 3 sumber · POMEksplorasi sebelum memperbaikisimpan sebelum perbaikanCheckpoint sebelum perbaikanCatatan pemulihan

    Checkpoint disimpan sebelum perbaikan. Sifatnya best-effort: penyimpanan yang gagal tidak menghentikan perbaikan, dan penyimpanan bukan bukti keberhasilan.

  4. Bukti penyebab · 3 sumber · POMEksplorasi sebelum memperbaikibukti · kesalahan dikelompokkanPerbaiki pola yang dikenalPerbaikan deterministik

    Mengumpulkan berkas Java yang gagal, baris-baris awal dari paling banyak tiga sumber, pengaturan anotasi, POM, dan annotation processor, serta import hingga kedalaman 2. Sampel terbatas, bukan pemahaman atas seluruh codebase.

  5. Pemeriksaan build ulangPerbaikan deterministiklolos · LLM dilewatibuild · test · iterasi +1Verifikasi

    Bila perbaikan deterministik untuk pola yang dikenal (misalnya penyiapan Lombok) membuat build ulang lolos, tidak ada model yang dipanggil. Eksekusi tetap kembali ke verifikasi, jadi ini bukan penerimaan akhir.

  6. Pemeriksaan build ulangPerbaikan deterministikbuild ulang gagalPerbaiki dengan bukti · instruksiPerbaikan model

    Bila build ulang gagal, bukti yang dikumpulkan dan instruksi perbaikan diteruskan ke perbaikan model. Membaca kode menunjukkan bahwa teks kesalahan yang ikut diteruskan adalah kesalahan build awal, bukan kesalahan baru dari build ulang, sehingga ini tidak boleh dibaca sebagai “hanya kesalahan yang tersisa yang diteruskan”. Bukan cacat yang direproduksi dalam eksekusi.

  7. Perbaikan sebelumnya, kesalahan samaCatatan pemulihanperbaikan sebelumnyaPerbaiki dengan bukti · instruksiPerbaikan model

    Perbaikan sebelumnya yang tercatat dengan tanda tangan kesalahan yang sama dicari dan dilampirkan. Catatan yang ditambahkan ke input, bukan pelatihan model.

  8. Perbaiki dengan bukti · instruksiPerbaikan modelverifikasi lagibuild · test · iterasi +1Verifikasi

    Model memperbaiki melalui jalur architect/editor terstruktur, atau prompt tool-use bila jalur itu tidak tersedia atau sedang dalam pemulihan, lalu build dan test memverifikasi lagi. Editan model tidak dengan sendirinya merupakan build yang lolos.

Lolos versus macet

Peringkat memerlukan kelima gerbang; test yang dihapus atau dikecualikan serta keluar karena batas atau macet tidak dihitung sebagai keberhasilan.

  1. Lanjut · ukur · maks 3Langkah berikutnyalolos · batas · macetPorsi aturan · test · cakupanPengukuran

    Bila build dan test sama-sama lolos, batas iterasi tercapai, atau kemacetan terdeteksi (setelah satu upaya pemulihan bila belum dicoba), eksekusi menuju pengukuran. Menuju pengukuran tidak berarti berhasil.

  2. Baseline · yang tidak diketahui tidak diukurStatus eksekusiperbandingan baselinePorsi aturan · test · cakupanPengukuran

    Pengukuran membaca baseline yang disimpan di status eksekusi. Ini bukan eksekusi baseline baru.

  3. 5 gerbang penerimaanPengukuranpemberian nilaiScorecard · nilai

    Build berhasil, tingkat kelulusan test 100%, perubahan cakupan −5 atau lebih baik (hanya bila baseline diketahui), nol test yang dihapus, nol pengecualian surefire. Nilai hanya diberikan bila kelimanya lolos.

  4. 5 gerbang penerimaanPengukurandihapus · dikecualikan · gagalLaporan kegagalan · macet

    Kelulusan yang diperoleh dengan menghapus test atau dengan pengecualian surefire, serta build atau test yang gagal, tetap dihitung gagal. Pemeriksaan penghapusan dan pengecualian menghitung nol bila Git atau POM tidak dapat dibaca, jadi bukan bukti bahwa setiap pelanggaran tertangkap.

  5. Lanjut · ukur · maks 3Langkah berikutnyakeluar karena batas · macetLaporan kegagalan · macet

    Eksekusi yang berakhir di batas atau macet tetap melewati pengukuran tetapi tidak dilaporkan sebagai keberhasilan. Ini menandai cara pelaporan; bukan jalan pintas yang melewati pengukuran.

Setiap koneksi dengan bobot yang sama. Pilih alur untuk menyorot hanya jalurnya, dengan langkah bernomor.

  • Garis utuh · arah input, hasil, dan catatan
  • Garis putus · eksekusi, penilaian, permintaan
  • Titik panjang · observasi dan pelaporan, terpisah dari penilaian
  • Strip pendek · kegagalan, berhenti, batas
  • Garis hitam tebal · alur yang dipilih; angka menunjukkan urutan
  • Kotak · batas kode atau status, namanya di bagian kepala
  • Chip dalam · komponen dari batas itu
  • Kotak bertitik · di luar batas itu
  • Garis tepi oranye · tempat model memutuskan
  • Langkah pipeline · perbaikan
  • Verifikasi · perutean · penerimaan
  • Status · catatan
  • Eksplorasi sebelum memperbaiki

Digambar dari catatan implementasi dan pengembangan privat. Nama-nama adalah nama publik umum; tidak ada path kode atau informasi pelanggan yang ditampilkan.

Input setelah build ulang gagal
Perbaikan model menerima bukti yang dikumpulkan dan instruksi perbaikan, tetapi teks kesalahan yang ikut diteruskan adalah kesalahan build awal, bukan kesalahan baru dari build ulang. Ditetapkan dengan membaca kode; tidak direproduksi dalam eksekusi, dan sumbernya tidak diubah.
Batas gerbang
Bila baseline cakupan tidak diketahui, gerbang itu dilewati. Pemeriksaan surefire menghitung pengecualian di POM saat ini, bukan selisih dari baseline. Pemeriksaan penghapusan dan pengecualian menghitung nol bila Git atau POM tidak dapat dibaca.
Kasus dan angkanya
Sekitar 40 kesalahan setter yang ditelusuri ke satu penyebab, penyiapan Lombok dan POM, adalah diagnosis yang dicatat saat itu. Ini bukan angka throughput, akurasi, atau penyerahan akhir.