{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- Die Aufgabenstellung verlangt in `ToDoApp` ein **Array für Task-Objekte**; du verwendest stattdessen eine `ArrayList<Task>`.\n- `listTasks(...)`: Wenn **keine** Tasks ausgegeben werden (z. B. Liste leer oder bei `list to do` sind alle done), soll `\"(No tasks)\"` ausgegeben werden – das passiert bei dir nicht.\n- `listTasks(false)`: Du filterst „nicht erledigt“ über `toString()`/`contains(\"true\")` statt über das `done`-Feld; dadurch hängt die Funktionalität von der String-Darstellung ab und ist nicht das geforderte Verhalten.\n- `Task.toString()`: Laut Aufgabenbeschreibung soll `IO.println(task);` eine einzelne Task im geforderten Format ausgeben (inkl. ID und ✓/Einrückung wie im Beispiel). Deine `toString()`-Ausgabe ist ein Debug-Objektstring (`Task{id=..., ...}`) und passt nicht zur geforderten Konsolen-Ausgabe.\n- `markTaskDone(int id)`: Du greifst immer mit `tasks.get(id)` zu, ohne zu prüfen, ob `id` überhaupt im gültigen Bereich liegt; das erfüllt nicht die Anforderung „Falls kein Task mit dieser ID gespeichert ist…“ (stattdessen kann es crashen).\n- `markTaskDone(int id)`: Die Schleife `for (int i=0; i<tasks.size(); i++)` ist logisch falsch, weil du `i` nie benutzt und denselben Task mehrfach setzen würdest; außerdem wird die „not found“-Meldung dadurch potenziell mehrfach ausgegeben.\n- Fehlermeldung: Gefordert ist **genau** `\"Task with ID XX not found\"` (XX = die ID). Deine Meldung lautet `\"Task with id ... not found\"` und weicht damit von der Spezifikation ab.\n\n### Suggestion\n- Schau dir nochmals die TODO-Kommentare an: dort steht explizit „Array“ und dass die **ID dem Index im Array** entspricht. Überlege dir, wie du mit einem festen `Task[]` und einem Zähler für „benutzte Plätze“ arbeiten kannst.\n- Für `listTasks(...)`: Führe eine Art „hat etwas ausgegeben“-Flag ein. Wenn nach dem Durchlaufen nichts gedruckt wurde, gib `\"(No tasks)\"` aus.\n- Für `list to do`: Prüfe direkt das Feld `task.done` (oder eine passende Methode/Property), statt den String zu durchsuchen.\n- Für die Ausgabe: Überlege dir, welche Informationen `toString()` liefern muss, damit `println(task)` genau die Zeilenform wie im Beispiel erzeugt (✓, ID in Klammern, Beschreibung).\n- Für `markTaskDone`: Prüfe zuerst, ob die ID überhaupt existiert (Bereich / Feld ist nicht `null`). Nur dann auf `done=true` setzen, sonst genau die geforderte Fehlermeldung einmal ausgeben.\n- Entferne in `markTaskDone` die unnötige Schleife und arbeite direkt mit dem Task an der gegebenen ID.\n\n### Code Style\n- `getDone(boolean done)` ist als Name irreführend: Das wirkt wie ein Getter, ist aber ein Setter. Besser wäre ein klarer Name, der „setzen“ ausdrückt.\n- In `listTasks(false)` nutzt du `String.valueOf(...)` und `contains(\"true\")`; das ist schwer lesbar und koppelt Logik an Textausgabe.\n- In `markTaskDone` ist die `for`-Schleife unübersichtlich, weil `i` unbenutzt bleibt; das deutet stark auf einen Logikfehler hin und erschwert das Verständnis.\n- `System.out.println` und `IO.println` sind gemischt; einheitliche Ausgabe macht den Code konsistenter.\n\n\n# Exercise: energymeter\n\n### Correctness\n- `percentFull()` berechnet den Prozentwert falsch: Du multiplizierst `capacity * level` statt den Füllstand ins Verhältnis zur Kapazität zu setzen.\n- `percentFull()` liefert in vielen Fällen 0 zurück (z. B. wenn `level > capacity` – auch wenn das bei dir durch `fill` verhindert wird – oder wenn die Bedingung nicht greift), obwohl ein sinnvoller Prozentwert erwartet wird.\n- Der Konstruktor setzt `capacity` bereits, bevor du auf negative Werte prüfst; bei einer Exception sollte das Objekt gar nicht in einen “teil-initialisierten” Zustand geraten.\n\n### Suggestion\n- Überlege bei `percentFull()`: “Wie viel Prozent sind `level` von `capacity`?” Formuliere das als Bruch und skaliere dann mit 100; prüfe es mit einfachen Zahlen (z. B. capacity=200, level=50 sollte 25% ergeben).\n- Achte darauf, dass `percentFull()` immer einen passenden Wert zurückgibt (nicht nur in einem `if`-Zweig) – setze den Rückgabewert so, dass er unabhängig von Bedingungen korrekt ist.\n- Im Konstruktor: prüfe erst, ob `capacity` gültig ist, und weise dann `this.capacity` zu.\n\n### Code Style\n- Einheitliche Sichtbarkeit: In der Aufgaben-/Beispiellösung sind Konstruktor/Methoden package-private; du verwendest überall `public`. Das ist nicht zwingend falsch, kann aber von den Unit-Tests/der Vorgabe abweichen – halte dich besser an die vorgegebene Sichtbarkeit.\n- Fehlermeldungen sind uneinheitlich (mal Englisch, mal Deutsch, mal generisch). Besser konsistent formulieren.\n- In `percentFull()` ist die Variable `percent` unnötig umständlich genutzt (Initialisierung, dann bedingtes Setzen, dann Rückgabe). Das lässt sich klarer strukturieren.\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 `StepTracker`, the required entry point `public static void main(String[] args)` is still not implemented; you kept `void main()` like in the template, which may not run as a normal Java program depending on the environment.\n- The exercise text shows usage via `stats.averageSteps`, but in your `StepStatistics` class you named the field `averageSteps` while the expected/one-shot example uses `avgSteps`; if the checker/tests expect the specific attribute names from the task statement/example, this mismatch can cause failures.\n- In `StepStatistics`, you compute `averageSteps` using `averageSteps += ...`; this accumulates instead of assigning. With the current initialization it happens to work once, but it violates the “computed in constructor” idea and becomes wrong as soon as the constructor logic changes (or if `averageSteps` is ever non-zero).\n\n### Suggestion\n- Check how the project expects the program to start (class name + `public static void main(String[] args)`); adapt `StepTracker` to match that required signature and class structure.\n- Re-read the required usage snippet and ensure your attribute names match exactly what the client code (or tests) will access; align your field names to what’s specified.\n- For the average, think about whether you want to *set* the result once after the loop or *add* to a previous value; use the operator that matches “store the computed average”.\n\n### Code Style\n- `totalSteps` is indented oddly and has no access modifier while other fields are `public`; keep consistent indentation and decide intentionally which fields should be `public` vs. not.\n- Prefer assigning `averageSteps` once (and not using `+=`) for readability and to avoid surprising side effects.\n- The large block comment answering the questions is unrelated to the required code changes; consider moving it to a separate document or removing it from the final submission to keep the source focused.\n",
"status" : "SUCCESS"
}
}