{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n- Im Konstruktor werden die Felder zuerst gesetzt und erst danach validiert; bei ungültigen Werten wird zwar eine `IllegalArgumentException` geworfen, aber das Objekt ist in diesem Moment bereits (kurzzeitig) in einem ungültigen Zustand.\n- In allen Settern weist Du den Wert zuerst zu und prüfst erst danach; wenn die Prüfung fehlschlägt, bleibt das Objekt anschließend mit dem ungültigen Wert bestehen, obwohl eine Exception geworfen wurde (Invarianten werden dadurch nicht zuverlässig eingehalten).\n- Die Fehlermeldung im Konstruktor ist unabhängig vom tatsächlichen Fehler immer `\"Street cannot be empty\"`, auch wenn z.B. `zipCode` oder `number` ungültig sind.\n\n### Suggestion\n- Prüfe die Argumente, bevor Du sie in den Feldern speicherst (gilt für Konstruktor und Setter), sodass bei einer Exception der alte/gültige Zustand erhalten bleibt bzw. gar kein ungültiger Zustand entstehen kann.\n- Wenn Du mehrere Invarianten in einer Prüfung zusammenfasst, achte darauf, dass die Exception-Nachricht zum tatsächlichen Fehler passt (oder unterscheide die Fälle).\n\n### Code Style\n- Parameternamen wie `bahnhofweg` und `basel` sind irreführend; verwende neutrale Namen passend zur Bedeutung (z.B. `street`, `city`), damit der Setter allgemein verständlich bleibt.\n- In den Settern könntest Du erst validieren und dann zuweisen; das macht den Code nicht nur korrekter, sondern auch leichter zu lesen (kein „erst kaputt machen, dann meckern“).\n\n\n# Exercise: timespan\n\n### Correctness\n- In `add(...)` stellst du nicht sicher, dass `0 ≤ getMinutes ≤ 59` nach dem Addieren weiterhin gilt; nach mehreren `add`-Aufrufen kann `minutes` > 59 bleiben, bis jemand `getHours()`/`getMinutes()` aufruft.\n- Die Invariante soll „ohne weitere Preconditions“ gelten und „von aussen gesehen“ immer stimmen; aktuell hängt das beobachtbare Verhalten davon ab, ob vorher ein Getter aufgerufen wurde (weil die Getter den Zustand verändern).\n- Die Precondition für `add(...)` deckt die Invariante „totalMinutes ≥ old(totalMinutes)“ nicht sauber ab, weil du nur `hours < 0 || minutes < 0` verbietest; Kombinationen, die insgesamt verkürzen würden (z.B. negatives Stundenargument mit positiven Minuten), werden durch deine Checks nicht generell ausgeschlossen, falls du so etwas später zulassen würdest.\n- Fehlermeldung im Konstruktor: „cannot be empty“ passt nicht zur geforderten Precondition (es geht um negative Werte, nicht um „empty“).\n\n### Suggestion\n- Sorge dafür, dass die Normalisierung von Minuten (Umwandlung in Stunden, Rest Minuten) immer dann passiert, wenn sich der Zustand ändert (Konstruktor und `add`), nicht erst in den Gettern.\n- Getter sollten idealerweise keinen Zustand verändern; überleg dir, wie du garantieren kannst, dass die Werte bereits vor dem Zugriff in einem gültigen Zustand sind.\n- Überlege bei der „nur verlängern“-Regel, ob deine Vorbedingungen wirklich jede Verkürzung ausschliessen (denk in „Delta totalMinutes“ statt nur in einzelnen Vorzeichen).\n- Passe die Exception-Message so an, dass sie das Problem korrekt beschreibt (negative Werte).\n\n### Code Style\n- Vermeide Seiteneffekte in `getHours()` und `getMinutes()` (sie verändern aktuell `hours`/`minutes`); das macht Debugging schwer und kann zu überraschendem Verhalten führen.\n- Du hast dieselbe Normalisierungslogik in mehreren Methoden dupliziert; kapsle das in einer gemeinsamen internen Methode, damit du es nicht an mehreren Stellen synchron halten musst.\n- Exception-Texte sollten präzise und konsistent sein (z.B. überall „negative values not permitted“ statt einmal „empty“).\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- `turnNextRoomBright`: Du schaltest/hellst nur einzelne Lampen in dem gefundenen Raum auf (und sogar nur die Lampen, die gerade nicht `on` sind oder nicht `1.0` haben). Gefordert ist: **sobald** der erste “nicht komplett bright”-Raum gefunden ist, sollen **alle Lampen in diesem Raum** eingeschaltet und auf **1.0** gesetzt werden.\n- `turnNextRoomBright`: Sobald du einen passenden Raum gefunden hast, läuft deine innere Schleife weiter und kann dadurch (im selben Raum) weitere Lampen verändern, aber du stellst eben nicht “alle Lampen” konsequent auf bright, sondern nur die, die die Bedingung erfüllen. Das entspricht nicht der Anforderung.\n- `saveEnergy`: Du initialisierst `minPowerConsumption` mit `25.0`. Wenn in einem Raum alle Lampen einen höheren Verbrauch hätten, bleibt `cheapestLamp` `null` und danach rufst du `cheapestLamp.turnOn()` auf (würde crashen). Die Aufgabe verlangt eine allgemeine Lösung für beliebige Lampenwerte.\n- `findHallway`: Du verwendest `contains(\"Hallway\")`, gefordert ist explizit der Raum, der den Namen **\"Hallway\" hat** (also Gleichheit, nicht “irgendwo enthalten”).\n- `nightMode`: Du schaltest jeweils **eine zufällige** Lampe in Hallway/Bedrooms ein. In der Aufgabenbeschreibung steht “je eine (beliebige) Lampe” – zufällig ist zwar “beliebig”, aber falls in der Vorlage/Tests erwartet wird, dass deterministisch z.B. “erste Lampe” genommen wird, kann das zu Testfehlschlägen führen.\n\n### Suggestion\n- `turnNextRoomBright`: Trenne gedanklich zwei Schritte: (1) Prüfen, ob ein Raum “nicht komplett hell” ist, und (2) wenn ja, dann in **einem separaten Durchlauf über die Lampen dieses Raums** wirklich jede Lampe auf `on` und `brightness=1.0` setzen. Achte darauf, dass du danach keine weiteren Räume mehr bearbeitest (ohne `break`/early return kannst du z.B. mit einem Flag arbeiten, aber die Aktion im Raum sollte trotzdem “alle Lampen” betreffen).\n- `saveEnergy`: Wähle den Startwert für das Minimum so, dass er garantiert über jedem echten Verbrauch liegt (oder initialisiere mit der ersten Lampe des Raums und starte die Suche ab der zweiten). Dann ist auch bei “ungewöhnlichen” Watt-Zahlen immer eine Lampe gewählt.\n- `findHallway`: Überlege dir, ob du wirklich “enthält” brauchst oder ob du exakt den Namen vergleichen solltest, den die Aufgabe nennt.\n- `nightMode`: Wenn du auf Nummer sicher gehen willst bei automatischen Tests, entscheide dich für eine feste “beliebige” Lampe (z.B. immer dieselbe Position pro Raum) statt Zufall.\n\n### Code Style\n- In `turnNextRoomBright` und `findHallway` ist das Muster `if (!found) { ... }` um die ganze Schleife herum etwas verschachtelt; lesbarer wird’s oft, wenn du die Logik so strukturierst, dass du pro Raum zuerst entscheidest und dann separat handelst (gerne auch mit einer kleinen Hilfsmethode).\n- `Random r = new Random();` wird in `randomize` und `nightMode` jeweils neu erstellt. Stilistisch ist oft ein einziges `Random`-Objekt als Feld oder eine Hilfsmethode cleaner (insbesondere falls du später reproduzierbares Verhalten möchtest).\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"
}
}