{
"llm" : {
"feedback" : "# Exercise: todo\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n\n\n# Exercise: energymeter\n\n### Correctness\n- `percentFull()` berechnet den Prozentwert nicht korrekt: Du gibst `level / 10` zurück, das hat keinen Bezug zur `capacity` und liefert in den meisten Fällen falsche Ergebnisse.\n- `percentFull()` behandelt den Fall `capacity < 0` stillschweigend mit `return 100`; laut deiner eigenen Konstruktor-Logik kann `capacity` aber gar nicht negativ sein, und die Anforderung ist nur für den Spezialfall `capacity == 0` relevant.\n\n### Suggestion\n- Überlege dir, was „percentFull“ bedeutet: Es soll ein Wert in Prozent sein, also „aktueller Füllstand im Verhältnis zur Kapazität“ mal 100. Prüfe dabei auch, welche Einheit `level` und `capacity` haben und wie daraus ein Prozentwert entsteht.\n- Behandle im Prozentrechnen den Sonderfall, dass die Kapazität genau 0 ist (Division durch 0 vermeiden). Für alle anderen Fälle solltest du den Prozentwert aus dem Verhältnis von `level` zu `capacity` ableiten (statt eines festen Divisors wie 10).\n\n### Code Style\n- Die Attribute und Methoden sind `public`; in solchen Aufgaben werden Felder meist gekapselt (z. B. `private`) und nur über Methoden verändert. Das hilft, unkontrollierte Änderungen von außen zu verhindern.\n- Die Initialisierung `public double capacity = 0; public double level = 0;` ist redundant, weil `double` in Java automatisch mit `0.0` initialisiert wird.\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 ist die Verwendung mit `stats.averageSteps` vorgegeben, in deinem `StepStatistics` heisst das Feld aber `averageSteps` (passt), allerdings steht im Beispiel `avgSteps`; wichtig ist hier: **StepTracker und Aufgaben-API müssen konsistent sein**. Prüfe, ob im restlichen Template/Tests evtl. exakt `averageSteps` oder doch `avgSteps` erwartet wird.\n- Der Client-Code (`StepTracker`) ist nicht so angepasst wie im Beispiel gefordert: Es fehlt die Klassen-/Package-Struktur (`package ...;`, `public class StepTracker`, `public static void main(String[] args)`), und du verwendest weiterhin `IO.println/IO.print`. Falls die Vorlage/Autotests das `System.out...`-Verhalten bzw. eine bestimmte Signatur erwarten, kann das als nicht erfüllt gelten.\n\n### Suggestion\n- Schau in der Aufgabenstellung bzw. in vorhandenen Tests/anderen Klassen nach, **welche Feldnamen exakt erwartet** werden (`averageSteps` vs. `avgSteps`). Richte die Namen danach aus, damit der Zugriff wie gefordert kompilierbar ist.\n- Vergleiche deine `StepTracker`-Datei mit der vorgegebenen Projektstruktur der Übung: **passt Package-Deklaration, Klassenname und main-Signatur**? Falls die Vorlage eine normale Java-Klasse erwartet, bring deinen Code in genau diese Form.\n\n### Code Style\n- `computeStatistics` ist als öffentliche Methode nicht zwingend nötig, wenn laut Aufgabe die Berechnungen “im Konstruktor durchgeführt” werden sollen; als private Hilfsmethode wäre es klarer.\n- Du initialisierst die Objektfelder (`minSteps`, `maxSteps`) mit `0`, obwohl du sie direkt danach berechnest; das kann man weglassen oder passend initialisieren, um Missverständnisse zu vermeiden.\n- In `computeStatistics` verwendest du lokale Variablen mit denselben Namen wie die Felder (`successDays`, `minSteps`, `maxSteps`). Das ist zwar legal, aber leicht verwirrend; entweder `this.` konsequent verwenden oder lokale Variablen anders benennen.\n",
"status" : "SUCCESS"
}
}