{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n- Das Attribut heisst bei dir `zipcode`, in der Aufgabenstellung ist es als `zipCode` definiert; wenn Tests/Checker exakt nach diesem Namen suchen (z.B. via Reflection), kann das zu einem Fehlschlag führen.\n\n### Suggestion\n- Prüfe, ob die Übungsumgebung/Unit-Tests Feld- und Methodennamen exakt vorgeben (insbesondere die Schreibweise `zipCode`). Falls ja, passe die Benennungen konsistent an (Attribut + Getter/Setter).\n\n### Code Style\n- Der auskommentierte Block im Konstruktor ist toter Code und sollte entfernt werden, um die Klasse übersichtlich zu halten.\n- In den Settern sind die `else`-Zweige nach `throw` nicht nötig; frühzeitig werfen und danach direkt zuweisen macht den Code kürzer/lesbarer.\n\n\n# Exercise: timespan\n\n### Correctness\n- Die Invariante `totalMinutes ≥ old(totalMinutes)` ist für `add(...)` nicht vollständig durchgesetzt: Wenn jemand `add(-1, 30)` aufruft, würde das die Zeitspanne insgesamt verkürzen (auch wenn Minuten positiv sind). Deine aktuelle Prüfung verhindert das zwar durch `hours < 0 || minutes < 0`, aber sie ist nicht an der Invariante „Gesamt-Minuten dürfen nicht sinken“ formuliert und deckt damit nicht alle Fälle ab, in denen die Gesamtänderung negativ wäre (z.B. falls du später erlauben würdest, dass einer der beiden Werte negativ sein darf, wäre es sofort kaputt). Gefordert ist eine Precondition, die sich direkt auf `totalMinutes` bezieht.\n- `0 ≤ getMinutes ≤ 59` ist nicht in allen Fällen garantiert: `updateTime()` normalisiert nur, wenn `this.minutes > 59`, aber nicht, wenn `this.minutes == 60` (das wird zwar durch `> 59` noch erfasst) — der eigentliche kritische Punkt ist: du normalisierst gar nicht, wenn `this.minutes` z.B. durch Konstruktor/Add auf einen großen Wert kommt und du später eventuell noch andere Operationen einführst; aktuell passt es, aber die Methode ist unnötig kompliziert und an einer Stelle anfällig, falls Minuten jemals negativ werden sollten (dann wäre `%` problematisch). Die Aufgabe verlangt ausdrücklich „ohne weitere Preconditions“ sicherzustellen, dass `getMinutes` immer im Bereich ist.\n\n### Suggestion\n- Formuliere die Precondition für `add(...)` so, dass sie direkt prüft, ob sich die gesamte Zeitspanne in Minuten nicht verkleinert (überlege dir dazu, wie du die Änderung in Minuten berechnen kannst und wie du „old totalMinutes“ vs. „new totalMinutes“ vergleichst).\n- Für die Minuten-Normalisierung: Überlege dir eine Normalisierung, die immer greift (nicht nur in bestimmten Fällen) und die Minuten nach jeder Änderung robust in den Bereich 0–59 bringt, während die Stunden entsprechend angepasst werden.\n\n### Code Style\n- `if (...) { throw ... } else { ... }` ist hier unnötig verschachtelt; nach einem `throw` kannst du den Rest ohne `else` schreiben, das macht den Code klarer.\n- `updateTime()` enthält eine umständliche Rechnung für die Stundenanpassung; das lässt sich lesbarer ausdrücken (du verwendest `minutes % 60` bereits — überlege, wie du den zugehörigen Quotienten klarer nutzen kannst).\n- Die `IllegalArgumentException` ohne Nachricht macht Debugging mühsamer; eine kurze Fehlermeldung hilft (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- `turnNextRoomBright`: Wenn bereits **in allen Räumen** alle Lampen an sind und auf Helligkeit 1.0 stehen, soll **nichts passieren**. Bei dir wird in diesem Fall trotzdem der letzte Raum nochmals auf 1.0 gesetzt (weil dein `while` spätestens beim vorletzten Index stoppt und du danach immer den gefundenen Index verarbeitest).\n- `randomize`: Der zufällige Wert für die Helligkeit soll **zwischen 0.5 und 1.0** liegen. Je nach verwendeter `nextDouble(0.5, 1.0)`-Variante ist die obere Grenze oft **exklusiv**, d.h. 1.0 wird nie erreicht (das kann gegen “zwischen 0.5 und 1.0” interpretiert werden, falls 1.0 inkludiert sein soll).\n- `saveEnergy`: Du rufst `returnLowestEnergyCunsumptionLamp()` pro Raum zweimal auf. Falls es in einem Raum mehrere Lampen mit identischem Minimalwert gibt, kann das (je nach Implementationsdetails/Iteration) dazu führen, dass du **Helligkeit bei einer Lampe setzt, aber eine andere einschaltest**.\n\n### Suggestion\n- `turnNextRoomBright`: Überlege dir, wie du nach der Suche unterscheiden kannst zwischen “ich habe einen passenden Raum gefunden” und “ich bin am Ende angekommen, weil alle schon hell sind”. Ein zusätzlicher Check nach der Schleife (oder eine passende Schleifenbedingung) hilft, damit du im “alles schon hell”-Fall wirklich nichts tust.\n- `randomize`: Prüfe in der Doku/IDE, ob `nextDouble(origin, bound)` die obere Grenze einschliesst oder nicht. Falls nicht: überlege, wie du den Bereich so wählst/berechnest, dass das Anforderungsintervall sicher getroffen wird.\n- `saveEnergy`: Speichere die gefundene “sparsamste” Lampe pro Raum zuerst in einer Variablen und arbeite dann mit genau dieser Referenz weiter. Dann ist garantiert, dass du an derselben Lampe sowohl Helligkeit setzt als auch einschaltest.\n\n### Code Style\n- Unbenutzte Imports in `Home`: `import java.util.Arrays;` wird nirgends verwendet.\n- Naming/Typo: `returnLowestEnergyCunsumptionLamp` enthält einen Tippfehler (“Cunsumption”). Besser konsistent und korrekt benennen (auch weil du die Methode oft aufrufst).\n- Redundante Aufrufe: In `saveEnergy` und `nightMode` rufst du mehrfach hintereinander dieselbe “finde-minimale-Lampe”-Methode auf; lesbarer ist, das Ergebnis einmal zwischenzuspeichern.\n- Zusätzliche Methode `Lamp.isMax()` ist ok, aber achte darauf, dass ein `==` Vergleich bei `double` potentiell heikel sein kann; wenn du später mal andere Berechnungen einführst, kann ein Toleranzvergleich robuster sein.\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"
}
}