{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n\n\n### Suggestion\n\n\n### Code Style\n- Die Fehlermeldungen bei `number`/`zipCode` sind teilweise widersprüchlich (z.B. prüfst du `<= 0`, meldest aber „non negative“). Passe Text und Bedingung so an, dass sie das gleiche aussagen.\n- Du hast die Validierungslogik im Konstruktor und in den Settern dupliziert; das erhöht Wartungsaufwand und Fehleranfälligkeit. Überlege, die Prüfungen zentral an einer Stelle zu bündeln, damit Änderungen nur einmal gemacht werden müssen.\n- Kleinigkeit: In `format()` ist ein doppeltes Leerzeichen zwischen `street` und `number` (`\" \" + number`). Das ist nicht falsch, aber unnötig und könnte zu unerwarteten Formatierungen führen.\n\n\n# Exercise: timespan\n\n### Correctness\n- Die Precondition in `add(...)` stellt nur sicher, dass der *Parameter* (hours/minutes kombiniert) nicht negativ ist, aber nicht, dass `totalMinutes` nach dem Addieren **nicht kleiner als vorher** wird. Mit einem negativen Delta (z.B. `hours=-1, minutes=30`) kann `60*hours+minutes` negativ sein (oder auch positiv je nach Kombination) und damit eine Verkürzung ermöglichen bzw. nicht sauber verhindern – die Anforderung sagt aber: Zeitspannen dürfen **nur verlängert**, nie verkürzt werden.\n- Im Konstruktor fehlt eine eigene/sichere Durchsetzung von `totalMinutes ≥ 0` als Precondition: Dadurch, dass du nur `add(...)` aufrufst, hängt die Validierung komplett an der Logik dort. Sobald `add(...)` das “nur verlängern”-Kriterium korrekt abprüft, muss der Konstruktor ebenfalls sicherstellen, dass ein Objekt nicht mit einer negativen Gesamtzeit entstehen kann (Precondition muss klar dem Konstruktor zugeordnet sein).\n\n### Suggestion\n- Überlege bei `add(...)`, welche Bedingung garantiert, dass `newTotalMinutes >= oldTotalMinutes` gilt. Dazu hilft es, einmal explizit “alter Zustand” und “neuer Zustand” gedanklich (oder in Variablen) gegenüberzustellen und die Ausnahme daran zu knüpfen.\n- Für den Konstruktor: formuliere die Precondition so, dass schon die **Startwerte** eine gültige, nicht-negative Zeitspanne bilden. Es kann helfen, die Eingaben zuerst in “Minuten insgesamt” umzuwandeln und dann genau diese Größe zu validieren.\n\n### Code Style\n- In `add(...)` berechnest du `60 * hours + minutes` mehrfach; speichere das in einer lokalen Variable (macht die Checks und das Update lesbarer und weniger fehleranfällig).\n- Die Fehlermeldung `\"no negative total permitted\"` ist etwas unpräzise (meint sie negative Eingaben oder eine resultierende Verkürzung?). Eine klarere Message hilft beim Debuggen.\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: bosses\n\n### Correctness\n\n\n### Suggestion\n\n\n### Code Style\n- In `isSuperiorOf` und `findCommonSuperiorWith` vergleichst du mit `==` (Objektidentität). Das ist hier zwar plausibel (weil es um dieselbe Person als Objekt geht), aber es wäre gut, dir bewusst zu machen, dass das nur funktioniert, wenn wirklich dieselben `Employee`-Instanzen in der Hierarchie verwendet werden (nicht “gleiche Namen” in verschiedenen Objekten).\n\n\n# Exercise: smarthome\n\n### Correctness\n- In `turnNextRoomBright()` beendest du die Suche nach dem ersten passenden Raum über die Schleifenbedingung `&& !firstRoomFound`; das ist inhaltlich ein “early exit” der Schleife und widerspricht der Vorgabe, ohne `break/continue/early return` bzw. möglichst ohne solche vorzeitigen Abbrüche zu lösen.\n- In `findHallway()` wird nicht garantiert, dass wirklich “genau eine Hallway” genutzt wird: falls es (entgegen Annahme) mehrere gäbe, würdest du die letzte zurückgeben statt eindeutig die eine gefundene. (Die Aufgabenannahme sagt zwar “genau eine”, aber deine Implementierung nutzt diese Annahme nicht konsequent aus.)\n- `nightMode()` schaltet jeweils stumpf `lamps[0]` ein. Wenn ein Bedroom oder die Hallway keine Lampen hätte (leeres Array), würde das nicht wie gefordert funktionieren (Indexzugriff). Die Aufgabe verlangt allgemeine Lösungen für beliebige Zimmer/Lampen.\n\n### Suggestion\n- Für `turnNextRoomBright()`: Überlege dir eine Blockstruktur, bei der du erst in einer ersten Phase den Index/Referenz des “nächsten” Raums bestimmst (ohne die Schleife frühzeitig abzubrechen), und danach in einer zweiten Phase nur dann die Lampen setzt, wenn du einen gefunden hast.\n- Für `findHallway()`: Wenn du von “genau eine Hallway existiert” ausgehst, kannst du deine Logik so aufbauen, dass du den Fund eindeutiger behandelst (z.B. indem du nur einmal zuweist bzw. dir merkst, ob schon gefunden wurde), statt potenziell mehrfach zu überschreiben.\n- Für `nightMode()`: Wähle “eine beliebige Lampe” pro Raum so, dass es auch dann robust ist, wenn ein Raum 0 Lampen hat. Ein einfacher Check auf die Lampenanzahl vor dem Zugriff reicht, ohne dass du die ganze Methode umschreiben musst.\n\n3. Code Style:\n- `HashMap<String, Lamp> lampDirectory` und `getLampByName` sind für die Aufgaben nicht erforderlich und werden nirgends verwendet; das macht die Klasse unnötig komplex.\n- `lampDirectory` sollte (wenn du es behalten willst) als `private final` deklariert werden und nicht package-private herumliegen.\n- In `findBedrooms()` nutzt du denselben Index `i` fürs Ergebnisarray; das erzeugt “Löcher” (nulls) an vielen Stellen. Das ist zwar erlaubt, aber schwerer zu lesen/weiterzuverwenden als nötig; ein separater Schreibindex wäre klarer.\n- Benennungen wie `lamps1` sind wenig aussagekräftig; sprechendere Namen (z.B. `bedroomLamps`) verbessern die Lesbarkeit deutlich.\n",
"status" : "SUCCESS"
}
}