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

Den Reparatur-Agenten zuerst die Konfiguration lesen lassen

Der Agent, der Setter für Setter zu korrigieren versuchte, ist der Reparatur-Agent im Produkt REODE; die Entwicklung änderte seine Eingabe. Code und Kundeninformationen sind nicht öffentlich.

Vollständige Legende

Lesehilfe · eine Grammatik für jeden Fall

  • Spalten zeigen, wer handelte; von oben nach unten verläuft die Zeit
  • Durchgezogen: eine aufgezeichnete Übergabe oder ein nächster Schritt
  • Dicke Lapislinie ↩: ein Befund, der die Arbeit zurückschickte
  • Gestrichelt: keine aufgezeichnete Ausführung (eine schriftliche Vorgabe, ein Rat ohne Befugnis, eine ungeprüfte Grenze)
  • Rechteck: eine Handlung
  • Abgerundet: ein beobachteter Zustand oder Befund
  • Eselsohr: ein Artefakt oder Beleg
  • Schraffierte Spalte: Teile des Produkts in Entwicklung (nicht die Agenten, mit denen es gebaut wird)

March 21, 2026

Fehlergruppen, der ursprüngliche Build und das Lombok-Setup wurden zur Reparatureingabe

  1. In EntwicklungREODE-Reparatur-Agent

    Beobachtung · BefundEinzelne Korrekturen für rund 40 Setter-Fehler versucht · @Data / POM nicht geprüft

  2. MenschEntwickler

    HandlungVor dem Korrigieren Quellcode und Build-Konfiguration lesen

    • ÜbergabeReparatureingabe geändert→ Ursprüngliche Baseline bauen · Fehler gleichen Musters gruppieren (Entwicklungsänderungen)

  3. ArbeitssessionEntwicklungsänderungen

    HandlungUrsprüngliche Baseline bauen · Fehler gleichen Musters gruppieren

    • Übergabe→ Belege sammeln: Pfade · 3 Quellstichproben · Annotationen · POM (Entwicklungsänderungen)

  4. Schriftliche VorgabeBeitragsrichtlinie

    Vorgabe · ungeprüftAufgabenplan · eigener Worktree

    • keine aufgezeichnete AusführungVon der Vorgabe verlangt→ Ursprüngliche Baseline bauen · Fehler gleichen Musters gruppieren (Entwicklungsänderungen)

  5. ArbeitssessionEntwicklungsänderungen

    HandlungBelege sammeln: Pfade · 3 Quellstichproben · Annotationen · POM

    • Übergabe→ Zuerst deterministische Lombok-Korrektur · LLM entfällt, wenn der Rebuild besteht (Entwicklungsänderungen)

  6. Schriftliche VorgabeBeitragsrichtlinie

    Vorgabe · ungeprüftZero-Context-Review: Plan ↔ Diff

    • keine aufgezeichnete AusführungVon der Vorgabe verlangt→ Belege sammeln: Pfade · 3 Quellstichproben · Annotationen · POM (Entwicklungsänderungen)

  7. ArbeitssessionEntwicklungsänderungen

    HandlungZuerst deterministische Lombok-Korrektur · LLM entfällt, wenn der Rebuild besteht

    • ÜbergabeRebuild gescheitert→ Scheitert der Rebuild, Modellreparatur mit Belegen und Korrekturanweisungen (REODE-Reparatur-Agent)

  8. In EntwicklungREODE-Reparatur-Agent

    Beobachtung · BefundScheitert der Rebuild, Modellreparatur mit Belegen und Korrekturanweisungen

    • ÜbergabeVerifikationssignale→ Scorecard: Build · Test · gelöschte Tests · Surefire-Ausschlüsse (Artefakte)

  9. ArtefakteArtefakte

    ArtefaktScorecard: Build · Test · gelöschte Tests · Surefire-Ausschlüsse

  10. ArbeitssessionEntwicklungsänderungen

    HandlungVerbleibende Fehlschläge gehen zurück zur Belegsammlung

Hintergrund
Der Reparatur-Agent versuchte, rund 40 Fehler setMsg() not found einzeln zu beheben, ohne @Data oder die Lombok-Version in pom.xml anzusehen. Bereits defekte Eingaben wurden nicht von Fehlern unterschieden, die die Migration verursacht hatte.
Ergebnis
Die Scorecard liest Build- und Testergebnisse zusammen mit der Zahl gelöschter Tests und Surefire-Ausschlüsse und überspringt den Coverage-Punkt, wenn die Baseline unbekannt ist. Bestehen durch Löschen von Tests bleibt ein Fehlschlag.
Grenze
Die Belegsammlung zieht Stichproben aus höchstens drei Quellen, ist also kein Verständnis der gesamten Codebasis. Es gibt keine Aufzeichnung, dass Worktree, unabhängiges Review oder develop-Merge-Queue der Vorgabe tatsächlich auf diesen Fall angewandt wurden, und Coding-Agent und Modell für diesen Fall sind nicht bestätigt. Es gibt keine finalen Test- oder Coverage-Ergebnisse von Kunden.
Quellen und verbleibende Grenzen
  • Die Baseline-Aufgabe und die Aufgabe „Erkunden vor dem Korrigieren“ wechselten von in Arbeit zu erledigt, und es gibt Implementierungs-Commits. Neue GitHub-Prüfergebnisse wurden nicht abgerufen.
  • Die Vorgabe dieses Repositorys legt eine Merge-Queue feature → develop → main fest, doch dasselbe Verfahren wird nicht auf andere Projekte angewandt.
  • Die optional zuschaltbaren Validierungsagenten sind ein Mechanismus der Implementierung, kein Beleg, dass sie bei jeder Lieferung eingesetzt wurden. Zahlen wie Liefergröße oder Quoten sind nicht enthalten, weil ihre ursprünglichen Belege nicht bestätigt werden konnten.
  • Scheitert der Rebuild, erhält die Modellreparatur trotzdem den ursprünglichen Build-Fehler, nicht den neuen des Rebuilds.