{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n- Die Anforderung „zipCode ist positiv und vierstellig“ ist in deiner Prüfung nicht vollständig abgedeckt: Du prüfst zwar auf vierstellig, aber nicht explizit auf „positiv“ (es gibt ungültige Werte, die durch „vierstellig“ allein nicht sauber als „positiv“ beschrieben sind).\n\n### Suggestion\n- Überlege, wie du die Bedingung „positiv“ beim `zipCode` unabhängig von der „vierstellig“-Prüfung formulierst, sodass beide Invarianten klar und getrennt erfüllt sind.\n\n### Code Style\n- In den Settern sind die `else`-Blöcke nach einem `throw` nicht nötig; du kannst den Code dadurch etwas schlanker machen.\n- In `format()` könntest du direkt die Felder oder die Getter verwenden (beides ist ok) – aber entscheide dich konsistent für einen Stil innerhalb der Klasse.\n\n\n# Exercise: timespan\n\n### Correctness\n- Im Konstruktor erlaubt deine Precondition durch `(minutes >= 0 && hours >= 0) || hours * 60 + minutes >= 0` Fälle mit negativen Minuten oder negativen Stunden, solange die Summe nicht negativ ist. Das widerspricht der geforderten Precondition für `totalMinutes >= 0` aus Client-Sicht (z.B. `0h -1min` wäre von aussen beobachtbar und sollte nicht möglich sein).\n- In `add(...)` ist die Precondition `hours*60 + minutes < 0` zu schwach: Damit sind Aufrufe möglich, die eine Zeitspanne verkürzen, obwohl `totalMinutes >= old(totalMinutes)` gefordert ist (z.B. `add(0, -10)`).\n- Deine Korrektur-Schleife `while (this.minutes < 0)` in `add(...)` verkürzt effektiv die Zeitspanne (durch `this.hours--`). Das steht im Konflikt mit „Zeitspannen können nur verlängert werden, nicht verkürzt“.\n\n### Suggestion\n- Überlege bei der Konstruktor-Validierung: Welche Eingaben führen aus Sicht von `totalMinutes()` zu einer negativen Zeitspanne? Formuliere genau daran die Bedingung und lass keine Kombinationen durch, die von aussen eine negative Gesamtdauer darstellen.\n- Für `add(...)`: Die geforderte Invariante bezieht sich auf die Änderung am Objekt. Prüfe daher nicht nur die Parameter, sondern ob das neue `totalMinutes()` nach dem Addieren mindestens so gross ist wie vorher.\n- Wenn Verkürzen grundsätzlich verboten ist, brauchst du keine Normalisierung für negative Minuten nach dem Addieren; stattdessen sollte der Fall vorher abgefangen werden (Precondition), sodass die Normalisierung nur noch „Überträge nach oben“ (>=60) behandeln muss.\n\n### Code Style\n- Die Precondition im Konstruktor ist unnötig kompliziert und dadurch fehleranfällig (OR-Kombination mit gemischten Bedingungen). Eine klarere, an der gewünschten Invariante ausgerichtete Bedingung wäre lesbarer.\n- `while`-Schleifen zum Normalisieren sind hier ok, aber für grosse Minutenwerte ineffizient; eine Umrechnung über Division/Modulo wäre deutlich kompakter und leichter zu überprüfen.\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- `findCommonSuperiorWith`: Du überspringst in der inneren Schleife den Fall, dass `b` am Anfang bereits gleich `a` ist (z.B. wenn `other` selbst der gemeinsame Vorgesetzte ist); dadurch liefert z.B. `sara.findCommonSuperiorWith(headOfSales)` nicht wie gefordert `headOfSales`, sondern kann weiter oben landen oder sogar `null`.\n- `findCommonSuperiorWith`: Du vergleichst `a` erst nachdem du `b` bereits zu `b.getBoss()` weitergeschoben hast; dadurch wird der direkte Kandidat `other` nie geprüft.\n- `findCommonSuperiorWith`: Wenn es keinen gemeinsamen Vorgesetzten gibt, gibst du am Ende `a` zurück; nach der Schleife ist `a` aber immer `null`, das passt zwar zufällig zur Anforderung, ist aber logisch nicht sauber (du solltest klar `null` zurückgeben, wenn nichts gefunden wurde).\n\n### Suggestion\n- Überlege dir für `findCommonSuperiorWith`, in welcher Reihenfolge du `b` prüfen und dann erst zum Boss weiterschalten solltest, damit auch `other` selbst (und generell jeder besuchte Knoten) als möglicher gemeinsamer Vorgesetzter zählt.\n- Denke an die Definition “jede Person ist ihre eigene Vorgesetzte”: Das heißt, bei beiden Ketten (`this`-Kette und `other`-Kette) muss der Startknoten selbst in die Suche einbezogen werden, nicht erst dessen Boss.\n- Für den “kein gemeinsamer Vorgesetzter”-Fall: Baue den Rückgabewert so, dass du explizit `null` zurückgibst, wenn du beide Ketten komplett durchsucht hast, ohne Treffer.\n\n### Code Style\n- In `isSuperiorOf` veränderst du den Parameter `other` (du läufst die Referenz hoch). Lesbarer ist es meist, dafür eine lokale Variable zu verwenden, damit der Parameter “als Eingabe” erhalten bleibt.\n- In `findCommonSuperiorWith` ist der innere Ablauf etwas schwer zu lesen, weil du `b` verschiebst und erst danach vergleichst; eine klarere Struktur (prüfen → dann weitergehen) verbessert Verständlichkeit und reduziert solche Logikfehler.\n\n\n# Exercise: smarthome\n\n### Correctness\n- `turnNextRoomBright`: In der `while`-Bedingung greifst du auf `rooms[i]` zu, bevor du sicherstellst, dass `i` noch im gültigen Bereich liegt. Dadurch kann es (je nach Zustand) zu einem Zugriff ausserhalb des Arrays kommen.\n- `findBedrooms`: Laut Aufgabenstellung darf das zurückgegebene Array „auch grösser als nötig sein und null-Einträge enthalten“ und „maximal so gross wie die Gesamtanzahl der Räume“. Deine Lösung gibt immer ein Array zurück, das exakt so gross ist wie die Anzahl Bedrooms, und erfüllt damit diese spezifische Vorgabe nicht (auch wenn es funktional funktioniert).\n\n### Suggestion\n- Bei `turnNextRoomBright`: Stelle die Abbruch-/Grenzprüfung so um, dass du *zuerst* sicherst, dass `i` noch gültig ist, bevor du `rooms[i]` verwendest. Überlege dir auch, wie du den Fall „alle Räume sind schon full bright“ sauber behandelst, ohne am Ende auf ein ungültiges `i` zu kommen.\n- Bei `findBedrooms`: Überlege dir, wie du ein Array mit Länge `rooms.length` bauen könntest und die gefundenen Bedrooms der Reihe nach einträgst (und den Rest leer lässt). Dann erfüllst du die „darf grösser sein + null-Einträge“ Vorgabe direkt.\n\n### Code Style\n- `fullBright`: `lamp.getBrightness() >= 1.0` ist unnötig „breit“ formuliert, da die Helligkeit ohnehin geclamped ist; lesbarer wäre eine direkte Prüfung auf den Sollwert, den du im System verwendest.\n- `findBedrooms`: Das wiederholte Erzeugen und Kopieren von Arrays in der Schleife ist unnötig teuer und macht den Code schwerer zu lesen; hier wäre eine Lösung mit einem einmalig allokierten Array und einem Index deutlich klarer.\n",
"status" : "SUCCESS"
}
}