{
"llm" : {
"feedback" : "# Exercise: timespan\n\n### Correctness\n- Die Precondition in `add` prüft nur, ob *die übergebenen Parameter* eine negative Zeitspanne bilden (`hours * 60 + minutes < 0`). Gefordert ist aber, dass eine bestehende Zeitspanne **nie verkürzt werden darf** (`totalMinutes ≥ old(totalMinutes)`). Mit deinem Check kann man die Zeitspanne trotzdem verkürzen (z.B. `add(0, -10)` bei einer bereits positiven Zeitspanne, sofern der Ausdruck nicht negativ wird bzw. je nach Werte).\n- Der Konstruktor übernimmt dieselbe Logik wie `add`, aber es fehlt eine klare Precondition, dass die **initiale** Zeitspanne nicht negativ ist (bezogen auf `totalMinutes ≥ 0`). Mit der aktuellen Implementierung hängt das wieder nur an deinem Parameter-Check, der nicht robust die gewünschte Bedingung ausdrückt.\n- Deine Normalisierung der Minuten (0 ≤ `getMinutes` ≤ 59) ist nicht in allen Fällen garantiert korrekt, weil du die Berechnung von `totalMinutes` in `add` nicht aus dem **gesamten aktuellen Zustand** ableitest (du verwendest `hours` nicht im Zwischentotal, sondern nur `this.minutes`). Dadurch kann das Ergebnis falsch werden, sobald `this.hours` bereits einen Wert hat und du erneut `add` aufrufst.\n\n### Suggestion\n- Überlege bei der Precondition von `add`: Vergleiche nicht nur die Parameter untereinander, sondern die **neue Gesamtdauer** mit der **alten Gesamtdauer**. Eine gute Gedankenhilfe ist: “Welche totalMinutes hätte das Objekt nach dem Addieren, und ist die mindestens so groß wie vorher?”\n- Für den Konstruktor: Formuliere die Bedingung aus Sicht der Invariante “Zeitspanne ist nie negativ” direkt auf Basis der initialen Gesamtdauer (Stunden+Minuten zusammen), statt nur auf einem Teil-Ausdruck.\n- Für die Minuten-Normalisierung: Rechne in `add` zuerst mit einer Größe, die wirklich die **gesamte bisherige Dauer** plus Zuwachs repräsentiert (nicht nur bisherige Minuten), und leite daraus anschließend `hours` und `minutes` ab.\n\n### Code Style\n- Der auskommentierte Block in `add` ist toter Code; entweder entfernen oder durch eine klare, finale Implementierung ersetzen, damit der Code leichter lesbar bleibt.\n- Die Fehlermeldung in der Exception könnte präziser sein (z.B. ob negative Eingaben verboten sind oder ob das Verkürzen verboten ist), damit Client-Code schneller versteht, welche Precondition verletzt wurde.\n\n\n# Exercise: address\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\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- `isSuperiorOf(Employee other)` ist nicht implementiert und liefert aktuell immer `false`, damit verletzt du die Anforderungen (z.B. muss `sara.isSuperiorOf(sara)` `true` sein, und Vorgesetzte in der Kette müssen erkannt werden).\n- `findCommonSuperiorWith(Employee other)` ist nicht implementiert und liefert aktuell immer `null`, damit erfüllt die Methode weder das Finden des ersten gemeinsamen Vorgesetzten noch die geforderten Fälle wie „eine Person ist eigener Vorgesetzter“.\n\n### Suggestion\n- Für `isSuperiorOf`: Starte bei `other` und gehe dann schrittweise über `getBoss()` nach oben, bis du entweder `this` triffst (dann `true`) oder `null` erreichst (dann `false`). Denk daran, den Fall `other == this` direkt oder automatisch in dieser Suche abzudecken.\n- Für `findCommonSuperiorWith`: Überlege dir eine Strategie, wie du alle Vorgesetzten von `this` „merkst“ (z.B. indem du von `this` nach oben gehst) und dann von `other` nach oben läufst, bis du den ersten triffst, der auch in der Kette von `this` vorkommt. Achte darauf, dass „erste“ hier heißt: der, der von `other` aus am nächsten liegt (also der früheste Treffer beim Hochlaufen von `other`).\n- Für den `null`-Fall bei `findCommonSuperiorWith`: Wenn du von `other` bis `null` läufst und nie einen gemeinsamen findest, dann muss `null` zurückkommen.\n\n### Code Style\n- Die `// TODO`-Kommentare sind noch vorhanden, obwohl die Methoden gefordert sind; sobald du implementiert hast, solltest du sie entfernen.\n- Du kannst zur Lesbarkeit in beiden Methoden mit lokalen Variablen arbeiten (z.B. `Employee current = other;`) statt direkt Parameter zu überschreiben.\n\n\n# Exercise: smarthome\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n",
"status" : "SUCCESS"
}
}