DE
Die ursprüngliche REODE-Figur, überarbeitet: ein lächelndes Axolotl-Gesicht in Creme und Rosa mit marineblauem Headset und cyanfarbenen Gläsern
Zurück zum Saal

REODE

Code migration

Vor dem Korrigieren die gemeinsame Ursache finden.

Ein Agent zur Migration von Java/Spring-Code.

2026.03 — 2026.04

Arbeitsprojekt · Migrations- und Verifikationssystem

  • CLIImplementiert · Arbeitsprojekt

Eine Migrationsschleife, die Reparaturbelege von der Abnahme trennt.

Der ursprüngliche Build-Zustand wird aufgezeichnet und die regelbasierte Konvertierung angewandt, dann werden vor der Reparatur Belege aus Quellcode und POM gesammelt. Nach der Änderung durch ein Modell werden Build, Test und Testintegrität erneut geprüft, und Läufe, die an einem Limit oder durch Stillstand enden, werden getrennt vom Erfolg gemeldet.

Er verbindet regelbasierte Konvertierung mit modellgestützter Reparatur und prüft den geänderten Code mit Build und Test. Ein Arbeitsprojekt.

REODE-Arbeit im Repository; Einsatz bei pinxlab von March 16, 2026 bis May 26, 2026

Ein CLI-Tool für die Arbeit.

Karte der Reparaturschleife · nach nicht öffentlichen Implementierungsaufzeichnungen
Reparaturschleife der REODE-MigrationDer ursprüngliche Build-Zustand wird als Baseline festgehalten, die regelbasierte Konvertierung angewandt, und Build und Test verifizieren das Ergebnis. Bei einem Fehlschlag werden vor jeder Korrektur Belege aus Quellcode, Annotationen und POM gesammelt, und bekannte Muster werden deterministisch korrigiert und neu gebaut. Besteht der Rebuild, wird kein Modell aufgerufen; scheitert er, repariert ein Modell mit den gesammelten Belegen und Korrekturanweisungen, und das Ergebnis wird erneut verifiziert. Läufe, die am Iterationslimit oder durch Stillstand enden, gehen in die Messung, zählen aber nicht als Erfolg, und die Scorecard vergibt nur dann eine Note, wenn alle fünf Abnahme-Gates bestehen.Quellcode · POMNicht öffentliche MigrationseingabeScorecard · NoteKein DeploymentBericht zu Fehlschlag · StillstandNicht als Erfolg gezähltPrüfung des OriginalsUrsprünglicher Zustand · KompilierenLaufzustandBaseline · Unbekanntes ungemessenWiederherstellungsaufzeichnungenCheckpoint vor der KorrekturFrühere Korrektur, gleicher FehlerKonvertierungPlan → regelbasierte KonvertierungErkunden vor dem KorrigierenUrsachenbelege · 3 Quellen · POMDeterministische KorrekturBekannte Muster korrigierenRebuild-PrüfungModellreparaturKorrektur mit Belegen · AnweisungenVerifikationBuild · Test · Iteration +1Nächster SchrittWeiter · messen · max. 3MessungRegelanteil · Tests · Coverage5 Abnahme-GatesEingabe · BaselineWiederherstellungsaufzeichnungenKonvertierung · ReparaturVerifikation · Ausstieg1 Quellcode · POM · Quellcode · POM → Ursprünglicher Zustand · Kompilieren12ursprüngliches Kompilieren3 Regelkonvertierung · Ursprünglicher Zustand · Kompilieren → Plan → regelbasierte Konvertierung34build · test5Ergebnis · Iterationen6bestanden · Limit · Stillstand7Baseline-Vergleich8Benotung1Ergebnis · Iterationen2 gescheitert · Wiederholung · Weiter · messen · max. 3 → Ursachenbelege · 3 Quellen · POM23vor der Korrektur speichern4Belege · gruppierte Fehler5bestanden · LLM entfällt6Rebuild gescheitert7 frühere Korrektur · Frühere Korrektur, gleicher Fehler → Korrektur mit Belegen · Anweisungen78erneut verifizieren1bestanden · Limit · Stillstand2Baseline-Vergleich3Benotung4gelöscht · ausgeschlossen · gescheitert5Limit · Ausstieg bei Stillstand

Regelkonvertierung

Der ursprüngliche Zustand wird als Baseline festgehalten; nach der Regelkonvertierung verifizieren Build und Test, und der Lauf geht weiter zur Messung.

  1. Quellcode · POMQuellcode · POMUrsprünglicher Zustand · KompilierenPrüfung des Originals

    Übernimmt Java/Spring-Quellcode und POM zur Migration. Kundencode und -bildschirme werden nicht gezeigt.

  2. Ursprünglicher Zustand · KompilierenPrüfung des Originalsursprüngliches KompilierenBaseline · Unbekanntes ungemessenLaufzustand

    Vor der Konvertierung wird die Runtime gewählt und das Original kompiliert, sodass ein bereits defekter Build in der Baseline festgehalten wird. Standardwerte für Test und Coverage in der Baseline sind keine Messungen.

  3. Ursprünglicher Zustand · KompilierenPrüfung des OriginalsRegelkonvertierungPlan → regelbasierte KonvertierungKonvertierung

    Der Laufgraph verläuft Prüfung des Originals → Konvertierungsplan → regelbasierte Konvertierung → Verifikation. Konvertierungen, die Regeln leisten können, werden zuerst angewandt.

  4. Plan → regelbasierte KonvertierungKonvertierungbuild · testBuild · Test · Iteration +1Verifikation

    Build und Test verifizieren den konvertierten Code, und der Iterationszähler steigt um eins. Die Ergebnisse gehen zurück in den Laufzustand.

  5. Build · Test · Iteration +1VerifikationErgebnis · IterationenWeiter · messen · max. 3Nächster Schritt

    Build-Erfolg, Testbestehensquote und Iterationszahl bestimmen den nächsten Schritt.

  6. Weiter · messen · max. 3Nächster Schrittbestanden · Limit · StillstandRegelanteil · Tests · CoverageMessung

    Bestehen Build und Test beide, ist das Iterationslimit erreicht oder wird ein Stillstand erkannt (nach einem Wiederherstellungsversuch, falls noch keiner erfolgte), geht der Lauf in die Messung. In die Messung zu gehen bedeutet keinen Erfolg.

  7. Baseline · Unbekanntes ungemessenLaufzustandBaseline-VergleichRegelanteil · Tests · CoverageMessung

    Die Messung liest die im Laufzustand festgehaltene Baseline. Es ist kein neuer Baseline-Lauf.

  8. 5 Abnahme-GatesMessungBenotungScorecard · Note

    Erfolgreicher Build, eine Testbestehensquote von 100%, eine Coverage-Änderung von −5 oder besser (nur bei bekannter Baseline), null gelöschte Tests, null Surefire-Ausschlüsse. Eine Note wird nur vergeben, wenn alle fünf bestehen.

Ursachenbasierte Reparatur

Vor dem Korrigieren werden Belege gesammelt, und deterministische Korrekturen kommen zuerst. Besteht der Rebuild, wird das Modell übersprungen; andernfalls repariert das Modell mit Belegen und Anweisungen, und das Ergebnis wird erneut verifiziert.

  1. Build · Test · Iteration +1VerifikationErgebnis · IterationenWeiter · messen · max. 3Nächster Schritt

    Build-Erfolg, Testbestehensquote und Iterationszahl bestimmen den nächsten Schritt.

  2. Weiter · messen · max. 3Nächster Schrittgescheitert · WiederholungUrsachenbelege · 3 Quellen · POMErkunden vor dem Korrigieren

    Ist der Build gescheitert oder liegt die Testbestehensquote unter 100% und ist das Iterationslimit (standardmäßig 3) nicht erreicht, geht der Lauf in die Reparatur.

  3. Ursachenbelege · 3 Quellen · POMErkunden vor dem Korrigierenvor der Korrektur speichernCheckpoint vor der KorrekturWiederherstellungsaufzeichnungen

    Vor der Korrektur wird ein Checkpoint gespeichert, best-effort: Ein fehlgeschlagenes Speichern stoppt die Reparatur nicht, und ein Speichern ist kein Beleg für Erfolg.

  4. Ursachenbelege · 3 Quellen · POMErkunden vor dem KorrigierenBelege · gruppierte FehlerBekannte Muster korrigierenDeterministische Korrektur

    Sammelt die fehlschlagenden Java-Dateien, die ersten Zeilen von bis zu drei Quellen, Einstellungen zu Annotationen, POM und Annotation-Processor sowie Imports bis Tiefe 2. Eine begrenzte Stichprobe, kein Verständnis der gesamten Codebasis.

  5. Rebuild-PrüfungDeterministische Korrekturbestanden · LLM entfälltBuild · Test · Iteration +1Verifikation

    Lässt eine deterministische Korrektur eines bekannten Musters (etwa des Lombok-Setups) den Rebuild bestehen, wird kein Modell aufgerufen. Der Lauf kehrt dennoch zur Verifikation zurück, daher ist dies keine finale Abnahme.

  6. Rebuild-PrüfungDeterministische KorrekturRebuild gescheitertKorrektur mit Belegen · AnweisungenModellreparatur

    Scheitert der Rebuild, gehen die gesammelten Belege und Korrekturanweisungen an die Modellreparatur. Der Code zeigt, dass der mitgegebene Fehlertext der ursprüngliche Build-Fehler ist, nicht der neue des Rebuilds; dies darf also nicht als „nur die verbleibenden Fehler werden weitergegeben“ gelesen werden. Kein in einem Lauf reproduzierter Defekt.

  7. Frühere Korrektur, gleicher FehlerWiederherstellungsaufzeichnungenfrühere KorrekturKorrektur mit Belegen · AnweisungenModellreparatur

    Frühere Korrekturen, die unter derselben Fehlersignatur aufgezeichnet sind, werden nachgeschlagen und beigefügt. Eine der Eingabe hinzugefügte Aufzeichnung, kein Modelltraining.

  8. Korrektur mit Belegen · AnweisungenModellreparaturerneut verifizierenBuild · Test · Iteration +1Verifikation

    Das Modell korrigiert über einen strukturierten Architect/Editor-Pfad oder, wenn dieser nicht verfügbar ist oder eine Wiederherstellung läuft, über einen Tool-Use-Prompt, und Build und Test verifizieren erneut. Die Änderung eines Modells ist für sich noch kein bestandener Build.

Bestehen versus Stillstand

Eine Note erfordert alle fünf Gates; gelöschte oder ausgeschlossene Tests sowie Ausstiege an Limit oder Stillstand zählen nicht als Erfolg.

  1. Weiter · messen · max. 3Nächster Schrittbestanden · Limit · StillstandRegelanteil · Tests · CoverageMessung

    Bestehen Build und Test beide, ist das Iterationslimit erreicht oder wird ein Stillstand erkannt (nach einem Wiederherstellungsversuch, falls noch keiner erfolgte), geht der Lauf in die Messung. In die Messung zu gehen bedeutet keinen Erfolg.

  2. Baseline · Unbekanntes ungemessenLaufzustandBaseline-VergleichRegelanteil · Tests · CoverageMessung

    Die Messung liest die im Laufzustand festgehaltene Baseline. Es ist kein neuer Baseline-Lauf.

  3. 5 Abnahme-GatesMessungBenotungScorecard · Note

    Erfolgreicher Build, eine Testbestehensquote von 100%, eine Coverage-Änderung von −5 oder besser (nur bei bekannter Baseline), null gelöschte Tests, null Surefire-Ausschlüsse. Eine Note wird nur vergeben, wenn alle fünf bestehen.

  4. 5 Abnahme-GatesMessunggelöscht · ausgeschlossen · gescheitertBericht zu Fehlschlag · Stillstand

    Bestehen durch gelöschte Tests oder Surefire-Ausschlüsse sowie gescheiterte Builds oder Tests bleiben Fehlschläge. Die Lösch- und Ausschlussprüfungen zählen null, wenn Git oder das POM nicht gelesen werden kann, sind also kein Beweis, dass jeder Verstoß erfasst wird.

  5. Weiter · messen · max. 3Nächster SchrittLimit · Ausstieg bei StillstandBericht zu Fehlschlag · Stillstand

    Ein Lauf, der am Limit oder durch Stillstand endet, durchläuft dennoch die Messung, wird aber nicht als Erfolg gemeldet. Das kennzeichnet die Art der Meldung; es ist keine Abkürzung an der Messung vorbei.

Alle Verbindungen in gleicher Stärke. Wird ein Ablauf gewählt, ist nur sein Pfad hervorgehoben, mit nummerierten Schritten.

  • Durchgezogen · Richtung von Eingaben, Ergebnissen und Aufzeichnungen
  • Gestrichelt · Ausführen, Urteil, Anfrage
  • Lang gepunktet · Beobachtung und Berichte, getrennt vom Urteil
  • Kurz gestrichelt · Fehlschlag, Stopp, Limit
  • Dicke schwarze Linie · der gewählte Ablauf; Nummern geben die Reihenfolge an
  • Kasten · Code- oder Zustandsgrenze, benannt in der Kopfzeile
  • Innerer Chip · eine Komponente dieser Grenze
  • Gepunkteter Kasten · außerhalb dieser Grenze
  • Orange Umrandung · wo ein Modell entscheidet
  • Pipeline-Schritte · Reparatur
  • Verifikation · Routing · Abnahme
  • Zustand · Aufzeichnungen
  • Erkunden vor dem Korrigieren

Gezeichnet nach nicht öffentlichen Implementierungs- und Entwicklungsaufzeichnungen. Die Namen sind allgemeine öffentliche Bezeichnungen; Codepfade und Kundeninformationen werden nicht gezeigt.

Eingabe nach gescheitertem Rebuild
Die Modellreparatur erhält die gesammelten Belege und Korrekturanweisungen, doch der mitgegebene Fehlertext ist der ursprüngliche Build-Fehler, nicht der neue des Rebuilds. Durch Lesen des Codes festgestellt; nicht in einem Lauf reproduziert, und der Quellcode wurde nicht geändert.
Grenzen der Gates
Ist die Coverage-Baseline unbekannt, wird dieses Gate übersprungen. Die Surefire-Prüfung zählt die Ausschlüsse im aktuellen POM, nicht die Differenz zur Baseline. Die Lösch- und Ausschlussprüfungen zählen null, wenn Git oder das POM nicht gelesen werden kann.
Der Fall und seine Zahlen
Dass rund 40 Setter-Fehler auf eine Ursache, das Lombok- und POM-Setup, zurückgingen, ist eine damals aufgezeichnete Diagnose. Es ist keine Durchsatz-, Genauigkeits- oder finale Lieferzahl.