{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- In `listTasks(false)` filterst du „nicht erledigt“ über `toString()` + `contains(\"true\")`; das ist logisch nicht zuverlässig und entspricht nicht der Idee „prüfe das `done`-Feld“ (außerdem hängt es davon ab, wie `toString()` formatiert ist).\n- `listTasks(...)` gibt nie `(No tasks)` aus, wenn keine Tasks vorhanden sind bzw. wenn bei `list to do` alle Tasks erledigt sind.\n- `Task.toString()` erfüllt nicht die geforderte Ausgabeform: Es soll beim `IO.println(task);` eine passende Task-Zeile wie im Beispiel erscheinen (mit ID und Done-Markierung), nicht die Debug-Ausgabe `Task{id=..., ...}`.\n- `markTaskDone(int id)` greift immer auf `tasks.get(id)` zu, auch wenn `id` außerhalb der gültigen Grenzen liegt → damit kann es zu einem Fehler kommen, statt die „not found“-Meldung auszugeben.\n- `markTaskDone(int id)` hat eine unnötige Schleife über `i`, markiert aber immer nur `tasks.get(id)`; dadurch kann die „not found“-Meldung mehrfach erscheinen bzw. das Verhalten ist nicht wie beschrieben „ein Task anhand seiner ID“.\n- Die Fehlermeldung weicht von der Spezifikation ab: gefordert ist `\"Task with ID XX not found\"` (mit „ID“ und genau diesem Text/Format).\n- Die Aufgabe verlangt explizit ein **Array** für Tasks in `ToDoApp`; du verwendest ein `ArrayList<Task>`, was die Anforderung verletzt.\n\n### Suggestion\n- Statt den `done`-Status aus dem String zu „parsen“, greife direkt auf das `boolean done` im `Task`-Objekt zu und entscheide damit, ob du ausgibst.\n- Baue in `listTasks` eine Zähl-/Flag-Logik ein: Wenn in der Schleife nichts ausgegeben wurde, gib danach `(No tasks)` aus (gilt sowohl für „list all“ als auch „list to do“).\n- Überlege dir, welche Informationen `toString()` wirklich liefern soll, damit `IO.println(task)` genau das Format aus dem Beispiel erzeugt (inkl. ID und ✓ für erledigt).\n- Prüfe in `markTaskDone` zuerst, ob `id` überhaupt gültig ist (Bereich + ob an dieser Position ein Task existiert), bevor du `get(id)`/Index-Zugriffe machst.\n- Entferne die Schleife in `markTaskDone` und arbeite direkt mit dem einen Task, der zur ID gehört (die ID ist ja genau „Position im Speichercontainer“).\n- Verwende exakt den geforderten Text für „not found“, damit die Ausgabe mit Tests/Erwartungen übereinstimmt.\n- Wenn die Aufgabenstellung „Array“ verlangt: überlege, wie du mit einem `Task[]` und einer „used“-Variable bzw. freiem Index arbeitest, statt dynamisch mit `ArrayList`.\n\n### Code Style\n- `getDone(boolean done)` ist als Name irreführend (es ist ein Setter, kein Getter). Benenne Methoden nach ihrer Funktion (z. B. „set…“), damit der Code lesbar bleibt.\n- In `markTaskDone` ist die `for`-Schleife redundant und erschwert das Verständnis; unnötige Schleifen vermeiden.\n- In `listTasks(false)` ist die temporäre String-Konvertierung (`String.valueOf(...)`) und das `contains(\"true\")` sehr „hacky“ und macht den Code schwer wartbar; arbeite lieber mit Feldern.\n- Du mischst `IO.println` und `System.out.println`; besser konsistent bleiben (im Gerüst wird `IO` verwendet).\n- `ArrayList<Task> tasks = new ArrayList<>();` steht im Snippet ohne Klassenkontext/Einrückung; achte darauf, dass Felder klar als Klassenfelder deklariert sind und Imports (z. B. `ArrayList`) vollständig vorhanden sind.\n\n\n# Exercise: energymeter\n\n### Correctness\n- In `fill(double energy)` prüfst Du `energy < 0` erst **nachdem** Du `level` bereits verändert (und ggf. gecappt) hast; bei negativen Werten wird also der Zustand kurz/teilweise geändert, bevor die Exception fliegt.\n- In `percentFull()` veränderst Du im `else`-Zweig den Zustand (`capacity = level/10;`), obwohl die Methode laut Aufgabe nur einen Prozentwert liefern soll; dadurch kann sich die Kapazität „heimlich“ ändern.\n- `percentFull()` liefert in Fällen, in denen `level > capacity`, pauschal `100` zurück (durch den letzten `return 100;`) statt den Prozentwert basierend auf den aktuellen Werten zu berechnen.\n- Die Signaturen sind als `public` deklariert; wenn die Unit-Tests paket-private Sichtbarkeit erwarten (wie im Aufgaben-/Beispielkontext), kann das zu einem Mismatch führen.\n\n### Suggestion\n- Überlege, in welcher Reihenfolge Du in `fill` validierst vs. den Zustand änderst: Wenn ein Parameter ungültig ist, sollte der Meter-Zustand danach unverändert sein.\n- Schau Dir `percentFull` an: Die Methode sollte keine Felder anpassen, sondern nur aus `level` und `capacity` den Prozentwert ableiten. Überlege auch, was passieren soll, wenn `level` größer als `capacity` ist (und ob das überhaupt möglich sein sollte, wenn `fill` korrekt cappt).\n- Prüfe die Sichtbarkeit (public vs. package-private) gegen das, was die Aufgabe/Tests vorgeben. Wenn nichts von `public` steht, ist es oft beabsichtigt, die Standard-Sichtbarkeit zu nutzen.\n\n### Code Style\n- Entferne den `// TODO`-Kommentar, sobald die Klasse implementiert ist.\n- Einheitliche Klammer-/Einrück-Formatierung würde die Lesbarkeit verbessern (z.B. `if (...) { ... }` konsequent).\n- In `consume` ist die Hilfsvariable `factor` nicht zwingend nötig; ein direkter Ausdruck kann es klarer machen (ohne Logik zu ändern).\n- Die Fehlermeldungen der Exceptions sind uneinheitlich (Deutsch/Englisch, unterschiedlich spezifisch); einheitliche, klare Messages helfen beim Testen/Debuggen.\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 wird die Verwendung mit `stats.averageSteps` gezeigt; in deinem `StepStatistics`-Code heisst das Feld zwar `averageSteps`, aber du berechnest es mit `averageSteps += ...` statt es zu setzen. Das ist funktional zwar oft “zufällig richtig” (weil Startwert 0.0), entspricht aber nicht der beabsichtigten einmaligen Berechnung im Konstruktor.\n- `totalSteps` ist ein Instanzfeld und nicht (wie in der Idee der Aufgabe) eine reine lokale Hilfsvariable im Konstruktor; dadurch hängt das Resultat davon ab, ob dasselbe Objekt jemals “wiederverwendet” würde (und es widerspricht dem Gedanken “Berechnung im Konstruktor, Resultate als Felder”).\n\n### Suggestion\n- Für den Durchschnitt: Überlege, ob du den Wert wirklich “aufsummieren” willst oder ob du ihn nach der Schleife genau einmal auf den korrekten Wert setzen solltest.\n- Für `totalSteps`: Frag dich, ob dieser Wert nach dem Konstruktor überhaupt noch gebraucht wird. Wenn nicht, ist es ein guter Kandidat dafür, nur innerhalb des Konstruktors zu existieren.\n\n### Code Style\n- Uneinheitliche Einrückung/Formatierung in `StepStatistics` (z. B. `int totalSteps;` ist anders eingerückt als die anderen Felder); das erschwert das Lesen.\n- `totalSteps` ist package-private (kein Modifier) und als Feld sichtbar, obwohl es eher ein internes Detail ist; mach dir Gedanken über Sichtbarkeit/Encapsulation (was soll wirklich von aussen zugreifbar sein?).\n- In `StepTracker` fehlt im gezeigten Versuch die Paket-/Klassenstruktur wie im Beispiel (z. B. `public class StepTracker` und `public static void main(String[] args)` bzw. zumindest konsistent zur Vorlage); achte darauf, dass es in deiner Abgabe-Umgebung wirklich kompilierbar ist.\n",
"status" : "SUCCESS"
}
}