{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- Die drei geforderten Methoden `listTasks`, `addTask` und `markTaskDone` sind nicht implementiert (stehen noch auf `// TODO`), damit erfüllt die App die geforderte Funktionalität nicht.\n- Es fehlt die Umsetzung der `Task`-Klasse (inkl. Felder wie `id`, `description`, `done` und einer `toString()`-Methode), die laut Aufgabenstellung für Modellierung und Ausgabe nötig ist.\n- Es fehlt ein `Task[]`-Array in `ToDoApp`, in dem die Tasks gespeichert werden sollen, wie in der Aufgabenbeschreibung verlangt.\n\n### Suggestion\n- Implementiere zuerst die `Task`-Klasse so, dass `IO.println(task)` genau die gewünschte Darstellung ausgeben kann; dafür ist `toString()` entscheidend.\n- Lege in `ToDoApp` ein Array für `Task`-Objekte an (mit fixer Größe) und überlege dir zusätzlich, wie du dir merkst, wie viele Plätze bereits benutzt sind bzw. wo der nächste freie Index ist (die ID soll ja dem Array-Index entsprechen).\n- Für `listTasks(all)`: Iteriere über die gespeicherten Tasks und gib abhängig von `all` entweder alle oder nur die nicht erledigten aus; falls dabei nichts ausgegeben wurde, drucke `(No tasks)`.\n- Für `markTaskDone(id)`: Prüfe, ob an dieser Position überhaupt ein Task existiert (bzw. ob die ID im gültigen Bereich liegt); nur dann auf “done” setzen, sonst die geforderte Meldung ausgeben.\n\n### Code Style\n- Aktuell besteht die Abgabe nur aus dem gegebenen Gerüst mit offenen TODOs; sobald du implementierst, achte darauf, die Zuständigkeiten klar zu trennen (z.B. `Task.toString()` nur für die Darstellung, App-Logik in `ToDoApp`).\n\n\n# Exercise: energymeter\n\n### Correctness\n- Es fehlen die geforderten Attribute `capacity` und `level`.\n- Der Konstruktor `EnergyMeter(double capacity)` ist nicht implementiert.\n- Die Methoden `fill(double)`, `consume(double, double)` und `percentFull()` sind nicht implementiert.\n\n### Suggestion\n- Lege zuerst die zwei Zustandswerte als Felder der Klasse an, damit sich der Füllstand über Methodenaufrufe hinweg merken lässt.\n- Implementiere dann den Konstruktor so, dass er die Kapazität setzt und den Start-Füllstand sinnvoll initialisiert.\n- Baue `fill` und `consume` so, dass sie den `level` verändern und dabei an sinnvollen Grenzen „sättigen“ (nicht über Kapazität, nicht unter 0).\n- Überlege bei `percentFull()`, wie du den Prozentwert berechnest und was passieren soll, wenn die Kapazität 0 ist.\n\n### Code Style\n- Aktuell besteht die Klasse nur aus einem `// TODO`; sobald du implementierst, achte darauf, die Signaturen exakt wie gefordert anzulegen (Namen, Parameter, Rückgabetypen), damit die Unit-Tests sie finden.\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 Aufgabe verlangt, dass die Berechnungen im Konstruktor erfolgen und die Resultate danach über Attribute (z. B. `stats.successDays`, `stats.averageSteps`, …) ausgelesen werden; bei dir werden die Werte jedes Mal über Methoden berechnet und nicht als Attribute bereitgestellt.\n- Bei der Erfolgszählung verwendest du `>` statt `>=`; damit zählt ein Tag mit exakt erreichter Zielzahl nicht als erfolgreich, obwohl es laut Vorgabe zählen soll.\n\n### Suggestion\n- Überlege dir, welche vier Resultate als Felder in der Klasse gespeichert werden sollen, und initialisiere/berechne sie direkt im Konstruktor, sodass der Client sie ohne Methodenaufruf lesen kann.\n- Vergleiche deine Erfolgsbedingung mit der ursprünglichen prozeduralen Version bzw. der Aufgabenbeschreibung („goal erreicht“): prüfe, ob Gleichheit mitgezählt werden muss.\n\n### Code Style\n- Die auskommentierte alte `computeStatistics`-Methode ist toter Code und sollte entfernt werden, sobald du die OO-Version fertig hast.\n- Tippfehler/Benennung: `succesDays()` (ein „s“ zu wenig) ist leicht verwirrend; konsistente, korrekt geschriebene Namen verbessern Lesbarkeit.\n- In `minSteps()`/`maxSteps()` sind magische Startwerte (`99999999`, `0`) unsauber; nutze dafür die passenden Konstanten aus `Integer`, dann ist der Code robuster und selbsterklärender.\n",
"status" : "SUCCESS"
}
}