{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n- Im Konstruktor setzt du die Felder zuerst und prüfst erst danach; wenn ein ungültiges Argument übergeben wird, existiert kurzzeitig ein `Address`-Objekt mit ungültigem Zustand (Invarianten sind damit nicht durchgehend eingehalten).\n- In den Settern weist du den Wert ebenfalls zuerst zu und validierst erst danach; bei ungültigen Werten wird zwar eine `IllegalArgumentException` geworfen, aber das Objekt wurde vorher schon in einen ungültigen Zustand versetzt.\n\n### Suggestion\n- Validierung vor der Zuweisung durchführen: Prüfe die Parameter/Eingaben zuerst und setze das Feld erst, wenn die Prüfung bestanden ist.\n- Alternativ kannst du im Konstruktor die Setter verwenden (sofern diese korrekt validieren, ohne vorher zuzuweisen), damit die Invarianten zentral an einer Stelle durchgesetzt werden.\n\n### Code Style\n- Die Parameternamen in den Settern (`bahnhofweg`, `basel`, `i`) sind irreführend; nimm sprechende, generische Namen wie `street`, `city`, `number`, `zipCode`.\n- Die Fehlermeldungen sind teils unpassend/ungenau (z.B. im Konstruktor wird bei beliebigem Fehler immer `\"Street cannot be empty\"` geworfen); das erschwert Debugging und Tests.\n\n\n# Exercise: timespan\n\n### Correctness\n- Deine Preconditions im Konstruktor sind nicht passend zur geforderten Invariante `totalMinutes ≥ 0`: Mit deiner Prüfung können z.B. positive Stunden und negative Minuten (oder umgekehrt) durchgehen, solange die Summe nicht negativ ist, obwohl die Aufgabe sinnvolle Preconditions für die Eingabeparameter verlangt.\n- Deine Preconditions in `add` setzen nicht die geforderte Invariante `totalMinutes ≥ old(totalMinutes)` korrekt durch: Mit z.B. `add(1, -120)` ist `addedTotal` nicht negativ, aber die Zeitspanne wird trotzdem verkürzt.\n- `getMinutes()` kann bei negativem `totalMinutes` (z.B. wenn der Konstruktor/`add` es doch zulassen) Werte außerhalb `0..59` liefern; die Aufgabe verlangt diese Invariante ohne weitere Preconditions sicherzustellen.\n\n### Suggestion\n- Überlege bei den Preconditions im Konstruktor, welche Bedingungen auf **hours** und **minutes** separat gelten sollten, damit garantiert keine negativen Anteile “versteckt” werden können.\n- Für `add`: Prüfe nicht nur, ob die Summe der hinzuzufügenden Minuten negativ ist, sondern ob der Aufruf in irgendeiner Form zu einer Reduktion der bestehenden Zeitspanne führen könnte (auch wenn sich negative und positive Anteile ausgleichen).\n- Denke daran: Die `0..59`-Minuten-Invariante soll “von außen” immer gelten. Das erreichst du entweder, indem du negative Zustände zuverlässig verhinderst oder indem du die Berechnung so absicherst, dass nie ein negativer Minutenrest sichtbar wird.\n\n### Code Style\n- Die Exception-Messages sind etwas irreführend (z.B. “empty” bei `int`-Parametern); formuliere sie so, dass klar ist, welche Bedingung verletzt wurde (negativ / verkürzend).\n- `totalMinutes` als Feldname und `totalMinutes()` als Methodenname sind sehr ähnlich; das ist nicht falsch, aber leicht verwirrend beim Lesen.\n\n\n# Exercise: asteroids\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n\n\n# Exercise: smarthome\n\n### Correctness\n- In `turnNextRoomBright()` machst du nur die einzelne Lampe hell, die das Kriterium verletzt; gefordert ist aber: **in diesem Raum alle Lampen einschalten und auf 1.0 setzen** (nicht nur die “erste gefundene” Lampe).\n- In `turnNextRoomBright()` setzt du `roomFound = true`, aber du schaltest danach nicht gezielt den Rest der Lampen im gefundenen Raum auf `on` und `1.0`; dadurch bleibt der Raum evtl. weiterhin nicht “voll hell”.\n- In `findHallway()` verwendest du `contains(\"Hallway\")`; gefordert ist ein Raum, der den Namen **\"Hallway\" hat** (also Gleichheit, nicht “irgendwo enthalten”).\n- In `saveEnergy()` initialisierst du `minPowerConsumption` fix mit `25.0`; wenn in einem Raum alle Lampen mehr als 25W hätten, bleibt `cheapestLamp` `null` und die Methode würde fehlschlagen (die Aufgabe verlangt eine allgemein funktionierende Lösung).\n- In `randomize()` nutzt du `r.nextDouble(0.5, 1.0)`; diese Überladung existiert erst in neueren Java-Versionen. Falls eure Umgebung das nicht unterstützt, erfüllt die Lösung die Anforderung “zufällig zwischen 0.5 und 1.0” zwar inhaltlich, kompiliert aber ggf. nicht.\n\n### Suggestion\n- Für `turnNextRoomBright()`: Überlege dir eine Struktur in zwei Phasen: (1) Raum finden, der nicht “voll hell” ist (du musst dafür prüfen, ob **alle** Lampen `on` und `brightness==1.0` sind), (2) sobald der Raum bestimmt ist, in einem zweiten Durchlauf über die Lampen dieses Raums **jede** Lampe auf `on` und `1.0` setzen.\n- Für `findHallway()`: Prüfe den Raumnamen auf exakte Übereinstimmung mit `\"Hallway\"` statt auf Teilstring-Vorkommen.\n- Für `saveEnergy()`: Statt mit einer fixen Zahl zu starten, nimm als Ausgangspunkt z.B. die **erste Lampe im Raum** (oder deren Verbrauch) und vergleiche dann den Rest dagegen; dann funktioniert es unabhängig davon, wie hoch die Wattzahlen sind.\n- Für `randomize()`: Falls `nextDouble(min,max)` nicht verfügbar ist, kannst du den Bereich auch aus einem `nextDouble()` (0..1) “skalieren und verschieben”, sodass du wieder auf 0.5..1.0 kommst.\n\n### Code Style\n- In `turnNextRoomBright()` und `findHallway()` ist das Muster `if (!found) { ... }` verschachtelt; lesbarer wird es oft, wenn du die Logik in kleine Hilfsmethoden auslagerst (z.B. “raumIstVollHell(room)” / “macheRaumVollHell(room)”).\n- `Random r = new Random();` wird in mehreren Methoden neu erstellt; stilistisch ist oft ein gemeinsames `Random`-Feld in `Home` übersichtlicher (und vermeidet unnötige Objekte).\n- In `nightMode()` rufst du in der Schleife `bedroom.getLamps()` mehrfach auf (`bedroomLamps` und nochmal im `nextInt(...)`); konsistenter wäre, nur die lokale Variable zu verwenden.\n\n\n# Exercise: bosses\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n",
"status" : "SUCCESS"
}
}