{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- `FlatRateCard` berechnet die Kosten unabhängig von der Parkzeit immer als 150 CHF; dadurch wird beim Beispielablauf der geforderte Gesamtumsatz von 156.75 CHF nicht erreicht (du bekommst damit deutlich mehr).\n- `GroupCard`: Der Konstruktor erlaubt `person == 0` (weil du nur `< 0` abfängst). Laut Tabelle ist die Anzahl Personen “bis 5” etc. gemeint, d.h. 0 Personen passt fachlich nicht in die Spezifikation.\n\n### Suggestion\n- Überlege dir, wann die 150 CHF bei einer `FlatRateCard` wirklich “anfallen” sollen: pro Monat/Abrechnungsperiode und nicht automatisch bei jeder Umsatzberechnung. Schau dir an, wann dein System `cost()` aufruft und wann `reset()` passiert, und leite daraus ab, wie `FlatRateCard.cost()` sich verhalten muss, damit die Beispielausgabe 156.75 CHF möglich wird.\n- Ergänze im `GroupCard`-Konstruktor eine Plausibilitätsprüfung, die nur sinnvolle Personenzahlen akzeptiert (und orientiere dich dabei an den Grenzen aus der Aufgaben-Tabelle).\n\n### Code Style\n- In `FlatRateCard` ist `totalTime` (inkl. `park()`/`reset()`-Logik) aktuell praktisch ungenutzt, weil `cost()` nie darauf basiert. Entweder konsequent verwenden oder weglassen, damit die Klasse klarer ist.\n- Einheitliche Benennung: `person` ist eigentlich “Anzahl Personen” (plural). Ein Name wie `persons`/`peopleCount` würde die Lesbarkeit verbessern.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- In `TryStraightFirst` prüfst du „links oder rechts“ erst **nachdem** du in einer inneren `while(figure.pathAhead())`-Schleife so weit wie möglich geradeaus gelaufen bist; gefordert ist aber eine Entscheidung **in jedem Schleifendurchlauf** (also pro Schritt), ob vorne geht, sonst links/rechts, sonst umkehren.\n- In `BacktrackingAlgorithm` kann der Else-Zweig (`path.get(path.size() - 1)`) bei bestimmten Situationen (z.B. direkt am Start in einer Sackgasse oder wenn du zwar abgebogen bist, aber noch keinen Eintrag in `path` hast) auf eine **leere** `path`-Liste zugreifen und damit crashen.\n- In `BacktrackingAlgorithm` fügst du bei `moveForward()` die Richtung erst **nach** dem Laufen (`path.add(figure.dir())`) hinzu; wenn du später zurückgehen willst, ist damit nicht eindeutig gespeichert, „wie du hierher gekommen bist“ (du speicherst die aktuelle Ausrichtung nach dem Move, nicht die „Kante“, die du gerade gegangen bist). Das kann dazu führen, dass dein `turnBack(...)` nicht zuverlässig in die korrekte Richtung zurückführt.\n- In `BacktrackingAlgorithm` markierst du Felder als besucht, aber beim Backtracking entfernst du sie nie aus `visited`. Für echtes Backtracking (wie in der Aufgabe angedeutet) führt das oft dazu, dass du legitime Wege später nicht mehr betreten darfst und dadurch ggf. nicht alle Labyrinthe lösen kannst.\n\n### Suggestion\n- Für `TryStraightFirst`: Versuche die Logik so zu strukturieren, dass **eine** äußere Schleife läuft und du darin genau **eine** Bewegungsentscheidung triffst (vorne/links/rechts/umdrehen) und anschließend (wenn möglich) genau **einen** Schritt machst – statt zuerst „geradeaus bis zum Ende“.\n- Für `BacktrackingAlgorithm` (Crash durch leeres `path`): Überlege, welche Information du beim ersten Betreten eines neuen Feldes mindestens brauchst, um **immer** sicher zurücklaufen zu können, und wie du mit dem Fall umgehst, dass du noch keinen „letzten Schritt“ gespeichert hast.\n- Für `BacktrackingAlgorithm` (falsche Rückrichtung): Denke darüber nach, ob du eher speichern willst: „Welche Richtung bin ich **gegangen**?“ oder „Wie war ich **ausgerichtet**?“ – und zu welchem Zeitpunkt (vor/nach `moveForward`) diese Info korrekt ist.\n- Für `BacktrackingAlgorithm` (visited bleibt für immer): Überlege, was „Backtracking“ normalerweise bedeutet: Wenn ein Weg als Sackgasse erkannt wurde und du zurückgehst, soll das Feld/der Abzweig weiterhin als „verboten“ gelten oder nur als „gerade in diesem Pfad schon benutzt“? Daraus ergibt sich, ob und wann du Einträge wieder entfernen müsstest (oder alternativ pro Feld eine andere Markierung wie „vollständig abgearbeitet“ brauchst).\n\n### Code Style\n- In `BacktrackingAlgorithm` wäre ein kleiner eigener Datentyp für Position (z.B. `row`,`col`) oder zumindest eine Hilfsmethode zum Erzeugen des Keys lesbarer als String-Konkatenation an mehreren Stellen.\n- Methodennamen: `nexCellVisited` wirkt wie ein Tippfehler (`next...`) und erschwert Lesen/Suchen.\n- Magic Numbers für Richtungen (0/1/2/3) sind fehleranfällig; ein `enum` oder benannte Konstanten würden die Logik (insb. in `switch` und `(dir + k) % 4`) deutlich verständlicher machen.\n\n\n# Exercise: swissmap\n\n### Correctness\n- `SwissMapApp`: Die `main`-Methode hat die falsche Signatur (`void main()` statt einer echten Einstiegsmethode). So wird das Programm typischerweise nicht als Java-Programm starten.\n- `Button`: Die Hover-Logik ist fachlich falsch umgesetzt: In `onMouseEnter`/`onMouseExit` toggelst du jeweils mit `!isHovered`. Wenn die Events mehrfach/unerwartet kommen, kann der Hover-Zustand inkonsistent werden (z. B. “hovered” obwohl Maus gar nicht drauf ist).\n- `City`, `Lake`, `Mountain`: Gleiches Problem beim Hover-Zustand (Toggle in Enter/Exit statt klar setzen).\n- `Button`: Du implementierst zwar `Hoverable`, verwendest `isHovered` aber nirgends in `draw` (damit erfüllt Hovering beim Button aktuell keinen sichtbaren Zweck).\n\n### Suggestion\n- Prüfe, wie eine Java-Startmethode deklariert sein muss, damit sie von der Laufzeitumgebung gefunden wird (Name, `static`, Parameter).\n- Bei Hover-Events ist es stabiler, wenn `onMouseEnter` den Zustand eindeutig auf “drin” setzt und `onMouseExit` eindeutig auf “draussen”, statt jeweils zu invertieren. Überlege dir kurz, was passiert, wenn Enter/Exit nicht streng alternieren.\n- Wenn du beim Button schon `Hoverable` implementierst, gib dem Hover-Zustand auch eine Auswirkung im Zeichnen (z. B. anderes Aussehen/Highlight), sonst ist die Hover-Unterstützung unvollständig.\n\n### Code Style\n- Klassen-/Aufgabenname: In der Aufgabe ist explizit eine Klasse `ModeButton` verlangt; du hast sie `Button` genannt. Besser die geforderte Bezeichnung verwenden, damit es zur Aufgabenstellung/Tests passt.\n- `Button`: Das Feld `isHovered` ist aktuell ungenutzt (entweder nutzen oder entfernen).\n- `Lake`/`Mountain`: Du lädst Bilder über `ImageIO` selbst und speicherst `BufferedImage`, zeichnest dann aber mit `gui.drawImageCentered(...)` über Pfade. Das `BufferedImage img` ist dann nur für Breite/Höhe da; das wirkt unnötig kompliziert. Außerdem wird pro Objekt ein Bild geladen (Potenzial für unnötige Doppelarbeit).\n- Tippfehler/Lesbarkeit: Variablenname `sateliteButton`/String `\"Satelite\"` (Schreibweise) – konsistent benennen hilft beim Verständnis.\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"
}
}