{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- In `main()` erstellst du ein **lokales** `Task[] tasks`, wodurch das **Feld** `tasks` der Klasse nicht verwendet wird; dadurch arbeiten `addTask/listTasks/markTaskDone` nicht auf dem Array, das du in `main()` befüllst.\n- `main` hat nicht die übliche Signatur `public static void main(String[] args)`; so wie es jetzt ist, wird das Programm je nach Setup nicht automatisch als Startpunkt erkannt.\n- `markTaskDone(int id)` greift direkt mit `tasks[id]` zu, ohne zu prüfen, ob `id` innerhalb der Array-Grenzen liegt; bei zu grosser/negativer ID kann das Programm abstürzen, statt die geforderte Meldung auszugeben.\n- `addTask(String description)` läuft mit `while (tasks[i] != null)` potentiell über das Ende des Arrays hinaus, wenn das Array voll ist; dann kommt es ebenfalls zu einem Absturz statt definiertem Verhalten.\n- Die Ausgabe eines Tasks entspricht nicht dem Beispiel: Es fehlt das führende Leerzeichen/Einrückung und vor allem wird ein erledigter Task nicht mit einem `✓` markiert.\n\n### Suggestion\n- Schau nach, **welches** `tasks`-Array deine Methoden wirklich verwenden (Feld vs. lokale Variable). Entferne die Schattenvariable oder sorge dafür, dass überall dasselbe Array genutzt wird.\n- Überprüfe die erwartete Einstiegsmethode: Vergleiche deine `main`-Signatur mit dem Standard in Java und mit dem vorhandenen Grundgerüst.\n- Bevor du in `markTaskDone` auf `tasks[id]` zugreifst, baue eine Abfrage ein, die **erst** sicherstellt, dass `id` gültig ist (Bereich prüfen), und gib sonst genau die vorgesehene „not found“-Meldung aus.\n- In `addTask`: Überlege dir eine Bedingung, die die Suche nach einem freien Platz stoppt, **bevor** `i` ausserhalb des Arrays liegt (z. B. wenn kein Platz mehr frei ist).\n- Damit `listTasks` die Ausgabe wie im Beispiel zeigt, sollte die Information „done/undone“ in der Task-Ausgabe (z. B. in `toString`) sichtbar werden und die Formatierung (Einrückung/✓) mit dem Beispiel übereinstimmen.\n\n### Code Style\n- In `listTasks` rufst du `toString()` explizit auf; `System.out.println(tasks[i])` reicht, weil Java automatisch `toString()` verwendet.\n- Du mischst `IO.println`/`IO.print` mit `System.out.println`; bleib möglichst konsequent bei einer Variante (idealerweise der aus dem Grundgerüst).\n- In `ToDoApp` hast du zweimal `Task[] tasks = new Task[10];` (Feld und lokale Variable); das ist verwirrend und führt leicht zu Fehlern durch Shadowing.\n\n\n# Exercise: energymeter\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\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` gibst du bei `\"You made the goal ... times.\"` `stats.goal` aus, gefordert ist hier die Anzahl erfolgreicher Tage (also das Attribut für die Trefferanzahl), nicht das Ziel selbst.\n\n### Suggestion\n- Schau dir an, welches Attribut in `StepStatistics` beim Durchlauf über die Tage hochgezählt wird, wenn `step >= goal` ist, und verwende genau dieses Attribut in der Ausgabe für `\"You made the goal ... times.\"`.\n\n### Code Style\n- Viele Attribute in `StepStatistics` sind `public` und zudem als Eingabedaten (`steps`, `goal`) gespeichert; überleg dir, ob wirklich alles von außen sichtbar sein muss bzw. ob du Eingaben als Felder überhaupt brauchst, wenn du die Resultate im Konstruktor berechnest.\n- `totalSteps`, `steps` und `goal` werden nach der Berechnung im Prinzip nicht mehr für die geforderte Nutzung gebraucht; das sind Kandidaten, die du eher lokal im Konstruktor halten könntest, um die Klasse schlanker zu machen.\n- Benennung: In der Aufgabenbeschreibung heißt das Feld `averageSteps`, im Beispiel `avgSteps`. Einheitliche, zur Aufgabenbeschreibung passende Namen erleichtern die Verwendung im Client-Code.\n",
"status" : "SUCCESS"
}
}