{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n\n\n### Suggestion\n\n\n### Code Style\n- In den Settern ist das `else` nach einem `throw` nicht nötig (du kannst nach der Validierung direkt zuweisen), das macht den Code etwas schlanker.\n- In `format()` brauchst du nicht zwingend über Getter zu gehen; direkt auf die Felder zuzugreifen ist innerhalb der Klasse üblich (ist aber kein Muss).\n\n\n# Exercise: timespan\n\n### Correctness\n- Die Precondition für `add(int hours, int minutes)` stellt nur sicher, dass die *übergebenen* Werte nicht negativ sind, aber nicht die geforderte Invariante `totalMinutes >= old(totalMinutes)` als Bedingung ausdrückt (insbesondere, falls dein interner Zustand jemals inkonsistent wäre oder später Änderungen kommen).\n- Die Invariante `totalMinutes >= 0` ist zwar über `hours >= 0 && minutes >= 0` im Konstruktor abgesichert, aber du drückst nicht explizit die geforderte Sichtweise über `totalMinutes` aus (Anforderung ist “aus Client-Code-Sicht formuliert”, also über `totalMinutes`).\n\n### Suggestion\n- Überlege bei `add(...)`, welche Bedingung direkt garantiert, dass die neue Zeitspanne nicht kleiner wird als vorher – und formuliere/prüfe diese Bedingung anhand des beobachtbaren Werts (z.B. über Minuten insgesamt) statt nur anhand einzelner Parameter.\n- Überlege auch im Konstruktor, wie du die Nicht-Negativität so prüfen kannst, dass sie exakt der Invariante “Zeitspanne ist nie negativ” entspricht (wieder: client-sichtbar, nicht feld-sichtbar).\n\n### Code Style\n- Du hast die Normalisierung der Minuten (Umrechnung in Stunden) im Konstruktor und in `add` doppelt implementiert; das schreit nach Wiederverwendung, damit du Logik nicht an zwei Orten konsistent halten musst.\n- `throw new IllegalArgumentException();` ohne Nachricht macht Debugging unnötig schwer; gib eine kurze, hilfreiche Fehlermeldung mit (z.B. was genau ungültig war).\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` ist die Bedingung in der `while`-Schleife in der falschen Reihenfolge: du greifst mit `rooms[i]` auf ein Element zu, bevor du sicherstellst, dass `i` noch innerhalb der Array-Grenzen liegt. Das kann bei bestimmten Zuständen zu einem `ArrayIndexOutOfBoundsException` führen.\n- `turnNextRoomBright` erfüllt die Anforderung „findet den ersten Raum …“ nicht zuverlässig: wenn alle Räume bereits voll hell sind, endest du zwar am letzten Raum, prüfst diesen aber nochmal; die Logik ist dadurch unnötig fehleranfällig und hängt stark davon ab, wie die Schleife ausläuft.\n- `findBedrooms` verletzt die Vorgabe für die Rückgabe: Laut Aufgabe darf das Array „auch grösser als nötig“ sein und `null` enthalten, aber „maximal so gross wie die Gesamtanzahl der Räume“. Dein Array ist immer exakt so gross wie die Anzahl gefundener Bedrooms (also nie grösser als nötig). Das ist zwar funktional oft ok, entspricht aber nicht der beschriebenen erlaubten Struktur/Erwartung (insbesondere wenn Tests auf genau dieses Verhalten abzielen).\n\n### Suggestion\n- Bei `turnNextRoomBright`: stelle sicher, dass du nie auf `rooms[i]` zugreifst, bevor du geprüft hast, ob `i` noch im gültigen Bereich liegt. Oft hilft es, die „Grenzprüfung“ als erstes in der Bedingung zu haben oder die Schleifenstruktur so zu wählen, dass der Index erst nach der Prüfung verwendet wird.\n- Für `turnNextRoomBright`: überlege dir eine Struktur, in der du beim ersten Raum, der nicht „full bright“ ist, dessen Lampen setzt und danach gar nicht mehr weiter „suchen“ musst – aber ohne `break`/early return. Das geht z.B. über ein Flag, das merkt, ob du schon „gehandelt“ hast.\n- Bei `findBedrooms`: wenn du die Vorgabe wirklich ausnutzen willst, kannst du ein Array mit `rooms.length` anlegen und die gefundenen Bedrooms fortlaufend eintragen; der Rest bleibt dann automatisch `null`. Das passt exakt zu „darf grösser sein und null-Einträge enthalten, aber maximal rooms.length“.\n\n### Code Style\n- `fullBright` ist als Hilfsmethode sinnvoll, aber der Name klingt eher nach einem Attribut als nach einer Abfrage; ein „Frage“-Name (z.B. mit `is...`) macht die Lesbarkeit deutlich besser.\n- In `findBedrooms` erzeugst du bei jedem Treffer ein neues Array und kopierst alles um (`System.arraycopy`). Das ist für kleine Daten ok, aber unnötig aufwendig und macht den Code schwerer zu lesen; ein Ansatz mit fester Maximalgrösse und Index-Zähler ist hier meist klarer.\n- Die Mischung aus `for-each` und indexbasierten `while`-Schleifen ist ok, aber in `findHallway`/`turnNextRoomBright` wäre eine einheitlichere Iterationsform oft leichter nachzuvollziehen (vor allem weil du dort mit Index-Grenzen aufpassen musst).\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"
}
}