{
"llm" : {
"feedback" : "# Exercise: floodfill\n\n### Correctness\n- `RecursiveFloodFill` prüft nicht auf die *alte* Startfarbe (die Farbe des angeklickten Pixels), sondern nur darauf, ob ein Pixel schon `newColor` hat; dadurch “flutest” du über Farbgrenzen hinweg und füllst potentiell das ganze Bild statt nur zusammenhängende Bereiche gleicher Ausgangsfarbe.\n- In `testFarbeRec` setzt du den Pixel (`setPixel`) **bevor** du sicherstellst, dass `(x, y)` im gültigen Bildbereich liegt; bei rekursiven Aufrufen wie `y - 1` kann das sofort zu `ArrayIndexOutOfBoundsException` führen.\n- Deine Bounds-Checks verwenden fixe Grenzen (`x > 400`, `y > 400`) statt `img.getWidth()` / `img.getHeight()`; bei 50×50 bringt das nichts und verhindert Fehler nicht zuverlässig.\n- Die Rekursion bricht nicht korrekt ab, wenn ein Pixel eine andere Farbe als die Startfarbe hat (Basisfall fehlt/ist falsch) → Endergebnis entspricht nicht dem Flood-Fill-Verhalten aus der Aufgabenbeschreibung.\n- `FillAlgorithm` deklariert `String toString();` explizit. Gefordert war, die `toString`-Schnittstelle zu nutzen, nicht sie im Interface vorzuschreiben; so wie es jetzt ist, zwingst du jede Implementation zu einer `toString`-Methode im Interface-Kontext (unnötig und weicht von der Aufgabe ab).\n- In `DrawingApp` wird beim Wechsel mit ↑/↓ zwar ein Algorithmus gesetzt, aber es gibt kein “Durchschalten”/Togglen zwischen Algorithmen (↑ setzt immer ColorReplace, ↓ immer RecursiveFloodFill). Die Aufgabe verlangt explizit “zwischen den beiden Algorithmen wechseln” analog zur Farblogik.\n\n### Suggestion\n- Überlege dir beim Flood Fill: Welche Farbe ist die “gesuchte” Farbe, die gefüllt werden darf? Das ist die Farbe am Startpixel beim Klick. Diese Information musst du in der Rekursion irgendwie mitgeben (z. B. als zusätzlicher Parameter in einer privaten Hilfsmethode).\n- Formuliere den Basisfall so, dass sofort zurückgegeben wird, wenn `(x, y)` außerhalb des Bildes liegt **oder** wenn das Pixel nicht die Startfarbe hat. Wichtig: Diese Prüfungen müssen passieren, bevor du `getPixel`/`setPixel` aufrufst.\n- Ersetze die fixen Grenzen (400) durch Abfragen gegen `img.getWidth()` und `img.getHeight()` (denk an `0 ≤ x < width` und `0 ≤ y < height`).\n- Achte darauf, dass du ein Pixel “besuchst” (einfärbst) bevor du die Nachbarn aufrufst, damit ein Zurücklaufen der Rekursion nicht endlos wird.\n- Für den Algorithmuswechsel: mach es wie bei `colorIndex` mit einem Index oder Toggle-Logik, sodass ↑ und ↓ wirklich zyklisch/robust zwischen den Optionen wechseln (statt “↑ = Algorithmus A” und “↓ = Algorithmus B” fest zu verdrahten).\n- Lass `toString` aus dem `FillAlgorithm`-Interface weg; implementiere `toString` einfach in den Klassen und nutze beim Zeichnen der Statuszeile die normale String-Konvertierung des aktuell ausgewählten Objekts.\n\n### Code Style\n- Variablennamen wie `ColorReplace` und `RecursiveFloodFill` beginnen bei dir groß und wirken wie Klassennamen; in Java sollten Felder/Variablen klein beginnen (das reduziert Verwechslungsgefahr massiv).\n- Die Methode `testFarbeRec` heißt nicht nach ihrer Aufgabe (sie “testet” nicht nur, sie füllt). Ein Name, der das Verhalten beschreibt, macht die Rekursion leichter nachvollziehbar.\n- `testFarbeRec` gibt `boolean` zurück, aber der Rückgabewert wird nie sinnvoll genutzt; das macht die Rekursion unnötig kompliziert.\n\n\n# Exercise: flashcard\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n\n\n# Exercise: imagestats\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n",
"status" : "SUCCESS"
}
}