{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- `FlatRateCard.cost()` gibt immer 150 zurück, unabhängig davon, ob überhaupt geparkt wurde; damit wird auch für unbenutzte Abos Umsatz gerechnet (im Beispiel wäre card3 dann 150, obwohl sie evtl. gar nicht genutzt werden müsste).\n- In `GroupCard` erlaubst du `person == 0` (weil du nur `person < 0` verbietest), obwohl “Anzahl Personen” inhaltlich mindestens 1 sein sollte.\n- Die Fehlermeldung/Logik für “mehr als 20 nicht erlaubt” ist bei `GroupCard` zwar da, aber du verbietest auch negative Werte statt “0 und weniger” (siehe Punkt oben); das entspricht nicht sauber der Vorgabe “mehr als 20 nicht erlaubt” + sinnvolle Personenanzahl.\n\n### Suggestion\n- Überlege bei der `FlatRateCard`, ob die Monatskosten wirklich “pro Karte pro Abrechnung” immer zählen sollen, oder ob sie nur dann in den Umsatz einfliessen sollen, wenn die Karte im Abrechnungszeitraum überhaupt verwendet wurde (Hinweis: du hast bereits `totalTime`, den du dafür nutzen könntest).\n- Prüfe bei `GroupCard`, welche minimal sinnvolle Personenzahl zugelassen sein sollte, und passe die Validierung entsprechend an (denk an 0 Personen).\n- Rechne testweise die erwartete Gesamtsumme 156.75 nach und vergleiche sie mit dem, was dein Programm ausgibt – daran siehst du schnell, ob die Flat-Rate-Logik so gedacht ist.\n\n### Code Style\n- In `FlatRateCard` ist `totalTime` aktuell nur für `reset()` relevant; entweder konsequent in die Logik einbauen oder weglassen, damit keine toten Datenfelder entstehen.\n- Bei `GroupCard`, `IndividualCard` fehlen konsequent `@Override`-Annotationen (funktional nicht nötig, aber hilft beim Compiler-Check und Lesbarkeit).\n- Benennung: `person` wirkt wie “eine Person”, ist aber “Anzahl Personen”; ein plural/sinnvoller Name (z.B. `persons`/`personCount`) 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 Rohwert (vermutlich in Dollar) zurück, während in der Aufgabenbeschreibung/Screenshots die x-Achse typischerweise als “Budget in Millionen” dargestellt wird; dein `getbudgetInMillions()` wird aktuell nicht für `getX()` verwendet, dadurch passt die Skalierung/Anzeige nicht zur erwarteten Visualisierung.\n- Beim Prozessor-Datensatz fehlt die geforderte logarithmische y-Achse; aktuell wird `getY()` linear geplottet, was die Darstellung über die Jahre stark “zusammendrückt” und nicht der Aufgabenanforderung entspricht.\n- Die Schnittstelle enthält die Methode `getDesciption()` (Schreibfehler); das ist zwar bei dir konsistent umgesetzt, aber die Aufgabenstellung verlangt eine saubere Schnittstelle mit Javadoc – ein Tippfehler im Methodennamen macht die Schnittstelle unnötig fehleranfällig und entspricht so nicht dem Anspruch der Aufgabe.\n- In `Processor.getClockRateKhzFormated()` werden GHz-Werte nicht wie gefordert formatiert (GHz soll als Kommazahl dargestellt werden, kHz/MHz als ganze Zahl); du gibst bei GHz zwar ein `double` aus, aber ohne kontrollierte Nachkommastellen (z.B. kann das sehr “unsauber” aussehen).\n- `VisualizerApp.main()` ist nicht als Java-Entry-Point deklariert (`public static void main(String[] args)`), d.h. so startet das Programm in einer Standard-Java-Umgebung nicht wie gefordert über die main-Methode.\n\n### Suggestion\n- Schau dir an, in welcher Einheit die x-Achse bei den Filmen in den Screenshots beschriftet/implizit gedacht ist, und leite daraus ab, welchen Zahlenbereich `getX()` liefern sollte (deine Hilfsmethode deutet schon in die richtige Richtung).\n- Überlege beim Prozessor-Plot, wo du am besten die Logarithmierung einbaust: Entweder liefert der Datenpunkt bereits einen transformierten y-Wert, oder der Visualizer bietet eine Option für log-Skalen (die Aufgaben-Tipps deuten an, dass du dafür irgendwo eine Anpassung brauchst).\n- Geh nochmal über den Methodennamen für die Detailanzeige: Wenn du später irgendwo “Description” erwartest, ist ein Tippfehler extrem teuer. Prüfe auch, ob du ihn wirklich überall gleich geschrieben hast (Interface + alle Implementierungen + Visualizer).\n- Für die GHz-Formatierung: überlege dir eine klare Regel “wie viele Nachkommastellen” du anzeigen willst und stelle sicher, dass bei MHz/kHz wirklich keine Dezimalstellen auftauchen.\n- Wenn deine Lösung auch “normal” ausführbar sein soll: vergleiche deine `main`-Signatur mit der üblichen Java-Signatur und passe sie entsprechend an.\n\n### Code Style\n- Benennung: `getbudgetInMillions()` sollte nach Java-Konvention `getBudgetInMillions()` heißen (CamelCase).\n- Schreibfehler in API: `getDesciption()` wirkt unprofessionell und macht die Schnittstelle schwerer verständlich (auch wenn es technisch funktioniert).\n- Strings in `getDesciption()`/`getName()` haben teils Tippfehler/uneinheitliche Einheiten (`millionen`, `GDP/capitas`, `km^2` statt `km²` etc.); das ist “UI-Text”, aber für die Lesbarkeit der Visualisierung relevant.\n- In `Processor.getClockRateKhzFormated()` wäre eine konsistentere Formatierung (z.B. mit Format-String) lesbarer als implizite `double`-Konvertierung durch String-Konkatenation.\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"
}
}