weitere Details in die Roadmap ergänzt

2026-07-10 22:44:49 +02:00
parent 4c9f57db5a
commit c4c690bd78
1 changed files with 327 additions and 15 deletions
@@ -81,6 +81,76 @@ Drag-&-Drop-Editor an sich (den bieten praktisch alle).
 - Preise der Konkurrenz als Orientierung für M4: kostenlose Kontingente liegen meist bei
  20–50 Gästen, Einmalzahlungen bei $8–30, Abo-Modelle bei ~$25/Monat für
  professionelle Nutzer:innen (Event-Planer:innen, nicht Privatpersonen).
 - Referenz-Preistabelle von [automatedseating.com](https://www.automatedseating.com/)
  (Abo-Modell, **nicht** unser Modell — siehe Konzeptentscheidungen unten):
  | Plan | Description | Price | Features |
  |---|---|---:|---|
  | Free | Perfect for trying out | $0/month | 1 event; Up to 40 guests |
  | Starter | Perfect for occasional events | $20/month | 1 event; Max 300 guests; Export PDF and Excel |
  | Pro | Unlimited events and no guest limit | $40/month | Unlimited events; Unlimited guests; Export to PDF and Excel |
  | Enterprise | Tailored solutions | Custom | Everything in Pro; Unlimited guests; Custom features; White-labeled solutions and exports; On-premise option |
 ---
 ## Konzeptentscheidungen (festgelegt 2026-07-10)
 Die folgenden Grundsatzfragen sind entschieden und gelten für alle Meilensteine:
 1. **Zielgruppe für den Launch: Brautpaare (B2C, DACH).** Deutschsprachige UI,
   niedrigschwellige Preise, DSGVO/deutsches Hosting als zentrales Verkaufsargument —
   passt zur identifizierten Marktlücke. B2B (Wedding-Planner, Locations) bleibt eine
   spätere Ausbaustufe (siehe M4), verwässert aber nicht den MVP-Fokus.
 2. **Bezahlmodell: Einmalzahlung pro Event, kein Abo.** Der frühere Widerspruch zur
   Abo-Preistabelle (automatedseating.com-Vorbild, siehe Marktübersicht) ist damit
   aufgelöst: die Tabelle dient nur noch als Konkurrenz-Referenz. Ein Abo passt nicht
   zum B2C-Nutzungsmuster (einmalige Hochzeit, 2–3 Monate Planungszeitraum).
 3. **Payment über einen Merchant of Record** (Paddle oder Lemon Squeezy statt
   Stripe/Mollie direkt): Der MoR tritt als Verkäufer auf und übernimmt EU-VAT/OSS,
   Rechnungsstellung und Steuer-Compliance komplett — bei etwas höheren Gebühren
   (~5 %) minimaler Verwaltungsaufwand, ideal für Solo-Betrieb.
 4. **Free-Tier: bis 40 Gäste, 1 Event**, Export mit Wasserzeichen. (Ersetzt die ältere
   "z.B. 30"-Angabe in M4.)
 5. **Konkrete Preispunkte: bewusst noch offen.** Rahmen: Einmalzahlung im Korridor
   ~15–45 €, ein oder zwei Stufen; Festlegung erst bei M4-Start per Test/Umfrage.
 6. **Hosting: Hetzner** (deutsches Unternehmen, Rechenzentren in DE/FI, AVV vorhanden,
   Cloud-VPS ab ~5 €/Monat). Deckt das Differenzierungsmerkmal "DSGVO-Hosting in
   Deutschland" ab; Single-Server-MVP (M1) und spätere Skalierung möglich.
 7. **Rechtsform: Betrieb über die bestehende MiSta GmbH** (steht im Impressum) — keine
   Neugründung nötig, Haftungsbegrenzung besteht damit ab Tag 1. Falls der Dienst gut
   läuft, kann später eine eigene GmbH aus der Holding ausgegründet werden. Die
   Namensfrage (Produktname/Domain) bleibt als M0-Punkt offen.
 8. **M1 wird zu zweit parallel entwickelt** (Frontend/Backend-Split): eine Person
   Backend-API + CSV-Import, eine Person Tisch-Editor. Verkürzt M1 entsprechend der
   Parallelisierungs-Option aus der Gesamtschätzung.
 9. **App-Store-Präsenz erst nach M4:** Die PWA-Fähigkeit (Manifest, Service Worker,
   Touch, responsive) wird in M1 von Anfang an mitgebaut, der Capacitor-Store-Wrapper
   aber erst nach der Monetarisierung angegangen — spart Store-Gebühren/Review-Aufwand
   in der MVP-Phase; Gäste kommen ohnehin per QR-Link ohne Store-Installation.
 10. **Personen-Vorlieben ("wen mag X nicht / besonders gern") kommen ins Backlog
    (M4+):** Die im Gäste-Screen skizzierten CSV-Vorlieben-Spalten erfordern eine echte
    Kern-Erweiterung der `Strafliste` um Personenpaar-Regeln. Erst Kernprodukt
    validieren; danach als Premium-Feature zum Event-Pass denkbar. Das CSV-Format aus
    M1 sieht die Spalten bereits vor (werden bis dahin ignoriert), damit später kein
    Formatbruch nötig ist.
 11. **Produktname: Zwei-Marken-Strategie** (festgelegt 2026-07-10):
    - **Deutschland (Hauptmarkt B2C): "Sitz & Platz"** — Wortspiel mit den
      Hundekommandos, kurz und merkfähig. Domains `sitzundplatz.de` und
      `sitzundplatz.com` waren zum Prüfzeitpunkt frei.
    - **Europa/international: "Sitzwunder" / "SeatWonder"** — ein Markenkern, je
      Markt übersetzt. Domains `sitzwunder.de`, `sitzwunder.com`, `seatwonder.de`
      und `seatwonder.com` waren zum Prüfzeitpunkt frei. "Sitzwunder" wird bisher
      nur generisch für Sitzmöbel verwendet, ein Markenauftritt existiert nicht.
    - Das englische Pendant des Hundekommando-Witzes ("Sit & Stay") ist als Domain
      vergeben (Pet-Branche) — daher international SeatWonder statt einer
      1:1-Übersetzung von Sitz & Platz.
    - Geprüfte Alternativen (frei, als Fallback notiert): Platzharmonie (.de/.com),
      Sitzfee (.de/.com), Tafelplan (.de — Nähe zu tableplan.io), Tafelwunder,
      Platzzauber, Platzmagie; englisch: theseatinggame.com, seatwhisperer.com,
      seatedeverafter.com, mindtheseat.com, seatingsorted.com. Claim-/Kampagnen-Ideen:
      "Wo sitzt Tante Erna?" (wositzttanteerna.de frei), "nie wieder Reise nach
      Jerusalem". Naheliegende Namen (sitzplan.de, platzplan.de, sitzordnung.de, …)
      sind sämtlich vergeben.
 ---
@@ -94,8 +164,18 @@ Drag-&-Drop-Editor an sich (den bieten praktisch alle).
      später. Kleine, risikoarme Änderung am bestehenden Code.
 - [ ] Determinismus-Option: `random.seed()` als Parameter durchreichen, damit ein Ergebnis
      bei Bedarf reproduzierbar ist (Support-Anfragen: "warum sitzt Tante Erna da?")
- [ ] Rechtsform/Namensfrage klären, Firmengründung falls Umsatz geplant ist (Impressumspflicht
+- [x] Rechtsform geklärt: Betrieb über die bestehende **MiSta GmbH** (Impressum), keine
-      bei einem öffentlichen Dienst mit Personendaten Dritter)
+      Neugründung — Ausgründung aus der Holding erst bei Erfolg (Konzeptentscheidung Nr. 7)
 - [x] Namensfrage geklärt: **"Sitz & Platz"** für Deutschland, **Sitzwunder/SeatWonder**
      für Europa/international (Konzeptentscheidung Nr. 11; Kandidaten-Recherche und
      Domain-Verfügbarkeit geprüft 2026-07-10)
 - [ ] Domains zeitnah registrieren (alle am 2026-07-10 frei — Verfügbarkeit ist
      flüchtig, nicht bis M4 warten): `sitzundplatz.de`, `sitzundplatz.com`,
      `sitzwunder.de`, `sitzwunder.com`, `seatwonder.de`, `seatwonder.com`
 - [ ] Markenregister-Check auf "Sitz & Platz" und "Sitzwunder"/"SeatWonder" in den
      relevanten Klassen (Software/SaaS, Kl. 9/42): DPMA (dpma.de-Registerauskunft)
      für Deutschland, EUIPO (eSearch) für die EU-weite Variante — bevor Geld in
      Branding fließt
 **Aufwand:** ~1 Woche. **Kein Nutzer sieht das noch.**
@@ -122,9 +202,13 @@ Session-basiert, nichts wird dauerhaft gespeichert (schont Datenschutz-Aufwand i
      aus räumlicher Nähe ableiten (statt manueller `Nachbarliste`-Pflege in `tische.ini`)
  - Baut direkt auf `alsSVG()`-Geometrie auf (Radius-Berechnung ist bereits da)
 - [ ] Undo/Redo, "Variante neu berechnen"-Button
- [ ] Hosting: einfacher Single-Server-Betrieb reicht (kein Kubernetes-Overkill für MVP)
+- [ ] Hosting: einfacher Single-Server-Betrieb bei **Hetzner** reicht (Konzeptentscheidung
      Nr. 6 — kein Kubernetes-Overkill für MVP)
 **Aufwand:** ~6–8 Wochen für 1 Entwickler:in (Backend-API + einfaches Frontend).
 Beschlossen ist die Umsetzung **zu zweit parallel** (Konzeptentscheidung Nr. 8):
 Backend-API + CSV-Import und Tisch-Editor laufen gleichzeitig, realistisch also
 ~4–5 Wochen Kalenderzeit.
 **Rechtlich:** Solange keine Daten dauerhaft gespeichert werden (nur Session-Storage,
 TTL von z.B. 24h), ist der DSGVO-Aufwand überschaubar (kein Account = kein
 Personenbezug zum Betreiber über die Sitzung hinaus). Trotzdem: Auftragsverarbeitungsvertrag
@@ -165,8 +249,8 @@ Gäste-CSV wiederverwenden (z.B. für mehrere Event-Teile: Trauung, Feier).
  - Datenexport/-löschung auf Anfrage (Art. 15/17 DSGVO)
  - Verschlüsselung ruhender Daten, falls sensible Zusatzfelder (Allergien,
    Sitzwünsche mit Konfliktpotential) erfasst werden
-  - AVV mit Hosting-Provider (z.B. bei EU-Hosting: Hetzner, IONOS — vermeidet
+  - AVV mit Hosting-Provider — Hetzner ist als Hoster beschlossen (Konzeptentscheidung
-    Standardvertragsklauseln-Diskussion bei US-Anbietern)
+    Nr. 6); EU-Hosting vermeidet die Standardvertragsklauseln-Diskussion bei US-Anbietern
 - [ ] Sharing: Account-Inhaber:in lädt Co-Planer:in (Partner, Wedding-Planner) mit
      eingeschränkten Rechten ein
@@ -177,19 +261,23 @@ ggf. Verarbeitungsverzeichnis) einplanen, bevor das live geht.
 ## Meilenstein 4 — Monetarisierung
-**Empfehlung: Freemium statt Werbung** (Begründung siehe unten).
+**Freemium statt Werbung** (Begründung siehe unten), Details siehe Konzeptentscheidungen
 oben: Einmalzahlung pro Event, Merchant of Record, Free-Grenze 40 Gäste.
- [ ] Kostenlos: bis N Personen (z.B. 30) und 1 gespeichertes Projekt, mit Wasserzeichen
+- [ ] Kostenlos: bis 40 Gäste und 1 Event/gespeichertes Projekt, mit Wasserzeichen
-      auf PDF-Export
+      auf PDF-Export (Konzeptentscheidung Nr. 4)
- [ ] Bezahlt (einmalig pro Event, nicht Abo — passt zum Nutzungsmuster):
+- [ ] Bezahlt (einmalig pro Event, nicht Abo — Konzeptentscheidung Nr. 2; konkrete
      Preisstufen bei M4-Start festlegen, Korridor ~15–45 €, Konzeptentscheidung Nr. 5):
      - Größere Gästezahlen
      - Mehrere Varianten gleichzeitig
      - PDF/Druckvorlagen ohne Wasserzeichen, Tischkarten-Export
      - Priorisierte Berechnung (schneller bei Stoßzeiten)
-  - [ ] Payment-Provider integrieren (Stripe/Mollie — Einmalzahlung reicht, kein
+  - [ ] Payment über Merchant of Record integrieren (Paddle oder Lemon Squeezy,
-        Abo-Billing nötig für MVP dieses Modells)
+        Konzeptentscheidung Nr. 3 — übernimmt EU-VAT/OSS und Rechnungsstellung;
- [ ] Später denkbar: B2B-Linzenz für Hochzeitsplaner:innen/Locations (mehrere Events,
+        Einmalzahlung reicht, kein Abo-Billing nötig)
-      White-Label) — deutlich höherer Wert pro Kunde als Einzelnutzer
+- [ ] Später denkbar: B2B-Lizenz für Hochzeitsplaner:innen/Locations (mehrere Events,
      White-Label, dann ggf. als Abo) — deutlich höherer Wert pro Kunde als Einzelnutzer;
      bewusst *nicht* Teil des Launch-Fokus (Zielgruppe B2C, Konzeptentscheidung Nr. 1)
 **Warum nicht Werbung:**
 Hochzeitsplanung ist eine seltene, emotional hochwertige Nutzung (im Schnitt einmal
@@ -214,8 +302,10 @@ für ein Freemium-Upgrade. Eine kleine, spitze Zielgruppe mit klarem Zahlungsanl
 | M3 Accounts + DSGVO | 4–6 Wochen | ~4,5 Monate |
 | M4 Monetarisierung | 2–3 Wochen | ~5 Monate |
-**Realistischer Fahrplan bis zum ersten zahlenden Kunden: ~5–6 Monate**, wenn M1 und M2
+**Realistischer Fahrplan bis zum ersten zahlenden Kunden: ~5–6 Monate.** Der
-teilweise parallel mit einem zweiten Paar Hände (Frontend/Backend-Split) laufen.
+Frontend/Backend-Split mit einem zweiten Paar Hände ist beschlossen (Konzeptentscheidung
 Nr. 8), M1 verkürzt sich damit auf ~4–5 Wochen Kalenderzeit und M2 kann teilweise
 parallel anlaufen — eher ~4–4,5 Monate bis M4-Abschluss.
 ---
@@ -231,3 +321,225 @@ teilweise parallel mit einem zweiten Paar Hände (Frontend/Backend-Split) laufen
   Differenzierung muss über Web-nativ + DSGVO-Hosting + detailliertere Regeln
   (Gruppentrennungs-Strafalgorithmus, VIP-Fixplätze, Nachbartisch-Bewertung) laufen,
   nicht über "wir haben einen Algorithmus" allein.
 ## Pricing
 **Entschieden: Einmalzahlung pro Event statt Abo** (siehe Konzeptentscheidungen Nr. 2/4/5).
 Die frühere Abo-Tabelle nach dem Vorbild von automatedseating.com steht jetzt als
 Konkurrenz-Referenz in der Marktübersicht und ist **nicht** unser Modell.
 | Plan | Preis | Leistung |
 |---|---:|---|
 | Free | 0 € | 1 Event, bis 40 Gäste, Export mit Wasserzeichen |
 | Event-Pass | einmalig, Korridor ~15–45 € (Stufen offen, Nr. 5) | unbegrenzte Gäste, mehrere Varianten, PDF/Excel/Tischkarten ohne Wasserzeichen, priorisierte Berechnung |
 | B2B (später) | offen, ggf. Abo | Wedding-Planner/Locations: mehrere Events, White-Label — nach dem B2C-Launch |
 ---
 ## Anhang: Namensrecherche (Stand 2026-07-10)
 Vollständige Kandidatenliste zur Namensentscheidung (Konzeptentscheidung Nr. 11).
 Verfügbarkeit geprüft am 2026-07-10 per DNS-NXDOMAIN (.de — DENIC verlangt für
 registrierte Domains funktionierende Nameserver) bzw. Verisign-RDAP (.com) —
 Verfügbarkeit ist flüchtig, vor Registrierung erneut prüfen.
 ### Entschiedene Marken
 | Markt | Marke | Domains (frei am 2026-07-10) |
 |---|---|---|
 | Deutschland (B2C-Hauptmarkt) | **Sitz & Platz** | sitzundplatz.de, sitzundplatz.com |
 | Europa/international | **Sitzwunder / SeatWonder** | sitzwunder.de, sitzwunder.com, seatwonder.de, seatwonder.com |
 ### Deutsche Kandidaten (seriös)
 | Name | .de | .com | Bemerkung |
 |---|---|---|---|
 | Sitzwunder | frei | frei | → gewählt für Europa-Variante; bisher nur generischer Möbel-Begriff, kein Markenauftritt |
 | Platzharmonie | frei | frei | beschreibt das Optimierungsziel, Fallback Nr. 1 |
 | Sitzfee | frei | frei | charmant, evtl. zu verspielt für B2B |
 | Tafelplan | frei | vergeben | seriös, aber Nähe zum Wettbewerber tableplan.io |
 | Tafelwunder | frei | frei | — |
 | Platzzauber | frei | frei | — |
 | Platzmagie | frei | frei | — |
 | Sitzharmonie / Tischharmonie | frei | ungeprüft | — |
 | Sitzmagie | frei | ungeprüft | — |
 | Sitzplatzwunder | frei | ungeprüft | lang |
 | Gutgesetzt | frei | frei | — |
 | Gaesteplatz | frei | frei | Umschreibung wegen Umlaut-Domain |
 | Feintafel | frei | frei | — |
 | Sitzo / Setzo | frei | vergeben | Kunstwort, SaaS-Klang |
 | sitzplan.de, platzplan.de, sitzordnung.de, tischordnung.de, sitzplaner.de, tischplaner.de, platzwunder.de, platzkarte.de, tischlein.de, … | vergeben | — | alle naheliegenden beschreibenden Namen sind weg |
 ### Witzige deutsche Namen (Film-/Kultur-Anspielungen)
 | Name | Anspielung | .de | Bemerkung |
 |---|---|---|---|
 | **Sitz & Platz** | Hundekommandos | frei | → gewählt als deutsche Hauptmarke |
 | Ein Platz an der Tafel | "Ein Platz an der Sonne" | einplatzandertafel.de + platzandertafel.de frei | auch als Claim stark |
 | Wo sitzt Tante Erna? | Insider aus dieser Roadmap (M0, Determinismus-Option) | wositzttanteerna.de frei | Kampagnen-/Claim-Material |
 | Herr der Tische | "Der Herr der Ringe" (Doppelbezug: Trauringe) | herrdertische.de + derherrdertische.de frei | Markenrecht-Risiko (Middle-earth Enterprises) |
 | Game of Tables | Game of Thrones ("Red Wedding") | frei | Markenrecht-Risiko (HBO), nur Blog/Kampagne |
 | Tischpate | "Der Pate" | frei | — |
 | Vier Hochzeiten | "4 Hochzeiten und ein Todesfall" | frei | Kollision mit VOX-Show "4 Hochzeiten und eine Traumreise" |
 | Wer sitzt denn da? | Quizshow-Klang | frei | — |
 | Und ewig sitzt die Tante | "Und ewig grüßt das Murmeltier" | frei | — |
 | Reise nach Jerusalem, Tischgeflüster, Platz da!, Tante Erna, Tafelrunde, Dinner for All, Setzkasten | — | vergeben | die wären gut gewesen |
 ### Englische Kandidaten (.com)
 | Name | Anspielung | Status | Bemerkung |
 |---|---|---|---|
 | **SeatWonder** | Zwilling von Sitzwunder | seatwonder.com + .de + seatingwonder.com frei | → gewählt als internationale Marke |
 | The Seating Game | "The Dating Game" / "The Crying Game" | frei | verspielt-ironisch |
 | Seat Whisperer | "Der Pferdeflüsterer" | frei | — |
 | Seated Ever After | "…happily ever after" | frei | hochzeitlichste Variante |
 | Mind the Seat | "Mind the Gap" | frei | britisch-trocken |
 | Seating Sorted | britisches "Sorted!" | frei | eher B2B-Ton |
 | Seat and Smile | "Meet & Greet"-Nachbarschaft | frei | generisch |
 | Sit & Stay (sitandstay.com, sitstay.com) | Hundekommandos — 1:1-Pendant zu Sitz & Platz | vergeben (Pet-Branche) | Grund für SeatWonder statt Übersetzung |
 | pleasebeseated, haveaseat, takeyourseat, beseated, seatyourself, sithappens, seatandgreet, seatmagic, seatharmony, seatcupid, happilyseated, seatfairy, … | — | vergeben | alle klassischen Usher-Phrasen/Puns sind weg |
 ### Chinesische Pendants (Fun Fact, kein Roadmap-Ziel)
 | Ausdruck | Pinyin | Bedeutung | Eignung |
 |---|---|---|---|
 | 对号入座 | duì hào rù zuò | "Nummer abgleichen, Platz einnehmen" — feststehende Redewendung fürs Finden des zugewiesenen Sitzplatzes; übertragen: "sich angesprochen fühlen" | Das idiomatische Pendant zu "Sitz & Platz" — als Name eines Seating-Tools für Muttersprachler sofort witzig |
 | 坐 / 座 | zuò / zuò | "sitzen" / "Sitzplatz" — perfekte Homophone (座 ist historisch aus 坐 entstanden) | eingebautes Wortspiel für Claims/Wortmarken |
 | 坐下 / 别动 | zuòxià / bié dòng | Hundekommandos "Sitz!" / "Bleib!" | 1:1-Übertragung des Hundekommando-Witzes scheitert: 别动 hat keine Sitzplatz-Bedeutung |
 | 婚宴座位表 | hūnyàn zuòwèi biǎo | "Hochzeitsbankett-Sitzplan" (Fachbegriff) | SEO-/Suchbegriff, kein Markenname |
 Ein China-Launch wäre ein eigenes Vorhaben (ICP-Lizenz, Datenlokalisierung nach PIPL,
 WeChat-Mini-Programm statt PWA) und ist bewusst **nicht** Teil dieser Roadmap.
 ## Wichtige Features
 ### Screen zur Eingabe der Tische
 - Vordefinierte Auswahl von Räumen und fertigen Konfigurationen, Räume mit einer Bühne und Musik daneben, Sitze im Halbkreis, Sitze im Parallelen zur Bühne und aussen im Kreis, Zentrale Bühne mit Tischen drum herum, Eingänge rechts, links oben unten per Klick und zum Verschieben an der Wand, Hufeisen Tafel, normale Tafel etc. -> Auswahl bzw. Verschiebung der Elemente. Verlängerung oder Verkürzung der Tische
 - Die Bühne ist in Ausdehnung und Breite ebenfalls anpassbar. Mehrere Bühnen sind möglich (z.B. Tanzfläche, separat davon die Band)
 - Vordefinierte Auswahl von Tischen, Gerade mit n - Sitzen, einreihig bestuhlt, zweireihig bestuhlt, M-Form (rechteckig zueinander gestellt), Kreissegment mit Radius R und N Sitzen darauf, Elliptische Sitze, Runde Sitze, Rechteckige Sitze
 - Anzahl der Stühle durch Anwahl einer Tischkante definierbar, durch Auswahl des ganzen Tisches, Selektion einer Reihe oder einzelner Stühle und dann löschbar
 - Einzelne Platzierung von Stühlen an einem Tisch siehe auch https://www.perfecttableplan.com/html/tour.html
 #### Technische Umsetzung (beantwortet 2026-07-09)
 Inline-`<svg>` im DOM, nicht `<img src="...svg">` (statisch, nicht klickbar) und nicht
 reines Canvas (pixelbasiert, kein Objekt pro Tisch/Stuhl im DOM). Jeder Tisch/Stuhl/jede
 Bühne ist ein eigenes SVG-Element, das Klick-/Drag-Events, Selektions-Highlighting per
 Style-Attribut bekommt und sich geometrisch an `alsSVG()` aus `Strukturdaten.py` anlehnt
 (Radius-/Platzierungsberechnung ist server-seitig schon vorhanden und dient als
 Ausgangslayout).
 - **State-getrieben rendern:** Ein JS-Array von Tisch-Objekten
  (`{id, typ, x, y, radius, plaetze, rotation, nachbarn}`) ist die Wahrheit; das SVG wird
  aus diesem State erzeugt, nicht umgekehrt aus dem SVG gelesen.
 - **React + SVG als JSX** für die Komponentenstruktur (`<Tisch>`, `<Buehne>`, `<Stuhl>`),
  State-Changes rendern automatisch neu.
 - Für Drag/Resize/Rotate/Selektion **nicht bei Null anfangen**, sondern eine Bibliothek
  nutzen: [Konva](https://konvajs.org/)/`react-konva` (Canvas-basiert, bringt
  Drag/Resize/Rotate fertig mit) oder [svg.js](https://svgjs.dev/)/[interact.js](https://interactjs.io/)
  (bleiben bei echtem SVG als gemeinsamer Quelle für Editor UND Export).
 - **Vordefinierte Layouts/Formen** (Hufeisen, M-Form, Kreissegment, Bühne mittig, …) sind
  reine **Presets, die den State vorbefüllen** — kein Sonderfall im Rendering, nur
  unterschiedliche Ausgangs-Arrays von Tisch-Objekten.
 - **Speichern:** Der State wird als JSON an `POST /sitzung/{id}/tische` geschickt — direkter
  Ersatz für die heutige `tische.ini`; "Nachbarliste" wird aus der räumlichen Nähe der
  Koordinaten abgeleitet statt manuell gepflegt.
 - **Ergebnis-Anzeige nach der GA-Berechnung** ist dagegen bewusst *kein* editierbarer
  Canvas-State mehr, sondern das serverseitig generierte `alsSVG()` — reine
  Anzeige/Export, direkt einbettbar oder als `<img>`. Damit gibt es zwei klar getrennte
  Pfade: einer zum Bearbeiten (Konva/SVG+JS im Frontend), einer zum Anzeigen/Drucken
  (`alsSVG()` server-seitig) — kein Aufwand, den Editor-State rückwärts in druckfähiges
  SVG zu konvertieren.
 **Empfehlung:** React + react-konva für den editierbaren Tisch-Editor, plus
 Weiterverwendung von `alsSVG()` für read-only Ergebnisdarstellung und Druck-Export.
 ### Screen zur Eingabe der Gäste
 - als anonyme Gruppe mit einer Menge von enthaltenen Leuten
 - als benannte Gruppe (Familie Heiner)
 - als Liste von einzelnen Personen die eine Gruppe sind und gemeinsam sitzen wollen
 - als csv Liste mit einer eigenen Spalte mit der Angabe mit Vorliebe der Gäste (wen diese
  Person nicht mag und einer Spalte wen sie besonders mag, Kommasepariert).
  **Backlog M4+ (Konzeptentscheidung Nr. 10):** die Auswertung dieser Spalten erfordert
  eine Kern-Erweiterung der `Strafliste` um Personenpaar-Regeln; das CSV-Format sieht die
  Spalten ab M1 vor, ausgewertet werden sie erst später (Premium-Feature-Kandidat).
 ### VIP Angabe
 - Das Brautpaar und die Brauteltern oder spezielle Gäste haben fixe Sitzplätze die sich nicht ändern sollen
 ### Visualisierung des Ergebnisses
 Raumplan mit Gruppen, Familien, VIP in mehreren Farben
 Mehrere Pläne durch Umschalten im Vergleich (Anzahl der gefundenen Lösungen und Rankings werden angezeigt)
 ### druckbare Ergebnis Listen
 - alphabetische Liste der Gäste und welcher Tisch
 - Alphabetische Liste der Gruppennamen und welche Tisch(e)
 - Liste der Tische und zugehörige Liste der Namen
 - QR Code für das Event und die zugehörige App, welche zu einem Namen den Tisch verrät
 - Tischkarten mit vordefinierten Designbereichen (Bild, Namen, Mittig) und verschiedenen Fonts
 - vordefinierten Designs die automatisch befüllt werden. Font anpassbar
 ### Kuchendiagramme im Dashboard für die Orga
 - Verteilung Männlich/Weiblich, Alter
 - befüllte unbefüllte Tische
 - noch nicht zugewiesene Gäste/ freie Sitze
 ## Technik Fragen (beantwortet 2026-07-09)
 ### Eine Webseite, per App (iOS/Android) UND Browser nutzbar
 Empfehlung: **kein separater App-Code**, sondern die Web-App (aus M1) als **installierbare
 PWA** bauen und zusätzlich per **WebView-Wrapper** (z.B. [Capacitor](https://capacitorjs.com/))
 in den App Store / Play Store bringen. Capacitor packt eine bestehende Web-App 1:1 in eine
 native Hülle — dieselbe Codebasis, kein Flutter/React-Native-Zweitprojekt.
 - Praktische Konsequenz für M1: Frontend von Anfang an PWA-fähig auslegen (Manifest,
  Service Worker, responsives Layout, Touch-Bedienung für den Tisch-Editor testen) —
  nachträglich draufzusetzen ist deutlich teurer als von Beginn an mitzudenken.
 - QR-Code-Feature (siehe "druckbare Ergebnis Listen") passt gut dazu: Link öffnet die PWA
  im Browser oder in der installierten App, kein Store-Zwang für Gäste.
 - Store-Present (native Wrapper-App) macht vor allem für den **Organisator/Wedding-Planner**
  Sinn (regelmäßige Nutzung, Push-Benachrichtigungen bei Änderungen); Gäste kommen i.d.R.
  einmalig über den QR-Link und brauchen keine Store-Installation.
 - Aufwand Capacitor-Wrapper: klein (~1–3 Tage) *sobald* die PWA steht.
  **Beschlossen (Konzeptentscheidung Nr. 9): der Store-Wrapper kommt erst nach M4** —
  bis dahin nur PWA. Achtung bei der späteren Umsetzung: das Gebühren-/In-App-Purchase-
  Modell von Apple/Google kollidiert ggf. mit der Einmalzahlung im Web (Kauf dann nur
  im Browser anbieten, App als reiner Viewer).
 ### Lokale Testinstanz für FastAPI (Hugo-Server-Äquivalent)
 Ja, das geht direkt und ohne Docker:
 ```bash
 uvicorn main:app --reload
 ```
 `--reload` beobachtet Dateiänderungen und lädt automatisch neu, läuft standardmäßig auf
 `localhost:8000`. FastAPI liefert zusätzlich unter `/docs` eine interaktive Swagger-UI, mit
 der sich alle Endpunkte (`POST /sitzung`, `.../tische`, `.../personen`, `.../berechnen`, …)
 ohne eigenes Frontend durchklicken/testen lassen — praktisch für die Backend-Entwicklung in
 M1, bevor der Tisch-Editor existiert.
 **Docker ist für die lokale Testinstanz nicht nötig** — erst relevant, sobald:
 - eine echte DB (Postgres, ab M3) oder weitere Services (Redis/Celery, ab M2 bei
  Hintergrund-Jobs) lokal mit reproduzierbarem Setup laufen sollen,
 - die Produktionsumgebung 1:1 nachgebildet werden soll (Nginx davor, gleiche
  Python-Version wie im Deployment),
 - mehrere Entwickler:innen ein identisches Setup brauchen.
 Aufwand dann: ein `Dockerfile` für FastAPI (~10 Zeilen) + `docker-compose.yml` für
 DB/Redis (~20–30 Zeilen) — überschaubar, aber erst ab M2/M3 sinnvoll, nicht für M1.
 **Empfehlung für M0/M1:** `uvicorn --reload` reicht für die gesamte MVP-Phase (M1, keine
 Accounts/DB). Docker-Compose erst einführen, wenn M2 (Job-Queue) oder M3 (Postgres)
 ansteht.