Doku: Anforderungen + ADRs (Symfony, htmx, SQLite, HA-Consumer)

Doku/adr/002-frontend-htmx.md

@@ -0,0 +1,22 @@
+# 002 – Frontend: serverseitig + htmx (kein React)
+
+**Status:** accepted
+
+**Kontext.** Die App ist eine CRUD-Liste mit Formularen, Drag-&-Drop-Reihenfolge
+und einem kurzen „Inspiration"-Panel. Kein Multiplayer, kein Offline-First, keine
+komplexe Client-State. Der Betrieb soll so wenig bewegliche Teile wie möglich
+haben (kein `npm install` im Runtime, keine Build-Pipeline).
+
+**Entscheidung.** Serverseitiges Rendern via Symfony (Twig) + **htmx** (~15 kB)
+für fragmentbasierte Updates + **SortableJS** (~20 kB) für Drag-&-Drop.
+Kein Node-Toolchain im Deployment, keine Client-State-Verwaltung.
+
+**Konsequenzen.**
+- + Sehr kleine Client-Oberfläche, kein Build-Step, keine Versionsschlachten.
+- + Business-Logik bleibt in Symfony/PHP – eine einzige Quelle der Wahrheit.
+- + Deploy = ein PHP-Container + statische Dateien (htmx, SortableJS).
+- + Fragmentbasierte Updates sind für Listen/CHECKBOXen fast unsichtbar.
+- − Keine echte Offline-First / kein Optimistic-Update über mehrere Entities –
+      reicht hier (nur Drag-&-Drop-Reihenfolge + Checkbox; beide sind schnell genug).
+- − Bei starkem Wachstum an interaktiver UI kann später ein SPA-Client nötig werden
+      (API ist JSON, bleibt kompatibel).