{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- In `GroupCard` ist der Fall **“mehr als 20 Personen: nicht erlaubt”** nicht umgesetzt; aktuell wird für `persons > 20` einfach weiter mit dem 2.00 CHF/h-Tarif gerechnet.\n- In `GroupCard` wird für **11–20 Personen** zwar ein anderer Tarif verwendet, aber die Bedingung ist nur `persons >= 11` (ohne Obergrenze) und überschneidet sich damit mit dem “nicht erlaubt”-Bereich.\n- `FlatRateCard` soll ein Abo mit **fixen Monatskosten von 150 CHF** sein; durch eure aktuelle Implementierung wird zwar immer 150 zurückgegeben, aber ihr sammelt dennoch Parkzeit (`totalTime`) – das Verhalten “Parken beeinflusst die Kosten nicht” ist dadurch nicht sauber abgebildet (auch wenn das Resultat aktuell passt).\n\n### Suggestion\n- Überlege dir für `GroupCard`, wie du beim Erzeugen einer Karte oder spätestens bei `cost()` sicherstellst, dass **`persons > 20` gar nicht erst akzeptiert** wird (z.B. durch eine Prüfung und geeignetes Reagieren).\n- Formuliere die Tarif-Regeln so, dass die **Intervalle sich nicht überlappen** und der verbotene Bereich eindeutig behandelt wird (bis 5 / 6–10 / 11–20 / >20).\n- Bei `FlatRateCard`: Wenn die Kosten wirklich **immer** 150 sind, frage dich, ob du überhaupt Zeit speichern musst bzw. was `park()` und `reset()` inhaltlich tun sollten, damit die Klassenlogik zur “Flatrate”-Idee passt.\n\n### Code Style\n- In `GroupCard` ist `HOURLY_RATE` deklariert, aber wird nie verwendet; entferne es oder nutze es sinnvoll.\n- `persons` ist package-private (`int persons;`); mach es konsistent zu den anderen Klassen (`private`) und verwende ggf. `final`, wenn es sich nach dem Konstruktor nicht ändern soll.\n- In `FlatRateCard` ist `totalTime` aktuell praktisch ungenutzt (nur für `park/reset`), was verwirrend wirkt; entweder weglassen oder klar begründen/kommentieren.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- In `TryStraightFirst` erfüllst du die geforderte Priorität nicht: verlangt ist *geradeaus*, sonst *links oder rechts*, sonst *rechtsum kehrt* — dein Code probiert nach “nicht geradeaus” zuerst rechts, und wenn das nicht geht drehst du nur 180° und machst **keinen** Schritt und probierst **nicht** explizit links.\n- In `TryStraightFirst` fehlt der Fall “weder vorne, noch links, noch rechts”: dort soll die Figur **umdrehen und weiterlaufen** (also in diesem Schleifendurchlauf zu einer Bewegung kommen oder zumindest die Richtung so setzen, dass der nächste Durchlauf korrekt ist).\n- In `BacktrackingAlgorithm` markierst du die aktuelle Zelle als besucht, aber beim Ausprobieren einer Richtung läufst du **zuerst hinein** und prüfst erst danach, ob `nextPos` schon besucht war. Dadurch betrittst du bereits besuchte Felder trotzdem (und drehst dann wieder um) – das kann zu sehr viel unnötiger Bewegung führen und kann je nach Labyrinth-/Zyklusstruktur auch problematisch werden.\n- In `BacktrackingAlgorithm` ist der “visited”-Key nur `(row,col)` ohne Blickrichtung. Wenn du aus einem Feld in unterschiedlichen Orientierungen ankommst, kann das für deine Logik zu früh “besucht” bedeuten, obwohl von der neuen Orientierung aus noch andere Wege sinnvoll wären.\n\n### Suggestion\n- Für `TryStraightFirst`: Bau dir gedanklich eine klare If-Else-Kaskade in der Reihenfolge “ahead → left → right → else u-turn” und achte darauf, dass du bei den Checks die Figur ggf. erst drehst, **dann** `pathAhead()` prüfst und bei Misserfolg wieder in einen definierten Zustand zurückkehrst.\n- Für den “u-turn”-Fall in `TryStraightFirst`: Überleg dir, was nach der 180°-Drehung passieren soll, damit du nicht einfach nur die Richtung änderst, sondern auch aus einer Sackgasse tatsächlich wieder herauskommst.\n- Für `BacktrackingAlgorithm`: Überlege, wie du entscheiden kannst, ob du eine Richtung überhaupt betreten willst, **bevor** du `moveForward()` machst (z.B. indem du die “Koordinate vor dir” in irgendeiner Form ableitest oder indem du dir Zustände inkl. Orientierung merkst).\n- Für `BacktrackingAlgorithm` bzgl. `visited`: Teste gedanklich ein Feld mit Kreuzung, das du einmal “falsch” verlässt und später von einer anderen Seite wieder erreichst. Frage dich, ob “besucht = blockiert” in deinem Modell wirklich stimmt, oder ob du zusätzliche Zustandsinformation (z.B. Richtung oder “ausprobierte Ausgänge pro Zelle”) brauchst.\n\n### Code Style\n- Du hast sehr viele Klassen (Figure, Labyrinth, LabyrinthGame, …) unverändert mitkopiert; in einer Abgabe reicht normalerweise, nur deine neuen/angepassten Klassen zu liefern (macht Reviews und Diff viel einfacher).\n- In `BacktrackingAlgorithm` wären Konstanten/Helper für Positions-Key (statt String-Konkatenation) lesbarer und weniger fehleranfällig (z.B. eigene kleine `record`/Klasse oder zumindest eine Methode `posKey(...)`).\n- Kommentare sind ok, aber teilweise beschreiben sie 1:1 den Code; hilfreicher wären Kommentare eher dort, wo die Idee/Invariant (z.B. “nach Backtracking wieder gleiche Orientierung wie vorher”) festgehalten wird.\n\n\n# Exercise: swissmap\n\n### Correctness\n- Deine `main`-Methode in `SwissMapApp` hat die Signatur `void main()`. So wird sie als Einstiegspunkt nicht automatisch gestartet; erwartet ist eine `public static void main(String[] args)`-Methode.\n- In `ModeButton.draw(...)` ist der Button-Text `\"Sattelite View\"` geschrieben; gefordert ist ein Wechsel in den «Satelliten-Modus» (rein funktional ok), aber so wie es ist, ist das Label zumindest inkonsistent/falsch geschrieben („Satellite“).\n- `ModeButton` soll laut Aufgabe auch `Hoverable` sein und als Knopf „auf der Karte“ angezeigt werden; du implementierst `Hoverable`, aber `onMouseEnter/onMouseExit` ändern aktuell nichts (damit ist „Hoverable implementieren“ zwar erfüllt, aber „auf Hover reagieren“ praktisch nicht umgesetzt).\n\n### Suggestion\n- Schau dir nochmal an, wie Java Programme gestartet werden: Welche Modifier und welcher Parameter werden für die Einstiegsmethode erwartet, damit das Programm ohne Umwege läuft?\n- Wenn du Hover beim `ModeButton` wirklich nutzen willst: Überlege dir, welches sichtbare Feedback (z. B. Farbe, Rahmen, Text) sich in `draw(...)` abhängig von einem gemerkten Hover-Zustand ändern könnte (ähnlich wie du es bei City/Lake/Mountain machst).\n- Für den Button-Text: Prüfe Schreibweise und/oder ob du ihn eher passend zum Modus umschalten willst (z. B. abhängig davon, ob gerade Satellite aktiv ist).\n\n### Code Style\n- Verwende konsistente Bezeichner: `SwissMap Karte` ist ein gemischter Stil (Deutsch + Großbuchstabe als Variable). In Java sind Variablen üblicherweise `lowerCamelCase` und meist englisch.\n- In `City/Lake/Mountain` importierst du `Shape`, verwendest aber den vollqualifizierten Namen bei `Rectangle` (`new ch.trick17.gui.component.Rectangle(...)`). Importiere `Rectangle` direkt oder nutze konsequent nur Imports, damit es einheitlich bleibt.\n- In `ModeButton` ist die Hover-Logik leer; wenn du `Hoverable` schon implementierst, ist es lesbarer, auch dort ein `hovered`-Feld wie bei den anderen Klassen zu nutzen (oder das Interface weglassen, falls du wirklich kein Hover-Verhalten 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"
}
}