PRD - MultiApps

1. Ziel und Zweck

MultiApps ist eine zentrale App-Sammlung unter einer gemeinsamen Domain und Infrastruktur. Ziel ist, mehrere Web-Anwendungen in einem Monorepo zu betreiben, gemeinsam zu verwalten und ueber eine dynamische Landingpage bereitzustellen. Die Plattform soll modular wachsen und Funktionen wie Auth, Billing, i18n und App-Start zentral steuern.

2. Produktumfang (Scope)

• Eine zentrale Landingpage (Svelte) als Einstiegspunkt.
• Mehrere Apps unter /apps/<slug> mit gemeinsamer Backend-API.
• Gemeinsame Datenbank (MongoDB) fuer Benutzer, Apps, Uebersetzungen, Highscores und Abos.
• Einheitliche Zugriffslogik (Free/Paid) fuer alle Apps.

Ausserhalb des Scopes:

• Separate App-Backends ohne zentrale Steuerung.
• Client-seitige Kernlogik in Svelte-Views (verboten).

3. Architektur

3.1 Monorepo Struktur

• /apps: einzelne Frontend-Apps.
• /backend: zentraler Express-Server (API, Auth, App-Start, Datenzugriff).
• /shared: gemeinsame Utilities (z. B. i18n, Access-Label).

3.2 Zentraler Server

• Backend ist Einstiegspunkt fuer API und App-Start.
• User-, App- und Zugriffslogik laeuft serverseitig.
• Apps werden unter /apps/<slug> ausgeliefert oder eingebettet.

3.3 Frontend

• Eine Svelte-Landing (frontend-svelte) als zentrale UI.
• Svelte-Views sind rein praesentational, keine Logik/Validierung im Client.
• Keine SvelteKit-Apps und kein TypeScript in den Apps.

3.4 Konfiguration

• Zentrale Backend-Konfiguration in backend/config/config.js oder backend/config/config.json.
• Pro App konfigurierbar (z. B. Feature-Flags, Limits, Pricing).

4. Datenhaltung (DB)

Alle Apps nutzen eine gemeinsame MongoDB:

• users: Login, Profil, Abo-Status, App-Zugaenge.
• users.fingerprint: Hash aus unveraenderlichen Browsermerkmalen + User-Email + Registrierdatum.
• apps: Metadaten, Status, Flags (running/translated/isSvelte).
• translations: Uebersetzungen (nur DB, keine Uebersetzungsordner im Repo).
• highscores: Spiele-Highscores (Top-Listen in der DB).
• billing/subscriptions: Free- und Paid-Tier Konditionen/Laufzeiten pro App.

5. Monetarisierung

• Free-Tier und Paid-Tier existieren fuer jede App.
• Konditionen und Laufzeiten werden pro App in der DB gespeichert.
• Backend steuert Zugriff, Ablauf und Anzeige von Tier-Status.

6. Highscores (Games)

• Highscores werden in der lokalen MongoDB gespeichert (keine LocalStorage-Listen).
• Top-Listen werden serverseitig geladen.

7. Sicherheit, Zugriff und Limits

• Nur registrierte und angemeldete Nutzer koennen Apps verwenden, sofern die App fuer den Nutzer freigeschaltet ist.
• Jeder Nutzer darf nur einmal gleichzeitig eingeloggt sein.
• Ein eigenes Fingerprint-System wird genutzt:
  • Hash aus unveraenderlichen Browser-Eigenschaften + User-Email + Registrierdatum.
  • Der Hash wird im User-Datensatz gespeichert und serverseitig geprueft.
• Nutzer koennen ihr Profil/Account im Profilbereich mit Sicherheitsabfrage loeschen.
• TOS und Datenschutzerklaerung sind in der Landing-Footer-Navigation erreichbar.

8. Admin und Benutzerverwaltung

• Es wird ein Admin-Dashboard benoetigt mit CRUD fuer User und Apps.
• Nutzer muessen im Profil sehen koennen, welche Apps fuer sie freigeschaltet sind.
• Der Punkt "Korrektur vorschlagen" gilt kontextbezogen: auf der Landingpage nur fuer Landing/Translations, in Apps fuer die jeweilige App und deren Uebersetzungen bzw. Aenderungen.

9. App-Portfolio (Kurzbeschreibung)

Spiele

• 2048+: Zahlen-Puzzle mit variabler Brettgroesse, Score und optionalem Autoplay.
• Wordle+: Wortspiel mit variabler Wortlaenge und Feedback pro Buchstabe.
• Fruits+: Match-3-Spiel mit Power-ups, Levelzielen und Score.

Tools und Utilities

• Qr-Code Generator: QR-Codes fuer URLs, Text und WLAN.
• Shortener: URL-Verkuerzer mit Verwaltung und Dashboard.
• URL_shorter: Einfache Shortener-Variante (klar getrennt benannt).
• Calculators: Sammlung verschiedener Online-Rechner.
• WordClock: Wortuhr mit textbasierter Zeitdarstellung.

Health und Alltag

• Blood: Blutdruck-Erfassung mit Historie.
• WasserReminder: Trink-Erinnerungen und Tagesziele.

Sprache und Content

• GrammarAi: Textkorrektur und Uebersetzung fuer nicht-muttersprachliche Nutzer.

Konzepte/Ideen

• QrShortDoorBell: QR-Klingel mit Owner-Landing und Standort-Check.
• Coffefinder: Cafe-Suche mit Bewertungen.
• Auction: Auktionsplattform nach eBay-Vorbild.
• taxiBayTreuhand: Treuhandplattform fuer die Taxi-Branche.
• MadeIn: Marktplatz-Konzept fuer europaeische Produkte.
• MemeCoinToken: Projektinfos und Whitepaper fuer TaxiToken.
• NaviQuiz: Quiz-Erweiterung fuer Navigation.
• Platform: Ueberblick ueber die Plattform.
• Games (Ordner): Kein klarer App-Inhalt, als Container/Placeholder.

10. Anforderungen (Must-Have)

• Alle Apps in Svelte.js (kein SvelteKit, kein TypeScript).
• Svelte-Views nur Darstellung, Logik/Validierung nur im Backend.
• Gemeinsame DB fuer alle Apps.
• Highscores in der DB (nicht im Client).
• Free/Paid-Tier Daten und Laufzeiten in der DB.
• Zugriff nur fuer registrierte, angemeldete und freigeschaltete Nutzer.
• Single-Login-Limit pro User mit Fingerprint-Hash im User-Datensatz.
• Account-Loeschung fuer User mit Sicherheitsabfrage im Profil.
• Footer-Links zu TOS und Datenschutzerklaerung in der Landing.
• Zentrale Backend-Konfiguration pro App.
• Landingpage listet Apps dynamisch anhand DB/Registry.
• App-Start und Zugriffskontrolle ueber das Backend.

11. Entwicklungsvorgaben

• Standard: npm run dev im Root.
• npm run build nur bei expliziter Anforderung.
• Aenderungen muessen in AblaufProtokoll.md dokumentiert werden.
• Keine destruktiven Git-Operationen ohne Freigabe.

12. Abhaengigkeiten

• Express.js Backend
• MongoDB (lokal)
• Svelte.js Apps

13. Offene Punkte

• Exakte Ausgestaltung der zentralen Konfiguration (Schluessel/Schema) je App.
• Einheitliches Schema fuer Free/Paid-Tier pro App (Felder, Laufzeiten, Limits).
• Status des Ordners apps/games (Platzhalter vs. App-Container).