{
"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` drehst du bei `pathToTheLeft()` bzw. `pathToTheRight()` nur, machst aber in diesem Schleifendurchlauf keinen Schritt nach vorne; gefordert ist in diesen Fällen „links oder rechts versuchen“ (also i.d.R. drehen *und* gehen).\n- In `TryStraightFirst` machst du beim „rechtsum kehrt“ nur eine 180°-Drehung, aber keinen Schritt nach vorne; die Beschreibung („Sollte das alles nicht gehen, soll die Figur rechtsum kehrt machen.“) zielt darauf ab, dann auch weiterzulaufen (sonst kann sie in einer Sackgasse eine Extra-Schleifenrunde „stehen bleiben“).\n- In `BacktrackingAlgorithm` prüfst du `figure.pathAhead()` und gehst dann `moveForward()`, aber erst *danach* überprüfst du, ob das neue Feld schon besucht ist; damit läufst du bewusst in bereits besuchte Felder hinein und musst direkt wieder zurück, was Backtracking unnötig aufbläht und je nach Labyrinth zu sehr vielen Moves führen kann.\n- In `BacktrackingAlgorithm` ist das „Zurücksetzen“ der Orientierung nach einem Backtrack nicht in allen drei Richtungsfällen symmetrisch/korrekt: Nach dem Backtrack aus „rechts“ endet die Figur in einer anderen Ausrichtung als sie vor dem Abbiegen hatte (bei „ahead“ stellst du sie wieder her, bei „right“ nicht vollständig). Das kann dazu führen, dass du beim Weiterprobieren aus einem Knoten mit falscher Blickrichtung weiterarbeitest.\n- In `Point.equals` castest du ohne Typprüfung und ohne `null`-Check; wenn `HashSet` intern oder durch andere Aufrufe mit einem anderen Objekttyp vergleicht, kann das zu `ClassCastException` führen.\n\n### Suggestion\n- Schau dir bei `TryStraightFirst` die vier Fälle als „Aktion pro Schleifendurchlauf“ an: Wenn du dich entscheidest, links/rechts zu gehen, welche zwei Operationen gehören dann typischerweise zusammen, damit wirklich ein neuer Zustand erreicht wird?\n- Überlege bei der Sackgasse: Nach der 180°-Drehung stehst du noch im gleichen Feld. Was muss als Nächstes passieren, damit der Algorithmus „aus der Sackgasse herauskommt“ ohne eine zusätzliche Leerlauf-Runde?\n- Fürs Backtracking: Versuch, die „visited“-Entscheidung zu treffen, bevor du einen Schritt machst. Dazu brauchst du eine Möglichkeit, aus aktueller Position + Richtung das nächste Feld (row/col) zu bestimmen, ohne es zu betreten.\n- Prüfe in `BacktrackingAlgorithm` nach jedem rekursiven Versuch (egal ob ahead/right/left), ob du nach dem Zurücklaufen wieder exakt denselben Zustand (Position *und* Richtung) hergestellt hast wie vor dem Versuch. Eine hilfreiche Kontrolle ist: Speichere dir `dir()` vor dem Abbiegen und vergleiche ihn nach dem Backtrack.\n- Für `Point.equals`: Implementiere die üblichen Schutzchecks (`this == o`, `o instanceof Point`, `o != null`), damit `HashSet`-Vergleiche robust sind.\n\n### Code Style\n- In `Point` sollten `row` und `col` typischerweise `private final` sein (immutable Value-Object), damit HashSet-Keys nicht nachträglich veränderbar sind.\n- In `BacktrackingAlgorithm` sind die Backtrack-Sequenzen (zweimal drehen, vorwärts, wieder drehen/ausrichten) sehr ähnlich, aber leicht unterschiedlich; das lädt zu Fehlern ein. Eine kleine Hilfsmethode für „go + recursive + undo“ würde die Lesbarkeit stark erhöhen.\n- In `TryStraightFirst` ist der `else`-Block in einer Zeile gequetscht; konsistente Klammer-/Zeilenformatierung macht das Verhalten leichter überprüfbar.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `SwissMapApp` ist die `main`-Methode nicht als echter Programmeinstieg definiert (Signatur). So wird das Programm je nach Umgebung nicht automatisch gestartet.\n- `ModeButton` wird zwar gezeichnet, aber als „Knopf auf der Karte“ wirkt er wegen der Darstellung vermutlich nicht wie erwartet: Du zeichnest den Text bei exakt derselben Koordinate wie die linke obere Ecke des Rechtecks (`drawString(button, 10, 10)`), wodurch der Text sehr wahrscheinlich im/auf dem Rand klebt bzw. schlecht lesbar ist (funktional ok, aber als Button-Anzeige fraglich).\n- Die Hover-/Interaktionsflächen für `Lake` und `Mountain` sind extrem klein (10×10). Dadurch ist „mit der Maus auf ein Objekt zeigen“ praktisch kaum möglich, obwohl es gefordert ist, dass man bequem auf die Objekte zeigen kann, um die Beschreibung zu sehen.\n\n### Suggestion\n- Schau dir die geforderte `main`-Signatur in Java an (Stichworte: `public static`, Parameter `String[] args`). Wenn deine Methode nicht so heisst/definiert ist, wird sie nicht als Einstiegspunkt erkannt.\n- Platziere den Button-Text so, dass er innerhalb des Rechtecks gut lesbar ist (z. B. mit einem kleinen Innenabstand) und nicht genau auf der Ecke liegt.\n- Überlege dir für `getInteractiveArea` eine Fläche, die zur tatsächlichen sichtbaren Größe des Symbols passt (z. B. abhängig von Bildgröße/Skalierung oder zumindest deutlich größer als 10×10), damit Hover zuverlässig auslöst.\n\n3. Code Style:\n- In `ModeButton` ist das Feld `button` als Zustand gespeichert, obwohl es nur aus `swissmap.isSatelliteMode()` abgeleitet wird; das kann man leicht „on the fly“ bestimmen, statt ein Feld zu mutieren.\n- Benennung: `private SwissMap swissmap;` ist inkonsistent (camelCase wäre `swissMap` wie im Konstruktorparameter). Das reduziert Lesbarkeit.\n- In `Lake`/`Mountain` steht die schließende Klammer von `getInteractiveArea` teilweise in derselben Zeile wie Code (`...10); }`); einheitliche Formatierung hilft beim Lesen.\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"
}
}