{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- In `GroupCard` fehlt die Vorgabe „mehr als 20 Personen: nicht erlaubt“: aktuell werden z.B. 25 Personen einfach wie der 11–20-Tarif behandelt.\n- In `GroupCard` gilt die Bedingung `persons >= 11` auch für Werte über 20; damit wird der „nicht erlaubt“-Fall nie ausgelöst.\n- `FlatRateCard` soll „fixe Monatskosten von 150 CHF“ haben: Deine Implementierung liefert zwar 150, aber sie sammelt trotzdem Parkzeit (`totalTime`) wie eine Minutenkarte, was fachlich nicht zur Karte passt (und kann zu falscher Interpretation führen, z.B. wenn später Logik davon abhängt).\n\n### Suggestion\n- Überlege dir im `GroupCard`-Konstruktor (oder spätestens in `cost()`), wie du ungültige Personenzahlen (>20) behandelst, sodass sie wirklich „nicht erlaubt“ sind (z.B. durch eine Abbruch-/Fehlermeldung statt Berechnung).\n- Formuliere die Tarifabfragen so, dass sich die Bereiche **bis 5**, **6–10**, **11–20** und **>20** eindeutig und ohne Überschneidung abdecken.\n- Prüfe bei `FlatRateCard`, ob du überhaupt Parkminuten speichern musst, wenn der Preis immer fix ist; falls nicht, vereinfacht das auch `park()`/`reset()`.\n\n### Code Style\n- In `GroupCard` ist `HOURLY_RATE` deklariert, aber nirgends verwendet.\n- In `GroupCard` ist `persons` package-private (kein `private`); konsistent mit den anderen Klassen wäre `private` sinnvoll.\n- In `FlatRateCard` ist `totalTime` zwar verwendet (in `park`/`reset`), aber für eine Flatrate fachlich unnötig; das macht die Klasse komplexer als nötig.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- In `TryStraightFirst` erfüllst du die Vorgabe „falls es keinen Pfad geradeaus gibt, wird links oder rechts versucht“ nicht: du prüfst nur rechts (durch `turnRight()`), aber nicht explizit links.\n- In `TryStraightFirst` erfüllst du die Vorgabe „Sollte das alles nicht gehen, soll die Figur rechtsum kehrt machen“ nicht eindeutig: wenn rechts nicht geht, drehst du dich nur um 90° nach links (bzw. insgesamt zurück zur ursprünglichen Richtung), aber nicht um 180°.\n- In `BacktrackingAlgorithm` ist die Berechnung von `nextRow/nextCol` aus `dir` nicht konsistent mit der Richtungscodierung der Spielfigur (die `dir`-Werte entsprechen nicht deinem Mapping `0→east,1→north,2→west,3→south`). Dadurch kann dein `visited`-Check falsche „nächste Felder“ annehmen und gültige Wege fälschlich überspringen oder bereits besuchte Felder nicht erkennen.\n\n### Suggestion\n- Für `TryStraightFirst`: Überlege dir eine feste Prioritäten-Reihenfolge pro Schleifendurchlauf (z.B. geradeaus, dann links, dann rechts) und setze die Drehungen so um, dass du nach jedem Check in einer definierten Orientierung bist, bevor du die nächste Option testest.\n- Für die „rechtsum kehrt“-Anforderung: Prüfe, wie viele `turnRight()`-Aufrufe nötig sind, um wirklich 180° zu drehen, und stelle sicher, dass dieser Fall genau dann passiert, wenn vorne/links/rechts alle blockiert sind.\n- Für `BacktrackingAlgorithm`: Nutze nicht eine selbst geschriebene `dir`→Koordinaten-Umrechnung, sondern leite die „nächste Position“ so ab, dass sie garantiert zur echten Bewegungslogik passt (z.B. indem du dich an der im Framework verwendeten Richtungslogik orientierst oder indem du Positionen vor/nach einem probeweisen Schritt vergleichst und dann wieder zurückgehst).\n\n### Code Style\n- Du duplizierst viele vorgegebene Dateien (`Figure`, `Labyrinth`, `LabyrinthGame`, usw.) in deiner Abgabe, obwohl dort keine Änderungen nötig sind; das macht Reviews schwieriger und erhöht das Risiko, versehentlich vom Template abzuweichen.\n- In `BacktrackingAlgorithm` verwendest du `Set<String>` mit `\"row,col\"`; lesbarer und weniger fehleranfällig wäre eine kleine Positionsklasse/Record oder eine eindeutige Kodierung (z.B. `row * cols + col`), damit du nicht mit String-Bastelei arbeiten musst.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `SwissMapApp` ist `main` als `void main()` deklariert; so wird es in Java nicht als Startpunkt erkannt (die Signatur muss der Java-`main`-Methode entsprechen), sonst startet die App nicht über “Run”.\n- In `SwissMapApp` verwendest du `gui.addComponents(...)`; je nach bereitgestellter `Gui`-API gibt es diese Methode evtl. nicht (in der Aufgabenstellung ist explizit `gui.addComponent(...)` genannt). Wenn `addComponents` nicht existiert, kompiliert das nicht.\n- In `ModeButton.draw` steht der Text `\"Sattelite View\"` (Schreibfehler). Falls in der Aufgabe erwartet wird, dass der Button klar den “Satelliten-Modus” bezeichnet, ist das inhaltlich/verbal nicht korrekt.\n\n### Suggestion\n- Prüfe die korrekte Java-Entry-Point-Signatur und passe `main` so an, dass deine Klasse wirklich als Programmstartpunkt läuft.\n- Schau in die Dokumentation/Autocomplete der verwendeten `Gui`-Bibliothek nach, ob es `addComponents` wirklich gibt; falls nicht, iteriere über die Arrays und registriere die Objekte einzeln über die in der Aufgabe genannte Methode.\n- Überlege, welche Beschriftung der Button haben soll (Aufgabenwortlaut “Satelliten-Modus”) und ob Tippfehler/Bezeichnung dazu passen.\n\n### Code Style\n- Benennungen: `SwissMap Karte` und `ModeButton modeButton` mischen Deutsch/Englisch und haben uneinheitliche Groß-/Kleinschreibung; wähle eine Sprache und ein konsistentes Namensschema (z.B. lowerCamelCase).\n- In `ModeButton` sind `onMouseEnter`/`onMouseExit` leer, obwohl `Hoverable` implementiert wird; entweder Hover-Effekt implementieren (z.B. Farbe ändern) oder (falls nicht gewollt) das Interface nicht implementieren.\n- Vermeide vollqualifizierte Klassennamen direkt im Code (`new ch.trick17.gui.component.Rectangle(...)`), wenn du sie sowieso immer nutzt: importieren macht es lesbarer.\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"
}
}