{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- In `ParkingSystemExample` muss die Ausgabe gemäss Aufgabenstellung einen Gesamtumsatz von **156.75 CHF** anzeigen; mit deiner aktuellen Logik (v. a. `FlatRateCard.cost()` immer 150) wird ein anderer Betrag herauskommen.\n- `FlatRateCard.cost()` liefert immer die Monatskosten, unabhängig davon, ob/wie lange geparkt wurde; dadurch wird die Karte in der Umsatzberechnung immer als 150 CHF gezählt, was das erwartete Resultat im Beispielablauf verfälscht.\n\n### Suggestion\n- Überlege dir, wann beim Ablauf im Beispiel die Monatskosten einer `FlatRateCard` tatsächlich in den Umsatz einfliessen sollen: bei jeder Revenue-Berechnung, nur wenn die Karte “benutzt” wurde, oder genau einmal pro “Abrechnungsperiode”. Nutze dafür ggf. internen Zustand (z. B. “wurde in dieser Periode geparkt?”) und setze ihn in `reset()` passend zurück.\n\n### Code Style\n- In `FlatRateCard` sind `park()` und `reset()` leer; selbst wenn das fachlich so gedacht ist, wäre ein kurzer Kommentar hilfreich, warum (oder welcher Zustand bewusst nicht nötig ist).\n- In `GroupCard`/`IndividualCard` könntest du `totalTime` direkt bei der Deklaration initialisieren (`= 0`), um die Absicht klarer zu machen (auch wenn Java das implizit macht).\n\n\n# Exercise: labyrinth\n\n### Correctness\n- In `TryStraightFirst` machst du beim „rechtsum kehrt“ nur zwei `turnRight()`-Aufrufe, aber keinen anschliessenden `moveForward()`-Schritt; die Anforderung sagt, dass die Figur in diesem Fall umdrehen **und dann weitergehen** soll.\n- Dein `BacktrackingAlgorithm` markiert Felder als „visited“ nur über `(row,col)` und nicht abhängig von der Blickrichtung; dadurch kann es passieren, dass du Zustände zu früh ausschliesst und nicht alle nötigen Varianten (gleiche Position, andere Orientierung) korrekt erkundest – je nach Labyrinth kann das dazu führen, dass kein Weg gefunden wird, obwohl einer existiert.\n\n### Suggestion\n- Für `TryStraightFirst`: Überlege dir, was „rechtsum kehrt machen“ im Kontext „sonst geht nichts“ bedeutet: Nach dem Umdrehen muss die Figur aus der Sackgasse auch wirklich herauslaufen. Prüfe, welche minimale zusätzliche Aktion nach den zwei Drehungen fehlt.\n- Für `BacktrackingAlgorithm`: Denke in „Zuständen“ statt nur in „Zellen“: Ein Zustand kann mehr enthalten als nur die Koordinaten. Überlege, welche Information das Bewegungsverhalten beeinflusst (und damit auch, ob ein Zustand wirklich schon „besucht“ ist).\n\n### Code Style\n- Du hast sehr viele Klassen aus der Vorlage (z.B. `Figure`, `Labyrinth`, `LabyrinthGame`) komplett in der Abgabe dupliziert; falls das nicht ausdrücklich verlangt ist, ist es besser, nur deine neuen Algorithmus-Klassen zu ergänzen und die Vorlage unverändert zu lassen.\n- In `LabyrinthGame` ist `moveCount`/`getMoveCount()` für die Aufgabe nicht nötig und wirkt wie Debug-/Zusatzcode; solche Extras besser entfernen oder klar kommentieren, wenn sie absichtlich drin bleiben.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `SwissMapApp` ist die `main`-Methode nicht als Java-Entry-Point deklariert (sie ist weder `public` noch `static` und hat keine `String[] args`-Parameter); so startet das Programm typischerweise nicht automatisch.\n- In `ModeButton.onLeftClick(...)` rufst du `swissMap.toggleSatelliteMode()` auf, aber die Aufgabenstellung verlangt, dass der Button `setSatelliteMode(...)` aufruft (über ein gespeichertes `SwissMap`-Objekt).\n\n### Suggestion\n- Schau dir die exakte Signatur an, die Java für den Programmeinstieg erwartet, und passe die `main`-Methode in `SwissMapApp` entsprechend an, damit deine App wirklich über “Run” startet.\n- Überlege dir, wie du den Moduswechsel auch ohne zusätzliche Hilfsmethode lösen kannst: Du hast mit `isSatelliteMode()` bereits die Info, welchen Zustand die Karte gerade hat, und mit `setSatelliteMode(boolean)` den geforderten Setter—kombiniere diese beiden in `onLeftClick(...)`.\n\n### Code Style\n- Achte in `SwissMapApp` auf konsistente Einrückung/Whitespace (bei dir sind einige Zeilen deutlich weiter eingerückt als der Rest), das erschwert das Lesen.\n- In `City`, `Lake`, `Mountain` wiederholt sich viel Hover-Logik (hovered-Flag, Enter/Exit, Textausgabe). Das ist nicht falsch, aber wenn ihr später mehr Objekte habt, lohnt es sich über gemeinsame Hilfsmethoden/Abstraktion nachzudenken.\n\n\n# Exercise: visualizer\n\n### Correctness\n- In `VisualizerApp` ist `main()` nicht `public static void main(String[] args)`. So kann das Programm je nach Umgebung nicht als Java-Startpunkt ausgeführt werden, obwohl die Aufgabe verlangt, dass du es starten und die Visualisierung sehen kannst.\n- Im `Visualizer` verwendest du für log-skalierte Datensätze `Math.log10(point.y())`. Wenn `y()` jemals `0` oder negativ ist (z.B. durch Datenfehler), führt das zu `-Infinity`/`NaN` und bricht die Skalierung/Anzeige (die Aufgabe erwähnt zwar Log-Achse, aber nicht, dass Daten immer > 0 garantiert sind).\n\n### Suggestion\n- Schau dir an, welche Methodensignatur Java als Einstiegspunkt erwartet, und passe `main` genau darauf an (inkl. `static` und Parameterliste).\n- Überlege dir, wie du im Visualizer (oder im jeweiligen `DataPoint`) sicherstellen kannst, dass eine logarithmische Darstellung nur mit gültigen (positiven) Werten arbeitet, ohne dass du die Werte „hart“ im Code ersetzen musst.\n\n### Code Style\n- Die `@SuppressWarnings(\"unused\")` bei `loadCountries()`/`loadProcessors()` ist ein Hinweis, dass du die Methoden aktuell nicht nutzt; sobald du wie gefordert zwischen Datensätzen umschaltest, kannst du diese Unterdrückung wieder entfernen.\n- In `Movie.details()` formatierst du Budget mit Tausendertrennzeichen, aber ohne Währung/Einheit; bei `Country`/`Processor` gibst du teils Einheiten an. Einheitliche Detaildarstellung (Einheiten, Rundung) würde die UI konsistenter machen.\n",
"status" : "SUCCESS"
}
}