{
"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` drehst du bei `pathToTheLeft()`/`pathToTheRight()` nur, machst aber danach keinen Schritt nach vorne; laut Aufgabenstellung soll in dem Fall auch gelaufen werden.\n- In `TryStraightFirst` fehlt der Fall „wenn vorne/links/rechts nicht geht: rechts um kehrt“ (also 180° drehen), den die Aufgabe explizit verlangt.\n- In `BacktrackingAlgorithm` kann der `else`-Zweig (`turnLeft(); turnLeft(); moveForward(); ...`) `moveForward()` aufrufen, obwohl hinter der Figur evtl. kein Pfad ist → das kann in `GameOver(\"Pfad verlassen!\")` enden.\n- In `BacktrackingAlgorithm` ist das `besucht`-Array fix auf `[100][100][100]` dimensioniert; wenn ein Level mehr als 100 Zeilen/Spalten hätte, würdest du beim Indexieren mit `row/col` abstürzen (und für `dir` brauchst du zudem nur 0..3).\n\n### Suggestion\n- Schau dir in `TryStraightFirst` an, was nach einer erfolgreichen Links-/Rechts-Entscheidung passieren muss, damit „ein Schritt“ wirklich ausgeführt wird (und nicht nur die Richtung geändert wird).\n- Ergänze in `TryStraightFirst` am Ende der Entscheidungs-Kette einen „fallback“-Zweig für den Fall, dass keine der drei Richtungen möglich ist; überlege dabei, wie du „rechts um kehrt“ mit den vorhandenen Dreh-Methoden ausdrücken kannst.\n- Bevor du im Backtracking beim Zurückgehen `moveForward()` machst, prüfe in der neuen Blickrichtung nochmals, ob dort überhaupt ein Pfad ist (du hast dafür bereits passende Abfragen im Interface).\n- Statt fester `100`-Grössen: überlege, wie du die benötigte Grösse aus dem Labyrinth ableiten könntest (du hast zwar im Algorithmus kein `Labyrinth`-Objekt, aber du könntest die Strategie auch so bauen, dass du ohne riesiges 3D-Array auskommst oder `dir` zumindest auf 4 begrenzt).\n\n### Code Style\n- In `BacktrackingAlgorithm` ist `System.out.println(figure.isGoalReached());` Debug-Ausgabe und sollte für die Abgabe entfernt werden (sie triggert nebenbei auch unnötige Goal-Checks/Listener-Events).\n- Einrückung/Whitespace ist teils inkonsistent (z.B. fehlende Einrückung nach `{` in der Klasse, leere Zeilen/Abstände); das erschwert das Lesen der Rekursion.\n- `besucht` als `boolean[][][]` ist sehr speicherintensiv und der dritte Index mit 100 ist irreführend, weil `dir` nur 0..3 ist; benenne/strukturiere das so, dass die Dimensionen klar sind.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `ModeButton` ist der interaktive Bereich (`getInteractiveArea`) viel kleiner als das gezeichnete Rechteck (du zeichnest 65×25, aber die Rectangle ist 15×15). Damit sind Klicks/Hover nur in einem kleinen Teil des Buttons möglich, obwohl der Button grösser dargestellt wird.\n- Die verwendeten Resource-Pfade für Bilder (`swissmap_img/...`) weichen von den im Aufgabentext erwähnten Ressourcen im `resources`-Ordner ab (und auch von den üblichen Pfaden wie in `SwissMap`). Wenn diese Dateien/Pfade nicht exakt so im Projekt vorhanden sind, werden Seen/Berge/Hintergrund nicht angezeigt.\n\n### Suggestion\n- Überlege bei interaktiven Komponenten immer: Passt die `Shape`-Fläche wirklich zur sichtbaren Zeichnung? Nimm dieselben x/y/width/height-Werte wie beim Zeichnen (oder zumindest eine Fläche, die das ganze sichtbare Element abdeckt).\n- Prüfe, wie die Bilder im Template/Projekt wirklich abgelegt sind (Ordnername, Gross-/Kleinschreibung, relativer Pfad). Orientiere dich an dem Pfad-Schema, das bereits in `SwissMap.draw` verwendet wird, und teste, ob `drawImage` die Datei tatsächlich findet.\n\n3. Code Style:\n- Mehrere Debug-Ausgaben (`System.out.println(...)` in `SwissMap.draw` und `City.onMouseEnter`) stören bei jeder Frame-Neuzeichnung bzw. jedem Hover-Event; solche Ausgaben solltest du nach dem Testen entfernen.\n- Unbenutzte Imports in `Mountain` und `SwissMap` (`ImageIO`, `BufferedImage`, `IOException`, `Objects`) – aufräumen, damit der Code klar bleibt.\n- In `ModeButton` sind die Felder `hovered` und `clicked` aktuell ohne sichtbaren Effekt (wird nirgends in `draw` genutzt); entweder nutzen oder entfernen.\n- `toString()` enthält bei dir Zeilenumbrüche (`\"\\n\"`). Das kann je nach GUI-Library dazu führen, dass nur die erste Zeile angezeigt wird (oder gar nicht wie erwartet). Wenn du mehrzeiligen Text willst, musst du ggf. explizit mehrere `drawString`-Aufrufe machen.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Dein `DataPoint`-Interface stellt keine Werte bereit, die der `Visualizer` für x/y-Koordinaten braucht (im Code wird überall mit `DUMMY_DOUBLE` gearbeitet, aber es gibt in `DataPoint` keine passenden Getter für numerische x/y-Werte).\n- `DataPoint`-Methoden sind als „Setter“ formuliert (`void title(...)`, `void information(...)`), aber der `Visualizer` braucht Informationen *vom* Datenpunkt (also Rückgabewerte), um Min/Max zu berechnen, Punkte zu plotten, Gruppen zu sammeln und Hover-Text zu zeichnen.\n- In `Visualizer` wurden die Dummy-Werte (`DUMMY_DOUBLE`, `DUMMY_STRING`) nicht durch Aufrufe auf das jeweilige `DataPoint point`/`closest` ersetzt; damit kann die Visualisierung nicht wie gefordert funktionieren.\n- `Movie` implementiert `DataPoint` nicht, dadurch kann `loadMovies()` nicht als `DataPoint[]` an den `Visualizer` übergeben werden (Anforderung: Film-Datensatz zuerst integrieren).\n- `VisualizerApp.main()` nutzt weiterhin `new DataPoint[0]` statt einen der geladenen Datensätze zu übergeben.\n- Es fehlen die Integrationen für `Country` und `Processor` (jeweils `implements DataPoint` + passende Achsenwerte/Details), die in der Aufgabe am Schluss ebenfalls verlangt sind.\n- Die geforderten Javadoc-Kommentare zur Dokumentation des erwarteten Verhaltens der `DataPoint`-Methoden fehlen.\n\n### Suggestion\n- Schau dir in `Visualizer` jede Stelle an, wo `DUMMY_DOUBLE` verwendet wird: dort braucht es je einen Zahlenwert pro Punkt für die x- und y-Achse. Überlege dir daher zwei Interface-Methoden, die genau diese beiden Werte liefern.\n- Schau dir jede Stelle mit `DUMMY_STRING` an: einmal wird daraus eine „Group“ für Farben/Legende gebildet und einmal wird ein Titel + mehrzeilige Detailbeschreibung für den Hover-Effekt dargestellt. Das legt nahe, dass dein Interface mindestens Methoden für „Gruppenname“, „Titel“ und „Detailtext“ liefern sollte.\n- Achte darauf, dass die benötigten Infos vom `Visualizer` *abgefragt* werden: Formuliere Interface-Methoden so, dass sie Werte zurückgeben, statt dass von außen Daten „reingeschrieben“ werden.\n- Wenn du `Movie` kompatibel machen willst: überlege dir, welche Movie-Felder auf x (Budget) und y (Rating) gehören und welche Strings in der Hover-Ansicht erscheinen sollen (Screenshots als Referenz).\n- Für `VisualizerApp`: sobald deine Datensatzklassen `DataPoint` implementieren, kannst du testweise nur einen Datensatz (zuerst Movies) an `Visualizer` übergeben und danach Countries/Processors umschalten.\n- Für `Processor`: denk daran, dass x aus Jahr+Monat zu einem Wert kombiniert werden muss und y aus (clockRate * cores) entsteht; zusätzlich muss der Hover-Text eine sinnvoll umgerechnete Frequenzeinheit anzeigen.\n\n### Code Style\n- Methodennamen im Interface wie `title(...)`, `information(...)`, `secondInfo(...)` sind unklar benannt (v. a. `secondInfo`) und wirken wie Mutatoren; sprechendere Namen für das, was geliefert wird, würden die Schnittstelle verständlicher machen.\n- `Map<String, Integer>` als Parameter-Typ in `information(...)` wirkt für den Anwendungsfall „Tooltip-Text zeichnen“ sehr indirekt/umständlich (außerdem passen viele Werte wie Rating oder Literacy nicht sauber in `Integer`).\n- Im `DataPoint`-Interface fehlen Javadocs komplett, obwohl die Aufgabe explizit danach verlangt.\n",
"status" : "SUCCESS"
}
}