PT
O personagem original do REODE, refinado: um rosto sorridente de axolote creme e rosa com headset azul-marinho e lentes ciano
Voltar à sala

REODE

Code migration

Antes de corrigir, encontrar a causa comum.

Um agente de migração de código Java/Spring.

2026.03 — 2026.04

Projeto de trabalho · sistema de migração e verificação

  • CLIImplementado · projeto de trabalho

Um loop de migração que mantém as evidências de reparo à parte da aceitação.

O estado de build original é registrado e a conversão baseada em regras é aplicada, depois as evidências de fonte e de POM são reunidas antes do reparo. Após a edição de um modelo, build, test e integridade dos testes são verificados de novo, e execuções que terminam em um limite ou travam são relatadas à parte do sucesso.

Combina conversão baseada em regras com reparo assistido por modelo e verifica o código alterado com build e test. Um projeto de trabalho.

Trabalho do REODE no repositório; contrato com a pinxlab: March 16, 2026 to May 26, 2026

Uma ferramenta CLI usada no trabalho.

Mapa do loop de reparo · a partir de registros de implementação privados
Loop de reparo de migração do REODEO estado de build original é mantido como linha de base, a conversão baseada em regras é aplicada, e build e test verificam o resultado. Em caso de falha, evidências de fonte, anotações e POM são reunidas antes de qualquer correção, e padrões conhecidos são corrigidos de forma determinística e reconstruídos. Se o rebuild passar, nenhum modelo é chamado; se falhar, um modelo repara com as evidências reunidas e as instruções de correção, e o resultado é verificado de novo. Execuções que terminam no limite de iterações ou travam seguem para a medição, mas não contam como sucesso, e a scorecard só dá nota quando os cinco critérios de aceitação passam.Fonte · POMEntrada de migração privadaScorecard · notaNão é uma implantaçãoFalha · relatório de travamentoNão conta como sucessoVerificação originalEstado original · compilaçãoEstado da execuçãoLinha de base · desconhecidos não medidosRegistros de recuperaçãoCheckpoint antes da correçãoCorreção anterior, mesmo erroConversãoPlano → conversão baseada em regrasExplorar antes de corrigirEvidências da causa · 3 fontes · POMCorreção determinísticaCorrigir padrões conhecidosVerificação de rebuildReparo por modeloCorrigir com evidências · instruçõesVerificaçãobuild · test · iteração +1Próxima etapaContinuar · medir · 3 no máx.MediçãoParcela de regras · testes · cobertura5 portões de aceitaçãoEntrada · linha de baseRegistros de recuperaçãoConversão · reparoVerificação · saída1fonte · POM2compilação original3 conversão por regras · Estado original · compilação → Plano → conversão baseada em regras34build · test5resultado · iterações6aprovação · limite · travamento7comparação com a linha de base8 atribuição de nota · 5 portões de aceitação → Scorecard · nota81resultado · iterações2 falha · nova tentativa · Continuar · medir · 3 no máx. → Evidências da causa · 3 fontes · POM23salvar antes de corrigir4evidências · erros agrupados5aprovado · LLM pulado6rebuild com falha7 correção anterior · Correção anterior, mesmo erro → Corrigir com evidências · instruções78verificar de novo1aprovação · limite · travamento2comparação com a linha de base3 atribuição de nota · 5 portões de aceitação → Scorecard · nota34apagados · excluídos · com falha5saída por limite · travamento

Conversão por regras

O estado original é mantido como linha de base; após a conversão por regras, build e test verificam, e a execução segue para a medição.

  1. Fonte · POMfonte · POMEstado original · compilaçãoVerificação original

    Recebe a fonte Java/Spring e o POM a migrar. O código e as telas de clientes não são mostrados.

  2. Estado original · compilaçãoVerificação originalcompilação originalLinha de base · desconhecidos não medidosEstado da execução

    Antes da conversão, o runtime é escolhido e o original é compilado, de modo que um build já quebrado fica na linha de base. Os valores padrão de test e cobertura na linha de base não são medições.

  3. Estado original · compilaçãoVerificação originalconversão por regrasPlano → conversão baseada em regrasConversão

    O grafo de execução segue verificação original → plano de conversão → conversão baseada em regras → verificação. As conversões que as regras conseguem cobrir são aplicadas primeiro.

  4. Plano → conversão baseada em regrasConversãobuild · testbuild · test · iteração +1Verificação

    Build e test verificam o código convertido e a contagem de iterações sobe em um. Os resultados voltam ao estado da execução.

  5. build · test · iteração +1Verificaçãoresultado · iteraçõesContinuar · medir · 3 no máx.Próxima etapa

    O sucesso do build, a taxa de aprovação dos testes e o número de iterações decidem a próxima etapa.

  6. Continuar · medir · 3 no máx.Próxima etapaaprovação · limite · travamentoParcela de regras · testes · coberturaMedição

    Quando build e test passam, o limite de iterações é atingido ou um travamento é detectado (após uma tentativa de recuperação, se ainda não feita), a execução vai para a medição. Ir para a medição não significa sucesso.

  7. Linha de base · desconhecidos não medidosEstado da execuçãocomparação com a linha de baseParcela de regras · testes · coberturaMedição

    A medição lê a linha de base mantida no estado da execução. Não é uma nova execução de linha de base.

  8. 5 portões de aceitaçãoMediçãoatribuição de notaScorecard · nota

    Build bem-sucedido, taxa de aprovação de testes de 100%, variação de cobertura de −5 ou melhor (só quando a linha de base é conhecida), zero testes apagados, zero exclusões do surefire. Uma nota só é dada quando os cinco passam.

Reparo baseado na causa

As evidências são reunidas antes de corrigir, e as correções determinísticas vêm primeiro. Se o rebuild passar, o modelo é pulado; se não, o modelo repara com evidências e instruções e o resultado é verificado de novo.

  1. build · test · iteração +1Verificaçãoresultado · iteraçõesContinuar · medir · 3 no máx.Próxima etapa

    O sucesso do build, a taxa de aprovação dos testes e o número de iterações decidem a próxima etapa.

  2. Continuar · medir · 3 no máx.Próxima etapafalha · nova tentativaEvidências da causa · 3 fontes · POMExplorar antes de corrigir

    Se o build falhou ou a taxa de aprovação dos testes está abaixo de 100%, e o limite de iterações (3 por padrão) não foi atingido, a execução vai para o reparo.

  3. Evidências da causa · 3 fontes · POMExplorar antes de corrigirsalvar antes de corrigirCheckpoint antes da correçãoRegistros de recuperação

    Um checkpoint é salvo antes da correção. É best-effort: uma falha ao salvar não interrompe o reparo, e salvar não é evidência de sucesso.

  4. Evidências da causa · 3 fontes · POMExplorar antes de corrigirevidências · erros agrupadosCorrigir padrões conhecidosCorreção determinística

    Reúne os arquivos Java com falha, as primeiras linhas de até três fontes, as configurações de anotações, POM e processador de anotações, e os imports até profundidade 2. Uma amostra limitada, não uma compreensão de toda a base de código.

  5. Verificação de rebuildCorreção determinísticaaprovado · LLM puladobuild · test · iteração +1Verificação

    Se uma correção determinística de um padrão conhecido (por exemplo a configuração do Lombok) faz o rebuild passar, nenhum modelo é chamado. A execução ainda volta à verificação, então isso não é aceitação final.

  6. Verificação de rebuildCorreção determinísticarebuild com falhaCorrigir com evidências · instruçõesReparo por modelo

    Se o rebuild falhar, as evidências reunidas e as instruções de correção vão para o reparo por modelo. A leitura do código mostra que o texto de erro repassado é o erro de build original, não o novo erro do rebuild, então isso não deve ser lido como “só os erros restantes são repassados”. Não é um defeito reproduzido em execução.

  7. Correção anterior, mesmo erroRegistros de recuperaçãocorreção anteriorCorrigir com evidências · instruçõesReparo por modelo

    Correções anteriores registradas sob a mesma assinatura de erro são buscadas e anexadas. Um registro acrescentado à entrada, não treinamento de modelo.

  8. Corrigir com evidências · instruçõesReparo por modeloverificar de novobuild · test · iteração +1Verificação

    O modelo corrige por um caminho estruturado architect/editor, ou por um prompt de uso de ferramentas quando esse caminho não está disponível ou está em recuperação, e build e test verificam de novo. A edição de um modelo não é, por si só, um build aprovado.

Aprovação versus travamento

Uma nota exige os cinco portões; testes apagados ou excluídos e saídas por limite ou travamento não contam como sucesso.

  1. Continuar · medir · 3 no máx.Próxima etapaaprovação · limite · travamentoParcela de regras · testes · coberturaMedição

    Quando build e test passam, o limite de iterações é atingido ou um travamento é detectado (após uma tentativa de recuperação, se ainda não feita), a execução vai para a medição. Ir para a medição não significa sucesso.

  2. Linha de base · desconhecidos não medidosEstado da execuçãocomparação com a linha de baseParcela de regras · testes · coberturaMedição

    A medição lê a linha de base mantida no estado da execução. Não é uma nova execução de linha de base.

  3. 5 portões de aceitaçãoMediçãoatribuição de notaScorecard · nota

    Build bem-sucedido, taxa de aprovação de testes de 100%, variação de cobertura de −5 ou melhor (só quando a linha de base é conhecida), zero testes apagados, zero exclusões do surefire. Uma nota só é dada quando os cinco passam.

  4. 5 portões de aceitaçãoMediçãoapagados · excluídos · com falhaFalha · relatório de travamento

    Aprovações obtidas apagando testes ou por exclusões do surefire, e builds ou testes com falha, continuam sendo falhas. As verificações de remoção e exclusão contam zero quando o Git ou o POM não podem ser lidos, então não provam que toda violação é detectada.

  5. Continuar · medir · 3 no máx.Próxima etapasaída por limite · travamentoFalha · relatório de travamento

    Uma execução que termina no limite ou trava ainda passa pela medição, mas não é relatada como sucesso. Isso marca como se relata; não é um atalho para pular a medição.

Todas as conexões com a mesma espessura. Escolha um fluxo para destacar só o caminho dele, com etapas numeradas.

  • Contínua · direção de entradas, resultados e registros
  • Tracejada · execução, julgamento, requisição
  • Pontos longos · observação e relatório, à parte do julgamento
  • Traços curtos · falha, parada, limite
  • Linha preta grossa · o fluxo selecionado; os números dão a ordem
  • Caixa · fronteira de código ou de estado, com o nome no cabeçalho
  • Chip interno · componente dessa fronteira
  • Caixa pontilhada · fora dessa fronteira
  • Contorno laranja · onde um modelo decide
  • Etapas do pipeline · reparo
  • Verificação · roteamento · aceitação
  • Estado · registros
  • Explorar antes de corrigir

Desenhado a partir de registros privados de implementação e desenvolvimento. Os nomes são nomes públicos genéricos; nenhum caminho de código ou informação de cliente é mostrado.

Entrada após um rebuild com falha
O reparo por modelo recebe as evidências reunidas e as instruções de correção, mas o texto de erro repassado é o erro de build original, não o novo erro do rebuild. Estabelecido pela leitura do código; não reproduzido em execução, e o código-fonte não foi alterado.
Limites dos portões
Se a linha de base de cobertura for desconhecida, esse portão é pulado. A verificação do surefire conta as exclusões do POM atual, não a diferença em relação à linha de base. As verificações de remoção e exclusão contam zero quando o Git ou o POM não podem ser lidos.
O caso e seus números
Os cerca de 40 erros de setter atribuídos a uma única causa, a configuração do Lombok e do POM, são um diagnóstico registrado na época. Não é um número de vazão, acurácia ou entrega final.