{
"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- Der Konstruktor setzt `level` nicht initial auf 0; dadurch ist der Startzustand nicht eindeutig festgelegt.\n- In `fill` wird bei negativer Energie erst nach einer möglichen Änderung von `level` geprüft (und sogar nur, wenn `level < capacity`), d. h. negative Werte werden nicht in jedem Fall korrekt abgefangen.\n- `fill` macht gar nichts, wenn `level` bereits `>= capacity` ist; die Anforderung ist aber, dass negative Eingaben trotzdem erkannt werden (und grundsätzlich sollte das Verhalten unabhängig vom aktuellen Füllstand korrekt sein).\n- `consume` verändert `capacity` (`capacity = level;`), obwohl die Kapazität ein fixer Wert des Meters bleiben muss.\n- `consume` berechnet den neuen Stand ausgehend von `capacity` statt vom aktuellen `level`; dadurch stimmt der Verbrauch nicht, wenn vorher schon teilweise gefüllt/geleert wurde.\n- `consume` prüft negative Werte für `intensivity` und `dauer` nicht wie gefordert und wirft stattdessen bei `capacity == 0` eine Exception (das ist nicht Teil der Spezifikation).\n- `consume` begrenzt den `level` nicht nach unten auf 0.\n- `percentFull` ist nicht implementiert und liefert immer `0.0`.\n\n### Suggestion\n- Setze im Konstruktor den Anfangsfüllstand explizit auf einen definierten Wert und überlege, was bei negativer Kapazität passieren soll, bevor Felder gesetzt werden.\n- Prüfe in `fill` die Gültigkeit des Parameters unabhängig vom aktuellen Zustand ganz am Anfang der Methode.\n- Überlege in `fill`, wie du nach dem Addieren von Energie sicherstellst, dass `level` nie größer als `capacity` wird.\n- Behandle `capacity` als unveränderlich im Verhalten: in `consume` sollte nur der aktuelle Füllstand sinken, nicht die Kapazität.\n- Rechne beim Verbrauch vom aktuellen `level` aus und nicht von `capacity`; stelle danach sicher, dass der Füllstand nicht negativ werden kann.\n- Ergänze in `consume` Parameterprüfungen für negative Intensität/Dauer analog zu `fill`.\n- Implementiere `percentFull` anhand von `level` und `capacity` und denke an den Sonderfall, wenn die Kapazität 0 ist (was soll dann zurückkommen?).\n\n### Code Style\n- Vermeide unnötige `return;` am Ende von `void`-Methoden.\n- Entferne auskommentierte/irrelevante Kommentarreste im Code (z. B. `//void fillBeyondCapacity()`), das erschwert das Lesen.\n- Einheitliche und korrekte Benennungen helfen: z. B. Tippfehler wie `energi`/`intensivity` und gemischte Sprachen machen den Code schwerer wartbar.\n- In `consume` ist die `if (capacity <= 100 ... )`-Verzweigung redundant (beide Zweige machen praktisch dasselbe); das kann vereinfacht werden.\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- Die geforderte Verwendung sieht die Attribute `averageSteps`, `minSteps`, `maxSteps`, `successDays` ohne `public`-Zugriff vor (wie im Beispiel: paket-private). Mit `public` erfüllst du zwar den Zugriff, aber es weicht von der intendierten Kapselung/Verwendung ab.\n- Im Aufgabenstatement wird `double avgSteps = stats.averageSteps;` gezeigt, aber in der vorgegebenen Nutzung steht `stats.averageSteps` vs. in der Aufgabenbeschreibung oben `stats.averageSteps` (ok) – allerdings heissen die Attribute in der Aufgabenbeschreibung konkret `averageSteps`, `minSteps`, `maxSteps`, `successDays`. Falls in der Vorlage/Tests andere Namen erwartet werden (z.B. `avgSteps` wie im Beispiel), könnten automatische Tests bei dir fehlschlagen.\n\n### Suggestion\n- Schau in die Aufgabenbeschreibung/Tests bzw. in die gewünschte Beispielverwendung: Stimmen die **Attributnamen** exakt mit dem überein, was von aussen verwendet wird? Wenn dort z.B. `avgSteps` erwartet wird, solltest du dein Feld entsprechend benennen (oder umgekehrt die Client-Ausgabe anpassen).\n- Überlege, ob die Attribute wirklich `public` sein müssen, oder ob es reicht, sie auf Paket-Sichtbarkeit zu lassen (kein `public` hinschreiben), damit sie genauso wie im Beispiel aus `StepTracker` zugreifbar sind, aber nicht “zu offen” werden.\n\n### Code Style\n- In beiden Dateien ist sehr viel auskommentierter “Altcode” drin. Das macht die Abgabe unübersichtlich; besser entfernen oder in Git-History belassen.\n- In `StepTracker` ist `import ch.fhnw.prog1.exercise.stepstats.StepStatistics;` redundant, weil die Klasse im selben Package ist.\n- Die Mischung aus `IO.print/println` und `Scanner` ist ok, aber achte darauf, dass `IO` wirklich aus der Vorlage kommt und korrekt importiert/auffindbar ist (sonst ist der Code nicht standalone compilierbar).\n",
"status" : "SUCCESS"
}
}