{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- In `FlatRateCard` wird immer 150 CHF zurückgegeben, unabhängig davon, ob überhaupt geparkt wurde; falls die Monatskosten nur dann zählen sollen, wenn die Karte im Abrechnungszeitraum benutzt wurde, ist das so nicht abbildbar (du sammelst zwar `totalTime`, nutzt ihn aber nicht für die Entscheidung).\n- Das geforderte Ausgaberesultat „156.75 CHF“ ist mit deiner aktuellen Beispielbelegung nicht plausibel erreichbar, wenn `FlatRateCard` immer 150 CHF kostet; prüfe daher, ob deine verwendeten Parkzeiten/Kartenkombinationen im `ParkingSystemExample` wirklich zu diesem erwarteten Umsatz führen sollen.\n\n### Suggestion\n- Überlege dir, ob eine `FlatRateCard` wirklich immer kostenpflichtig sein soll oder nur dann, wenn sie im Monat auch verwendet wurde (Hinweis: du hast bereits `totalTime` – die Frage ist, ob du ihn zur Kostenberechnung/Entscheidung brauchst).\n- Rechne die erwarteten Kosten für jede der drei Karten im Beispiel einmal von Hand nach und vergleiche sie mit der Soll-Ausgabe 156.75 CHF; dadurch findest du schnell, ob das Problem bei der Kostenlogik einer Karte oder bei den Beispiel-Parkzeiten liegt.\n\n3. Code Style:\n- `import javax.smartcardio.Card;` in `ParkingSystem` ist unbenutzt und wirkt wie ein Versehen – entfernen.\n- In `GroupCard` sollte `HOURLY_RATE` als Konstante/Instanzfeld klarer benannt und kapsuliert werden (z.B. `private final double hourlyRate` statt ein veränderbares Feld in Großbuchstaben).\n- In `FlatRateCard` ist `totalTime` aktuell ungenutzt (außer beim Reset) – entweder begründen/verwenden oder entfernen, damit die Klasse klarer bleibt.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- In `LabyrinthApp` startest du die Levels erst ab `level = 7`; die Aufgabe verlangt aber, dass du mit den verschiedenen Algorithmen die Levels der Reihe nach spielen kannst (insbesondere: erst Stupid für Level 1, dann TryStraightFirst für Level 1–4, dann Backtracking für die restlichen).\n- Dein `BacktrackingAlgorithm` ist nicht „allgemein“ im Sinn der Aufgabenstellung, weil du in `navigate` eine fixe Start-`direction` setzt („Anpassen je nach Level“). Das widerspricht dem Ziel, dass der Algorithmus ohne manuelle Anpassungen für alle Labyrinthe funktioniert.\n- Im `BacktrackingAlgorithm` nutzt du kein „Visited“-Konzept (z.B. besuchte Zellen/Positionen oder besuchte Kanten). Dadurch kann dein rekursives Suchen in Labyrinthen mit Zyklen/Schlaufen in Endlossuche bzw. sehr viele Wiederholungen geraten und damit Level nicht zuverlässig lösen.\n- Die Variable `direction` ist fachlich inkonsistent zur echten Richtung der Figur: `Figure` verwaltet die Richtung selbst über `turnLeft/turnRight` und `dir()`. Deine Updates von `direction` passen zudem nicht zu deiner Kommentar-Konvention `0=Nord,1=Ost,2=Süd,3=West` (bei `turnRight` erhöhst du, bei `turnLeft` verringerst du – die Figur macht es im bereitgestellten Code umgekehrt). Damit ist diese Richtung intern unzuverlässig.\n\n### Suggestion\n- Damit alle Levels nacheinander laufen, überlege dir, wie du in `main` wieder bei Level 1 startest und nur den verwendeten Algorithmus austauschst (oder je nach Level einen auswählst), statt die Schleife bei 7 beginnen zu lassen.\n- Wenn dein Backtracking „allgemein“ sein soll, vermeide jede Annahme über die Startausrichtung. Du kannst die Orientierung entweder komplett über `figure.dir()`/relative Checks steuern oder die Startausrichtung einfach nicht hartcodieren.\n- Um Schleifen sicher zu beherrschen, brauchst du eine Strategie, die verhindert, dass du immer wieder dieselben Stellen/Kanten abläufst. Denk an eine Datenstruktur, die (row,col) bzw. (row,col,dir) oder „Kante von A nach B“ markiert, sobald du sie schon abgearbeitet hast.\n- Wenn du eine eigene `direction`-Variable behalten willst, gleiche sie konsequent mit dem Verhalten von `Figure.turnLeft/turnRight` ab (oder lass sie ganz weg und verwende nur `figure.dir()`), damit du nicht auf einem falschen internen Zustand aufbaust.\n\n### Code Style\n- In `BacktrackingAlgorithm` ist das Feld `direction` aktuell effektiv ungenutzt (es beeinflusst keine Entscheidung) und erzeugt eher Verwirrung; entweder sinnvoll einsetzen oder entfernen.\n- Der Kommentar „Anpassen je nach Level“ in `navigate` ist ein starker Hinweis auf manuelle Konfiguration; das passt schlecht zur geforderten Allgemeinheit und macht den Code schwer wartbar.\n- Du hast sehr viel Template-Code (Figure, Labyrinth, GameOver, LabyrinthGame) in deinem Attempt mitkopiert; falls das nicht verlangt ist, reicht normalerweise, nur deine eigenen Algorithmus-Klassen und die minimal nötigen Änderungen (z.B. in `LabyrinthApp`) abzugeben.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `ModeButton.draw(...)` verwendest du `gui.setColor(new Color(...))` mit `ch.trick17.gui.Color`; je nach GUI-Bibliothek-API wird die Farbe nicht als Objekt gesetzt, sondern z. B. über eine Methode mit Zahlenwerten (wie du es in `SwissMap` bereits machst). Das kann so zu einem Compile-Fehler führen.\n- In `ModeButton` sind `getInteractiveArea(...)`, `onMouseEnter()` und `onMouseExit()` nicht mit `@Override` markiert; falls die Methodensignaturen nicht exakt zu `Hoverable` passen (z. B. Parameter/Return-Typ), würde das Interface dann nicht korrekt implementiert und Hover würde nie auslösen (oder es gäbe einen Compilerfehler).\n- Deine zusätzliche Klasse `InteractiveArea` implementiert `Shape.contains(...)` immer mit `false`. Falls du sie irgendwo einsetzen würdest, wäre das Hover/Click nie möglich (auch wenn du aktuell stattdessen `Rectangle` nutzt).\n\n### Suggestion\n- Schau in der Doku/IDE-Signatur von `Gui#setColor(...)` nach, welche Parameter-Typen wirklich erwartet werden (Objekt vs. RGB/RGBA-Werte). Richte deinen `ModeButton` daran aus.\n- Setz bei allen Interface-Methoden konsequent `@Override` (insb. im `ModeButton`). Wenn dann etwas nicht passt, zeigt dir der Compiler sofort, welche Signatur abweicht.\n- Falls du `InteractiveArea` behalten willst: Überleg dir, wie `contains(x,y)` für deinen gewünschten interaktiven Bereich funktionieren müsste (z. B. Rechteck um einen Punkt) – sonst ist die Klasse als `Shape` nicht brauchbar.\n\n3. Code Style:\n- In `ModeButton` sind Imports sehr unaufgeräumt/teilweise falsch bzw. unnötig (`import ch.trick17.gui.Gui.*;`, Wildcards, doppelte/überflüssige Imports). Reduziere auf die tatsächlich verwendeten Klassen.\n- `InteractiveArea` wirkt aktuell ungenutzt und lenkt eher ab; entweder fertig implementieren und verwenden oder entfernen.\n- In `City.draw(...)` zeichnest du Kreis/Fill sowohl im `if` als auch im `else` identisch; das kann man zusammenziehen, damit weniger Duplikation entsteht.\n- In `ModeButton.onLeftClick(...)` kann man das Umschalten von `satelliteMode` kompakter ausdrücken (weniger if/else), dadurch wird die Intention klarer.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Beim Prozessor-Datensatz soll die y-Achse die «effektive Rechengeschwindigkeit» sein (Taktfrequenz * Cores) und die Achse soll dafür logarithmisch dargestellt werden; in `Processor.getY()` berechnest du aber `log10(cores * clockRateKhz) / 1000`, was nicht einfach “logarithmische Achse” ist, sondern den Wert selbst zusätzlich skaliert/verändert.\n- In `Processor.getDetails()` gibst du `clockRateKhz` als `\"Mhz\"` aus, obwohl der Wert laut Attributname in kHz ist (falsche Einheit/Formatierung in der Detailbeschreibung).\n- Die Detailbeschreibung für Prozessoren soll die Taktfrequenz “in eine geeignete Einheit (kHz, MHz oder GHz)” umrechnen und passend formatieren; das machst du aktuell nicht (immer gleiche Einheit, zudem falsch beschriftet).\n- Bei der x-Achse der Prozessoren: “Kombiniere Jahr und Monat zu einem einzigen Wert.” Deine Berechnung `year + month / 12.0` hängt davon ab, ob `month` 1..12 oder 0..11 ist; falls es 1..12 ist, verschiebt sich alles um ~1 Monat und Dezember wird fast “nächstes Jahr”. Das kann die Zeitachse verfälschen.\n\n### Suggestion\n- Überlege beim Prozessor-Plot, ob `getY()` wirklich schon den Logarithmus liefern sollte, oder ob du stattdessen die “effektive Geschwindigkeit” als Rohwert zurückgibst und die logarithmische Darstellung an einer anderen Stelle passieren muss (Stichwort: “logarithmische y-Achse” vs. “logarithmierter Datenwert”).\n- Prüfe für die Prozessor-Frequenz: Welche Einheit steckt tatsächlich in `clockRateKhz` (kHz), und welche Umrechnungen brauchst du für MHz/GHz? Leite daraus ab, wann du ganze Zahlen vs. Dezimalzahlen anzeigen möchtest.\n- Schau dir die Monat-Codierung aus der CSV bzw. den geladenen Daten an: Ist `month` 1-basiert oder 0-basiert? Passe dann die “Jahr+Monat”-Kombination so an, dass Januar wirklich am Jahresanfang liegt und Dezember am Jahresende (ohne ins nächste Jahr zu rutschen).\n\n### Code Style\n- In `Visualizer` sind `DUMMY_DOUBLE` und `DUMMY_STRING` jetzt unbenutzt; die kannst du entfernen, damit keine “Altlasten” im Code bleiben.\n- In `Movie.getX()` steht der Kommentar `// Beispiel`, der nicht mehr zum finalen Code passt und eher verwirrt; besser entfernen oder durch eine sinnvolle Erklärung ersetzen.\n- In `Country.getDetails()` ist die Formatierung inkonsistent (Kommas, Zeilenumbrüche, zusätzliche Leerzeichen vor “Literacy”); lesbarer wäre eine klarere, einheitliche Zeilenstruktur.\n",
"status" : "SUCCESS"
}
}