Merge remote-tracking branch 'origin/Projektabschluss'

# Conflicts:
#	project/backend/tests/test_recipe_sucuk.py

Author: EdenBernhard

docs/Projekt-Retrospektive.png

@@ -224,7 +224,7 @@ niedrig
 ___
 ### 3. Nicht-funktionale Anforderungen
 Das Projekt muss zum Ende des 4. Semesters abgegeben werden, genaueres wird noch bekannt gegeben. <br>
-Sollte die Zeit nicht ausreichen, um alle geplanten Features zu implementieren, sollen die Kernfunktionen (Zutaten hinzufügen/entfernen, Rezeptsuche und Rezeptvorschläge) Priorität haben. Das Projekt soll dem schichtenbasierten Architekturstil und dem Liskov Substitution Designprinzip entsprechen. 
+Sollte die Zeit nicht ausreichen, um alle geplanten Features zu implementieren, sollen die Kernfunktionen (Zutaten hinzufügen/entfernen, Rezeptsuche und Rezeptvorschläge) Priorität haben. Das Projekt soll dem schichtenbasierten Architekturstil und dem Single Responsibility Designprinzip entsprechen. 
 #### 3.1 Technische Einschränkungen
 - **TE-1 (Architektur):** Das System muss als Web-Applikation realisiert werden. Eine native Installation auf dem Endgerät des Nutzers ist nicht vorgesehen.
 - **TE-2 (Laufzeitumgebung/Browser):** Die Anwendung muss auf den aktuellsten stabilen Versionen der Browser Google Chrome, Mozilla Firefox und Safari lauffähig sein. Eine Optimierung für veraltete Browser (z.B. Internet Explorer) oder Browser-Versionen erfolgt nicht.

docs/Softwareanforderungsspezifikation (SRS).md

@@ -451,7 +451,7 @@ Die wichtigsten Architekturentscheidungen sind als ADRs (Architecture Decision R
 | ADR02 | Intuitive Nutzbarkeit | Direkte Weiterleitung von Registrierung zum RecipeFinder (ohne erneute Anmeldung) |
 | ADR03 | Verhinderung von Informationsüberladung | 3x3-Matrix für Rezeptanzeige, keine maximale Begrenzung |
 | ADR04 | Architekturstil | Schichtbasierter Architekturstil (Frontend → Backend → Datenbank) |
-| ADR05 | Designprinzipien | Liskov Substitution Principle (LSP) für austauschbare Speicher-Implementierungen |
+| ADR05 | Designprinzipien | Single Responsibility Principle (SRP) für klare Trennung der Verantwortlichkeiten und Funktionalität |
 
 Alle ADRs sind [hier](https://github.com/GalacticCodeGambit/LazyCook/tree/4710a641f177a29e59067edf688781efb3b03a3d/docs/adr) zu finden.
 
@@ -485,7 +485,7 @@ Alle ADRs sind [hier](https://github.com/GalacticCodeGambit/LazyCook/tree/4710a6
 
 | Risiko/Schuld | Beschreibung | Priorität | Maßnahme |
 |---------------|-------------|-----------|----------|
-| SQLite-Skalierbarkeit | SQLite unterstützt keine parallelen Schreibzugriffe; bei hoher Nutzerzahl kann es zu Engpässen kommen | Gering | Mittelfristig Migration auf PostgreSQL oder MySQL möglich dank LSP (ADR05) |
+| SQLite-Skalierbarkeit | SQLite unterstützt keine parallelen Schreibzugriffe; bei hoher Nutzerzahl kann es zu Engpässen kommen | Gering | Mittelfristig Migration auf PostgreSQL oder MySQL möglich dank SRP (ADR05) |
 | Fehlende maximale Rezeptbegrenzung | Bei vielen Rezepten in der Datenbank gibt es keine Begrenzung der Ergebnisanzahl, was zu langen Ladezeiten führen kann (ADR03) | Mittel | Pagination implementieren |
 | Rechtliche Probleme durch Urheberrecht bei Rezepten | Rezepte sind urheberrechtlich geschützt. Rezepte einfach ohen Erlaubnis bereitszustellen könnte zu Rechtlichen Problemen führen | Mittel |  Vorhandene AGBs und Meldebutton, Verlinkung auf Original Rezept in Rezeptansichts zu sehen |
 | TODO-Kommentare im Code | Mehrere offene TODOs: Datenbank-Speicherort, E-Mail-Validierung, Passwortstärke, Error Messages generalisieren | Mittel | Systematisch abarbeiten |
@@ -504,7 +504,7 @@ Alle ADRs sind [hier](https://github.com/GalacticCodeGambit/LazyCook/tree/4710a6
 | SRS | Software Requirements Specification; Softwareanforderungsspezifikation |
 | REST | Representational State Transfer; Architekturstil für Web-APIs |
 | CORS | Cross-Origin Resource Sharing; Mechanismus zum Erlauben von Cross-Origin-Anfragen im Browser |
-| LSP | Liskov Substitution Principle; Designprinzip, das sicherstellt, dass Unterklassen die Basisklasse ersetzen können |
+| SRP | Single Responsibility Principle; Designprinzip, das sicherstellt, dass Verantwortlichkeiten in Klassen getrennt werden |
 | Docker Compose | Tool zur Definition und Verwaltung von Multi-Container-Docker-Anwendungen |
 | FastAPI | Modernes Python-Web-Framework für den Aufbau von APIs |
 | Next.js | React-Framework für serverseitiges Rendering und statische Seitengenerierung |

docs/Softwarearchitekturdokument.md

@@ -15,15 +15,13 @@ Welcher Designprinzipien soll für das Projekt verwendet werden? Um eine einheit
 
 ## Entscheidung
 
-Gewählte Variante: "Liskov Substitution Principle (LSP)", denn damit stellen wir sicher, dass sich alle unsere Speicher-Implementierung gegenüber der Geschäftslogik gleich verhalten. Diese Variante, erlaubt uns es die Datenquelle später auszutauschen, ohne den Code im Service ändern zu müssen
+Gewählte Variante: "Single Responsibility Principle (SRP)", da wir als Architekturentscheideung das Schichtenmodell gewählt haben, passt SRP perfekt dazu. Wir möchten einen klare Trennung der Verantwortlichkeiten und Funktionalitäten, sodass Codeänderungen nicht an mehreren Stellen passieren müssen und Fehler weitreichend das ganze Projekt beeinflussen. Zudem möchten wir ELemente in der Datenpersistenz und dem Frontend einfach bei Bedarf austauschen können.
 
 ## Status
 
 Angenommen
 
 ## Konsequenzen
 
-* Gut, weil die Wartbarkeit erhöht wird. 
-* Gut, weil die Testbarkeit verbessert wird.
-* Schlecht, weil der initiale Entwicklungsaufwand leicht steigt, da wir erst Interfaces definieren müssen, bevor wir die Logik implementieren können.
-* Schlecht, weil wir beim Design der Schnittstellen sehr sorgfältig sein müssen, um sicherzustellen, dass zukünftige Implementierungen (z. B. eine API, die Netzwerkfehler werfen kann) das Prinzip nicht verletzen.
+- Wechsel von LSP auf SRP. Da wir keinen Vererbung haben und auch keine Datenlogik mit Vererbung geplant ist ist LSP als Designprinzip sinnfrei
+- Einbindung von Service-Dateien für klare Trenneung der Aufgabenbereiche

docs/adr/ADR05.md

@@ -4,9 +4,10 @@
 
 sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), "..")))
 
-import services.RecipeSUCUK as recipe_service_module
-from domain.ingredient import Ingredient
-from services.RecipeSUCUK import findRecipes
+import RecipeSucuk
+import Ingredient as IngredientModule
+from Ingredient import Ingredient
+from RecipeSucuk import findRecipes
 
 
 # ── Hilfsfunktionen ────────────────────────────────────────────

project/backend/tests/test_recipe_sucuk.py

@@ -17,7 +17,7 @@ services:
       - PYTHONUNBUFFERED=1
       - GMAIL_USER=${GMAIL_USER}
       - GMAIL_PASSWORD=${GMAIL_PASSWORD}
-      - JWT_SECRET_KEY=${JWT_SECRET_KEY}
+      - JWT_SECRET_KEY=${JWT_SECRET_KEY:-dev-secret-change-me}
       - FRONTEND_URL=${FRONTEND_URL:-http://localhost:8000}
     volumes:
       - ./data:/data

project/compose.yaml

@@ -90,7 +90,7 @@
     margin: 0;
 }
 
-.popup-fields{
+.popup-fields {
     display: flex;
     gap: 10px;
 }