{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- In `GroupCard` fehlt die Anforderung „mehr als 20 Personen nicht erlaubt“: aktuell wird für `persons > 20` einfach weiter mit dem 2.00 CHF/h Tarif gerechnet, statt das zu verhindern.\n- In `GroupCard` wird für `persons <= 0` ebenfalls ein Tarif berechnet (fällt ins `else`), obwohl die Tabelle nur sinnvolle positive Gruppengrössen beschreibt.\n\n### Suggestion\n- Überlege dir, wo du die Regel „> 20 nicht erlaubt“ am besten durchsetzen willst: beim Erstellen der Karte (Konstruktor) oder erst bei der Kostenberechnung; in beiden Fällen brauchst du eine klare Reaktion (z.B. Exception), damit solche Karten gar nicht betrieben werden können.\n- Definiere, welche Personenzahlen gültig sind (z.B. mindestens 1) und behandle ungültige Werte explizit, statt sie stillschweigend einem Tarif zuzuordnen.\n\n### Code Style\n- In `GroupCard` ist `HOURLY_RATE` deklariert, aber wird nie verwendet; das lenkt ab und sollte weg oder konsistent genutzt werden.\n- In `GroupCard` ist `persons` package-private (`int persons;`); mach das Feld lieber `private` (Kapselung).\n- In `FlatRateCard` speicherst du `totalTime`, benutzt ihn aber für die Kosten nie; das ist unnötiger Zustand und kann verwirren.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- `TryStraightFirst` erfüllt die geforderte Entscheidungslogik nicht: Wenn vorne kein Pfad ist, soll links **oder** rechts versucht werden und wenn das auch nicht geht, rechtsum kehrt. Deine Implementierung prüft effektiv nur „rechts“, und wenn das nicht geht, drehst du nur um 180° ohne danach den verbleibenden Weg (links bzw. hinten) korrekt als nächsten Move abzuwickeln.\n- `BacktrackingAlgorithm`: Deine Berechnung von `nextRow/nextCol` passt nicht zur tatsächlichen Bewegungslogik der Figur (`dir`-Mapping). Dadurch kann es passieren, dass du ein Feld als „unvisited“ ansiehst, obwohl du in Wirklichkeit in eine andere Richtung laufen würdest (oder umgekehrt), was den Algorithmus falsche Entscheidungen treffen lässt.\n- `BacktrackingAlgorithm`: Durch das `visited`-Set nur auf Basis von `\"row,col\"` schließt du aus, dieselbe Zelle aus einer anderen Richtung erneut zu betreten. Für Backtracking in Labyrinthen kann das zu früh sein und Wege abschneiden, obwohl sie aus einer anderen Orientierung heraus noch sinnvoll wären.\n- `BacktrackingAlgorithm`: Wenn `solve(...)` am Start `false` zurückgibt, endet `navigate` einfach ohne das Ziel erreicht zu haben; das Spiel wird dann als „Ziel nicht gefunden“ werten. Für die Aufgabe „funktioniert für alle diese Labyrinthe“ ist das ein Problem, falls dein Backtracking durch obige Punkte in eine Sackgasse läuft.\n\n### Suggestion\n- Für `TryStraightFirst`: Bau die Prüf-Reihenfolge pro Schleifendurchlauf so auf, dass du wirklich drei Fälle abdeckst: (1) vorne möglich, sonst (2) links möglich, sonst (3) rechts möglich, sonst (4) umdrehen. Achte darauf, nach jedem Drehen die Richtung wieder konsistent zu halten, damit du nicht „zufällig“ in einer gedrehten Orientierung in den nächsten Loop gehst.\n- Für `BacktrackingAlgorithm` (Richtungen): Verlass dich nicht auf ein selbst ausgedachtes `dir`→Delta-Mapping, sondern leite die „nächste Position“ so ab, dass sie garantiert mit der Engine übereinstimmt (oder vermeide das Vorberechnen komplett und entscheide nur anhand der `path...()`-Methoden und tatsächlichen Bewegungen).\n- Für `visited`: Überlege, ob „besucht“ eher ein Zustand aus *Position + Blickrichtung* sein müsste, oder ob du statt globalem `visited` eine klassische Backtracking-Variante brauchst, die beim Zurückgehen auch wieder „Freigabe“ macht (je nachdem, welche Eigenschaft du erreichen willst).\n- Für den Backtracking-Schritt: Kontrolliere, ob du nach dem Zurücklaufen wieder exakt in der gleichen Orientierung bist wie vor dem Vorwärtsschritt (und dass du nicht zusätzlich noch durch das `for`-Loop-TurnLeft am Ende eine Richtung „verlierst“). Eine kleine gedankliche Simulation mit 1–2 Schritten hilft hier enorm.\n\n### Code Style\n- Du hast sehr viel Template-Code (Figure, Labyrinth, LabyrinthGame, …) in deiner Abgabe dupliziert. Üblicherweise sollst du nur die neuen/angepassten Klassen einreichen; das Duplizieren erschwert Review und birgt das Risiko, dass du unabsichtlich Vorlagecode veränderst.\n- In `BacktrackingAlgorithm` sind viele Kommentare gut gemeint, aber teilweise beschreiben sie „was“ statt „warum“. Knappere Kommentare an den wirklich kniffligen Stellen (z.B. Orientierung/Backtracking-Invarianten) wären hilfreicher.\n- `TryStraightFirst` hat uneinheitliche Formatierung (z.B. fehlende Leerzeichen bei `while(!...)`, Klammerstil). Einheitliche Formatierung macht Logikfehler leichter sichtbar.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `SwissMapApp` ist die `main`-Methode nicht als Java-Entry-Point deklariert (Signatur passt nicht), dadurch startet das Programm u. U. gar nicht automatisch.\n- In `ModeButton.draw` ist der Button-Text „Sattelite View“ (Schreibfehler) – falls in der Aufgabe erwartet wird, dass ein Satelliten-Modus-Knopf klar beschriftet ist, ist das irritierend (außerdem weicht es von „Satelliten-Modus“ ab).\n\n### Suggestion\n- Prüfe, welche exakte Methodensignatur Java für den Programmstart erwartet (Stichwort: `public`, `static`, Parameterliste). Passe deine `main` so an, dass die JVM sie als Einstiegspunkt erkennt.\n- Überlege beim Button-Label, ob du die Beschriftung konsistent und korrekt zum Modus machen willst (und ob du ggf. den aktuellen Zustand im Text widerspiegeln möchtest).\n\n### Code Style\n- Verwende für Variablennamen in Java üblicherweise `camelCase` und eher Englisch oder konsistent eine Sprache (z. B. `karte` statt `Karte`), damit es zu den restlichen Klassen (`SwissMap`, `ModeButton`, …) passt.\n- Importe: In `City`, `Lake`, `Mountain` importierst du `Shape`, nutzt aber den konkreten Typ über den vollqualifizierten Namen `new ch.trick17.gui.component.Rectangle(...)`. Entweder den Import nutzen oder den vollqualifizierten Namen weglassen – mischen wirkt unnötig.\n- In `ModeButton` sind `onMouseEnter`/`onMouseExit` leer, obwohl du `Hoverable` implementierst. Wenn du Hover nicht brauchst, ist das zwar funktional ok, aber dann könntest du wenigstens im Code kurz kommentieren, dass du bewusst keinen Hover-Effekt willst.\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"
}
}