{
"llm" : {
"feedback" : "# Exercise: parking\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- In `TryStraightFirst` entspricht die Logik nicht der Aufgabenbeschreibung: Du sollst **in jedem Schleifendurchlauf** zuerst geradeaus prüfen, sonst links oder rechts, und wenn gar nichts geht **rechts um kehrt** machen; bei dir läufst du erst “so weit wie möglich geradeaus” und entscheidest danach nur noch zwischen links und rechts (kein definierter U‑Turn-Fall).\n- In `TryStraightFirst` fehlt der Fall, wenn **weder links noch rechts** ein Pfad ist: Dann machst du aktuell immer `turnRight()`, aber das ist nicht zwingend “rechts um kehrt” und kann in einer Sackgasse direkt zum Crash führen (weil danach wieder `pathAhead()` false sein kann und du in der nächsten Iteration trotzdem wieder rechts drehst usw.).\n- `BacktrackingAlgorithm`: Deine Hauptschleife läuft nur, solange `figure.pathAhead()` true ist. Wenn du an einer Stelle stehst, wo **vorne kein Pfad** ist, aber **links/rechts** einer wäre (oder du eigentlich zuerst drehen müsstest), endet die Methode sofort, obwohl das Ziel evtl. noch erreichbar ist.\n- `BacktrackingAlgorithm`: Durch den rekursiven Aufruf `navigate(figure)` ohne sauber definiertes “Zurückkehren zum letzten Abzweig” kann es passieren, dass du nach dem Rücksprung **nicht zuverlässig am gleichen Knoten/Zustand** (Position+Richtung) weiterarbeitest, den du für korrektes Backtracking bräuchtest.\n- `StupidAlgorithm`: Der Algorithmus soll “geradeaus bis Ziel” laufen; bei dir wird `moveForward()` auch dann aufgerufen, wenn **kein Pfad ahead** ist → damit crasht es schon dann, wenn der Gang endet, statt “geradeaus solange möglich/ bis Ziel” (und der erste Teil der Aufgabe sagt zwar, Level 2 crasht, aber geradeaus laufen impliziert trotzdem, dass du nicht absichtlich sofort vom Pfad läufst).\n\n### Suggestion\n- Für `TryStraightFirst`: Überlege dir eine **einzelne Iteration** als “genau ein Schritt” (oder mindestens: genau eine Entscheidungslogik) und bilde die Priorität **ahead → left → right → U‑turn** direkt darin ab.\n- Für den U‑Turn-Fall: Prüfe explizit den Zustand “kein Pfad ahead, kein Pfad links, kein Pfad rechts” und leite daraus ab, wie viele Drehungen nötig sind, damit die Figur wirklich zurückschaut.\n- Für `BacktrackingAlgorithm`: Wenn `pathAhead()` false ist, solltest du nicht einfach aufhören, sondern das als “ich muss eine Alternative probieren oder zurück” interpretieren; plane also auch den Fall “ich stehe vor einer Wand” ein.\n- Für echtes Backtracking: Du brauchst eine Art, dir zu merken, welche Abzweigungen du schon ausprobiert hast (z.B. über gespeicherte Zustände/Positionen oder eine Stack-ähnliche Struktur). Ohne so eine Merkhilfe läufst du leicht im Kreis oder “verlierst” den Rückweg.\n- Für `StupidAlgorithm`: Wenn du wirklich “nur geradeaus” willst, hilft eine Bedingung, die das Vorwärtslaufen an “Ziel noch nicht erreicht” **und** “vorne ist ein Pfad” koppelt (damit es nicht sofort durch `GameOver` endet, sobald der Korridor endet).\n\n### Code Style\n- In `StupidAlgorithm` sind viele auskommentierte Codezeilen/alte Ansätze drin; das macht es schwer zu lesen – besser entfernen, sobald du dich für eine Variante entschieden hast.\n- `StupidAlgorithm` hat einen leeren Konstruktor ohne Zweck; den kannst du weglassen, solange du nichts initialisieren musst.\n- `BacktrackingAlgorithm` ist durch die verschachtelten Blöcke schwer nachzuvollziehen; kleinere Hilfsmethoden (z.B. “drehe um”, “gehe zurück bis …”) würden die Lesbarkeit deutlich verbessern.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `SwissMapApp` ist `main()` nicht als echter Java-Entry-Point deklariert (`public static void main(String[] args)`); so startet das Programm in einer normalen Java-Ausführung nicht.\n- In `Coordinate.toGuiX/toGuiY` greifst du auf `SwissMap.TOP_LEFT.east` bzw. `.north` zu, obwohl `east` und `north` in `Coordinate` `private` sind; das kompiliert so nicht (anderes Class-File, auch im selben Package).\n- In `City.getInteractiveArea(...)`, `Lake.getInteractiveArea(...)` und `Mountain.getInteractiveArea(...)` verwendest du `new Rectangle(coord.toGuiX(gui), coord.toGuiY(gui), ...)` so, als wäre `(x,y)` die linke obere Ecke; deine Zeichnung (Circle bzw. `drawImageCentered`) ist aber um `(x,y)` zentriert. Dadurch liegt die Hover-Fläche nicht korrekt über dem sichtbaren Objekt.\n\n### Suggestion\n- Schau dir die Java-Signatur an, die eine Klasse braucht, damit sie beim Starten als Programm erkannt wird, und passe die Methode entsprechend an.\n- Wenn du auf die Werte von `TOP_LEFT` zugreifen willst, nutze die vorhandenen Getter (`getEast()/getNorth()`) statt direkt auf die Felder zuzugreifen, oder überlege, in welcher Klasse dieser Zugriff überhaupt stattfinden soll.\n- Überlege bei `getInteractiveArea`: Welche Koordinaten erwartet die `Rectangle`-Klasse (Top-Left vs. Center)? Wenn dein Icon um den Punkt zentriert ist, musst du die Rectangle-Position entsprechend um die halbe Breite/Höhe verschieben, damit Hover zuverlässig funktioniert.\n\n### Code Style\n- In `ModeButton` sollten Felder wie `map`, `x`, `y`, `width`, `height` gekapselt werden (`private final` wo möglich).\n- Du wiederholst an vielen Stellen `coord.toGuiX(gui)` und `coord.toGuiY(gui)` mehrfach pro `draw`/`getInteractiveArea`; speichere die Werte lokal in Variablen, das macht es lesbarer.\n- `gui.setBold(true)` wird gesetzt, aber nirgends wieder zurückgesetzt; das kann andere Komponenten beeinflussen (gleiches gilt für Textausrichtung/FontSize).\n\n\n# Exercise: visualizer\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n",
"status" : "SUCCESS"
}
}