{
"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- `TryStraightFirst` erfüllt die Vorgabe „Sollte das alles nicht gehen, soll die Figur rechtsum kehrt machen“ nicht: Wenn vorne/links/rechts kein Pfad ist, macht dein Code nichts und bleibt in der `while`-Schleife stecken.\n- `TryStraightFirst`: Wenn links oder rechts frei ist, drehst du nur, gehst aber im gleichen Schleifendurchlauf keinen Schritt vorwärts. Damit setzt du die Beschreibung „links oder rechts wird versucht“ nur halb um.\n- `BacktrackingAlgorithm` verlangt in deinem Design ein `Labyrinth` im Konstruktor und verwendet dann `labyrinth.cols()/rows()/goalAt(...)`. In `LabyrinthGame.play(...)` wird aber nur `navi.navigate(lab.figure())` aufgerufen und pro Level ein neues `Labyrinth` intern erzeugt. Dein Algorithmus arbeitet dadurch nicht garantiert auf dem Labyrinth/Figure des aktuellen Levels (du gibst ihm sogar fix `MAPS[1]`), womit er die Levels nicht korrekt lösen kann.\n- `BacktrackingAlgorithm`: Du prüfst das Ziel mit `labyrinth.goalAt(row,col)` statt über das bereitgestellte `figure.isGoalReached()`. Damit kann das Verhalten vom tatsächlich gespielten Level abweichen (siehe Punkt oben).\n- `BacktrackingAlgorithm`: Beim Backtracking gehst du nach dem rekursiven Aufruf immer „zurück“ (180° drehen, `moveForward`, wieder 180°), auch wenn der rekursive Aufruf das Ziel bereits gefunden hat. Dadurch läufst du potentiell vom Ziel wieder weg und `navigate` endet nicht zwingend am Ziel.\n- `BacktrackingAlgorithm`: Der Block `if(!figure.pathAhead() && !figure.pathToTheLeft() && !figure.pathToTheRight()) { turnRight(); turnRight(); checkPath(...) }` dreht nur um und ruft erneut `checkPath` auf, ohne ein Feld zu wechseln. Weil das Feld bereits als besucht markiert ist, bricht der rekursive Aufruf sofort ab; effektiv passiert bei Sackgassen kein „echtes“ Zurückgehen entlang des Pfads.\n\n### Suggestion\n- Für `TryStraightFirst`: Überlege dir, was im Fall passieren soll, dass **alle drei** Abfragen (`ahead/left/right`) `false` sind, und setze genau diesen Fall explizit um.\n- Für `TryStraightFirst`: Wenn du dich für „links versuchen“ oder „rechts versuchen“ entscheidest, prüfe, ob zur Aufgabenbeschreibung ein reines Drehen reicht oder ob du danach auch sofort einen Schritt machen solltest.\n- Für `BacktrackingAlgorithm`: Versuche, den Algorithmus so zu bauen, dass er **nur** mit dem `Figure`-Interface auskommt (die Aufgabe gibt dir genau dafür `path...`, `turn...`, `moveForward()`, `isGoalReached()`), statt ein externes `Labyrinth`-Objekt zu benötigen.\n- Für `BacktrackingAlgorithm`: Plane eine klare Abbruchbedingung: Wenn ein rekursiver Schritt das Ziel findet, muss diese Information nach oben „zurückgegeben“ werden, damit die höheren Stack-Frames nicht weiter andere Richtungen ausprobieren oder zurücklaufen.\n- Für `BacktrackingAlgorithm`: Bei Sackgassen brauchst du eine Strategie, wie du physisch zur vorherigen Kreuzung zurückkommst (also wirklich Felder zurückläufst), nicht nur die Richtung wechselst. Prüfe, ob dein Code in diesem Fall tatsächlich eine Bewegung macht.\n\n### Code Style\n- In `BacktrackingAlgorithm.navigate` sind auskommentierte Codeblöcke (alte Ideen) drin; das macht es schwer zu lesen—entferne sie, wenn du dich entschieden hast.\n- `BacktrackingAlgorithm` hat ein Feld `labyrinth`, das den Algorithmus stark koppelt; selbst wenn du es später korrekt machst, ist das unnötige Abhängigkeit für ein `NaviAlgorithm`-Interface, das nur eine `Figure` bekommt.\n- In `checkPath` wiederholst du die gleiche „vorwärts gehen, rekursiv, zurückgehen“-Sequenz dreimal; das schreit nach einer kleinen Hilfsmethode, um Duplikation zu reduzieren.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `SwissMapApp` ist der `ModeButton` zwar implementiert und hinzugefügt, aber seine `getInteractiveArea(...)`-Grösse passt nicht zum gezeichneten Button: Du zeichnest ein Rechteck mit `65x25`, interaktiv ist aber nur `15x15` – damit reagieren Hover/Klick nur auf einen kleinen Teil des Buttons.\n- In `Lake` und `Mountain` verwendest du Bildpfade wie `\"swissmap_img/...\"`, während `SwissMap` in der Aufgabenstellung/Library-Beispiel auf Ressourcen wie `\"swissmap/...\"` verweist; wenn deine Ressourcen nicht exakt so heissen/liegen wie im Projekt erwartet, werden die Bilder nicht geladen und die Objekte nicht korrekt angezeigt.\n- Deine Skalierung für Lake/Mountain-Bilder nutzt `WIDTH * scale(gui) / BG_PIXEL_WIDTH` (also die Hintergrund-Skalierung). Das führt sehr wahrscheinlich dazu, dass See/Berg viel zu gross/klein werden (weil die Objekt-Icons nicht dieselbe Pixelbasis wie die Hintergrundkarte haben). Damit wird die Darstellung “wie oben dargestellt” typischerweise verfehlt.\n\n### Suggestion\n- Mach die interaktive Fläche des `ModeButton` deckungsgleich mit dem tatsächlich gezeichneten Button-Rechteck (Position und Breite/Höhe sollten zusammenpassen), dann funktionieren Hover/Klick überall auf dem Button.\n- Prüfe, wie die Resource-Pfade im bereitgestellten Projekt wirklich heissen (Ordnername in `resources`, Gross-/Kleinschreibung) und orientiere dich an der Art, wie `SwissMap` sein Bild lädt. Wenn ein Pfad nicht stimmt, zeichnet `drawImage` ggf. einfach “nichts”.\n- Für die Icon-Grösse von Lake/Mountain: überlege dir eine eigene sinnvolle Icon-Skalierung (z.B. feste Pixelgrösse oder eine kleine Skalierung relativ zu `SwissMap.scale(gui)`), statt die Hintergrund-Skalierungsformel zu übernehmen.\n\n### Code Style\n- Entferne Debug-Ausgaben aus der Render-/Event-Logik (`System.out.println(...)` in `SwissMap.draw` und `City.onMouseEnter`), das spamt die Konsole massiv.\n- In `Mountain` und `SwissMap` sind Imports/Variablen für `ImageIO`, `BufferedImage`, `IOException`, `Objects` unbenutzt – diese bitte entfernen.\n- In `ModeButton` sind die Felder `hovered` und `clicked` aktuell ohne Effekt (sie beeinflussen weder Zeichnen noch Logik); entweder verwenden (z.B. fürs Hover-Design) oder weglassen.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Das `DataPoint`-Interface stellt nicht die Informationen bereit, die der `Visualizer` braucht: Es fehlen Methoden für die numerischen Werte auf x- und y-Achse sowie für die Strings, die für Gruppierung/Farbe und Hover-Text benötigt werden.\n- Die Methoden-Signaturen im `DataPoint`-Interface sind als Setter gestaltet (`void title(String name)`, `void information(...)`), aber der `Visualizer` benötigt Getter-artige Methoden, um Daten *aus* einem Datenpunkt zu lesen.\n- In `Visualizer` wurden die `DUMMY_DOUBLE`- und `DUMMY_STRING`-Stellen nicht durch Aufrufe auf das jeweilige `DataPoint`-Objekt ersetzt; damit kann die Visualisierung nicht korrekt funktionieren.\n- `Movie` (und analog `Country`, `Processor`) implementiert das `DataPoint`-Interface nicht, wie es in der Aufgabe gefordert ist; dadurch kann `loadMovies()` nicht als `DataPoint[]` an den `Visualizer` übergeben werden.\n- In `VisualizerApp.main()` wird weiterhin `new DataPoint[0]` verwendet statt einen der Loader (`loadMovies()`, `loadCountries()`, `loadProcessors()`) als Datensatz zu übergeben.\n\n### Suggestion\n- Schau dir in `Visualizer` jede Stelle mit `DUMMY_DOUBLE` an und überlege: „Welcher x- oder y-Wert eines Datenpunkts wird hier gebraucht?“ Daraus ergeben sich direkt 2 zentrale Methoden, die jedes `DataPoint` liefern muss.\n- Schau dir dann jede Stelle mit `DUMMY_STRING` an: Ein String wird für die Legende/Farbgruppe gebraucht, ein anderer für den Titel beim Hover, und ein weiterer (mehrzeiliger) für die Detailbeschreibung. Überlege, ob das dieselbe Methode sein soll oder mehrere unterschiedliche Strings.\n- Dein Interface sollte Informationen *zurückgeben* (Return-Werte), nicht entgegennehmen. Überlege: „Wenn der Visualizer etwas zeichnen will, muss er fragen können, nicht setzen.“\n- Sobald das Interface steht, implementiere es in `Movie` so, dass x/y den Achsenanforderungen entsprechen (Budget vs. Rating). Erst danach macht es Sinn, in `VisualizerApp` den Movie-Datensatz an den `Visualizer` zu übergeben.\n- Wenn Movies laufen, wiederhole das Mapping für `Country` (literacy vs. GDP per capita) und `Processor` (Zeitwert aus Jahr+Monat; effektive Geschwindigkeit aus Takt * Cores; für die Darstellung zusätzlich überlegen, wo/ob eine Log-Skalierung einfliessen muss).\n\n### Code Style\n- Interface-Methodennamen wie `title`, `information`, `secondInfo` sind sehr unpräzise/mehrdeutig; besser sind klar benannte, selbsterklärende Methoden (v. a. wenn sie von einem generischen `Visualizer` verwendet werden).\n- `Map<String, Integer>` in einem allgemeinen `DataPoint`-Interface ist sehr schwergewichtig und unflexibel (z. B. brauchst du teils `double` und formatierte Strings); ausserdem ist unklar, welche Keys erwartet werden.\n",
"status" : "SUCCESS"
}
}