{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- `FlatRateCard.cost()` liefert immer 150 CHF, unabhängig davon, ob überhaupt geparkt wurde; damit wird in deinem Beispiel immer mindestens 150 CHF Umsatz gezählt, selbst wenn die Karte nie benutzt wird.\n- `GroupCard`: Laut Aufgabe ist „mehr als 20“ nicht erlaubt; bei dir ist `person = 0` erlaubt (weil du nur `< 0` verbietest). Das passt nicht zur Idee „Anzahl Personen“ (sollte sinnvollerweise mindestens 1 sein).\n- `GroupCard`: Für „mehr als 20“ soll „nicht erlaubt“ gelten; du verbietest zwar `> 20`, aber die Aufgabe impliziert diese Einschränkung als fachliche Regel für Gruppenkarten (also nicht nur “irgendein Wert”, sondern genau die geforderten Kategorien). Prüfe, ob deine Grenzfälle (z.B. 20, 21) exakt der Tabelle entsprechen.\n\n### Suggestion\n- Überlege bei der Flatrate, wann die Monatskosten anfallen sollen: pro Abrechnungsperiode/Reset oder unabhängig von Nutzung? Schau dir an, wie `calculateRevenueAndReset()` funktioniert (es summiert `cost()` und ruft dann `reset()`), und passe das Verhalten der Flatrate so an, dass der Umsatz am Ende genau dem erwarteten Gesamtumsatz entspricht.\n- Bei `GroupCard`: Überlege, ob „0 Personen“ überhaupt ein sinnvoller/zulässiger Fall ist und wie du den Konstruktor-Check formulieren musst, damit nur erlaubte Personenzahlen durchkommen (gemäss Aufgabenbeschreibung).\n- Teste die Grenzwerte explizit (5/6/10/11/20/21) und kontrolliere, ob jeweils der richtige Tarif bzw. die richtige Exception ausgelöst wird.\n\n### Code Style\n- In `FlatRateCard` ist `totalTime` aktuell redundant, weil `cost()` nicht davon abhängt; entweder sinnvoll nutzen oder weglassen, damit die Klasse klarer ist.\n- Einheitliche Benennung: `person` klingt nach einer einzelnen Person; für eine Anzahl wäre z.B. ein Plural/`personCount` verständlicher.\n- Bei den Interface-Implementierungen könntest du konsequent `@Override` auch in `GroupCard`/`IndividualCard` setzen (bei `GroupCard`/`IndividualCard` fehlt es), das macht Implementationsfehler leichter sichtbar.\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- Beim Prozessor-Datensatz soll für eine gute Darstellung eine **logarithmische y-Achse** verwendet werden; in deiner Lösung bleibt die y-Skalierung linear (Visualizer verwendet `guiY(...)` direkt auf `getY()` ohne Log-Transformation).\n- Die Detailanzeige der Prozessor-Taktfrequenz soll laut Aufgabe bei **GHz mit Dezimalzahl** (z. B. `2.5 GHz`) dargestellt werden; deine Methode `getClockRateKhzFormated()` gibt bei GHz aktuell durch Integer-Division nur ganze Zahlen aus und zudem ohne Leerzeichen vor `GHz`.\n- In `DataPoint` / Implementierungen ist der Methodenname **`getDesciption()`** (Tippfehler) festgelegt; das ist zwar innerhalb deines Codes konsistent, aber falls im vorgegebenen Code/Tests oder in anderen Teamteilen **`getDescription()`** erwartet wird, würde das nicht zusammenpassen.\n\n### Suggestion\n- Überlege dir, wo im Rendering-Pfad du die y-Werte für Prozessoren transformieren könntest: Du brauchst die Log-Skalierung konsistent an allen Stellen, wo y verwendet wird (Min/Max, Plotten, Hover-Distanz, Highlight).\n- Schau dir bei der Formatierung der Taktfrequenz an, welche Datentypen und Divisionen du verwendest: Für GHz brauchst du eine Rechnung, die Nachkommastellen nicht „wegschneidet“, und die Ausgabe soll die Einheiten-Regel (kHz/MHz als ganze Zahl, GHz mit Dezimalzahl) erfüllen.\n- Prüfe die Schreibweise des Interface-Methodennamens für die Beschreibung nochmals sehr genau und gleiche sie mit dem erwarteten API-Namen ab (und passe dann alle Implementierungen + Aufrufstellen gemeinsam an).\n\n### Code Style\n- Benenne `getbudgetInMillions()` konsistent nach Java-Konvention (`getBudgetInMillions`) und korrigiere Tippfehler wie `getClockRateKhzFormated` (Formatted).\n- Strings in `getDesciption()` sind teils schwer lesbar („millionen“, „GDP/capitas“, gemischte Sprache/Einheiten, fehlende Abstände). Einheitliche, sauber formatierte Texte helfen auch beim Debuggen der Hover-Ansicht.\n- `DUMMY_DOUBLE` und `DUMMY_STRING` bleiben in `Visualizer` unbenutzt; wenn du fertig bist, könntest du sie entfernen, damit der Code klarer ist.\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"
}
}