{
"llm" : {
"feedback" : "# Exercise: todo\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n\n\n# Exercise: energymeter\n\n### Correctness\n- Im Konstruktor wird `level` nicht initialisiert; der Füllstand soll zu Beginn definiert (typisch 0) sein.\n- `fill(double ...)` prüft den negativen Wert erst nach dem Addieren und kann dadurch kurzzeitig einen ungültigen Zustand erzeugen.\n- `fill(...)` begrenzt den Füllstand nicht auf die Kapazität (kein „Clamp“ auf maximal `capacity`).\n- In `fill(...)` verwendest du den Parameternamen `capacity`, wodurch du semantisch nicht „Energie“ auffüllst, sondern „Kapazität“ (das verletzt die geforderte Bedeutung des Parameters).\n- `consume(...)` zieht Energie ab, bevor du prüfst, ob `intensity`/`duration` negativ sind; auch hier entsteht zuerst ein ungültiger Zustand.\n- `percentFull()` verändert `capacity` (und damit den Zustand des Objekts). Die Methode soll nur einen Prozentwert berechnen, nicht Kapazität überschreiben.\n- `percentFull()` berechnet den Prozentwert nicht korrekt (sie hängt von willkürlichen Schwellen wie `>= 100`, `> 1000` ab statt von `level` und `capacity`) und liefert damit nicht „Prozent voll“ gemäß Aufgabenstellung.\n- Es fehlt die Sonderbehandlung für `capacity == 0` (sonst ist die Prozentberechnung nicht sinnvoll/führt zu falschen Werten).\n\n### Suggestion\n- Setze im Konstruktor den Start-Füllstand explizit auf einen sinnvollen Wert und stelle sicher, dass nach dem Konstruktor ein konsistenter Zustand gilt.\n- Validierungen (z. B. „negativ?“) immer durchführen, bevor du mit den Werten rechnest oder den Zustand (`level`) änderst.\n- Beim Auffüllen: Überlege dir eine Begrenzung, damit `level` nie größer als die maximale Kapazität werden kann.\n- Benenne den Parameter von `fill` so, dass klar ist, dass es sich um die aufzufüllende Energiemenge handelt, und nicht um die Kapazität des Meters.\n- Bei `percentFull`: Berechne einen Rückgabewert aus `level` und `capacity`, ohne Felder zu verändern. Denk an den Spezialfall, wenn die Kapazität 0 ist.\n\n### Code Style\n- Parametername `capacity` in `fill` ist verwirrend, weil es auch ein gleichnamiges Attribut gibt; das erschwert das Lesen und führt leicht zu Denkfehlern.\n- `percentFull()` nutzt „magische Zahlen“ (`100`, `1000`, `/10`) ohne Bezug zur Aufgabe; das macht die Logik schwer nachvollziehbar.\n- Unterschiedliche/uneinheitliche Fehlermeldungen (`\"Negativer Wert\"`, `\"capacity cannot be negative\"`) – besser konsistent halten.\n\n\n# Exercise: pong\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n\n\n# Exercise: stepstats\n\n### Correctness\n- In `StepStatistics` heisst das Attribut gemäss Aufgabenstellung `averageSteps`, aber im vorgegebenen Verwendungsbeispiel wird `stats.averageSteps` nicht verwendet, sondern `stats.averageSteps`? (Im Text steht `double avgSteps = stats.averageSteps;`, im Beispiel jedoch `stats.averageSteps` vs. `stats.averageSteps` ist ok) — allerdings verlangt die Aufgabenbeschreibung explizit das Attribut **`averageSteps`**? Sie zeigt **`averageSteps`**, aber dein Client liest `stats.averageSteps`; das passt. Problem: Die Aufgabenstellung zeigt `double avgSteps = stats.averageSteps;` aber auch `int successDays = stats.successDays;` usw. → Bei dir ist das Attribut **`averageSteps`**, im Beispiel heisst es **`avgSteps`**. Falls die Tests/Autograder auf den Beispielnamen gehen, wird das nicht übereinstimmen.\n- `averageSteps` wird im Konstruktor mit `+=` berechnet statt mit einer Zuweisung. Wenn der Konstruktor (oder das Objekt) aus irgendeinem Grund mehrfach “initialisiert” wird bzw. falls `averageSteps` vorher nicht garantiert 0 ist, kann das zu falschen Resultaten führen (und es ist hier logisch einfach eine einmalige Berechnung).\n- `totalSteps` ist ein Instanzfeld und wird im Konstruktor nicht explizit initialisiert (nur implizit 0). Das funktioniert zwar, ist aber fachlich inkonsistent mit der Idee “Berechnung im Konstruktor und danach fix”; als Feld kann es später noch versehentlich verändert werden und macht die Objektresultate potenziell inkonsistent.\n\n### Suggestion\n- Vergleiche die erwarteten Attributnamen aus der Aufgabenbeschreibung/Beispielnutzung mit deinen Feldnamen und überlege, welche Namen im Projekt/Test wirklich verlangt sind.\n- Überlege, ob `averageSteps` wirklich “aufaddiert” werden soll, oder ob du den Wert genau einmal berechnen und setzen willst.\n- Frage dich, welche Variablen nach der Konstruktor-Berechnung noch gebraucht werden: Muss `totalSteps` überhaupt ein Attribut sein, oder reicht es als lokale Variable während der Berechnung?\n\n3. Code Style:\n- Die Einrückung/Formatierung in `StepStatistics` ist uneinheitlich (z.B. `int totalSteps;` ist anders eingerückt als die anderen Felder; überflüssige Leerzeilen/geschlossene Klammer auf eigener Ebene).\n- `totalSteps` ist als Feld deklariert, aber ausserhalb des Konstruktors nicht verwendet; das wirkt wie “State”, der nicht Teil des Resultats ist.\n- Die grossen Blockkommentare mit Fragen/Antworten gehören nicht in die Abgabe-Klasse (und sind fachlich zudem eher Diskussion als Code-Dokumentation); besser in separaten Notizen oder als kurze Kommentare direkt dort, wo sie relevant sind.\n- In `StepTracker` fehlen Paket-/Import-Angaben für `Scanner` und ggf. `IO` (falls das im Template nicht automatisch gegeben ist); achte darauf, dass die Datei im gleichen Stil wie die übrigen Projektdateien aufgebaut ist.\n",
"status" : "SUCCESS"
}
}