{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- `listTasks(boolean all)` gibt nicht die einzelnen Tasks aus, sondern in jeder Schleifeniteration die komplette Liste als String; außerdem wird der Parameter `all` nicht berücksichtigt (es müssten bei `all == false` nur nicht-erledigte Tasks erscheinen).\n- `listTasks` behandelt den Fall ohne auszugebende Tasks nicht wie gefordert (`(No tasks)`).\n- In `addTask(String description)` wird die ID nicht korrekt bestimmt: Du startest immer mit `id = 0` und setzt sie nur, wenn du `null` in der Liste findest (in einer `ArrayList` passiert das aber normalerweise nicht automatisch). Dadurch stimmen IDs und Positionen nicht zuverlässig überein.\n- `markTaskDone(int id)` markiert den Task nicht wirklich als erledigt: `task.getDone(true)` verändert kein Feld; es liefert nur einen Wert zurück (und sogar den falschen).\n- `markTaskDone(int id)` prüft nicht korrekt, ob die ID existiert: Du greifst immer `tasks.get(id)` zu (auch wenn `id` außerhalb der Listengröße liegt), und die Schleife über `i` wird dabei gar nicht sinnvoll genutzt.\n- Die Aufgabenstellung verlangt explizit ein Array für Task-Objekte in `ToDoApp`; du verwendest stattdessen `ArrayList`.\n\n### Suggestion\n- In `listTasks`: Iteriere über die Tasks und gib pro Task wirklich `task` aus (nicht `tasks`). Überlege dir eine Bedingung, wann du einen Task ausgibst (abhängig von `all` und dem `done`-Status), und tracke, ob überhaupt etwas ausgegeben wurde, um sonst `(No tasks)` zu drucken.\n- Für die IDs: Entscheide dich für eine klare Regel “ID == Index”. Dann musst du beim Hinzufügen entweder immer am Ende anfügen und die ID entsprechend setzen, oder gezielt einen freien Platz finden (was mit einem Array naheliegender ist als mit einer `ArrayList` ohne `null`-Einträge).\n- Für “mark done”: Statt eines “getters” brauchst du eine echte Änderung am Task-Objekt (z.B. ein Feld setzen oder eine Methode, die `done` auf `true` setzt). Prüfe vor dem Zugriff, ob `id` im gültigen Bereich liegt.\n- Wenn du bei `ArrayList` bleiben willst, müsstest du sehr bewusst mit `null`-Plätzen arbeiten (z.B. über `set(index, ...)`)—aber die Aufgabenstellung erwartet ein Array, daher ist es einfacher, dich an das Gerüst zu halten.\n\n### Code Style\n- In `ToDoApp` hast du `tasks` doppelt deklariert (einmal lokal in `main` und einmal als Feld). Das ist verwirrend und führt leicht dazu, dass Methoden auf eine andere Liste zugreifen als du denkst.\n- In `listTasks` mischst du `IO.println` (im Gerüst) und `System.out.println`. Bleib konsistent mit der vorgesehenen IO-Klasse.\n- `Task.getDone(boolean done)` ist vom Namen/Design her unüblich: Ein Getter sollte keinen Parameter haben und den Objektzustand zurückgeben; so wie es jetzt ist, wirkt es wie ein Fehler und macht den Code schwer verständlich.\n- `Task.toString()` gibt gerade die komplette Objektstruktur aus (`Task{id=..., ...}`), während die Ausgabe im Beispiel eher kompakt ist; das macht die Konsolenausgabe unübersichtlich.\n\n\n# Exercise: energymeter\n\n### Correctness\n- In `fill` prüfst du `energy < 0` erst **nachdem** du den `level` bereits verändert (und ggf. auf `capacity` begrenzt) hast; bei negativen Werten wird der Zustand also kurzzeitig falsch verändert, obwohl du eine Exception werfen willst.\n- `percentFull` gibt bei `capacity == 0` nicht das geforderte Verhalten: aktuell führt `level*100/capacity` zu einer Division durch 0.\n- `percentFull` verändert im `else`-Zweig den Zustand (`capacity = level/10`), obwohl die Methode nur einen Prozentwert liefern soll; ausserdem wird der `else`-Zweig praktisch nie erreicht, weil `level` durch `fill` ohnehin auf `capacity` begrenzt wird.\n- `percentFull`-Logik ist nicht konsistent mit der geforderten Bedeutung „Prozent des Meters“ (bei normalem Fall sollte nicht einfach immer `100` zurückkommen, und die Bedingung `capacity >= level` ist nicht die passende Fallunterscheidung für die Sonderbehandlung).\n- Der Konstruktor soll den `level` initialisieren; bei dir ist `level` zwar als Feld auf `0` gesetzt, aber die Validierung passiert erst nach `this.capacity = capacity` (bei negativer Kapazität ist der Zustand vor dem Throw bereits gesetzt).\n\n### Suggestion\n- Prüfe Eingaben (z. B. negative Werte) immer **bevor** du Felder veränderst; überlege dir die Reihenfolge der Statements in `fill` und im Konstruktor.\n- Überlege für `percentFull`, welche Sonderfälle wirklich existieren: insbesondere „Kapazität ist 0“ (was sollte dann zurückgegeben werden?) und der normale Fall „Kapazität > 0“; darauf kannst du die Fallunterscheidung aufbauen.\n- Eine „Query“-Methode wie `percentFull()` sollte nichts am Objektzustand ändern; entferne jede Zuweisung an `capacity`/`level` aus dieser Methode und berechne nur den Rückgabewert.\n- Wenn du `level` in `fill` sowieso auf `capacity` begrenzt, dann ist `level > capacity` später kein normaler Fall mehr; prüfe, ob dein `else`-Zweig in `percentFull` überhaupt sinnvoll/erreichbar ist.\n\n### Code Style\n- Verwende konsistente Sichtbarkeiten: Im Beispiel sind Konstruktor/Methoden package-private; du hast alles `public`. Kläre, was die Tests erwarten, und wähle dann konsequent (nicht mischen).\n- Fehlermeldungen sind uneinheitlich („capacity cannot be negative“ vs. „Negativer Wert“); entscheide dich für eine Sprache/Terminologie.\n- In `consume` ist `factor` nur ein Zwischenschritt; das kann die Lesbarkeit auch verschlechtern, wenn es keinen Mehrwert bringt.\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 Aufgabenstellung wird die Verwendung mit `stats.averageSteps` gezeigt; dein Feld heisst zwar so, aber im Beispiel heisst es `avgSteps`. Falls die Tests/Client-Code exakt den in der Aufgabe gezeigten Attributnamen erwarten, ist das ok – falls sie den Beispielnamen erwarten, würdest du daran scheitern. Prüfe, welcher Name wirklich gefordert ist (Aufgabe vs. vorhandene Tests/Schablone).\n- `averageSteps` wird im Konstruktor mit `+=` gesetzt. Wenn das Objekt (aus irgendeinem Grund) mehrfach initialisiert/der Wert vorher ungleich 0 wäre, würdest du kumulieren statt korrekt zu setzen. Der Konstruktor soll die Berechnung einmalig “fest” setzen.\n- In `StepTracker` ist die Signatur `void main()` (ohne `public static void main(String[] args)` und ohne Klassenrahmen) nicht die übliche Java-Entry-Point-Signatur. Wenn die Vorlage/Autograder ein echtes Java-Programm erwartet, startet das so nicht.\n\n### Suggestion\n- Schau dir genau an, welche Attributnamen im Aufgabentext unter “soll folgendermassen verwendet werden können” vorgegeben sind, und richte deine Feldnamen daran aus (oder an das, was die Tests erwarten).\n- Statt den Durchschnitt “aufzuaddieren”, setze ihn am Ende des Konstruktors einmal auf den berechneten Wert (denk daran: Konstruktor wird zur Initialisierung verwendet).\n- Vergleiche deine `StepTracker`-Struktur mit der ursprünglichen/provided Vorlage: Wird dort eine Klasse `StepTracker` mit einer `public static void main(String[] args)` erwartet? Falls ja, passe das entsprechend an.\n\n### Code Style\n- Einrückung/Formatierung ist inkonsistent (`totalSteps` ist eingerückt, andere Felder nicht; zusätzliche schliessende Klammer am Ende). Das macht den Code schwer lesbar und kann leicht zu Syntaxfehlern führen.\n- `totalSteps` ist ein Implementationsdetail des Konstruktors; als Feld wirkt es unnötig “global” für die Instanz. Besser als lokale Variable im Konstruktor halten (reduziert Zustand und Fehlerquellen).\n- Der Block-Kommentar mit den Antworten zur Reflexionsfrage gehört wahrscheinlich nicht in die Abgabe-Datei (und die Antworten sind zudem eher knapp/teilweise am Kern vorbei); wenn das nicht verlangt ist, entferne ihn oder schreibe ihn dorthin, wo er gefordert ist (z.B. separater Text/README).\n",
"status" : "SUCCESS"
}
}