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

Hacer que el agente de reparación lea primero la configuración

El agente que intentaba correcciones setter por setter es el agente de reparación dentro del producto REODE; el desarrollo cambió su entrada. El código y la información de clientes son privados.

Leyenda completa

Cómo leer · una misma gramática para cada caso

  • Las columnas indican quién actuó; de arriba abajo, el tiempo
  • Continua: un traspaso registrado o un paso siguiente
  • ↩ lapislázuli grueso: un hallazgo que devolvió el trabajo
  • Discontinua: no es una ejecución registrada (una regla escrita, un consejo sin autoridad, una frontera sin verificar)
  • Rectángulo: una acción
  • Redondeado: un estado observado o un hallazgo
  • Esquina doblada: un artefacto o una evidencia
  • Columna rayada: partes del producto en desarrollo (no los agentes usados para construirlo)

March 21, 2026

Los grupos de errores, el build original y la configuración de Lombok pasaron a ser la entrada de la reparación

  1. En desarrolloAgente de reparación de REODE

    Observación · hallazgoIntentó correcciones individuales para unos 40 errores de setter · @Data / POM sin revisar

  2. PersonaDesarrollador

    AcciónLeer la fuente y la configuración de build antes de corregir

    • traspasoEntrada de reparación cambiada→ Construir la línea base original · agrupar errores del mismo patrón (Cambios de desarrollo)

  3. Sesión de trabajoCambios de desarrollo

    AcciónConstruir la línea base original · agrupar errores del mismo patrón

    • traspaso→ Reunir evidencia: rutas · 3 muestras de fuentes · anotaciones · POM (Cambios de desarrollo)

  4. Regla escritaPolítica de contribución

    Regla · sin verificarPlan de tareas · worktree propio

    • no es una ejecución registradaExigido por la política→ Construir la línea base original · agrupar errores del mismo patrón (Cambios de desarrollo)

  5. Sesión de trabajoCambios de desarrollo

    AcciónReunir evidencia: rutas · 3 muestras de fuentes · anotaciones · POM

    • traspaso→ Primero la corrección determinista de Lombok · se omite el LLM si la reconstrucción pasa (Cambios de desarrollo)

  6. Regla escritaPolítica de contribución

    Regla · sin verificarRevisión sin contexto: plan ↔ diff

    • no es una ejecución registradaExigido por la política→ Reunir evidencia: rutas · 3 muestras de fuentes · anotaciones · POM (Cambios de desarrollo)

  7. Sesión de trabajoCambios de desarrollo

    AcciónPrimero la corrección determinista de Lombok · se omite el LLM si la reconstrucción pasa

    • traspasoReconstrucción fallida→ Si la reconstrucción falla, reparación con modelo usando evidencia e instrucciones de corrección (Agente de reparación de REODE)

  8. En desarrolloAgente de reparación de REODE

    Observación · hallazgoSi la reconstrucción falla, reparación con modelo usando evidencia e instrucciones de corrección

    • traspasoSeñales de verificación→ Scorecard: build · test · tests eliminados · exclusiones de surefire (Artefactos)

  9. ArtefactosArtefactos

    ArtefactoScorecard: build · test · tests eliminados · exclusiones de surefire

  10. Sesión de trabajoCambios de desarrollo

    AcciónLos fallos restantes vuelven a la recolección de evidencia

Contexto
El agente de reparación intentaba corregir uno por uno unos 40 errores setMsg() not found sin mirar @Data ni la versión de Lombok en pom.xml. No se distinguía una entrada que ya estaba rota de los errores que introdujo la migración.
Resultado
La scorecard lee los resultados de build y test junto con el número de tests eliminados y de exclusiones de surefire, y omite el ítem de cobertura cuando la línea base es desconocida. Aprobar eliminando tests sigue siendo un fallo.
Límite
La recolección de evidencia toma como muestra hasta tres fuentes, así que no es una comprensión de toda la base de código. No hay registro de que el worktree, la revisión independiente o la cola de merge de develop de la política se aplicaran realmente a este caso, y no se confirmaron el agente de programación ni el modelo de este caso. No hay resultados finales de tests ni de cobertura del cliente.
Fuentes y límites restantes
  • La tarea de línea base y la de explorar antes de corregir pasaron de en curso a terminadas, y existen commits de implementación. No se obtuvieron resultados recientes de comprobaciones de GitHub.
  • La política de este repositorio fija una cola de merge feature → develop → main, pero el mismo procedimiento no se aplica a otros proyectos.
  • Los agentes de validación opcionales son un mecanismo de la implementación, no evidencia de que se usaran en cada entrega. No se incluyen cifras como el tamaño o los ratios de entrega porque no se pudo confirmar su evidencia original.
  • Cuando la reconstrucción falla, la reparación con modelo sigue recibiendo el error de build original, no el nuevo de la reconstrucción.