{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- Die geforderte `Task`-Klasse ist nicht implementiert (inkl. Felder wie `id`, `description`, `done` und `toString()`), dadurch können Tasks nicht als Objekte modelliert werden.\n- In `ToDoApp` fehlt das Task-Array, in dem die Tasks gespeichert werden sollen; ohne dieses können `add`, `list` und `mark done` nicht wie verlangt funktionieren.\n- Die drei vorgegebenen Methoden `listTasks(boolean all)`, `addTask(String description)` und `markTaskDone(int id)` sind noch nicht implementiert, damit werden die Kernanforderungen (Tasks hinzufügen/auflisten/als erledigt markieren) nicht erfüllt.\n\n### Suggestion\n- Lege zuerst die Datenstruktur fest: Erstelle ein Array für `Task`-Objekte (mit fixer Größe wie im Grundgerüst angedeutet) und eine Variable, die merkt, wie viele Plätze bereits belegt sind bzw. wo der nächste freie Index ist.\n- Implementiere danach die `Task`-Klasse so, dass `IO.println(task)` genau die gewünschte Darstellung ausgibt; dafür ist insbesondere `toString()` entscheidend (und ggf. muss es den “done”-Zustand berücksichtigen).\n- Für `addTask`: Überlege, wie du den “ersten freien Platz” im Array findest und wie dieser Index gleichzeitig als ID dient; danach dort ein neues `Task`-Objekt ablegen.\n- Für `listTasks`: Iteriere über die gespeicherten Tasks und gib abhängig vom Parameter `all` entweder alle oder nur “nicht erledigte” aus; denk an den Spezialfall, dass nichts ausgegeben wird → dann `(No tasks)` drucken.\n- Für `markTaskDone`: Nutze die ID als Array-Index, aber prüfe zuerst, ob an dieser Stelle überhaupt ein Task existiert; falls nicht, soll die Meldung `\"Task with ID XX not found\"` erscheinen.\n\n### Code Style\n- Aktuell sind viele `// TODO`-Platzhalter übrig; sobald du implementierst, entferne die TODOs und halte die Methoden kurz und fokussiert (jede Methode nur ihre eigene Aufgabe).\n- Achte darauf, durchgängig entweder `IO.print/println` oder `System.out.print/println` zu verwenden (nicht mischen), damit die Ausgabe konsistent bleibt.\n\n\n# Exercise: energymeter\n\n### Correctness\n- Der Konstruktor setzt `level` nicht explizit auf `0`. Falls die Unit-Tests erwarten, dass der Startzustand garantiert initialisiert wird (und nicht nur „zufällig“ durch Default-Werte), kann das zu einem Fehlschlag führen.\n- Sichtbarkeit weicht von der geforderten Signatur ab: In der Aufgabenbeschreibung sind Konstruktor und Methoden ohne `public` angegeben; wenn die Tests package-private Zugriffe erwarten (oder genau diese Signaturen prüfen), kann `public` zu Mismatches führen.\n\n### Suggestion\n- Schau dir an, welchen Startwert der Füllstand unmittelbar nach dem Erzeugen haben soll und setze ihn im Konstruktor bewusst (nicht nur implizit).\n- Vergleiche die in der Aufgabe verlangte Sichtbarkeit (kein Modifier vs. `public`) mit dem, was die Unit-Tests vermutlich aufrufen/prüfen; passe die Modifier so an, dass es zu den Tests passt.\n\n### Code Style\n- Entferne den `// TODO`-Kommentar, wenn du fertig bist, damit keine „unfertig“-Markierung im finalen Code bleibt.\n- Nutze konsistente Parameternamen (z.B. bei `fill`: `energy` statt `fillUp`), damit die Bedeutung überall gleich klar ist.\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 ist vorgesehen, dass man `stats.averageSteps` (nicht `stats.averageSteps`) verwendet; dein Attribut heisst `averageSteps`, was nicht zur geforderten Verwendung passt.\n- In der Aufgabenstellung ist der Client-Code in `StepTracker` im Package `ch.fhnw.prog1.exercise.stepstats` (wie im Beispiel). Deine `StepTracker.java` hat keine `package`-Deklaration und nutzt weiterhin das alte `IO`-Setup/`void main()` aus der Vorlage; damit ist nicht sichergestellt, dass es „wieder gleich funktioniert wie zuvor“ im erwarteten Projekt-/Package-Setup.\n\n### Suggestion\n- Benenne das Attribut so, dass es exakt dem in der Aufgabenbeschreibung gezeigten Zugriff entspricht (achte auf den exakten Namen).\n- Vergleiche deinen `StepTracker` mit der erwarteten Projektstruktur: Ist er im richtigen Package und hat er die richtige `main`-Signatur/Imports, sodass er im gleichen Kontext wie die restlichen Dateien kompiliert und läuft?\n\n### Code Style\n- Du iterierst viermal separat über `steps`; das lässt sich in einer einzigen Schleife zusammenfassen (Zählen, Summe, Min, Max in einem Durchlauf).\n- `steps` und `goal` als Felder zu speichern ist hier nicht zwingend nötig, wenn du sie nur im Konstruktor für die Berechnung brauchst; das macht die Klasse einfacher und reduziert Zustand.\n- `allSteps` ist als `double` ok, aber typischer ist hier erst mit `int totalSteps` zu summieren und erst bei der Division zu casten; das macht die Absicht klarer.\n",
"status" : "SUCCESS"
}
}