Add AI workspace reviews

decisions/0012-frontend-strategy.md

@@ -0,0 +1,69 @@
+# ADR 0012 — Frontend-Strategie
+
+## Status
+Accepted
+
+## Kurz erklärt
+Die Frontend-Strategie legt fest, wie Benutzer die Anwendung bedienen.
+
+Wichtig ist die Frage:
+
+```text
+Klassische Laravel-Seiten
+oder modernes API-basiertes Frontend?
+```
+
+## Kontext
+Das Architekturreview hat kritisiert, dass „Blade oder später Vue/Nuxt“ eine offene Grundsatzentscheidung ist.
+
+Für API-first darf das Frontend nicht direkt an Datenbanklogik hängen.
+
+## Entscheidung
+V1 verwendet ein Laravel-basiertes Admin-Frontend, aber strikt über interne Service-/API-Schichten.
+
+Es wird kein vollständig getrenntes Nuxt/Vue-SPA in V1 gebaut.
+
+Das Frontend darf nicht direkt fachliche Datenbanklogik umgehen.
+
+## Warum?
+Ein vollständiges SPA erhöht V1-Komplexität:
+
+- separater Build-Prozess
+- separate Auth-Flows
+- mehr Frontend-Architektur
+- mehr Testing-Aufwand
+
+Für V1 ist ein Laravel-nahes Frontend effizienter.
+
+## API-first bleibt bestehen
+API-first bedeutet hier:
+
+- Geschäftslogik liegt in Services/Contracts
+- REST API wird parallel sauber definiert
+- spätere externe Clients bleiben möglich
+- WordPress-Plugin nutzt später ausschließlich API
+
+## Später möglich
+In V2/V3 kann ein SPA-Frontend entstehen, wenn:
+
+- API stabil ist
+- Auth-Scopes klar sind
+- Kundenportal ausgebaut wird
+- Plugin-/App-Ökosystem entsteht
+
+## Konsequenzen
+
+### Positiv
+- schnellerer V1-Start
+- weniger Komplexität
+- gute Laravel-Integration
+
+### Negativ
+- API-first muss diszipliniert umgesetzt werden
+- Gefahr eines klassischen Laravel-Monolithen bleibt
+- klare Architekturregeln nötig
+
+## Verwandte ADRs
+- ADR 0006 — Auth-Strategie
+- ADR 0018 — WordPress-Plugin-Security
+- ADR 0020 — Customer-Portal-Scope