{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- `FlatRateCard` erfüllt das erwartete Verhalten eines Park-Abos nicht: Wenn `cost()` immer 150 zurückgibt, wird bei `calculateRevenueAndReset()` auch dann 150 CHF Umsatz gezählt, wenn die Karte gar nie “verwendet” wurde (und unabhängig davon, ob sie im System überhaupt in diesem Zeitraum “aktiv” war). Für das geforderte Ergebnis (156.75 CHF) muss das Zusammenspiel von `park()`, `cost()` und `reset()` so funktionieren, dass genau der erwartete Umsatz herauskommt.\n- In `GroupCard` ist `HOURLY_RATE` als `static` definiert. Dadurch teilen sich alle `GroupCard`-Objekte dieselbe Rate; wenn du mehrere Gruppenkarten mit unterschiedlicher Personenanzahl registrierst, überschreiben sie sich gegenseitig den Tarif und die Kostenberechnung wird falsch.\n- `GroupCard`: Der Tarif ist “abhängig von der Anzahl Personen (durch einen Konstruktor-Parameter definiert)”. Mit dem aktuellen `static`-Ansatz ist diese Abhängigkeit nicht pro Karte gespeichert, sondern global für alle Gruppenkarten.\n\n### Suggestion\n- Überlege bei `FlatRateCard`, wie `calculateRevenueAndReset()` arbeitet: es summiert `cost()` über alle registrierten Karten und ruft danach `reset()`. Frage dich: Wann soll ein Flat-Rate-Abo Umsatz erzeugen, und wie kann deine Karte diesen Umsatz-Zeitpunkt über ihren internen Zustand abbilden (z.B. erst nachdem sie “in Anspruch genommen” wurde / für einen Monat gezählt wurde / etc.)?\n- Für `GroupCard`: Stell dir vor, du registrierst `new GroupCard(5)` und `new GroupCard(15)` gleichzeitig. Welche Variable muss dann pro Objekt unterschiedlich sein, damit beide korrekt rechnen? Prüfe, ob diese Variable wirklich `static` sein darf.\n- Speichere den im Konstruktor ermittelten Stundentarif als Instanz-Zustand der Karte, nicht als Klassen-Zustand, damit jede Gruppenkarte ihren eigenen Tarif behält.\n\n### Code Style\n- Benennungen: `Personen` als Parametername startet groß und mischt Sprache/Stil; in Java sind `personen`/`numberOfPeople` üblich (camelCase, klein beginnend).\n- In `GroupCard` sollte `HOURLY_RATE` (falls es überhaupt eine Variable pro Objekt ist) `final` sein, sobald er im Konstruktor festgelegt wurde; so wird klar, dass sich der Tarif nicht mehr ändert.\n- In `FlatRateCard` sind leere Methoden (`park`, `reset`) ohne Kommentar irritierend. Wenn das Absicht ist, dokumentiere kurz, warum sie nichts tun bzw. welcher Zustand stattdessen relevant ist.\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: swissmap\n\n### Correctness\n- Teil c) fehlt: `City`, `Lake` und `Mountain` implementieren noch nicht `Hoverable` (inkl. `getInteractiveArea`, `onMouseEnter`, `onMouseExit`) und es wird nirgends beim Hover eine Beschreibung angezeigt.\n- Teil d) fehlt: Die Klasse `ModeButton` ist nicht implementiert/registriert, und der Wechsel in den Satelliten-Modus per Klick ist nicht möglich.\n- In `SwissMapApp` ist die `main`-Methode nicht als Java-Entry-Point definiert (Signatur passt nicht), dadurch startet das Programm in einer normalen Java-Ausführung nicht über `main`.\n\n### Suggestion\n- Für c): Ergänze in jeder der drei Klassen einen internen Zustand (z.B. ein boolean), der beim Betreten/Verlassen des interaktiven Bereichs umgeschaltet wird, und nutze diesen Zustand dann in `draw`, um `toString()` (oder eine Beschreibung) neben dem Objekt zu zeichnen. Den interaktiven Bereich kannst du für den Anfang als `Rectangle` um die gezeichnete Position herum wählen.\n- Für d): Überlege dir, wo der Button auf der Karte liegen soll (fixe GUI-Koordinaten oder ebenfalls via `Coordinate`). Der Button braucht eine Referenz auf dein `SwissMap`-Objekt, damit `onLeftClick` dort den Modus toggeln kann. `onRightClick` darf leer bleiben, muss aber vorhanden sein.\n- Für `main`: Prüfe, welche Signatur Java für den Programmeinstieg erwartet (Stichworte: `public`, `static`, Parameter), und passe die Methode entsprechend an.\n\n### Code Style\n- In `draw` von `City` rufst du `getCoord().toGuiX(gui)` und `toGuiY(gui)` mehrfach auf; speichere die Werte einmal in lokale Variablen, das macht den Code lesbarer.\n- In `Lake`/`Mountain` ist der Skalierungsfaktor für das Icon an die Kartenbreite gekoppelt; das wirkt etwas “magisch”. Eine klar benannte Konstante für Icon-Grösse/Skalierung (und ggf. ein Kommentar) würde die Absicht besser ausdrücken.\n\n\n# Exercise: visualizer\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n",
"status" : "SUCCESS"
}
}