{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- `FlatRateCard.cost()` liefert immer 150 CHF; damit wird bei jeder Abrechnung (jedem Aufruf von `calculateRevenueAndReset()`) 150 CHF zum Umsatz addiert, selbst wenn mit der Karte gar nicht geparkt wurde. Das passt nicht zur Idee “fixe Monatskosten”, wenn in eurem System mehrmals abgerechnet werden kann.\n- In `GroupCard` erlaubt der Konstruktor aktuell auch `person == 0` (und sogar negative Werte werden nur teilweise ausgeschlossen, weil du `< 0` prüfst); laut Tabelle ist der Tarif “abhängig von der Anzahl Personen” und “mehr als 20 nicht erlaubt”, implizit ist eine Gruppengrösse von mindestens 1 zu erwarten.\n\n### Suggestion\n- Überlege dir, ob die 150 CHF in deinem System pro Monat/Periode nur einmal verrechnet werden sollen: Was passiert, wenn `calculateRevenueAndReset()` zweimal hintereinander aufgerufen wird? Prüfe, wie du sicherstellen kannst, dass die Pauschale nicht bei jeder Abrechnung erneut anfällt (oder ob du das System so interpretieren willst, dass genau einmal pro “Monat” abgerechnet wird).\n- Überlege, welche Werte für “Anzahl Personen” sinnvoll sind: Wenn 0 Personen keinen Sinn ergibt, passe die Validierung so an, dass nur ein realistischer Bereich akzeptiert wird (und teste explizit die Grenzwerte 1, 5, 6, 10, 11, 20, 21).\n\n### Code Style\n- `FlatRateCard` speichert `totalTime`, nutzt es aber nicht für die Kostenberechnung; wenn die Zeit keinen Zweck hat, lass das Feld weg, sonst nutze es konsistent.\n- In `FlatRateCard` sind `this.`-Qualifizierungen inkonsistent bzw. unnötig (nicht falsch, aber uneinheitlich); entscheide dich für einen einheitlichen Stil.\n- In `GroupCard`/`IndividualCard` fehlen teilweise `@Override`-Annotationen; die Annotationen helfen, Tippfehler bei Interface-Methoden sofort zu erkennen.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- `TryStraightFirst` erfüllt die Anforderung „Sollte das alles nicht gehen, soll die Figur rechtsum kehrt machen“ nicht: Wenn vorne/links/rechts kein Pfad ist, endet dein Schleifendurchlauf ohne Drehung/Bewegung und die Figur bleibt stecken (Endlosschleife).\n- `TryStraightFirst` prüft in jedem Schleifendurchlauf nicht vollständig die geforderte Reihenfolge „geradeaus, sonst links oder rechts, sonst umkehren“: Bei dir wird links/rechts zwar geprüft, aber danach wird nicht konsequent „ein Schritt“ gemacht bzw. der Fall „nach links/rechts drehen und dann weiter“ ist nicht als vollständige Iteration abgedeckt.\n- `BacktrackingAlgorithm` ist leer und implementiert das `NaviAlgorithm`-Interface nicht; damit fehlt der geforderte allgemeine Algorithmus für die letzten Levels.\n\n### Suggestion\n- Überlege dir für `TryStraightFirst`, was genau passieren soll, wenn **vorne, links und rechts** jeweils **kein** Pfad ist: In diesem Fall muss die Figur ihre Richtung so ändern, dass sie wieder zurück kann, sonst hängt sie fest.\n- Prüfe die Logik pro „Schleifendurchlauf“: Ein Durchlauf sollte am Ende immer zu einer Aktion führen (mindestens drehen oder gehen), sodass du garantiert Fortschritt machst oder bewusst zurückgehst.\n- Für `BacktrackingAlgorithm`: Du brauchst eine Strategie, wie du Kreuzungen behandelst und wie du erkennst, dass du in eine Sackgasse gelaufen bist und wieder zurück musst (z.B. indem du Entscheidungen/Abzweigungen „merkst“ und beim Zurückgehen alternative Wege ausprobierst).\n\n### Code Style\n- In `TryStraightFirst` sind verschachtelte `while`-Schleifen etwas schwer zu lesen; eine klare „ein Schritt pro Iteration“-Struktur (mit gut benannten Hilfsmethoden) wäre leichter nachvollziehbar.\n- `BacktrackingAlgorithm` existiert, ist aber komplett leer; entweder implementieren oder (bis zur Implementierung) weglassen, damit keine „leeren Platzhalter“ im Code liegen.\n\n\n# Exercise: swissmap\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n\n\n# Exercise: visualizer\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n",
"status" : "SUCCESS"
}
}