{
"llm" : {
"feedback" : "# Exercise: magic\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n\n\n# Exercise: tv\n\n### Correctness\n- `getSeasons()` gibt bei dir die interne Liste direkt zurück; damit können Aufrufer die Staffeln nachträglich umsortieren/ändern, wodurch die Anforderung „chronologisch sortiert zurückgeben“ nicht mehr zuverlässig garantiert ist.\n- `getSeasons()` verwendet einen rohen Typ (`List` ohne Generics); erwartet ist eine typsichere Rückgabe von `List<Season>`.\n\n### Suggestion\n- Überlege, wie du verhindern kannst, dass Code außerhalb von `TvShow` deine intern gespeicherte `seasons`-Liste verändern kann (z. B. indem du beim Zurückgeben nicht dasselbe Objekt herausgibst).\n- Schau dir die Methodensignatur von `getSeasons` an: wenn die Liste Staffeln enthält, welcher generische List-Typ passt dann, damit Compiler und Nutzer der Methode den richtigen Typ erzwingen?\n\n### Code Style\n- Markiere Felder, die nach dem Konstruktor nicht mehr geändert werden sollen, als `final` (z. B. `name`, `seasons`) und verwende für Felder/Signaturen möglichst Interfaces (`List<Season>`) statt konkreter Implementierungen (`ArrayList<Season>`).\n- Vermeide Raw Types: `public List getSeasons()` sollte generisch sein, sonst verlierst du Typsicherheit und bekommst Warnungen.\n- `new ArrayList<>(List.copyOf(seasons))` ist redundant; eine Kopie reicht (entweder `copyOf` oder `new ArrayList<>(...)`).\n\n\n# Exercise: smartcampus\n\n### Correctness\n- In `ShadesAutomation.perform(...)` sammelst du `Shades` in einer Instanzliste und leerst sie nie; bei mehrfachen Aufrufen werden dieselben Storen wiederholt hinzugefügt und dadurch mehrfach gesetzt (und die Liste wächst unbegrenzt).\n- In `ShadesAutomation.perform(...)` entscheidest du mit `if (hour == 6)` statt mit der vollständigen Zeitbedingung (inkl. Minute). Falls `perform` aus irgendeinem Grund um 06:xx aufgerufen würde, würdest du trotzdem öffnen (obwohl aktiv eigentlich nur um 06:00 sein soll).\n\n### Suggestion\n- Überlege, ob du die Storen wirklich „merken“ musst: Wenn `perform` läuft, kannst du direkt durch die Räume/Devices iterieren und sofort setzen, statt sie dauerhaft in einem Feld zu speichern. Wenn du sie doch speicherst, musst du sicherstellen, dass du keine Duplikate ansammelst (z.B. vor dem Sammeln leeren oder Duplikate verhindern).\n- Verwende in `perform` dieselbe exakte Zeitlogik wie in `isActive` (also Stunde *und* Minute), damit Öffnen/Schliessen nur zu den vorgesehenen Zeitpunkten passiert.\n\n### Code Style\n- Unnötige Imports in `Campus` (`HashSet` wird nicht verwendet) entfernen.\n- `automations` sollte wie `rooms` als `final` Feld deklariert und konsistent bei den Feldern platziert werden (nicht „zwischen“ Methoden).\n- In `totalPowerConsumptionForRoom` ist `Double sum` unnötig als Wrapper-Typ; ein primitiver `double` ist passender.\n- In `ShadesAutomation` ist das Feld `ArrayList<Shades> shades` als dauerhafter Zustand irreführend; das macht die Klasse zustandsbehaftet und führt leicht zu den oben genannten Problemen.\n\n\n# Exercise: mapcoloring\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n\n\n# Exercise: commitactivity\n\n### Correctness\n- `TimeSlot.equals` ist logisch falsch: Wenn die Stunden unterschiedlich sind, vergleichst du nur die `quarter`-Werte; wenn die Stunden gleich sind, gibst du immer `true` zurück (auch wenn `quarter` unterschiedlich ist). Damit sind sehr viele verschiedene Zeitslots “gleich”, was die Tests und jede Map-/Set-Logik kaputt macht.\n- Zu `TimeSlot.equals` fehlt das dazu passende `hashCode()`. Sobald `TimeSlot` irgendwo in einer Hash-basierten Struktur landen würde (oder Tests das prüfen), ist das ein Vertragsbruch (`equals`/`hashCode` müssen konsistent sein).\n- `ActivityChart` nutzt `TreeMap<TimeSlot, Integer>`, aber `TimeSlot.compareTo` ist nicht konsistent mit deiner `equals`-Implementierung. Bei `TreeMap` ist die Sortierung/Equality über `compareTo` relevant; wenn `compareTo` “gleich” sagt, müssen die Objekte auch per `equals` gleich sein (und umgekehrt ist es stark empfohlen). Mit deiner aktuellen `equals`-Logik passt das nicht zusammen und kann zu “verschwindenden” Keys bzw. unerwartetem Überschreiben führen.\n\n### Suggestion\n- Überlege dir für `TimeSlot.equals`: Zwei `TimeSlot`-Objekte sollen genau dann gleich sein, wenn **beide** Komponenten (Stunde **und** Viertel) übereinstimmen. Prüfe deine If/Else-Struktur darauf, ob sie wirklich genau diese Bedingung abbildet.\n- Ergänze `hashCode()` so, dass er aus denselben Feldern berechnet wird, die auch in `equals` verglichen werden (ansonsten verhalten sich Maps/Sets unzuverlässig).\n- Stelle sicher, dass `compareTo` dieselbe “Gleichheit” definiert wie `equals`: Wenn `compareTo` `0` liefert, sollten die beiden Objekte auch als gleich gelten. Prüfe das gezielt mit ein paar Beispielen (z.B. 10:00 vs 10:15, 10:00 vs 11:00).\n\n### Code Style\n- Unbenutzte Imports: `java.util.Collections` wird nicht verwendet.\n- Methodennamen: `putinMap` ist wenig sprechend; ein Name wie “increment…”/“add…” wäre klarer.\n- Rückgabetyp von `getHistogram()`: In der Signatur könntest du beim Interface `Map<TimeSlot, Integer>` bleiben (wie vorgegeben), statt die konkrete Implementierung `TreeMap` nach außen zu leaken.\n",
"status" : "SUCCESS"
}
}