{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n- Im Konstruktor weist du die Felder zuerst zu und prüfst erst danach die Invarianten. Wenn eine Exception fliegt, wurde das Objekt schon mit ungültigem Zustand befüllt (auch wenn es dann nicht “fertig” konstruiert wird, ist das gegen die Idee der sauberen Kapselung/Invariantenprüfung im Konstruktor).\n- In allen Settern setzt du den Wert zuerst und validierst erst danach. Wenn ein ungültiger Wert übergeben wird, hat das Objekt unmittelbar danach bereits einen ungültigen Zustand (bevor die Exception fliegt).\n- Die `IllegalArgumentException`-Message im Konstruktor ist irreführend, weil du dort auch `city`, `number` und `zipCode` prüfst, aber immer nur `\"Street cannot be empty\"` meldest.\n\n### Suggestion\n- Prüfe die Argumente im Konstruktor, bevor du die Felder setzt; nutze dann erst nach erfolgreicher Validierung die Zuweisungen (oder delegiere an Setter, die korrekt validieren).\n- In Settern: erst den neuen Wert prüfen, dann erst übernehmen. So bleibt das Objekt bei einem Fehler in seinem vorherigen gültigen Zustand.\n- Gestalte die Fehlermeldungen so, dass sie zur tatsächlich verletzten Bedingung passen (z.B. getrennte Checks oder zumindest eine allgemeinere Message).\n\n### Code Style\n- Setter-Parameternamen wie `bahnhofweg`/`basel`/`i` wirken wie Testdaten und nicht wie Bedeutung; nutze aussagekräftige, konsistente Namen (z.B. `street`, `number`, `zipCode`, `city`).\n- Du wiederholst sehr ähnliche Validierungslogik in Konstruktor und Settern; das lässt sich zur besseren Wartbarkeit zentralisieren (z.B. durch private Hilfsmethoden), damit Regeln nicht auseinanderlaufen.\n\n\n# Exercise: timespan\n\n### Correctness\n- Im Konstruktor setzt du `this.hours`/`this.minutes` bereits, bevor du die Precondition prüfst; bei ungültigen Werten wird damit ein (kurzzeitig) inkonsistenter Zustand hergestellt, obwohl die Invariante „von Anfang an“ gelten soll.\n- Die Invariante `totalMinutes ≥ 0` ist im Konstruktor nicht vollständig abgesichert: Wenn `hours >= 0` und `minutes >= 0`, aber `minutes` sehr groß ist, passt du zwar an, aber du verlässt dich auf getrennte Felder statt auf eine klare „totalMinutes“-Sicht (wichtig, weil die Aufgabenstellung die Invarianten in `totalMinutes` formuliert).\n- In `add(...)` prüfst du nur `addedTotal < 0`. Damit können aber negative Parameter (z.B. `hours < 0`, `minutes > 0`) durchrutschen, solange die Summe nicht negativ ist. Das widerspricht der geforderten Precondition „Zeitspannen können nur verlängert werden“ (die soll gegenüber Client-Code klar durchgesetzt werden, also typischerweise auf den Eingaben).\n- In `add(...)` ist die Precondition „darf nicht verkürzen“ nur über die Summe umgesetzt. Damit ist es möglich, dass der Client negative Stunden über positive Minuten „kaschiert“ und du es akzeptierst, obwohl die API eigentlich keine negativen Werte zulassen sollte.\n\n### Suggestion\n- Überlege, in welcher Reihenfolge du im Konstruktor prüfen und dann erst Felder setzen solltest, damit nie ein Objektzustand entsteht, der die Invarianten verletzt (auch nicht „kurz“).\n- Formuliere die Preconditions so, dass sie direkt die Eingaben abdecken (z.B. was ist mit `hours < 0` oder `minutes < 0`), statt nur die resultierende Summe zu prüfen.\n- Wenn du die „nicht verkürzen“-Regel über `totalMinutes` ausdrücken willst, vergleiche gedanklich „neu“ gegen „alt“: Welche Bedingung muss gelten, damit `totalMinutes` garantiert nicht kleiner wird, auch wenn einzelne Parameter negativ wären?\n\n### Code Style\n- Die Fehlermeldung im Konstruktor („cannot be empty“) passt semantisch nicht zu der Prüfung (`< 0`); wähle eine Message, die das tatsächliche Problem beschreibt.\n- Du hast Normalisierung von Minuten im Konstruktor, aber nicht als gemeinsame Logik gekapselt; überlege, ob du die Umrechnung/Normalisierung an einer Stelle bündeln willst, damit Verhalten konsistent bleibt.\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 *eine* Lampe hell, die den Zustand-Check nicht erfüllt; gefordert ist aber: sobald Du den ersten passenden Raum gefunden hast, sollen **alle Lampen in diesem Raum** eingeschaltet und auf **1.0** gesetzt werden.\n- In `saveEnergy` schaltest Du am Anfang mit `turnAllOff()` zwar alles aus, aber Du setzt dann in jedem Raum nur die „günstigste“ Lampe an, ohne explizit sicherzustellen, dass in *diesem Raum* alle anderen Lampen aus sind (das ist aktuell nur indirekt wegen `turnAllOff()` korrekt; die Methode selbst soll aber pro Raum genau „die eine an, alle anderen aus“ herstellen, unabhängig vom Startzustand).\n- In `saveEnergy` ist `minPowerConsumption` fix auf `25.0` gesetzt. Wenn ein Raum nur Lampen mit höherem Verbrauch hätte, bleibt `cheapestLamp` `null` und dann würdest Du eine `NullPointerException` auslösen (die Aufgabe verlangt Lösungen, die allgemein mit beliebigen Lampen funktionieren).\n\n### Suggestion\n- Für `turnNextRoomBright`: Trenne gedanklich „Raum finden“ von „Raum bearbeiten“. Sobald Du in einem Raum *irgendeine* Lampe findest, die nicht „on & 1.0“ ist, markiere den Raum als Zielraum, und wende danach die „alle Lampen in diesem Raum auf on + 1.0“-Aktion auf **jede Lampe dieses Raums** an.\n- Für `saveEnergy`: Überlege Dir eine Struktur „pro Raum: erst Minimum suchen, dann nochmal über alle Lampen laufen und je nach ‘ist Minimum?’ an/aus setzen“. So ist die Anforderung „alle anderen aus“ auch erfüllt, wenn vorher irgendwo Lampen an waren.\n- Für `saveEnergy` mit beliebigen Verbrauchswerten: Initialisiere Dein Minimum so, dass es garantiert von der ersten Lampe „geschlagen“ wird (oder starte direkt mit der ersten Lampe als aktuelles Minimum), statt mit einer willkürlichen Konstante.\n\n### Code Style\n- In `turnNextRoomBright` und `findHallway` verwendest Du zusätzliche Booleans (`roomFound`, `hallwayFound`), um ein „Pseudo-break“ zu bauen. Das macht die Verschachtelung schwerer zu lesen; oft geht das übersichtlicher, wenn man die Schleifen-/Blockstruktur anders aufbaut (z.B. erst Ziel bestimmen, dann separat handeln).\n- `Random r = new Random();` wird in `randomize` und `nightMode` jeweils neu erstellt. Üblicher ist ein gemeinsames `Random`-Objekt als Feld oder eine kleine Hilfsmethode, damit Du nicht an mehreren Orten das gleiche Muster hast.\n- Kleine Lesbarkeit: In `nightMode` verwendest Du einmal `bedroomLamps.length` und einmal `bedroom.getLamps().length` für dasselbe; bleib bei einer Variante (am besten bei der lokalen Variable), dann ist klarer, was gemeint ist.\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"
}
}