{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- `FlatRateCard` berechnet immer 150 CHF, auch wenn gar nicht geparkt wurde; falls die Monatskosten nur anfallen sollen, wenn die Karte im Abrechnungszeitraum “verwendet” wurde, passt das Ergebnis sonst nicht zum geforderten Gesamtumsatz.\n- In `GroupCard` erlaubst du `person = 0` (weil du nur `< 0` verbietest). Laut Tabelle ist “bis 5” definiert, aber “0 Personen” ist inhaltlich fragwürdig und kann zu unerwartetem Verhalten führen.\n\n### Suggestion\n- Überlege bei `FlatRateCard`, woran das System erkennen soll, ob die Monatsgebühr in die aktuelle Umsatzberechnung eingehen muss (z.B. abhängig davon, ob in diesem Zeitraum überhaupt geparkt wurde, oder ob es pro Abrechnungslauf immer anfällt). Prüfe das gegen die erwarteten 156.75 CHF.\n- Entscheide für `GroupCard`, ob `0` als gültige Personenzahl gelten soll. Falls nicht, passe die Validierung im Konstruktor entsprechend an.\n\n### Code Style\n- In `FlatRateCard` speicherst du `totalTime`, nutzt ihn aber für die Kostenberechnung nicht. Entweder konsequent entfernen oder für eine “wurde genutzt?”-Logik verwenden, damit die Klasse klarer ist.\n- In `GroupCard`/`IndividualCard` fehlen die `@Override`-Annotationen bei den Interface-Methoden (funktioniert zwar ohne, hilft aber beim Vermeiden von Tippfehlern und macht die Implementierung eindeutiger).\n- Benennung: `person` ist eigentlich eine Anzahl (`persons`/`personCount`), das macht den Code leichter verständlich.\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- In `Movie.getX()` gibst du das Budget als rohe Zahl (vermutlich in Dollar) zurück, obwohl du dir mit `getbudgetInMillions()` schon selbst eine passende Skala vorbereitet hast; das kann dazu führen, dass die Film-Visualisierung nicht der erwarteten Achsenskalierung/Lesbarkeit aus den Screenshots entspricht.\n- Beim Prozessor-Datensatz soll die *effektive Rechengeschwindigkeit* (clockRate * cores) verwendet werden und **der Visualizer** soll dafür eine logarithmische y-Achse verwenden; du logarithmierst stattdessen bereits in `Processor.getY()`. Damit ist die y-Achse nicht mehr “Wert”, sondern schon “log(Wert)” und entspricht nicht mehr der geforderten Schnittstellenidee (DataPoint liefert Daten, Visualizer entscheidet Darstellung).\n- In `Processor.getDesciption()` rechnest du die Taktfrequenz immer als `MHz` (`clockRateKhz / 1000`) aus und formatierst sie nicht gemäss Anforderung (kHz/MHz als ganze Zahl, GHz als Kommazahl, passende Einheit je nach Grösse).\n\n### Suggestion\n- Überleg dir bei Filmen, welche Einheit/Skalierung auf der x-Achse in den Screenshots plausibel ist, und ob dein `getX()` dazu passen sollte oder ob du stattdessen den bereits berechneten “in Millionen”-Wert verwenden willst.\n- Beim Prozessor: Lass `getY()` eher den “echten” Geschwindigkeitswert (clockRate * cores) liefern und überlege, wo in der Architektur sinnvollerweise die Log-Skalierung hingehört (Stichwort: Darstellung vs. Daten).\n- Für die Prozessor-Detailzeile: Prüfe die Größenordnung von `clockRateKhz` und entscheide dann dynamisch, ob du kHz, MHz oder GHz anzeigen willst; für GHz brauchst du eine Dezimaldarstellung statt Integer-Division.\n\n### Code Style\n- Tippfehler in Methodennamen: `getDesciption()` ist falsch geschrieben; das zieht sich durchs ganze Projekt (Interface + Implementierungen + Visualizer). Besser konsistent korrekt benennen, sonst wird’s später fehleranfällig.\n- Methoden-/Variablennamen sind teils inkonsistent formatiert: `getbudgetInMillions()` sollte Java-üblich `getBudgetInMillions()` heissen.\n- Strings in den Description-Methoden wirken “zusammengebastelt” (z.B. `\"GDP/capitas\"` / `\"millionen\"`); besser einheitliche Begriffe/Formatierung, damit Hover-Texte sauber lesbar sind.\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"
}
}