{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- In `listTasks` wird `(No tasks)` nach einem ersten erfolgreichen `list all`/`list to do` später nie mehr angezeigt, selbst wenn beim nächsten Aufruf eigentlich keine Tasks ausgegeben werden sollten (weil `foundTasks` als Feld nie zurückgesetzt wird).\n- Die Ausgabe eines Tasks entspricht nicht dem im Beispiel gezeigten Format: dort steht z. B. `\" ✓ [0] Waschen\"` bzw. `\" [1] Lernen\"`, bei dir kommt `\"[X] 0: Waschen\"` bzw. `\"[ ] 1: Lernen\"` (anderes Symbol, andere Klammern, andere Position von ID/Delimiter).\n- `listTasks(false)` (“list to do”) soll nur offene Tasks anzeigen und `(No tasks)` ausgeben, wenn **keine offenen Tasks** existieren. Durch das globale `foundTasks` kann diese Bedingung in späteren Aufrufen falsch ausgewertet werden.\n\n### Suggestion\n- Überlege, ob der “es wurde etwas ausgegeben”-Status wirklich als Attribut der App gespeichert sein muss, oder ob er nur innerhalb eines einzelnen `listTasks`-Aufrufs relevant ist. Wenn er nur pro Aufruf zählt, setze ihn passend zu Beginn von `listTasks` zurück bzw. verwende eine lokale Variable.\n- Vergleiche dein `toString()`-Format genau mit der erwarteten Konsolen-Ausgabe: Welche Zeichen stehen vor der ID (Leerzeichen/✓), wie sehen die Klammern aus, und ob nach der ID ein `:` vorkommt oder nicht.\n- Teste gezielt die Sequenz: `add A`, `mark done 0`, `list to do` → hier muss `(No tasks)` kommen. Wenn das bei dir nicht passiert, liegt es sehr wahrscheinlich am “foundTasks”-Handling.\n\n### Code Style\n- `import ch.fhnw.prog1.exercise.todo.Task;` ist in `ToDoApp` redundant, weil `Task` im gleichen Package liegt.\n- `foundTasks` als Feld macht die Methode schwerer nachvollziehbar (Zustand über mehrere Aufrufe). Besser ist ein klarer, lokaler Zustand innerhalb von `listTasks`.\n- In `Task` sind `id` und `description` private, aber es gibt keine Getter; aktuell ist das ok, weil `toString()` alles übernimmt, aber falls du später Format/ID anders brauchst, könnte ein gezielter Zugriff sinnvoll werden.\n\n\n# Exercise: energymeter\n\n### Correctness\n- Die Sichtbarkeit von Konstruktor und Methoden ist bei dir `public`, in der Aufgabenbeschreibung (und typischerweise den Unit-Tests) sind sie ohne `public` vorgesehen (package-private). Falls die Tests explizit die Modifier prüfen oder sich am Beispiel orientieren, kann das zu einem Fehlschlag führen.\n\n### Suggestion\n- Schau dir an, wie die Signaturen im Aufgaben-Tableau angegeben sind (kein `public` erwähnt) und wie die Unit-Tests die Klasse im gleichen Package verwenden könnten. Passe die Access Modifier so an, dass sie den erwarteten Sichtbarkeiten entsprechen.\n\n### Code Style\n- Einheitlichkeit bei Exceptions: einmal mit Message, sonst ohne – entscheide dich konsistent (falls nicht gefordert, eher schlicht halten).\n- Du könntest in `fill`/`consume` jeweils erst den neuen Level berechnen und dann clampen (macht den Code kürzer/leichter lesbar), ohne das Verhalten zu ändern.\n\n\n# Exercise: pong\n\n### Correctness\n- Es fehlen die Klassen `Player` und `Ball` (mit den geforderten Eigenschaften: Position, Balkenlänge/Punktestand bzw. Geschwindigkeit).\n- In `PongGame` werden keine zwei `Player`-Objekte und kein `Ball`-Objekt erstellt/initialisiert (Ball Mitte + zufällige Geschwindigkeit).\n- In der Spielschleife werden weder Spieler noch Ball bewegt (Tastaturabfrage ist da, aber ohne Wirkung).\n- Kollisionen mit oberer/unterer Wand (Ball abprallen, Balken im Feld halten) sind nicht implementiert.\n- Kollisionen Ball–Balken sowie Punktevergabe bei Verlassen links/rechts inkl. Ball-Reset sind nicht implementiert.\n- Die Anzeige zeichnet aktuell nur feste Beispiel-Formen statt die tatsächlichen Objektpositionen (und kein Punktestand).\n- Erweiterung auf mehrere Bälle (Array, periodisches Hinzufügen, Entfernen beim Verlassen) ist nicht umgesetzt.\n\n### Suggestion\n- Starte damit, wirklich zwei `Player`-Instanzen (links/rechts) und einen `Ball` in Variablen anzulegen, damit du im Loop immer denselben Spielzustand weiterverwendest.\n- Gib dem Ball beim Erzeugen eine zufällige `vx/vy` (achte darauf, dass `vx` nicht 0 ist und mal nach links, mal nach rechts zeigen kann) und setze seine Startposition auf die Feldmitte.\n- Ersetze die festen `fillRect`/`fillCircle`-Koordinaten durch Zeichnen basierend auf den gespeicherten `px/py` der Objekte (z.B. über `draw()`-Methoden in den Klassen).\n- Nutze die `isKeyPressed(...)`-Ergebnisse, um `py` der Spieler pro Frame zu ändern (oben/unten) und clamp-e danach `py`, damit die Balken nicht aus dem Spielfeld laufen.\n- Bewege den Ball in jedem Frame mit `px += vx` und `py += vy`; prüfe danach die Kollision mit oben/unten und invertiere bei Kontakt nur `vy`.\n- Für Ball–Balken-Kollisionen brauchst du eine Überschneidungsprüfung (z.B. Rechteck-Rechteck mit Ball-Bounding-Box oder Kreis-Rechteck); beim Treffer kehrst du die x-Richtung um und korrigierst die Position, damit der Ball nicht „im Balken“ stecken bleibt.\n- Wenn der Ball links oder rechts rausgeht: Punkt für den anderen Spieler erhöhen und den Ball neu in der Mitte starten (mit neuer zufälliger Geschwindigkeit).\n- Für mehrere Bälle: verwalte ein Array plus einen Zähler „aktive Bälle“ und halte eine Invariante wie „alle aktiven Bälle stehen kompakt in `balls[0..active-1]`“, damit Entfernen/Hinzufügen ohne Lücken geht; zusätzlich einen Timer/Frame-Counter für „alle 1–2 Sekunden neuer Ball“.\n\n### Code Style\n- Der Code besteht praktisch nur aus der unveränderten Vorlage mit TODO-Kommentaren; sobald du anfängst zu implementieren, lohnt es sich, Logik in Methoden auszulagern (z.B. `move()`, `draw()`, Kollisionscheck), statt alles in der Schleife zu sammeln.\n- Die Variablen `p1Up` und `p2Up` werden aktuell nicht verwendet; entweder direkt in Bewegung umsetzen oder entfernen, um toten Code zu vermeiden.\n\n\n# Exercise: stepstats\n\n### Correctness\n- In deinem `StepTracker` fehlt (im Vergleich zur Vorlage/Beispiel) die Klassen- und `public static void main(String[] args)`-Struktur sowie die nötigen Imports/Package-Deklaration; so wie es jetzt dasteht, wird es in einem normalen Java-Setup nicht kompilieren.\n- Wenn `steps.length == 0`, bleiben `minSteps` bei `Integer.MAX_VALUE` und `maxSteps` bei `Integer.MIN_VALUE`; das führt zu unsinnigen Ausgaben, obwohl das Programm dann „durchläuft“.\n\n### Suggestion\n- Schau dir an, wie die Signatur und Einbettung der `main`-Methode in der Beispiel-Lösung aussieht (Klasse, `public static`, Parameter, Package/Imports) und bring deinen `StepTracker` in dieselbe Form wie in der Code-Vorlage des Projekts.\n- Überlege dir, was bei „Anzahl Tage = 0“ fachlich sinnvoll ist: Soll das überhaupt erlaubt sein? Wenn ja, welche Werte sollen dann für `minSteps/maxSteps/avgSteps` gelten, damit die Ausgabe nicht irreführend ist?\n\n### Code Style\n- Deine Felder sind alle `public`; üblich wäre, sie zu kapseln (z. B. `private` + Getter), auch wenn die Aufgabenstellung den direkten Zugriff demonstriert.\n- Einrückungen/Whitespace im `for`-Block sind teils uneinheitlich (z. B. `successDays++;` vs. `totalSteps += step;`), das erschwert das Lesen.\n- `this.avgSteps` setzt du, die anderen Felder nicht mit `this`; bleib konsistent (entweder immer oder nur bei Namenskonflikt).\n",
"status" : "SUCCESS"
}
}