ES
El personaje original de REODE, retocado: una cara sonriente de ajolote crema y rosa con auriculares azul marino y lentes cian
Volver a la sala

REODE

Code migration

Antes de corregir, encontrar la causa común.

Un agente de migración de código Java/Spring.

2026.03 — 2026.04

Proyecto laboral · sistema de migración y verificación

  • CLIImplementado · proyecto laboral

Un bucle de migración que mantiene la evidencia de reparación aparte de la aceptación.

Se registra el estado de build original y se aplica la conversión basada en reglas, y luego se reúne la evidencia de fuentes y POM antes de reparar. Tras la edición de un modelo, se vuelven a comprobar build, test y la integridad de los tests, y las ejecuciones que terminan en un límite o se estancan se informan aparte del éxito.

Combina la conversión basada en reglas con la reparación asistida por modelos y comprueba el código modificado con build y test. Un proyecto laboral.

Trabajo de REODE en el repositorio; colaboración con pinxlab: March 16, 2026 to May 26, 2026

Una herramienta CLI usada en el trabajo.

Mapa del bucle de reparación · según registros de implementación privados
Bucle de reparación de migración de REODEEl estado de build original se conserva como línea base, se aplica la conversión basada en reglas, y build y test verifican el resultado. Si falla, se reúne evidencia de fuentes, anotaciones y POM antes de cualquier corrección, y los patrones conocidos se corrigen de forma determinista y se reconstruyen. Si la reconstrucción pasa, no se llama a ningún modelo; si falla, un modelo repara con la evidencia reunida y las instrucciones de corrección, y el resultado se vuelve a verificar. Las ejecuciones que terminan en el límite de iteraciones o se estancan pasan a la medición pero no cuentan como éxito, y la scorecard solo califica cuando pasan los cinco criterios de aceptación.Fuente · POMEntrada de migración privadaScorecard · calificaciónNo es un despliegueFallo · informe de estancamientoNo cuenta como éxitoComprobación originalEstado original · compilaciónEstado de ejecuciónLínea base · desconocidos sin medirRegistros de recuperaciónCheckpoint antes de corregirCorrección anterior, mismo errorConversiónPlan → conversión basada en reglasExplorar antes de corregirEvidencia de la causa · 3 fuentes · POMCorrección deterministaCorregir patrones conocidosComprobación de reconstrucciónReparación con modeloCorregir con evidencia · instruccionesVerificaciónbuild · test · iteración +1Paso siguienteContinuar · medir · 3 máx.MediciónProporción de reglas · tests · cobertura5 puertas de aceptaciónEntrada · línea baseRegistros de recuperaciónConversión · reparaciónVerificación · salida1fuente · POM2compilación original3 conversión por reglas · Estado original · compilación → Plan → conversión basada en reglas34build · test5resultado · iteraciones6aprobado · límite · estancamiento7comparación con la línea base8 calificación · 5 puertas de aceptación → Scorecard · calificación81resultado · iteraciones2 fallo · reintento · Continuar · medir · 3 máx. → Evidencia de la causa · 3 fuentes · POM23guardar antes de corregir4evidencia · errores agrupados5aprobado · LLM omitido6reconstrucción fallida7 corrección anterior · Corrección anterior, mismo error → Corregir con evidencia · instrucciones78volver a verificar1aprobado · límite · estancamiento2comparación con la línea base3 calificación · 5 puertas de aceptación → Scorecard · calificación34eliminados · excluidos · fallidos5salida por límite · estancamiento

Conversión por reglas

El estado original se conserva como línea base; tras la conversión por reglas, build y test verifican, y la ejecución pasa a la medición.

  1. Fuente · POMfuente · POMEstado original · compilaciónComprobación original

    Recibe la fuente Java/Spring y el POM que se van a migrar. No se muestran el código ni las pantallas de clientes.

  2. Estado original · compilaciónComprobación originalcompilación originalLínea base · desconocidos sin medirEstado de ejecución

    Antes de la conversión se elige el runtime y se compila el original, de modo que un build que ya estaba roto se conserva en la línea base. Los valores por defecto de test y cobertura de la línea base no son mediciones.

  3. Estado original · compilaciónComprobación originalconversión por reglasPlan → conversión basada en reglasConversión

    El grafo de ejecución sigue comprobación original → plan de conversión → conversión basada en reglas → verificación. Primero se aplican las conversiones que las reglas pueden cubrir.

  4. Plan → conversión basada en reglasConversiónbuild · testbuild · test · iteración +1Verificación

    Build y test verifican el código convertido y el contador de iteraciones sube en uno. Los resultados vuelven al estado de ejecución.

  5. build · test · iteración +1Verificaciónresultado · iteracionesContinuar · medir · 3 máx.Paso siguiente

    El éxito del build, la tasa de aprobación de los tests y el número de iteraciones deciden el siguiente paso.

  6. Continuar · medir · 3 máx.Paso siguienteaprobado · límite · estancamientoProporción de reglas · tests · coberturaMedición

    Cuando build y test pasan ambos, se alcanza el límite de iteraciones o se detecta un estancamiento (tras un intento de recuperación si aún no se hizo), la ejecución pasa a la medición. Pasar a la medición no significa éxito.

  7. Línea base · desconocidos sin medirEstado de ejecucióncomparación con la línea baseProporción de reglas · tests · coberturaMedición

    La medición lee la línea base guardada en el estado de ejecución. No es una nueva ejecución de línea base.

  8. 5 puertas de aceptaciónMedicióncalificaciónScorecard · calificación

    Build exitoso, una tasa de aprobación de tests del 100%, un cambio de cobertura de −5 o mejor (solo cuando se conoce la línea base), cero tests eliminados, cero exclusiones de surefire. Solo se asigna una calificación cuando pasan los cinco.

Reparación basada en la causa

La evidencia se reúne antes de corregir y las correcciones deterministas van primero. Si la reconstrucción pasa, se omite el modelo; si no, el modelo repara con evidencia e instrucciones y el resultado se vuelve a verificar.

  1. build · test · iteración +1Verificaciónresultado · iteracionesContinuar · medir · 3 máx.Paso siguiente

    El éxito del build, la tasa de aprobación de los tests y el número de iteraciones deciden el siguiente paso.

  2. Continuar · medir · 3 máx.Paso siguientefallo · reintentoEvidencia de la causa · 3 fuentes · POMExplorar antes de corregir

    Si el build falló o la tasa de aprobación de los tests es inferior al 100%, y no se alcanzó el límite de iteraciones (3 por defecto), la ejecución pasa a reparación.

  3. Evidencia de la causa · 3 fuentes · POMExplorar antes de corregirguardar antes de corregirCheckpoint antes de corregirRegistros de recuperación

    Se guarda un checkpoint antes de la corrección. Es best-effort: un guardado fallido no detiene la reparación, y un guardado no es evidencia de éxito.

  4. Evidencia de la causa · 3 fuentes · POMExplorar antes de corregirevidencia · errores agrupadosCorregir patrones conocidosCorrección determinista

    Reúne los archivos Java con fallos, las primeras líneas de hasta tres fuentes, los ajustes de anotaciones, POM y procesador de anotaciones, y los imports hasta profundidad 2. Una muestra acotada, no una comprensión de toda la base de código.

  5. Comprobación de reconstrucciónCorrección deterministaaprobado · LLM omitidobuild · test · iteración +1Verificación

    Si una corrección determinista de un patrón conocido (por ejemplo la configuración de Lombok) hace pasar la reconstrucción, no se llama a ningún modelo. La ejecución vuelve igualmente a la verificación, así que no es la aceptación final.

  6. Comprobación de reconstrucciónCorrección deterministareconstrucción fallidaCorregir con evidencia · instruccionesReparación con modelo

    Si la reconstrucción falla, la evidencia reunida y las instrucciones de corrección pasan a la reparación con modelo. Leer el código muestra que el texto de error que se pasa es el error de build original, no el nuevo de la reconstrucción, así que no debe leerse como “solo se pasan los errores restantes”. No es un defecto reproducido en una ejecución.

  7. Corrección anterior, mismo errorRegistros de recuperacióncorrección anteriorCorregir con evidencia · instruccionesReparación con modelo

    Se buscan y adjuntan las correcciones anteriores registradas con la misma firma de error. Un registro añadido a la entrada, no entrenamiento del modelo.

  8. Corregir con evidencia · instruccionesReparación con modelovolver a verificarbuild · test · iteración +1Verificación

    El modelo corrige mediante una ruta estructurada architect/editor, o con un prompt de uso de herramientas cuando esa ruta no está disponible o está en recuperación, y build y test vuelven a verificar. La edición de un modelo no es en sí un build aprobado.

Aprobado frente a estancamiento

Una calificación requiere las cinco puertas; los tests eliminados o excluidos y las salidas por límite o estancamiento no cuentan como éxito.

  1. Continuar · medir · 3 máx.Paso siguienteaprobado · límite · estancamientoProporción de reglas · tests · coberturaMedición

    Cuando build y test pasan ambos, se alcanza el límite de iteraciones o se detecta un estancamiento (tras un intento de recuperación si aún no se hizo), la ejecución pasa a la medición. Pasar a la medición no significa éxito.

  2. Línea base · desconocidos sin medirEstado de ejecucióncomparación con la línea baseProporción de reglas · tests · coberturaMedición

    La medición lee la línea base guardada en el estado de ejecución. No es una nueva ejecución de línea base.

  3. 5 puertas de aceptaciónMedicióncalificaciónScorecard · calificación

    Build exitoso, una tasa de aprobación de tests del 100%, un cambio de cobertura de −5 o mejor (solo cuando se conoce la línea base), cero tests eliminados, cero exclusiones de surefire. Solo se asigna una calificación cuando pasan los cinco.

  4. 5 puertas de aceptaciónMedicióneliminados · excluidos · fallidosFallo · informe de estancamiento

    Los aprobados obtenidos eliminando tests o mediante exclusiones de surefire, y los builds o tests fallidos, siguen siendo fallos. Las comprobaciones de eliminación y exclusión cuentan cero cuando no se pueden leer Git o el POM, así que no prueban que se detecte cada violación.

  5. Continuar · medir · 3 máx.Paso siguientesalida por límite · estancamientoFallo · informe de estancamiento

    Una ejecución que termina en el límite o se estanca pasa igualmente por la medición, pero no se informa como éxito. Esto marca cómo se informa; no es un atajo para saltarse la medición.

Todas las conexiones con el mismo grosor. Elija un flujo para resaltar solo su recorrido, con pasos numerados.

  • Continua · dirección de entradas, resultados y registros
  • Discontinua · ejecución, juicio, solicitud
  • Puntos largos · observación e informe, aparte del juicio
  • Guiones cortos · fallo, parada, límite
  • Línea negra gruesa · el flujo seleccionado; los números dan el orden
  • Recuadro · frontera de código o de estado, con su nombre en la cabecera
  • Chip interior · componente de esa frontera
  • Recuadro punteado · fuera de esa frontera
  • Contorno naranja · donde decide un modelo
  • Pasos del pipeline · reparación
  • Verificación · enrutamiento · aceptación
  • Estado · registros
  • Explorar antes de corregir

Dibujado a partir de registros privados de implementación y desarrollo. Los nombres son nombres públicos genéricos; no se muestran rutas de código ni información de clientes.

Entrada tras una reconstrucción fallida
La reparación con modelo recibe la evidencia reunida y las instrucciones de corrección, pero el texto de error que se pasa es el error de build original, no el nuevo de la reconstrucción. Establecido leyendo el código; no se reprodujo en una ejecución y no se cambió el código fuente.
Límites de las puertas
Si se desconoce la línea base de cobertura, esa puerta se omite. La comprobación de surefire cuenta las exclusiones del POM actual, no la diferencia con la línea base. Las comprobaciones de eliminación y exclusión cuentan cero cuando no se pueden leer Git o el POM.
El caso y sus cifras
Los unos 40 errores de setter atribuidos a una sola causa, la configuración de Lombok y POM, son un diagnóstico registrado en su momento. No es una cifra de rendimiento, exactitud ni entrega final.