EN
The original REODE character, refined: a smiling cream-and-pink axolotl face with a navy headset and cyan lenses
Back to the hall

REODE

Code migration

Before fixing, find the common cause.

A Java/Spring code-migration agent.

2026.03 — 2026.04

Work project · migration and verification system

  • CLIImplemented · work project

A migration loop that keeps repair evidence apart from acceptance.

The original build state is recorded and rule-based conversion applied, then source and POM evidence is gathered before repair. After a model’s edit, build, test and test integrity are checked again, and runs that end at a limit or stall are reported apart from success.

It combines rule-based conversion with model-assisted repair and checks the changed code with build and test. A work project.

REODE work in the repository; pinxlab engagement March 16, 2026 to May 26, 2026

A CLI tool used at work.

Repair loop map · from private implementation records
REODE migration repair loopThe original build state is kept as a baseline, rule-based conversion is applied, and build and test verify the result. On failure, source, annotation and POM evidence is gathered before any fix, and known patterns are fixed deterministically and rebuilt. If the rebuild passes, no model is called; if it fails, a model repairs with the gathered evidence and fix instructions, and the result is verified again. Runs that end at the iteration limit or stall go on to measurement but are not counted as success, and the scorecard grades only when all five acceptance gates pass.Source · POMPrivate migration inputScorecard · gradeNot a deploymentFailure · stall reportNot counted as successOriginal checkOriginal state · compileRun stateBaseline · unknowns unmeasuredRecovery recordsCheckpoint before fixEarlier fix, same errorConversionPlan → rule-based conversionExplore before fixingCause evidence · 3 sources · POMDeterministic fixFix known patternsRebuild checkModel repairFix with evidence · instructionsVerificationbuild · test · iteration +1Next stepContinue · measure · 3 maxMeasurementRule share · tests · coverage5 acceptance gatesInput · baselineRecovery recordsConversion · repairVerification · exit1source · POM2original compile3 rule conversion · Original state · compile → Plan → rule-based conversion34build · test5result · iterations6pass · limit · stall7baseline comparison8grading1result · iterations2 failed · retry · Continue · measure · 3 max → Cause evidence · 3 sources · POM23save before fix4evidence · grouped errors5passed · LLM skipped6rebuild failed7earlier fix8verify again1pass · limit · stall2baseline comparison3grading4deleted · excluded · failed5limit · stall exit

Rule conversion

The original state is kept as a baseline; after rule conversion, build and test verify, and the run goes on to measurement.

  1. Source · POMsource · POMOriginal state · compileOriginal check

    Takes the Java/Spring source and POM to migrate. Customer code and screens are not shown.

  2. Original state · compileOriginal checkoriginal compileBaseline · unknowns unmeasuredRun state

    Before conversion, the runtime is selected and the original is compiled, so a build that was already broken is kept in the baseline. Default test and coverage values in the baseline are not measurements.

  3. Original state · compileOriginal checkrule conversionPlan → rule-based conversionConversion

    The run graph goes original check → conversion plan → rule-based conversion → verification. Conversions that rules can carry are applied first.

  4. Plan → rule-based conversionConversionbuild · testbuild · test · iteration +1Verification

    Build and test verify the converted code and the iteration count goes up by one. Results return to the run state.

  5. build · test · iteration +1Verificationresult · iterationsContinue · measure · 3 maxNext step

    Build success, test pass rate and the iteration count decide the next step.

  6. Continue · measure · 3 maxNext steppass · limit · stallRule share · tests · coverageMeasurement

    When build and test both pass, the iteration limit is reached, or a stall is detected (after one recovery attempt if not yet tried), the run goes to measurement. Going to measurement does not mean success.

  7. Baseline · unknowns unmeasuredRun statebaseline comparisonRule share · tests · coverageMeasurement

    Measurement reads the baseline kept in the run state. It is not a new baseline run.

  8. 5 acceptance gatesMeasurementgradingScorecard · grade

    Build success, a 100% test pass rate, a coverage change of −5 or better (only when the baseline is known), zero deleted tests, zero surefire exclusions. A grade is given only when all five pass.

Cause-based repair

Evidence is gathered before fixing and deterministic fixes come first. If the rebuild passes, the model is skipped; if not, the model repairs with evidence and instructions and the result is verified again.

  1. build · test · iteration +1Verificationresult · iterationsContinue · measure · 3 maxNext step

    Build success, test pass rate and the iteration count decide the next step.

  2. Continue · measure · 3 maxNext stepfailed · retryCause evidence · 3 sources · POMExplore before fixing

    If the build failed or the test pass rate is below 100%, and the iteration limit (3 by default) is not reached, the run goes to repair.

  3. Cause evidence · 3 sources · POMExplore before fixingsave before fixCheckpoint before fixRecovery records

    A checkpoint is saved before the fix. It is best-effort: a failed save does not stop the repair, and a save is no evidence of success.

  4. Cause evidence · 3 sources · POMExplore before fixingevidence · grouped errorsFix known patternsDeterministic fix

    Collects the failing Java files, the opening lines of up to three sources, annotation, POM and annotation-processor settings, and imports to depth 2. A bounded sample, not an understanding of the whole codebase.

  5. Rebuild checkDeterministic fixpassed · LLM skippedbuild · test · iteration +1Verification

    If a deterministic fix of a known pattern (for example the Lombok setup) makes the rebuild pass, no model is called. The run still returns to verification, so this is not final acceptance.

  6. Rebuild checkDeterministic fixrebuild failedFix with evidence · instructionsModel repair

    If the rebuild fails, the gathered evidence and fix instructions go to model repair. Reading the code shows that the error text passed along is the original build error, not the rebuild’s new one, so this must not be read as “only the remaining errors are passed on”. Not a defect reproduced in a run.

  7. Earlier fix, same errorRecovery recordsearlier fixFix with evidence · instructionsModel repair

    Earlier fixes recorded under the same error signature are looked up and attached. A record added to the input, not model training.

  8. Fix with evidence · instructionsModel repairverify againbuild · test · iteration +1Verification

    The model fixes through a structured architect/editor path, or a tool-use prompt when that path is unavailable or in recovery, and build and test verify again. A model’s edit is not in itself a passing build.

Pass versus stall

A grade needs all five gates; deleted or excluded tests and limit or stall exits are not counted as success.

  1. Continue · measure · 3 maxNext steppass · limit · stallRule share · tests · coverageMeasurement

    When build and test both pass, the iteration limit is reached, or a stall is detected (after one recovery attempt if not yet tried), the run goes to measurement. Going to measurement does not mean success.

  2. Baseline · unknowns unmeasuredRun statebaseline comparisonRule share · tests · coverageMeasurement

    Measurement reads the baseline kept in the run state. It is not a new baseline run.

  3. 5 acceptance gatesMeasurementgradingScorecard · grade

    Build success, a 100% test pass rate, a coverage change of −5 or better (only when the baseline is known), zero deleted tests, zero surefire exclusions. A grade is given only when all five pass.

  4. 5 acceptance gatesMeasurementdeleted · excluded · failedFailure · stall report

    Passes obtained by deleting tests or by surefire exclusions, and failed builds or tests, remain failures. The deletion and exclusion checks count zero when Git or the POM cannot be read, so they are no proof that every violation is caught.

  5. Continue · measure · 3 maxNext steplimit · stall exitFailure · stall report

    A run that ends at the limit or stalls still goes through measurement but is not reported as success. This marks how it is reported; it is not a shortcut around measurement.

Every connection at the same weight. Pick a flow to highlight only its path, with numbered steps.

  • Solid · direction of input, results and records
  • Dashed · run, judgment, request
  • Long dots · observation and reporting, apart from judgment
  • Short dashes · failure, stop, limit
  • Heavy black line · the selected flow; numbers give the order
  • Box · code or state boundary, named in its header
  • Inner chip · a component of that boundary
  • Dotted box · outside that boundary
  • Orange outline · where a model decides
  • Pipeline steps · repair
  • Verification · routing · acceptance
  • State · records
  • Explore before fixing

Drawn from private implementation and development records. Names are generic public names; no code paths or customer information are shown.

Input after a failed rebuild
Model repair receives the gathered evidence and fix instructions, but the error text passed along is the original build error, not the rebuild’s new one. Established by reading the code; not reproduced in a run, and the source was not changed.
Limits of the gates
If the coverage baseline is unknown, that gate is skipped. The surefire check counts the exclusions in the current POM, not the difference from the baseline. The deletion and exclusion checks count zero when Git or the POM cannot be read.
The case and its numbers
About 40 setter errors traced to one cause, the Lombok and POM setup, is a diagnosis recorded at the time. It is not a throughput, accuracy or final delivery figure.