{
"llm" : {
"feedback" : "# Exercise: parking\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- In `TryStraightFirst` ist die Priorität bei einer Sackgasse nicht wie gefordert: Du prüfst zuerst links und erst dann rechts, verlangt ist aber „falls geradeaus nicht geht, wird links **oder rechts** versucht“ und im nächsten Satz „Sollte das alles nicht gehen, soll die Figur rechtsum kehrt machen“ – zusammen mit der Aufgabenbeschreibung ist bei dieser Teilaufgabe typischerweise „geradeaus, sonst **links, sonst rechts**, sonst umdrehen“ gemeint; bei dir ist es zwar „links dann rechts“, aber du drehst nur um, wenn beides nicht geht – das passt, nur die Formulierung „wird links oder rechts versucht“ wird in der Beispielaufgabe meist als „links zuerst, dann rechts“ oder „rechts zuerst, dann links“ konkretisiert (hier: links **oder** rechts ist ok), allerdings widerspricht deine Reihenfolge der späteren Aussage aus Teil b („links oder rechts versucht“ ist nicht eindeutig), d.h. je nach Tests kann die erwartete feste Reihenfolge „rechts vor links“ sein.\n- `BacktrackingAlgorithm` (ohne Memory) kann in Labyrinthen mit Zyklen/endlosen Schleifen hängen bleiben, weil du keine besuchten Zustände speicherst; damit ist „allgemein … für alle diese Labyrinthe“ nicht erfüllt, falls die letzten Levels Zyklen enthalten (was bei Backtracking-Aufgaben sehr häufig der Fall ist).\n- In `BacktrackingAlgorithmWithMemory` markierst du „besucht“ nur über `(row,col)` und ignorierst die Blickrichtung; dadurch kann ein Feld, das aus einer anderen Richtung betreten wird (und damit andere „pathAhead/Left/Right“-Optionen hat), fälschlich als schon abgearbeitet gelten und du backtrackst zu früh → das kann dazu führen, dass ein existierender Weg zum Ziel nicht gefunden wird.\n- In `BacktrackingAlgorithmWithMemory` wird beim Wiederbesuch (`positions.contains(pos)`) sofort `cleanUp()` gemacht und `return`; je nachdem, woher du kommst, kann dieses „ein Schritt zurück“ nicht zum tatsächlichen Vorgänger im Suchbaum passen (weil du die Vorgängerbeziehung nicht speicherst), was Backtracking in Verzweigungen kaputt machen kann.\n- `LabyrinthApp` enthält nicht mehr die vorgegebenen `MAPS` aus der Aufgabe, sondern komplett andere Maps; dadurch ist nicht überprüfbar, ob deine Algorithmen die geforderten Level (insb. „erste vier Levels“ / „letzte Levels“) schaffen.\n\n### Suggestion\n- Schau bei `TryStraightFirst` nochmal genau nach, welche feste Entscheidungs-Reihenfolge in der Aufgabenbeschreibung impliziert ist (und welche Reihenfolge die Tests vermutlich erwarten). Wenn du dich für eine Reihenfolge entscheidest, halte sie strikt ein.\n- Wenn du „Backtracking für alle Labyrinthe“ willst, überlege dir, wie du Zyklen zuverlässig verhinderst. Nur rekursiv „probieren und zurücklaufen“ reicht in Graphen mit Schleifen meist nicht ohne eine Art Zustands-/Besuchsverwaltung.\n- Denk bei „besuchten Zuständen“ daran, dass ein Zustand im Labyrinth nicht nur die Zelle sein kann, sondern auch die Orientierung (weil „ahead/left/right“ davon abhängt). Überlege, was dein `Position`-Objekt dafür alles speichern müsste, damit du nicht zu früh abschneidest.\n- Reines „bei Wiederbesuch: einmal umdrehen und einen Schritt zurück“ ist nur dann korrektes Backtracking, wenn du garantiert genau entlang der Kante zurückgehst, über die du gekommen bist. Überlege, wie du sicherstellen kannst, dass du wirklich zum richtigen Vorgänger zurückkehrst (z.B. indem du dir Abzweigungen/Entscheidungen merkst statt nur „gesehen/ungesehen“).\n- Setz in `LabyrinthApp` wieder die originalen `MAPS` ein, bevor du bewertest, ob Teil b/c wirklich erfüllt ist; sonst testest du nicht das, was die Aufgabe verlangt.\n\n### Code Style\n- `BacktrackingAlgorithm` und `BacktrackingAlgorithmWithMemory` enthalten sehr viel duplizierte Logik (inkl. identischem `cleanUp`); überlege, ob du gemeinsame Helfermethoden/Abstraktion nutzen willst, um Redundanz zu reduzieren.\n- In `BacktrackingAlgorithm` sind viele `&& !figure.isGoalReached()` direkt nach einem Check, obwohl du am Anfang der Methode schon auf Goal prüfst; das macht die Bedingungen schwerer lesbar.\n- `BacktrackingAlgorithmWithMemory`: `positions` als Instanzfeld ist ok, aber das `clear()` nur bei Zielerreichung ist etwas versteckt; wenn das Objekt wiederverwendet wird, ist das Verhalten nicht sofort offensichtlich (besser klar dokumentieren oder die Lebensdauer der Daten strukturieren).\n- `Position` hat `getX()/getY()`, die nirgends verwendet werden; entweder nutzen oder weglassen, um die Klasse schlanker zu halten.\n- In `LabyrinthApp` hast du die Übungs-Maps ersetzt; das ist für eigene Tests ok, aber als Abgabe wirkt das wie „unrelated code change“ und erschwert die Korrektur.\n\n\n# Exercise: swissmap\n\n### Correctness\n- Die `main`-Methode in `SwissMapApp` hat nicht die übliche/signatur-konforme Form (sie ist weder `public` noch `static` und hat keinen `String[] args`-Parameter). Je nach Setup wird das Programm so nicht als Startklasse erkannt bzw. nicht automatisch gestartet.\n\n### Suggestion\n- Schau dir an, wie Java den Programmeinstieg erwartet: Welche Modifier (`public`, `static`) und welcher Parameter-Typ für `main` nötig sind, damit die IDE/der Runner die Methode als Einstiegspunkt findet?\n\n### Code Style\n- In `Circle` sind die Parameternamen in `contains(double v, double v1)` nichtssagend; sprechendere Namen (z. B. `px`, `py`) machen die Absicht klarer.\n- In `City.draw` erzeugst du zusätzliche lokale Variablen (`rad`, `off`) nur zum Weiterrechnen; das ist ok, aber mit klareren Namen bzw. weniger Zwischenschritten wird es leichter lesbar.\n- `import ch.trick17.gui.component.*;` in `ModeButton` ist recht breit; gezieltere Imports helfen, Abhängigkeiten übersichtlicher zu halten.\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"
}
}