{
"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- Die Aufgaben a) und b) fehlen: Es gibt keine Klassen `StupidAlgorithm` und `TryStraightFirst`, obwohl sie explizit verlangt sind.\n- In `LabyrinthApp` hast du die vorgegebenen `MAPS` durch eigene ersetzt; damit erfüllst du nicht mehr die Level-Vorgaben der Aufgabe („erste vier Levels“, „letzte Levels“ etc.).\n- `BacktrackingAlgorithmWithMemory` kann vorzeitig abbrechen, obwohl vom aktuellen Zustand aus noch ein Weg zum Ziel existiert: Du markierst nur `col/row` als „gesehen“ und ignorierst die Blickrichtung (`dir`). Da die erlaubten nächsten Schritte stark von der Orientierung abhängen, ist „Position schon besucht“ nicht gleichbedeutend mit „hier gibt es nichts mehr zu finden“.\n\n### Suggestion\n- Implementiere zuerst wirklich die zwei einfachen Algorithmen aus a) und b) als eigene Klassen, die `NaviAlgorithm` implementieren, und schalte dann in der `main` jeweils zwischen ihnen um (wie in der Aufgabenbeschreibung gefordert).\n- Lass die `MAPS` in `LabyrinthApp` unverändert und teste deine Algorithmen gegen genau diese Level; sonst kannst du nicht beurteilen, ob die Anforderungen („bis Level 4“, „alle Level“) erfüllt sind.\n- Wenn du „Memory“ verwenden willst, überlege dir, welchen Zustand du tatsächlich speichern musst, damit du nicht fälschlich einen sinnvollen Zustand wegschneidest. Tipp: Ein Zustand kann mehr sein als nur `(row,col)`; prüfe, was sich noch unterscheidet, wenn du dieselbe Zelle erneut betrittst.\n\n### Code Style\n- `BacktrackingAlgorithm` und `BacktrackingAlgorithmWithMemory` haben duplizierte Logik (vor/zurück gehen, drehen, rekursiver Aufruf). Das könntest du in kleine Hilfsmethoden auslagern, damit es leichter lesbar und weniger fehleranfällig wird.\n- Für `seenPositions` wäre ein kleiner eigener Schlüsseltyp (z.B. eigene Klasse/Record oder zumindest ein konsistenter String inkl. Richtung) verständlicher als String-Konkatenation im Code.\n- Du hast sehr viel Template-Code (Figure/Labyrinth/LabyrinthGame etc.) 1:1 mit abgegeben; normalerweise gehört in die Abgabe nur, was du selbst ergänzt/änderst (je nach Vorgaben des Kurses/Autograders).\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `SwissMapApp` ist `main()` nicht `public static void main(String[] args)`, dadurch startet die Applikation in einer normalen Java-Umgebung typischerweise nicht.\n- Die Hover-Anforderung „Beschreibung anzeigen, wenn man darüber hovert“ ist nicht umgesetzt: In `City`/`Lake`/`Mountain` wird beim Hover nur die Darstellung (Grösse/Bild) geändert, aber nirgends der Text (z. B. via `toString()`) gezeichnet.\n- `getInteractiveArea(...)` ist bei `City`, `Lake` und `Mountain` sehr wahrscheinlich falsch dimensioniert, weil du als Breite/Höhe `area` bzw. `height` verwendest (das sind km² bzw. Meter, keine GUI-Pixel). Dadurch wird der Hover-Bereich riesig oder völlig unpassend und stimmt nicht mit dem gezeichneten Objekt überein.\n- `ModeButton.onLeftClick(...)` koppelt das Umschalten an `onButton` (Hover-Status). Gemäss Aufgabe soll beim Klick innerhalb des interaktiven Bereichs umgeschaltet werden; ob vorher `onMouseEnter` sauber passiert ist, sollte dafür nicht Voraussetzung sein.\n\n### Suggestion\n- Prüfe, wie dein Projekt den Programmeinstieg erwartet (IDE/Autograder): Wenn ein echtes `main` erwartet ist, muss Signatur und Sichtbarkeit exakt passen.\n- Nutze den `hovering`-Zustand nicht nur für „grösser/anderes Icon“, sondern zeichne in `draw(...)` zusätzlich einen Text, solange `hovering == true` (z. B. neben dem Objekt oder an einer festen Stelle).\n- Leite die Grösse des interaktiven Bereichs von der tatsächlichen Darstellung ab (Icon-/Kreisgrösse in Pixeln), nicht von fachlichen Werten wie Fläche/Höhe. Orientiere dich: gleicher Mittelpunkt wie das Objekt, Breite/Höhe passend zum Bild/Kreis.\n- Beim `ModeButton`: Verlass dich für das Umschalten auf den Klick (x,y) relativ zum `getInteractiveArea(...)` bzw. darauf, dass die GUI Clicks nur an Clickables im Bereich weitergibt—dann brauchst du den zusätzlichen `onButton`-Check nicht (oder nur für visuelles Feedback).\n\n### Code Style\n- In `ModeButton` sollten `WIDTH` und `HEIGHT` als `static final` Konstanten (und idealerweise sprechend benannt) definiert werden, statt als Instanzfelder.\n- `ModeButton` importiert `ch.trick17.gui.component.*`; verwende lieber gezielte Imports, damit klar ist, welche Typen du wirklich nutzt.\n- `SwissMapApp.main()` fehlt die `public`/`static` Kennzeichnung (ist nicht nur korrektheitsrelevant, sondern auch ein typischer Stil-/Konventionspunkt in Java-Projekten).\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"
}
}