{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- In `listTasks(boolean all)` ist die Filterlogik für `all == true` falsch: Mit deiner Bedingung werden bei `list all` nur erledigte Tasks ausgegeben, aber es sollten **alle** Tasks erscheinen (erledigte und nicht erledigte).\n- Die Fehlermeldung in `markTaskDone(int id)` entspricht nicht der geforderten Ausgabe: Laut Aufgabenstellung soll exakt `\"Task with ID XX not found\"` ausgegeben werden (nicht mit der konkreten Zahl eingesetzt).\n\n### Suggestion\n- Schau dir die If-Bedingung in `listTasks` an und überlege, wie sie aussehen muss, damit bei `all == true` wirklich **jede** Aufgabe durchgelassen wird, und bei `all == false` nur die nicht-erledigten.\n- Verwende in `markTaskDone` genau den String aus dem Kommentar (inkl. `XX`), auch wenn es „komisch“ wirkt, dass dort keine echte ID eingesetzt wird.\n\n### Code Style\n- In `Task` solltest du `@Override` über `toString()` setzen, damit der Compiler prüfen kann, dass du wirklich überschreibst.\n- Die Felder `id`, `description`, `done` sind alle `public`; üblicherweise kapselt man diese (z.B. `private`) und steuert Zugriff über Methoden/Konstruktor (auch wenn es in dieser Aufgabe evtl. noch nicht verlangt ist).\n- In `ToDoApp.java` fehlen in deinem Snippet offensichtliche Imports (z.B. `Scanner`), und `import ch.fhnw.prog1.exercise.todo.Task;` ist redundant, wenn `ToDoApp` im gleichen Package liegt.\n- `Task[] taskList = new Task[0];` und ständiges `Arrays.copyOf` funktioniert, ist aber unnötig teuer; ein fixes Array (wie im Gerüst angedeutet) oder eine `used`-Variable macht das einfacher und performanter.\n\n\n# Exercise: energymeter\n\n### Correctness\n\n\n### Suggestion\n\n\n### Code Style\n- In `consume(...)` prüfst du `intensity` und `duration` gemeinsam in einem `if`; zwei getrennte Checks (wie bei `fill`) machen die Fehlerursache klarer und erleichtern Tests/Debugging.\n- Die Fehlermeldung `\"Input has to be positive\"` ist etwas ungenau, weil du `0` akzeptierst (du meinst eigentlich „nicht negativ“); formuliere sie konsistent oder lass die Message ganz weg, falls die Tests nur auf den Exception-Typ prüfen.\n- Du initialisierst `level` direkt beim Attribut (`double level = 0;`) und zusätzlich implizit im Konstruktor nicht mehr; beides ist okay, aber entscheide dich für eine Variante, um Redundanz zu vermeiden.\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 nennt das Attribut `averageSteps` als `averageSteps`? In der Aufgabenbeschreibung steht `double avgSteps = stats.averageSteps;`, aber im Beispiel und in der Beschreibung wird auch `averageSteps` vs. `avgSteps` uneinheitlich benutzt; stelle sicher, dass deine Attributnamen exakt zu dem passen, was im restlichen Template/Tests erwartet wird (oft ist es `avgSteps` wie im Beispiel).\n- In `StepTracker` fehlt die `package`-Deklaration und eine `public static void main(String[] args)`-Methode wie im vorgegebenen Rahmen; falls die Code-Vorlage das erwartet, wird dein `void main()` so nicht als Programmeinstieg erkannt.\n\n### Suggestion\n- Prüfe in der Aufgabenstellung/Code-Vorlage, wie das Feld für den Durchschnitt genau heissen soll (z. B. `avgSteps` vs. `averageSteps`) und benenne es entsprechend um, damit der Client-Code/Tests darauf zugreifen können.\n- Schau dir die vorgegebene Projektstruktur an: Wenn `StepTracker` in einem Package liegt und ein klassisches `public static void main(String[] args)` verlangt ist, passe Signatur und Package-Kopf so an, dass es mit dem restlichen Projekt konsistent ist.\n\n### Code Style\n- Die Felder sind alle `public` (direkt von aussen beschreibbar). Üblicher ist: Felder kapseln (z. B. `private`) und über Getter nur lesend zugreifbar machen; auch wenn die Aufgabe direkten Zugriff zeigt, solltest du zumindest vermeiden, dass sie von aussen verändert werden können (z. B. `final` wo möglich).\n- Du nutzt häufig `this.` obwohl es nicht nötig ist (z. B. bei `successDays`, `minSteps`, `maxSteps`). Das ist nicht falsch, aber uneinheitlich/unnötig kann es die Lesbarkeit senken.\n",
"status" : "SUCCESS"
}
}