{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- In `markTaskDone(int id)` entspricht die Fehlermeldung nicht der geforderten Ausgabe: verlangt ist genau `\"Task with ID XX not found\"`, du gibst `\"Task with ID \" + id + \" not found\"` aus.\n- In `listTasks(true)` gibst du bei einem leeren Array zwar `(No tasks)` aus, aber wenn später ein “freier Platz” im Array existieren würde (also `null`-Einträge), würdest du `IO.println(task)` auch für `null` ausführen (Ausgabe wäre dann `\"null\"`), was nicht dem gewünschten “nur echte Tasks ausgeben / sonst (No tasks)” entspricht.\n\n### Suggestion\n- Schau dir die Aufgabenbeschreibung zur Fehlermeldung in `markTaskDone` ganz genau an: da steht ein fixer Text. Überlege, ob hier wirklich die konkrete ID in die Ausgabe soll oder ob der String exakt so erwartet wird, wie er im Kommentar steht.\n- Überlege bei `listTasks`, woran du erkennen willst, ob “keine Tasks ausgegeben wurden”. Das ist nicht zwingend dasselbe wie `taskList.length == 0` (z. B. wenn du später mit einem vorinitialisierten Array und freien Slots arbeitest). Eine Zähl-/Flag-Logik (“wurde etwas gedruckt?”) hilft hier.\n\n3. Code Style:\n- `Task`-Felder sind `public`; kapsle sie typischerweise (z. B. `private`) und steuere Zugriff über Methoden/Konstruktor, vor allem weil `done` von außen verändert wird.\n- In `Task` fehlt `@Override` vor `toString()`.\n- `Task[] taskList = new Task[0];` plus `Arrays.copyOf` bei jedem `addTask` ist für eine Übung ok, aber untypisch für ein “Array mit freien Plätzen” wie in der Aufgabenstellung beschrieben; das macht auch spätere Erweiterungen/Fehlersuche schwerer.\n- Unnötiger `null`-Check in `markTaskDone`: durch dein “Array wächst immer genau um 1” wird `taskList[id]` praktisch nie `null`; das kann verwirren, weil es Fälle suggeriert, die in deiner Datenstruktur gar nicht vorkommen.\n\n\n# Exercise: energymeter\n\n### Correctness\n\n\n### Suggestion\n\n\n### Code Style\n- Die Fehlermeldung in `IllegalArgumentException` ist ok, aber achte darauf, dass Unit-Tests manchmal auf den Exception-Typ (nicht die Message) prüfen; eine neutrale Message oder keine Message kann robuster sein.\n- Du nutzt mal `this.` und mal nicht (z. B. bei `capacity` im Konstruktor vs. `level` in Methoden). Entscheide dich für einen konsistenten Stil.\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 der Aufgabenbeschreibung sollen die Resultate über die Attribute `successDays`, `averageSteps`, `minSteps`, `maxSteps` zugreifbar sein; bei dir heisst das Attribut für den Durchschnitt `averageSteps`, im Beispiel/Template wird aber `avgSteps` verwendet. Falls im restlichen Template oder in Tests explizit `avgSteps` erwartet wird, führt das zu Fehlern.\n- Dein `StepTracker` ist nicht wie in der Vorlage als vollständige Java-Klasse mit `public static void main(String[] args)` und Paketdeklaration umgesetzt; wenn die Abgabe/Tests genau diese Struktur erwarten, kompiliert/läuft es so nicht in der vorgesehenen Umgebung.\n\n### Suggestion\n- Prüfe in der vorhandenen Code-Vorlage bzw. in den Tests/der Aufgabenbeschreibung, ob der Attributname für den Durchschnitt exakt vorgegeben ist (z. B. `avgSteps` statt `averageSteps`) und passe ihn ggf. an.\n- Vergleiche deinen `StepTracker` mit der ursprünglichen Projektstruktur: Paketzeile, `public class StepTracker` und eine `public static void main(String[] args)`-Methode werden in typischen Java-Projekten und Autotests oft vorausgesetzt.\n\n### Code Style\n- Die Felder sind alle `public`; üblich wäre, Felder zu kapseln (z. B. `private`) und über Getter zuzugreifen. Falls die Aufgabe aber explizit “über Attribute zugreifen” meint, ist das zumindest erklärbar – kläre das kurz gegen die Konvention.\n- `this.` wird in deinem Konstruktor konsistent genutzt; du könntest es dort weglassen, wo keine Namenskollision besteht, um es etwas ruhiger zu machen.\n",
"status" : "SUCCESS"
}
}