{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- In `main()` erstellst du ein **lokales** `Task[] tasks` und überschattest damit das **Feld** `Task[] tasks` der Klasse; dadurch arbeiten `addTask/listTasks/markTaskDone` nicht auf demselben Array wie dein `main()`-Code erwartet (du initialisierst effektiv zwei unterschiedliche Arrays).\n- `addTask`: Wenn das Array voll ist (kein `null` mehr), läuft deine `while (tasks[i] != null) { i++; }`-Suche über das Arrayende hinaus → das verletzt die Anforderung, zuverlässig Tasks hinzufügen zu können (sonst Absturz).\n- `markTaskDone`: Bei ungültigen IDs (z. B. `-1` oder `>= tasks.length`) greifst du direkt auf `tasks[id]` zu → kann zu einem Absturz führen, statt wie gefordert die Meldung „Task with ID XX not found“ auszugeben.\n- Ausgabeformat: Laut Beispiel soll bei erledigten Tasks ein Häkchen erscheinen und nicht-erledigte sollen anders aussehen (z. B. eingerückt). Deine `toString()` gibt immer nur `\"[id] description\"` aus und berücksichtigt `done` nicht; damit passt die Ausgabe nicht zur geforderten/gegebenen Konsoleninteraktion.\n\n### Suggestion\n- Achte darauf, dass es **genau ein** Task-Array gibt, auf dem **alle** Methoden arbeiten; prüfe, ob du irgendwo eine Variable mit gleichem Namen neu deklarierst und damit das Feld „versteckst“.\n- Überlege dir bei der Suche nach dem „ersten freien Platz“ im Array, was passieren soll, wenn es **keinen freien Platz** mehr gibt, und baue eine passende Abbruchbedingung ein.\n- Bevor du in `markTaskDone` auf `tasks[id]` zugreifst, prüfe zuerst, ob `id` überhaupt im gültigen Bereich liegt; nur dann darfst du ins Array schauen, sonst musst du die „not found“-Meldung ausgeben.\n- Für die Konsolenausgabe: Schau dir das Beispiel genau an und überlege, welche Infos ein `Task` beim Ausgeben zeigen muss (z. B. `done`-Status). Dann sollte `toString()` genau dieses Format liefern, damit `println(task)` reicht.\n\n### Code Style\n- In `listTasks` rufst du `System.out.println(tasks[i].toString())` auf; idiomatischer ist `System.out.println(tasks[i])`, dann wird automatisch `toString()` verwendet (und du testest gleichzeitig, dass `toString()` korrekt integriert ist).\n- Du mischst `IO.println/IO.print` und `System.out.println`; entscheide dich konsistent für eine Ausgabe-Variante im ganzen Programm.\n- Felder in `Task` sind package-private; üblich wären `private` Felder (und ggf. Methoden), damit die Klasse klar kapselt, was von außen verändert werden darf.\n\n\n# Exercise: energymeter\n\n### Correctness\n- Die Sichtbarkeit von Konstruktor und Methoden ist `public`; in der Aufgabenbeschreibung sind sie ohne `public` angegeben, und die Unit-Tests erwarten ggf. package-private (sonst passen die Signaturen nicht).\n- Die Attribute `capacity` und `level` sind ebenfalls package-private; falls die Tests explizit eine bestimmte Sichtbarkeit verlangen (z. B. default wie im Beispiel), kann das je nach Vorgabe/Tests relevant sein.\n\n### Suggestion\n- Vergleiche deine Methodensignaturen (inkl. `public` vs. keine Angabe) exakt mit dem, was die Tests erwarten; schon ein anderes Access-Modifier kann dazu führen, dass Tests nicht kompilieren oder reflektionsbasiert fehlschlagen.\n- Schau dir besonders an, ob im Übungssetting bewusst keine Modifiers angegeben sind (package-private) und passe deine Deklarationen entsprechend an.\n\n### Code Style\n- Du nutzt mehrfach `if (...) { throw ... } else { ... }`; nach einem `throw` ist das `else` überflüssig und macht den Code unnötig verschachtelt.\n- In `consume` verwendest du eine kompakte Rechnung mit `Math.min(...)`; das ist okay, aber etwas weniger direkt lesbar als eine klare “erst abziehen, dann unten begrenzen”-Struktur (Lesbarkeit vs. Kürze abwägen).\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`, you print `stats.goal` for “You made the goal X times.”, but that line must output the number of successful days (i.e. the computed result), not the goal value.\n\n### Suggestion\n- Check which attribute in `StepStatistics` actually counts how many days met/exceeded the goal, and use that in the first output line instead of the stored `goal`.\n\n### Code Style\n- `StepStatistics` exposes a lot of internal state as `public` (`steps`, `goal`, `totalSteps`, etc.); the task only needs the result values to be accessible—consider reducing what you expose to just the statistics results.\n- Storing `steps` and `goal` as fields isn’t necessary for the requested usage after construction; it increases mutable state without benefit.\n- Naming: the exercise text uses `averageSteps`/`avgSteps` inconsistently; pick one naming scheme and keep it consistent across class and client code.\n",
"status" : "SUCCESS"
}
}