{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- `FlatRateCard` erfüllt die Abo-Idee nur teilweise: Monatskosten sind fix 150 CHF, aber du sammelst trotzdem Parkzeit (`totalTime`) und `park(...)` verändert den Zustand; das passt nicht zur Anforderung „fixe Monatskosten“ (unabhängig von Parkzeit).\n- `GroupCard`: Konstruktor lässt `person == 0` zu, obwohl „Anzahl Personen“ inhaltlich mindestens 1 sein sollte; deine Validierung entspricht damit nicht sauber der Tabelle („bis 5“, „6–10“, „11–20“, „mehr als 20 nicht erlaubt“).\n- Das geforderte Ausgaberesultat „Gesamtumsatz von 156.75 CHF“ wird mit deinen Karten/Beispielaufrufen sehr wahrscheinlich nicht erreicht (insbesondere wegen der FlatRate-Karte, die immer 150 addiert).\n\n### Suggestion\n- Überlege bei `FlatRateCard`, ob eine Abo-Karte überhaupt Parkminuten „mitzählen“ muss, wenn der Preis ohnehin konstant ist, und was dann `park(...)` und `reset()` sinnvollerweise tun sollten.\n- Prüfe bei `GroupCard`, welche Werte für „Anzahl Personen“ sinnvoll/erlaubt sind (inkl. Untergrenze) und gleiche das mit der Tabelle ab.\n- Rechne einmal den erwarteten Umsatz aus den im Example geparkten Minuten und den Tarifen nach; wenn dein Programm nicht auf 156.75 kommt, liegt der Fehler meist bei der Kostenlogik einer Kartenklasse (oder daran, dass eine Flatrate nicht pro Nutzung abgerechnet werden soll).\n\n### Code Style\n- In `FlatRateCard` ist `totalTime` vermutlich unnötig (führt zu totem/irreführendem Zustand).\n- Bei `GroupCard`, `IndividualCard` fehlen teils `@Override`-Annotationen; die sind nicht Pflicht, helfen aber, Tippfehler bei Interface-Methoden sofort zu erkennen.\n- Benennung: `person` klingt nach einer einzelnen Person; `persons`/`personCount` wäre klarer.\n\n\n# Exercise: labyrinth\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Im `DataPoint`-Interface und in allen Implementierungen heisst die Methode `getDesciption()` (Tippfehler). Wenn Du irgendwo später (oder in Tests/Angaben) `getDescription()` erwartest, wird das nicht zusammenpassen; zudem ist das ein unnötiges neues “API”, das nicht der Aufgaben-Idee einer sauberen Schnittstelle entspricht.\n- In `Visualizer` wird `logY` einmalig aus `data[0].isLogY()` abgeleitet. Damit funktioniert die logarithmische Skalierung nur korrekt, wenn wirklich alle Punkte im Datensatz dasselbe Verhalten haben und der erste Punkt repräsentativ ist; das ist als Schnittstellen-Integration fragil.\n- Bei `Movie`: Die Aufgabenstellung verlangt auf der x-Achse das Filmbudget (nicht “Budget in Millionen”); damit veränderst Du die Achsenskalierung gegenüber der geforderten Datenrepräsentation.\n- Bei `Country`: Literacy soll den Einfluss auf GDP per capita zeigen; in Deiner Beschreibung gibst Du Literacy als Prozent mit `%` aus, aber als x-Wert verwendest Du den Rohwert aus dem CSV. Falls der CSV-Wert nicht bereits Prozent ist (sondern z.B. 0–100 vs. 0–1), kann Darstellung und Text inkonsistent werden.\n\n### Suggestion\n- Schau Dir die Methodennamen in Deinem Interface an: ein einziger Tippfehler in einem Interface-Namen zieht sich durch alle Klassen. Vergleiche gezielt “description” vs. “desciption” und entscheide Dich für eine konsistente, korrekt geschriebene API.\n- Überlege beim Log-Scale-Feature: Soll wirklich der *Datensatz* entscheiden, ob log-Skalierung verwendet wird (ein globales Setting), oder soll das *jeder Punkt* individuell liefern? Falls es global ist, wo wäre dann der beste Ort, diese Information zu beziehen, ohne von `data[0]` abhängig zu sein?\n- Prüfe bei den Movies die Aufgabenformulierung “x-Achse: Filmbudget”: wenn Du umrechnest (z.B. Millionen), dann ist es streng genommen nicht mehr das Budget im Originalwert. Wenn Du umrechnen willst, überlege, ob das besser nur in der Hover-Description passiert statt für die Achsenwerte.\n- Validier einmal, welche Skala “literacy” in der CSV tatsächlich hat, und stelle sicher, dass Achsenwert und der Text mit `%` wirklich zusammenpassen (ggf. entweder im Text oder im x-Wert anpassen, aber konsistent).\n\n### Code Style\n- Benenne `getDesciption()` unbedingt korrekt und konsistent (auch in Javadoc): Tippfehler in öffentlichen Methoden sind wartungsintensiv und wirken wie “kaputte” API.\n- In `Movie`/`Processor` sind einige Getter aus dem Ausgangscode entfernt/umgebaut; das ist nicht per se falsch, aber achte darauf, dass Du nur das Interface als Integrationspunkt brauchst und sonst möglichst wenig am bestehenden Datenmodell “Team-Code” veränderst.\n- In `Processor.getClockRateFormatted()` nutzt Du bei GHz immer `%.1f`; die Aufgabenbeschreibung spricht von “Kommazahlen” (nicht zwingend genau eine Nachkommastelle). Überlege, ob Du Formatierung robuster/angemessener gestalten willst (z.B. ohne unnötige `.0`).\n\n\n# Exercise: swissmap\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n",
"status" : "SUCCESS"
}
}