Projektablauf und Architektur

Dieses Dokument beschreibt die Architektur, den Entwicklungs-Workflow und die zentralen Konzepte dieses Multi-App-Projekts.

Checkliste (laufend)

Offen

Fehlende Punkte/Abweichungen aus Regeln/PRD identifizieren und aufnehmen.

Erledigt

Checkliste eingefuehrt und in den Ablauf integriert.
TypeScript-Dateien im Ordner obsolent vorhanden (veraltet). Nicht verwenden!
SvelteKit-Verwendung im Unterverzeichnis apps/MadeIn/Projekt entdeckt. Nicht verwenden!
React/Next-Abhängigkeiten in package.json vorhanden, jedoch nicht genutzt. Nicht verwenden!
Laufende Arbeitsschritte fuer die naechste Iteration ergaenzen.

1. Ziel & Vision

Das Ziel ist die Entwicklung einer Sammlung von Web-Anwendungen innerhalb einer zentralisierten Monorepo-Architektur. Eine dynamische, datenbankgesteuerte Landingpage dient als zentraler Einstiegspunkt zu allen verfügbaren Applikationen. Dieser Ansatz vereinfacht die Verwaltung, Wartung und Skalierung des gesamten Systems.

2. Architektur-Überblick

2.1. Monorepo-Struktur

Das Projekt nutzt eine Monorepo-Struktur, um Code zentral zu verwalten:

/apps: Enthält die einzelnen Frontend-Anwendungen (z.B. Svelte.js, nicht SvelteKit, auch kein Typescript).
/backend: Der zentrale Express.js-Server.
/packages: (Geplant) Geteilter Code wie UI-Komponenten, Hooks oder Konfigurationen.
package.json: Zentrale Verwaltung aller Abhängigkeiten.

2.2. Zentraler Backend-Server

Der Server unter /backend ist das Herzstück der Anwendung und verantwortlich für:

User-Verwaltung & Authentifizierung (JWT in httpOnly Cookies + Refresh-Token)
Payment / Abrechnung
Sprachverwaltung / Übersetzungen
Datenbank-Interaktionen (MongoDB)
Auslieferung der statischen Apps unter /apps/<slug> (wenn vorhanden).

2.3. Datenbank-gesteuerte Landingpage

Die Landingpage (/) wird dynamisch gerendert. Die Liste der angezeigten Apps wird aus der apps-Collection in der MongoDB geladen. Jede App in der Datenbank hat einen status (ready, coming_soon, maintenance), der die Darstellung und Klickbarkeit des entsprechenden Buttons auf der Landingpage steuert.

2.4. App-Auslieferung

Der Backend-Server auf Port 3000 liefert Apps als statische Dateien aus:

Statische Apps: Einfache Apps (z.B. HTML/JS/CSS) werden unter /apps/<slug> ausgeliefert.
Dev-Server für Apps: Werden manuell separat gestartet (kein automatischer Proxy aktiv).

3. Entwicklungs-Setup

3.1. Installation

Repository klonen:
```
git clone <repo-url>
cd <repo-name>
```
Abhängigkeiten installieren:
```
npm install
```

3.2. Entwicklungsumgebung starten

Empfohlen: npm run dev im Root startet Backend + frontend-svelte parallel (concurrently), wie im Projekt genutzt.

Optional: zwei Terminals (wie im Projekt genutzt):

# Terminal 1
npm --prefix frontend-svelte run dev

# Terminal 2
npm run dev:backend

3.3. Zugriff im Browser

Landing Page (Dev): http://localhost:5173/
API: http://localhost:3000/
Beispiel-App: http://localhost:3000/apps/<slug>

4. Datenbank-Management

4.1. App-Modell

Das App-Modell in backend/models/App.js definiert die Struktur für einen App-Eintrag in der Datenbank. Das wichtigste Feld für die Landingpage ist status.

4.2. Datenbank Seeding

Um die Datenbank mit den im /apps-Verzeichnis vorhandenen Anwendungen zu befüllen, wird ein Seeding-Skript verwendet.

npm run db:seed

Dieser Befehl:

Liest alle Ordner im /apps-Verzeichnis.
Prüft, für welche Ordner noch kein Eintrag in der Datenbank existiert.
Fügt nur die neuen Apps zur Datenbank hinzu und setzt deren status standardmäßig auf coming_soon.

Bestehende Einträge in der Datenbank werden nicht verändert. So bleiben manuelle Anpassungen (z.B. ein geänderter status) erhalten.

5. Eine neue App hinzufügen (Workflow)

Ordner erstellen: Lege einen neuen Ordner für deine App in /apps an (z.B. /apps/neue-app).
App entwickeln: Baue deine Anwendung.
Proxy konfigurieren (falls nötig): Wenn deine App einen eigenen Server (z.B. Vite) benötigt, füge eine neue Proxy-Regel in backend/server.js hinzu.
Datenbank aktualisieren: Führe npm run db:seed erneut aus. Das Skript findet deine neue App und fügt sie zur Datenbank hinzu, ohne bestehende Einträge zu verändern.

6. Deployment (Produktion)

In einer Produktionsumgebung wird ein dedizierter Webserver wie nginx als Reverse Proxy vor den NodeJS-Server geschaltet. Nginx übernimmt das SSL-Handling (HTTPS) und das effiziente Routing von Anfragen an die korrekten Services.

Etappenprotokoll

Kurzfassung (verifiziert, bereinigt)

Landing/Embed: Apps koennen in der Hero-Section eingebettet werden; App-Karten werden im Embed ausgeblendet; Profil-Start oeffnet Embedded-App, wenn vorhanden.
Shortener (Embed): CRUD vorhanden, QR pro Zeile mit Inline-Preview, ToggleButton statt Checkbox, URL-Text wird mit truncateUrl(..., 40) gekuerzt.
QR-Code Generator (Embed): erweiterte Typen/Formulare, Speichern/Loeschen/Reports, QR-Preview in der Haupt-Box mit Toggle, keine Tracking-URL im QR-Bild, kein Klickzaehler.
Calculators (Embed): Tabs fuer Units, Time, Data, Numbers, Encoding, CSV/JSON/XML, Strings, Hashes, Formatters, Internet, WebDev, Encoders.
Games: Sammelkarte in Landing; serverseitige Game-APIs aktiv; i18n in Games-Apps.
Zugriff/Entitlements: App-Start Buttons in Landing/Profil/Modal, Free-Tier-Ablaufschutz, Access-Labels ueber shared/appAccess.js.
Billing: Paid-Aktivierung via /api/v1/billing/checkout mit Rueckmeldung in der Landing.
i18n (Shared): shared/i18n.js genutzt in Qrcode, Shortener, Games, Blood-WebApp; Games setzen Asset-Base im Embed.
Slug-Schutz: bad-words + Blockliste in Shortener/QR-Controller aktiv.
Seeds: Svelte-Fallbacks fuer DB werden via backend/scripts/seedSvelteFallbacks.js gesetzt.

Hinweis: Der Legacy-Block wurde in den Anhang verschoben.

Appendix: Legacy Etappen

Archivierte Etappen (Legacy/ungeprueft)

Etappe: Fix Svelte Runtime-Fehler (effect_orphan)

Initialisierung in frontend-svelte/src/views/Landing.svelte nach onMount verschoben.
Popstate-Listener mit Cleanup registriert, um Runtime-Fehler zu vermeiden.
Ziel: Fehler "effect_orphan" nach npm run dev beseitigen.

Etappe: Build-Fehler in Svelte behoben

Print-HTML in frontend-svelte/src/views/Landing.svelte so angepasst, dass kein </script> im Template-Literal vorkommt.
Ziel: Vite Build ohne "Unterminated template".
Test: npm run build in frontend-svelte (erfolgreich, nur A11y-Warnungen).

Etappe: Default-User + Admin-Dashboard Basis

Seed-Skript fuer Test- und Admin-User erstellt (backend/seedUsers.js).
Admin-API fuer Uebersicht hinzugefuegt (/api/v1/admin/overview).
Admin-Ansicht in frontend-svelte/src/views/Landing.svelte integriert (Stats + User-CRUD(fehlt noch)).
Test: npm run build in frontend-svelte (erfolgreich, A11y-Warnungen).
Seed ausgefuehrt: npm run db:seed:users.

Etappe: Login-Reparatur + Forgot/Reset Password

Passwort-Reset-Token im User-Model ergaenzt.
Forgot/Reset-Endpunkte in Auth-Controller und Routes implementiert.
Reset-E-Mail Versand via mailService ergaenzt.
Landingpage um Forgot/Reset Views erweitert.
Shortener-Login auf Plattform-Forgot-Link umgestellt.
Test: npm run build in frontend-svelte (erfolgreich, A11y-Warnungen).
Seed aktualisiert: npm run db:seed:users.

Etappe: App-Start Static Routing + Dashboard Label

App-Index-Auswahl auf public/dist/build priorisiert und Asset-Pfade fuer /apps/<slug> automatisch gepraefixed.
Static-Asset-Serving fuer /apps/<slug>/* hinzugefuegt, damit gebaute Apps geladen werden.
Header-Label "Dashboard" fuer angemeldete Nutzer angepasst und Login-State beim Login stabilisiert.
Test: npm run build in frontend-svelte (erfolgreich, A11y-Warnungen).

Etappe: Dev-Start via Concurrently

Root-npm run dev startet jetzt Backend (nodemon) und frontend-svelte parallel.
dev:backend und dev:frontend Scripts hinzugefuegt; Vite laeuft auf Port 5173.
Dependency concurrently im Root installiert.

Etappe: Public-Ordner deaktiviert

Ordner public in xxpublic umbenannt.
Backend nutzt xxpublic nur noch, wenn SERVE_STATIC_UI=true gesetzt ist.
Vite-Output auf xxpublic/ui umgestellt, damit keine Builds mehr in public landen.

Etappe: Vite-Port korrigiert

frontend-svelte Dev-Port von 4173 auf 5173 gestellt, passend zu npm run dev.

Etappe: Login sichtbar auf Landingpage

Schnell-Login-Block in der Landing-Ansicht hinzugefuegt (Login/Registrieren/Passwort vergessen).

Etappe: CORS fuer Vite-Dev

http://localhost:5173 in die erlaubten Origins aufgenommen, damit Login per Vite-Dev funktioniert.

Etappe: API-Calls ueber Vite-Proxy

frontend-svelte nutzt jetzt relative /api-Calls (kein Cross-Origin), damit Cookies sauber funktionieren.

Etappe: Login-UI bereinigt + Auth-Status stabilisiert

Schnell-Login in der Landing-Ansicht entfernt (Login nur via /login).
Auth-Requests gegen parallele fetchMe()-Updates abgesichert, damit der Login-Status nicht ueberschrieben wird.

Etappe: Login-Feedback & Profil-Navigation

Nach Login direkte Weiterleitung auf /profile.
Header zeigt Profil-Link und gruene Login-Markierung mit Username/E-Mail.

Etappe: Reaktives Login-Flag

isLoggedIn ist jetzt ein reaktiver Wert statt Funktionsaufruf, damit Header/Profil sofort umschalten.

Etappe: Admin immer Vollzugang

Admin bekommt in /api/v1/auth/apps alle Apps als aktiv/paid zurück.
App-Aktivierung ignoriert Free-Tier fuer Admins.

Etappe: Dummy Revolut Link in config.js

Ein Dummy-Revolut-URL wird in backend/config/config.js als revolutDummyLink hinzugefügt.
Dies dient der Testumgebung, um Zahlungssimulationen ohne Stripe zu ermöglichen.

Etappe: App-Start im Dev-Modus

App-Start-Links zeigen in Dev auf http://localhost:3000/apps/<slug> statt Vite, damit die Apps geladen werden.
Profil-Ansicht bietet fuer freigeschaltete Apps jetzt direkt "App starten".

Etappe: Ablauf-Dokumentation aktualisiert (verworfen)

Verworfen: Meta-Aktualisierung ist nicht direkt im Code verifizierbar.

Etappe: Direkter /apps/<slug> Zugriff

/apps/<slug> auf der Landing-URL (Dev/Prod) validiert Login + App-Zugriff und leitet danach auf die App um.
Bei fehlender Freischaltung Redirect auf /profile mit Hinweis.

Etappe: Plan.md Baseline erstellt

Neue Plan.md mit kompletter ToDo-Baseline erstellt, basierend auf rules.md, README.md, PRD.md und AblaufProtokoll.md.
Alle Punkte sind bewusst als ungeprueft/offen markiert, damit spaeter gezielt abgehakt werden kann.

Etappe: README aktualisiert (Englisch, Legacy-Hinweise)

README.md auf Englisch aktualisiert und an den aktuellen Code-Stand angepasst.
Legacy/konzeptionelle App-Ordner explizit genannt und mit Migrationshinweis zu Svelte versehen.

Etappe: README erweitert (Legacy-Detail + Migrationscheckliste)

Registry-Apps mit Source-Pfaden und Status ergaenzt.
Legacy/konzeptionelle App-Ordner detailliert aufgefuehrt und Migrations-Checkliste hinzugefuegt.

Etappe: RalphWiggum Prompt-Quellen erweitert + Migration Guide

ralphWiggum.sh liest jetzt rules.md, PRD.md, Plan.md und README.md mit klarer Prioritaet fuer Konflikte.
README um Migrationsstatus-Spalte ergaenzt.
Neues Dokument MIGRATION.md mit konkreten Legacy-Migrationsschritten erstellt.

Etappe: RalphWiggum Dateisuche tolerant gemacht

ralphWiggum.sh loest Kern-Dateien jetzt case-insensitive auf und bricht nicht wegen abweichender Schreibweise ab.

Etappe: Vollpruefung AblaufProtokoll (Audit-Report)

Vollaudit aller Etappen erstellt und nach OK/UNKLAR/FALSCH klassifiziert.
Report liegt unter .ralphWiggum/full_audit.md.

Etappe: Audit-Korrekturen + Build-Punkte obsolet

Build-bezogene Etappen als obsolet markiert (spaeterer Nachholtermin).
Korrekturen und offene UNKLAR-Punkte in AblaufProtokoll_Audit_Corrections.md erfasst.

Etappe: UNKLAR-Punkte verifiziert (Audit-Fortschritt)

UNKLAR-Liste weitgehend verifiziert und mit konkreten Dateibelegen ergaenzt.
Verbleibende unklare/kontradizierende Punkte sind markiert.
Slug-Validierung (mind. 4 Zeichen) als intern reserviert dokumentiert.

Etappe: UNKLAR-Punkte weiter verifiziert

Weitere UNKLAR-Punkte verifiziert (u.a. Paid-Aktivierung Start, Games serverseitig + i18n).
Neue Widersprueche in der Audit-Korrekturliste markiert.
Unverifizierbare Etappen als verworfen markiert.

Etappe: App-Index-Aufloesung erweitert

App-Serving sucht jetzt auch in WebApp/ und LandingPage/ (inkl. dist/build/public).

Etappe: Git-Setup

Lokales Git-Repo initialisiert.
.gitignore fuer typische Artefakte/Builds und xxpublic/ hinzugefuegt.

Etappe: Eingebettete Git-Repos entfernt

Unterordner mit eigenen .git-Ordnern in Apps entfernt, damit alles im Monorepo versioniert wird.

Etappe: Blood-WebApp in Landing eingebettet

frontend-svelte/src/apps/BloodApp.svelte als Wrapper fuer die bestehende Blood-WebApp erstellt.
Vite-Server erlaubt jetzt Imports aus dem Monorepo (frontend-svelte/vite.config.js).
Blood-Assets nach frontend-svelte/public/assets/images kopiert und flaggs Alias angelegt.

Etappe: Wasser-Reminder in Landing eingebettet

frontend-svelte/src/apps/WasserReminderApp.svelte erstellt und Wasser-HTML/JS eingebunden.
Wasser-Assets nach frontend-svelte/public/wasser kopiert.

Etappe: Games als einzelne Apps eingebettet

Svelte-Komponenten fuer 2048+, Wörtli und Fruits+ erstellt.
Game-Assets nach frontend-svelte/public/games kopiert.

Etappe: Einbettung rueckgebaut + Games umbenannt

Landing-Embedding fuer Blood/Wasser/Games entfernt, damit die Landing wieder startet.
Spiele-Ordner nach apps/2048-plus, apps/wordle-plus, apps/fruits-plus verschoben.

Etappe: Games nach Svelte migriert

2048+, Wordle+ und Fruits+ als eigenstaendige Svelte-Apps unter apps/2048-plus, apps/wordle-plus, apps/fruits-plus angelegt.
Landing nutzt Svelte-Komponenten aus den neuen App-Ordnern.
Vite-Proxy in frontend-svelte erweitert, damit /apps/* und /assets/* im Dev ueber das Backend erreichbar sind.

Etappe: Landing stabilisiert + doppelte Assets entfernt

Alte Embedding-Wrapper und Hilfsdateien entfernt (frontend-svelte/src/apps/BloodApp.svelte, frontend-svelte/src/apps/WasserReminderApp.svelte, frontend-svelte/src/apps/GameRoyalMatchApp.svelte).
Doppelte Assets in frontend-svelte/public entfernt (assets, games, wasser), damit Assets nur noch aus den App-Ordnern kommen.
Landing-Hintergrund explizit auf das Standard-Design gesetzt.

Etappe: Games-Styles auf einheitliches Design gezogen

Game-Styles auf App-Wrapper gekapselt, damit kein globaler body-Style die Landing ueberschreibt.
Farbpalette an das MultiApps-Design angepasst (primary/secondary/accent).
Zusätzliche CSS-Scopes eingefuegt, damit generische Klassen wie .container und header die Landing nicht mehr beeinflussen.

Etappe: Blood API (MongoDB) gestartet

Neue Mongo-Modelle fuer Blutdruck-Eintraege und Reminder-Settings angelegt.
REST-API unter /api/v1/blood hinzugefuegt (Entries + Settings).

Etappe: Blood Svelte-Port (Mongo)

Neue Svelte-App unter apps/blood/WebApp umgesetzt (Eintraege, Trends, Reminder).
Plattform-Login via /api/v1/auth/me integriert, Daten per /api/v1/blood/*.
Landing-Embedding fuer Blood wieder aktiviert.

Etappe: Landing Karten mobile-first

Kartenraster auf mobile-first Breakpoints umgestellt (1/2/3 Spalten).
Abstaende, Schriftgroessen und Buttons fuer kleine Screens optimiert.

Etappe: Sensitive Dateien entfernt

anmeldeDaten.txt aus Git entfernt und in .gitignore aufgenommen.

Etappe: Admin-Apps immer aktiv + Regeln

Admin sieht App starten in den App-Karten (Zugriff immer aktiv).
rules.md im Root angelegt.

Etappe: Login-Status nach Zurueck

pageshow Event refresht fetchMe(), damit der Header nach Browser-Back korrekt auf "App starten" bleibt.

Etappe: Dev-Proxy fuer App-Starts

Backend proxied /apps/<slug> auf App-Dev-Server (konfigurierbar in backend/config/appDevProxy.js).

Etappe: QR-Code Generator (Svelte)

Neue Svelte-App unter apps/qrcode mit QR-Generator (URL/Text/WLAN).
Dev-Port 4201 eingerichtet (Vite), passend zum Dev-Proxy.

Etappe: QR-Code Generator erweitert

QR-Typen fuer Web, Kontakte, Kommunikation, Termine, Standort, Technik, Payment, Daten und Marketing ergänzt.
Scan-Counter via Shortener für URL-basierte Typen integriert.
CORS fuer App-Dev-Ports erweitert (4201-4204).

Etappe: Root-Dev startet QR-App

Root-npm run dev startet jetzt zusaetzlich den QR-Code-Generator (apps/qrcode) im Dev-Modus.

Etappe: QR-App Dependencies installiert

npm --prefix apps/qrcode install ausgefuehrt, damit vite fuer die QR-App verfuegbar ist.

Etappe: QR-App Vite Base gesetzt

apps/qrcode/vite.config.js auf base: "/apps/qrcode/" gestellt, damit Dev-Assets ueber den Backend-Proxy geladen werden.

Etappe: QR-Proxy Prefix behalten

Dev-Proxy behaelt fuer qrcode den /apps/qrcode Pfad, damit Vite-Redirects nicht in einen Loop laufen.

Etappe: QR-Proxy BaseUrl nutzen

Dev-Proxy nutzt fuer qrcode req.baseUrl, damit /apps/qrcode/ korrekt an Vite weitergegeben wird.

Etappe: CSP fuer Vite-HMR

connect-src im CSP erweitert, damit WebSocket-HMR ueber /apps/qrcode im Dev-Modus nicht blockiert wird.

Etappe: Ready-Apps eingebettet

QR-Code-Generator als Svelte-Komponente (frontend-svelte/src/apps/QrcodeApp.svelte) eingebettet.
Landingpage rendert qrcode und qrshortdoorbell in der Hero-Section; App-Buttons nutzen das Embedding fuer diese Apps.

Etappe: QR-URL nur Slug

QR-Code Generator verwendet fuer URL-Typ einen Slug-Input und baut daraus https://ucall.me/<slug>.

Etappe: Slug-Validierung (intern, mind. 4 Zeichen)

Interne Slugs sind ab 4 Zeichen gueltig; oeffentliche Slug-Configs bleiben bei 6 Zeichen.

Etappe: Dynamische Beispiel-URL

Beispiel-Zeile zeigt den eingegebenen Slug als https://ucall.me/<slug> und faerbt gruen, sobald gueltig.

Etappe: Scan-Counter Label zweizeilig (verworfen)

Verworfen: kein belegbarer Scan-Counter-Label im aktuellen QR-Embed.

Etappe: Scan-Counter Styling verbessert (verworfen)

Verworfen: kein belegbares Scan-Counter-Styling im aktuellen QR-Embed.

Etappe: Home-Link und Admin-Header

Home-Link schliesst eingebettete Apps, damit die Haupt-Landingpage sichtbar ist.
About-Link im Header fuer Admin ausgeblendet.

Etappe: Shortener-CRUD

Backend: Shortener-API um Listen/Update/Delete erweitert.
Frontend: UrlManager mit Bearbeiten/Löschen + klick-Statistik umgesetzt.

Etappe: Shortener eingebettet

Shortener als Svelte-Komponente in der Landingpage eingebettet (Dashboard/CRUD in der Hero-Section).

Etappe: Shortener-URL Schema

Short-URLs nutzen https://ucall.me/<slug> (ohne /s/), Backend akzeptiert fehlendes https:// und normalisiert.
URL_shorter Karte wird aus der Landingpage-Liste ausgefiltert.

Etappe: App-Karten ausblenden bei Embed

Wenn eine App in der Hero-Section eingebettet ist, werden die App-Karten ausgeblendet und erst bei Home/Logo wieder angezeigt.

Etappe: Shortener Checkbox Layout (verworfen)

Verworfen: aktuelle UI nutzt ToggleButton statt Checkboxen.

Etappe: Toggle-Buttons statt Checkboxen

Checkboxes in Shortener, Qr-Code-Generator und Doorbell-Embed durch Toggle-Buttons mit ✅/❔ ersetzt.
Shortener bietet optionalen QR-Code-Output fuer die erzeugte Short-URL.

Etappe: Shortener QR pro Zeile

QR-Code wird nun per Icon in der URL-Liste erzeugt und direkt in der jeweiligen Zeile angezeigt.

Etappe: QR-Icon ucall.me

QR-Icon in der Shortener-Liste zeigt ein QR fuer https://ucall.me.

Etappe: Shortener Liste kompakt

QR-Code Vorschau sitzt inline in der Aktionszeile; Ziel-URL wird via truncateUrl(..., 40) gekuerzt.

Etappe: Short-URL Base via NODE_ENV

Short-URL Basis ist in Dev http://localhost:3000/<slug> und in Prod https://ucall.me/<slug>.

Etappe: Admin-Shortener + Qr-Code-Generator Slug-Regeln

Admin darf Shortener-Slugs mit variabler Laenge nutzen (nur erlaubte Zeichen).
Qr-Code-Generator Slugs sind jetzt mindestens 6 Zeichen lang.

Etappe: Slug-Sanitizer (Blockliste)

Shortener und Qr-Code-Generator blocken Slugs mit porn, sex, ns Kombinationen.

Etappe: bad-words integriert

bad-words Filter nutzt Blockliste fuer Shortener und Qr-Code-Generator.

Etappe: bad-words Import fix

bad-words wird als Named Export ({ Filter }) importiert, damit Vite laedt.

Etappe: Deutsche Bad-words erweitert

Filterliste um fick, ficker, fickdich erweitert (inkl. Substring-Check).

Etappe: QR-Generator Speichern + Reports

QR-Codes werden gespeichert, via /q/<slug> getrackt und in einer Liste mit Klicks angezeigt.
Reports sperren Short-URLs/QR-Codes, warnen User in-App und blocken nach 3 Verwarnungen.
Ziel-Links mit nicht jugendfreien Begriffen werden geblockt.
User sehen Verwarnungen im Profil (In-App Hinweise).

Etappe: QR-Generator Tracking-URL Basis + Scan-Counter immer aktiv

QR-Tracking-URLs nutzen jetzt nur NODE_ENV (Prod = Host-Domain, Dev = localhost).
QR-Code Bild nutzt immer die Tracking-URL (Scan-Counter immer aktiv).
QR-Generator-UI ohne Scan-Counter Toggle/Short-URL-Option.

Etappe: QR-Codes loeschbar

DELETE Endpoint fuer eigene QR-Codes hinzugefuegt.
Loesch-Button in QR-Listen (Embedded + Standalone) ergaenzt.

Etappe: Toasts statt Alerts + Modals statt Confirm

Alerts/Confirm durch Toasts und eigene Bestaetigungs-Modals ersetzt (Landing, Shortener, QR-Generator).

Etappe: QR-Code-Listen mit QR-Icon

QR-Code-Listen zeigen ein QR-Icon-Button zum Anzeigen des gespeicherten QR-Codes.

Etappe: Ablaufdatum fuer Shortener & QR-Generator

Shortener und QR-Codes speichern optional ein Gueltig-bis-Datum.
Redirects blockieren abgelaufene Links (410).

Etappe: QR-Generator ohne Tracking-URL im QR-Bild

QR-Codes enthalten wieder den eigentlichen Payload (kein Tracking-Link im QR-Bild).

Etappe: QR-Generator ohne Slug

URL-Eingabe akzeptiert echte URLs (kein eigener Slug im QR-Generator).

Etappe: Labels naeher an Inputs (verworfen)

Verworfen: kein eindeutiger Beleg fuer reduzierte Label-Abstaende im QR-Embed.

Etappe: QR-Preview aus Liste in Haupt-QR-Box

QR-Icon in der Liste zeigt den QR-Code in der Haupt-Preview (nicht inline) und nutzt Payload statt Tracking-URL.

Etappe: QR-Preview Toggle

QR-Icon in der Liste toggelt die Vorschau in der Haupt-QR-Box an/aus.

Etappe: QR-Listen ohne Klickzaehler

Klickzaehler-Anzeige im QR-Generator entfernt.

Etappe: QR-Listen ohne Slug-Anzeige (verworfen)

Verworfen: QR-Listen zeigen entry.qrUrl und enthalten damit den Slug.

Etappe: App-Start aus Profil direkt in Embed

App-Start aus dem Profil behält das Embedded-App-Rendern beim Wechsel zur Landingpage.

Etappe: WasserReminder als Svelte-Port

Neue Svelte-App in apps/wasserReminder/WebApp mit Vite-Base /apps/wasserreminder/ und Nutzung des bestehenden public/wasser-Asset-Pools.
WasserReminder UI/Logik (Reminder, History/Chart, Ads, Share, Audio-Recorder, Sprache) nach Svelte portiert und per Module strukturiert.
CSS auf .app-wasser gescoped, damit keine globalen Styles auf die Landingpage durchschlagen.
Landingpage-Embed wasserreminder inklusive Wrapper-Komponente hinzugefuegt.
Manifest/Service-Worker Pfade auf /apps/wasserreminder/ angepasst.

Etappe: WordClock als Svelte-Port

WordClock nach apps/WordClock/WebApp portiert (Svelte/Vite, Base /apps/wordclock/).
WordClock-Logik aus script.js in Svelte-Module ueberfuehrt und JSON-Daten (timeTexts.json) direkt importiert.
Styles auf .app-wordclock gescoped und Landing-Embed wordclock samt Wrapper integriert.

Etappe: GrammarAI Migration (Plattform)

GrammarAI als Svelte-App unter apps/grammarAi/WebApp portiert und in die Landing eingebettet.
Backend-Integration ueber /api/v1/grammar/* (History, Feedback, API-Keys) sowie /api/v1/billing/checkout fuer Paid-Upgrade.
Free-Tier Standard auf 14 Tage gesetzt und Paid-Upgrade setzt App als ad-free.

Etappe: GrammarAI Fix (Translations Import)

Import-Pfad fuer translations.ts in apps/grammarAi/WebApp/src/lib/i18n.js korrigiert, damit Vite das File findet.

Etappe: GrammarAI Fix (Gemini API Key)

Dev-Fallback in apps/grammarAi/WebApp/src/lib/geminiService.js: wenn kein VITE_GEMINI_API_KEY gesetzt ist, wird eine neutrale Korrektur (Text unveraendert, keine Vorschlaege) geliefert.

Etappe: Obsolent-Ordner

Nicht mehr benoetigte Dateien/Ordner (Skripte, Generatoren, alte Dokumentations-Snapshots) nach obsolent/ verschoben.

Etappe: App-Registry (SSOT)

Zentrales appRegistry.js eingefuehrt (Slugs, Namen, Embed-Flags, Dev-Ports, Short-Codes).
Landing nutzt Embedded-Slugs aus der Registry, Dev-Proxy nutzt die Registry.
Script db:sync:apps passt App-Namen in der DB an (z.B. Qr-Code-Generator).

Etappe: Reservierte Short-URLs

Script db:seed:shorturls legt 4-Zeichen-Shortcodes fuer admin@ucall.me an und zeigt auf /apps/<slug>.
PUBLIC_BASE_URL in zentrale Backend-Env aufgenommen.

Etappe: .env Zentralisierung

Alle .env* Dateien in env/ zentralisiert.
Backend/Script-Lader sowie Vite-Configs auf die neuen Env-Pfade umgestellt.

Etappe: Dev-Watcher (ohne nodemon/concurrently)

Root-Dev startet ueber node scripts/dev.js (Backend via node --watch).

Etappe: Shortener Dev-Proxy

Shortener Vite-Base auf /apps/shortener/ gesetzt und Dev-Port auf 4209 gelegt.
Root-Dev startet Shortener-Dev-Server mit, damit /apps/shortener im Dev funktioniert.

Etappe: App-Dev-Server komplett (verworfen)

Verworfen: keine belegbare Aussage zur Vollstaendigkeit im aktuellen Setup.

Etappe: /apps/qrshortdoorbell Redirect

App-Redirect fuer qrshortdoorbell oeffnet die Landingpage mit eingebetteter Doorbell statt einem eigenen App-Server.

Etappe: App-Registry DB Sync (Create)

db:sync:apps legt fehlende App-Records aus der Registry an.

Etappe: Dev-Abhaengigkeiten (Blood/Shortener) (verworfen)

Verworfen: keine belegbare Aenderung zu Abhaengigkeiten im Root gefunden.

Etappe: Games-Sammelkarte

Games-Karte fasst 2048+, Woertli und Fruits+ zusammen.
Klick auf Games oeffnet eine eigene Games-Landing in der Hero-Section, die die drei Spiele startet.
Buttontexte fuer Games auf "Zu den Games" angepasst.
Wordle+ Bezeichnung vereinheitlicht (Landing + Spieltitel).
Fruits+ in der Plattform benannt.
Games-Assets fuer Wordle+/Fruits+ nutzen jetzt die definierte App-Basis-URL, damit Daten/Sounds geladen werden.
Games-Embeds auf mobile Hoehe angepasst (keine 100vh in der Landing).

Etappe: Dev-PIDs Cleanup

scripts/dev.js beendet vorherige Dev-Prozesse per PID-File, damit Ports nicht blockiert bleiben.

Etappe: Dev-Start mit Logfile

npm run dev killt vorhandene Dev-Prozesse und schreibt die Ausgabe nach dev.log.

Etappe: Dev-Port Cleanup

scripts/dev.js beendet Prozesse auf den festen Dev-Ports (3000/5173/4201-4209), damit die Apps nicht auf Ausweichports starten.

Etappe: Dev-Port Cleanup (lsof Pfad)

scripts/dev.js nutzt nun den absoluten lsof-Pfad, damit das Port-Killing auf macOS sicher greift.

Etappe: Landing Container & Mobile-Nav

Landing-Inhalt (Header/Stats/App-Karten) wird nur angezeigt, wenn keine Embedded-App aktiv ist; Embedded-Apps ersetzen damit die Hero-Section.
Navigation auf Mobile-First umgestellt: Logo + Sprache + Icon-Shortcuts, zusaetzlich Hamburger-Menue fuer die restlichen Links.
Mobile-Nav erweitert: Login-Icon sichtbar wenn nicht eingeloggt, Menue mit allen Punkten; Hintergrund des Menues auf gray-700.
Embedded-Apps zeigen nur ein Close-Icon rechts oben, ohne eigenen Titel-Header.

Etappe: 2048+ Mobile-Responsive

Board-Groesse wird aus der Wrapper-Breite berechnet, damit es im View bleibt.
2048+ Layout stapelt Header/Controls auf kleinen Screens und reduziert Padding/Typo.
Board nutzt jetzt max. 95% der View-Breite, geringere Margin/Padding fuer mehr Spielflaeche.
Embedded-View reduziert Container-Padding und zeigt das Close-Icon als Overlay rechts oben.
2048+ Titel links ausgerichtet, kleinere Padding/Gaps fuer mehr Spielflaeche.
2048+ Board/Tile-Groesse weiter reduziert, Gap kleiner; Container-Rahmen im Embed entfernt.
Grid-Size Buttons immer in einer Reihe (4 Spalten).
Board-Container auf max. 90% der Wrapper-Breite begrenzt, Padding weiter reduziert.
Board-Groesse kommt jetzt direkt aus der 90%-Wrapper-Berechnung, damit Grid-Cells und Tiles exakt gleich gross sind.
2048+ Board: Gap weiter reduziert, Wrapper-Padding wird exakt abgezogen, Min-Cell kleiner fuer 4x4 im View.
2048+ Board: Cell- und Tile-Groesse wird jetzt direkt aus vw / gridSize minus Gaps berechnet (keine festen Groessen).
2048+ Board richtet sich an der Breite der Grid-Size-Auswahl aus (Brett = Selector-Breite minus Gaps).
Referenz fuer Board-Breite ist jetzt .grid-selector-buttons.
Board-Groesse = min(Selector, Wrapper) minus 2x Board-Umrandung (Gap), Cells daraus berechnet.
Default CSS-Variablen fuer 2048+ (Board/Gap/Cell) angepasst.
Grid-Columns/Rows im 2048+ Board werden in px gesetzt, damit Cells und Tiles exakt passen.
Board-Maxbreite ist jetzt 100% - 2 * gap, Cell-Groesse daraus berechnet (inkl. Board-Umrandung).
Grid-Cells/Tiles werden nun ueber die Formel (boardOuter - gap*(grid-1)) / grid exakt identisch berechnet.
2048+ nutzt jetzt dieselbe Root-Quelle fuer CSS-Variablen bei Grid und Tiles, damit Position/Size konsistent bleiben.

Etappe: Wordle+ Daily Word (verworfen)

Verworfen: im aktuellen apps/wordle-plus/src keine Daily-Word-Logik vorhanden.

Etappe: Games Assets Proxy

Wordle+/Fruits+ Assets werden im Embed immer relativ zu /apps/... geladen, damit der Vite-Proxy gleiche Origin bleibt (keine CORP-Blocks).

Etappe: Calculators Auswahl (V1)

Geplant (V1, Prioritaet): Unit Converter, Zeitzonen-Umrechner, Data Size Converter, Nummern-Konverter (Binary/Decimal/Hex/Octal), Text/Encoding (Base64, URL Encode/Decode), Datum/Unix Timestamp.
Offen (spaeter): CSV/JSON/XML Converter, String Utils (HTML/XML Escape/Unescape, Strip Tags), Hash-Generatoren (MD5/SHA1/SHA256/SHA512), Formatters (CSS/JS/JSON/SQL), Sonstiges (IP, Email-Validator, Is-It-Up).

Etappe: Calculators App (Start)

Neue Svelte-Component CalculatorsApp mit Tabs und V1-Umrechnern (Units, Timezone, Data, Numbers, Encoding, Date/Unix).
Landing-Embed und Registry-Eintrag fuer calculators hinzugefuegt.
Sync-Script setzt calculators auf Status ready, damit die Karte sofort startbar ist.
Tabs im Calculators-Header duerfen umbrechen (so wenig Zeilen wie noetig).

Etappe: Calculators App (CSV/JSON/XML)

CSV/JSON/XML Konverter hinzugefuegt (CSV↔JSON, JSON↔XML) inkl. Delimiter.
CSV/JSON/XML → HTML/TSV hinzugefuegt (Tabellen-Output).
CSV → XML und XML → CSV hinzugefuegt, plus Convert Files (csv/json/xml -> json/csv/xml/html/tsv).

Etappe: Calculators App (String Tools)

HTML/XML Escape & Unescape sowie Strip-Tags hinzugefuegt.
Word Counter und Regex-Tester hinzugefuegt.
String-Konverter erweitert: Binary/Hex ↔ String, separate Strip-Optionen fuer HTML/XML.

Etappe: Calculators App (Hashes)

Hash-Generatoren hinzugefuegt: MD5, SHA-1, SHA-256, SHA-512.

Etappe: Calculators App (Formatters)

JSON Pretty/Minify und einfache Formatter fuer CSS/JS/SQL hinzugefuegt.
Formatter-Liste erweitert (CSS, GO, HTML, JS Obfuscate, JSON Editor/Validator, Perl/PHP/Python/Ruby, XML).

Etappe: Calculators App (Internet Tools)

Email Validator, URL Parser und "What is my IP" (ipify) hinzugefuegt.
Binary/Hex String Encoder/Decoder hinzugefuegt (String↔Binary, String↔Hex).
Internet-Tools erweitert: Is-It-Up Check, Router Defaults, User Manuals (Links).

Etappe: Calculators App (Web Dev)

Web-Dev-Links integriert (Playground, Color Tools, CSS Fonts, Diff Tool, Regex Tools, RGB/HEX, Spritegen, Epoch/Unix, Speed Test).

Etappe: Calculators App (Encoders/Decoders)

Kombinierter Tab fuer Base64, URL Encode/Decode und Hash Generatoren hinzugefuegt.
Email-Validator trimmt Eingaben, damit gueltige Mails nicht faelschlich scheitern.
Email-Regex korrigiert (escape Sequenzen bereinigt).

Etappe: Calculators App (Numbers)

Zusaetzliche Basis-Ausgaben (Binary/Octal/Decimal/Hex) parallel angezeigt.
Numbers-Converter-Optionen erweitert (Binary/Decimal/Hex/Octal in alle Richtungen).
URL-Parser-Variablen umbenannt, um Namenskonflikt mit Encoding-Tab zu vermeiden.
Regex fuer URL-Parser korrigiert (Svelte-Parse-Fehler behoben).
Tile-Animation verlangsamt und Spawn-Delay eingefuegt, damit Bewegungen/Neue Tiles ruhiger wirken.
CSS-Variablen fuer 2048+ werden direkt auf .app-2048 gesetzt, damit Cells/Tiles wirklich gleich bleiben.

Etappe: Calculators App (Time + Date/Unix)

Date/Unix Tab in den Time-Tab integriert, damit kein Doppel-Tab existiert.

Etappe: Calculators App (Reverse Toggle)

Alle hin/her-Umrechner verwenden jetzt ein 🔄-Icon fuer die Richtungsumkehr.
Labels zeigen die Richtung mit gruenem Pfeil, Eingabefelder wechseln die Seite.
Reverse-Button zeigt jetzt den Text "Umkehren 🔄".

Etappe: I18n Basis (Shared)

Gemeinsames i18n-Helper-Modul hinzugefuegt, das Sprachen und Uebersetzungen aus der MongoDB-API lädt.
Landing nutzt jetzt das Shared-Helper fuer Sprache/Translation (preferredLanguage zentral).
GrammarAI i18n ist auf DB-Quelle umgestellt und nutzt die zentrale Spracheinstellung.

Etappe: I18n Calculators (Start)

CalculatorsApp nutzt jetzt DB-Translations ueber Shared-i18n.
UI-Texte sind per t() verschluesselt und in der DB hinterlegt.

Etappe: I18n Shortener (Embed)

ShortenerApp bindet Shared-i18n ein und nutzt DB-Keys fuer alle UI-Texte.
Fehlende Embed-Keys wurden in der DB ergaenzt.

Etappe: Embedded Container Spacing

Embedded-Container nutzt px-1 py-1 fuer mehr Nutzflaeche, Close-Icon weiter nach unten (top-6).

Etappe: I18n QR-Code-Generator (Embed)

QrcodeApp nutzt Shared-i18n und t()-Keys fuer UI, Fehler, Confirm und Toasts.
QR-Typen, Labels, Actions und Hints sind in der DB hinterlegt.

Etappe: I18n Games Landing (Embed)

GamesLanding nutzt Shared-i18n fuer Spielnamen und CTA.
Deutsche Seed-Texte liegen in der DB (Translation-Collection); keine Dateien.

Etappe: I18n Game 2048+

2048+ nutzt Shared-i18n fuer UI-Labels, Overlay und Autoplay-Text.
Game-Logik nutzt data-Attribute fuer dynamische Texte (Game Over, Autoplay).
Deutsche Seed-Texte liegen in der DB (Translation-Collection); keine Dateien.

Etappe: I18n Game Wordle+

Wordle+ nutzt Shared-i18n fuer Titel, CTA und Meldungen.
UI-Texte werden via window.__wordleUiTexts in die Spiel-Logik gereicht.
Deutsche Seed-Texte liegen in der DB (Translation-Collection); keine Dateien.

Etappe: I18n Game Fruits+

Fruits+ nutzt Shared-i18n fuer UI-Texte, Dialoge und Highscore-Anzeigen.
Spiel-Logik liest UI-Strings aus window.__fruitsPlusUiTexts.
Deutsche Seed-Texte liegen in der DB (Translation-Collection); keine Dateien.

Etappe: I18n Pfadfixes (Games + GrammarAI) (teilweise)

Games setzen Asset-Base via window.__*AssetBase im Embed; GrammarAI hat keinen nachweisbaren Pfadfix.

Etappe: I18n WasserReminder (WebApp)

WasserReminder nutzt Shared-i18n ueber language.js und setzt window.lang aus DB-Translations.
Language-Modal bezieht verfuegbare Sprachen aus der DB (gefiltert auf bekannte Codes).
Reminder/Charts/Toasts nutzen DB-Strings statt Hardcodes.
Deutsche Seed-Texte liegen in der DB (Translation-Collection); keine Dateien.

Etappe: I18n QR-Code (Standalone)

Standalone QR-Code-App nutzt Shared-i18n fuer UI, Fehler, Confirm und Toasts.
QR-Typen/Labels verwenden die gleichen Keys wie das Embedded-Widget.

Etappe: I18n Shortener (Standalone)

Standalone Shortener laedt UI-Translations ueber Shared-i18n in svelte-i18n (DB als Quelle).

Etappe: I18n WordClock (Standalone)

WordClock laedt Zeittexte und UI-Labels aus der DB (Shared-i18n), mit Fallback auf timeTexts.json.
Arrays werden aus DB-Strings rekonstruiert (Texts/PrefixRules).

Etappe: I18n Blood (WebApp)

Blood nutzt Shared-i18n im LanguageStore (DB-Quelle), inkl. globaler Spracheinstellung.
Sprachliste wird aus der DB bezogen; Fallback bleibt lokal verfuegbar.
Seed-Texte liegen in der DB (Translation-Collection); keine Dateien.

Etappe: I18n Qr-Code-Doorbell (Platform + App)

Doorbell-Beschreibung ist in den Plattform-Translations unter app.description.qrshortdoorbell hinterlegt.
Plattform-Texte fuer Doorbell-UI sind in der DB hinterlegt.

Etappe: Layout + Umlaute (MultiApps) (verworfen)

Verworfen: keine belegbare Aenderung gefunden.

Etappe: Landing i18n (Apps + Menue + Buttons)

App-Titel, Buttons und Menueeintraege in Landing nutzen jetzt t()-Keys.
Kurzbeschreibungen der Apps werden ueber app.description.<slug> geladen.
Games-Landing zeigt i18n-Kurzbeschreibungen fuer alle drei Spiele.

Etappe: App-Vorschlaege im Footer

Footer-Modal nutzt jetzt den Titel "Korrektur vorschlagen" und laedt alle Texte aus der DB.
Wenn zuletzt eine App genutzt wurde, wird die App im Modal angezeigt und als App-Vorschlag gespeichert.
Backend speichert App-Vorschlaege mit type=app, appSlug und Status neu.

Etappe: Translation-Konsolidierung (DB)

Translation-Model/Controller unterstützen jetzt app-übergreifende Einträge ueber apps.
Home-Translations setzen app.description.* und app.long_description.* fuer alle Apps im Eintrag.
Seed-Script konsolidiert Übersetzungen nach identischem Key+Text und aktualisiert die DB-Einträge.
Übersetzungen liegen ausschließlich in der DB; keine Übersetzungsordner im Code.

Etappe: Translation-Backfill (API)

Backfill-Endpoint ergänzt, der fehlende Übersetzungen automatisch uebersetzt und speichert.
Fehlende Sprachen werden per 1:1-Textkopie (bevorzugt de/en) ergänzt, ohne externe Übersetzungsdienste.
Translation-Controller behandelt Map- und Objekt-Strukturen robust beim Lesen.
Translation-Controller toleriert Konflikte zwischen String- und Objekt-Keys (z.B. app.title vs. app.title.*).
Landing laedt home/init ohne Cache, damit Sprachwechsel sicher greifen.
Footer-Rechtezeile nutzt nun i18n-Keys.
Home-Controller gibt Übersetzungen auch bei fehlenden Sprach-Sätzen zurück (kein "translating" Block mehr).
Landing merged Platform-Translations explizit nach dem home/init, damit Header/Footer sicher aktualisiert werden.
Landing erzwingt bei Sprachwechsel ein Re-Render von Header/Stats/Footer ueber #key selectedLang.
Home-Controller beruecksichtigt Plattform-Keys auch dann, wenn sie via apps dedupliziert sind.
Landing aktualisiert t() reaktiv, damit Übersetzungen ohne Reload erscheinen.
Landing-Layout: Nav, Content-Container und Footer erhalten kleinere Padding-Werte fuer Mobile-First.
App-Titel in der Nav bekommt ein nicht umbrechbares Leerzeichen fuer minimalen Abstand.
Footer-Padding reduziert und mt-auto entfernt, damit der Footer nicht nach unten wandert.
Hauptlayout nutzt h-screen + overflow-hidden, damit Nav/Footer sticky bleiben und die Hero-Section scrollt.
Dummy-Werbebanner ergänzt: Mobile ueber dem Footer, Desktop/Tablet links/rechts/bottom.
Werbebanner werden nur fuer Nicht-Paid/AdFree/Non-Admin angezeigt; Content-Container bekommt seitliche Reserve, damit Karten nicht ueberdeckt werden.
Auto-Tag Script fuer Ads in frontend-svelte/index.html eingebunden.

Etappe: App-Start Buttons (Landing/Profil/Modal)

Start-Buttons in Landing, Profil und App-Modal nutzen jetzt eine gemeinsame Start-Logik, die eingebettete Apps in der Hero-Section oeffnet.

Etappe: App-Tier Anzeige in App-Ansichten

In eingebetteten App-Ansichten wird der aktuelle Status (Free/Paid/Admin) inkl. verbleibender Free-Tage angezeigt.

Etappe: Paid/Free Aktivierung im App-Modal

Free-Tier, abgelaufene Free-Tier und Paid-Aktivierung werden im App-Modal generisch pro Slug angeboten.
Free-Tier-Aktivitaet beachtet jetzt Ablaufdatum, Paid-Aktivierung nutzt /api/v1/billing/checkout.
Werbe-Logik zeigt Ads in App-Ansichten nur, wenn die aktive App nicht als Paid/AdFree markiert ist.
Paid-Jahresbetrag ist jetzt leer und zeigt nur den Placeholder "min. 12€/Jahr".

Etappe: Blood Paid-Ablaufdatum im Titel

Blood-App zeigt Paid-Ablaufdatum direkt neben dem Titel (aus /api/v1/auth/apps), die separate Statuszeile in der Landing wurde entfernt.

Etappe: Access-Label fuer alle Apps

Gemeinsamer Helper shared/appAccess.js liefert Access-Label (Paid/Free-Tier) pro App.
Alle eingebetteten Apps zeigen den Access-Status neben dem jeweiligen App-Titel.

Etappe: Free-Tier Ablaufschutz (App-Start)

Starten von Apps blockiert jetzt abgelaufene Free-Tiers und zeigt ein Modal mit Hinweis + Paid-Option.

Etappe: Nav/Footer Border (verworfen)

Verworfen: kein belegbarer Border im aktuellen Layout.

Etappe: Nav/Footer Ebenen

Nav und Footer liegen ueber dem Content (hoher z-index), Content-Scrollbereich liegt darunter.
Footer zeigt das aktuelle Jahr dynamisch an und hat hoechsten z-index.
Content-Scrollbereich hat jetzt immer Bottom-Padding, damit der Footer-Border nicht ueberdeckt wird.
Footer ist zusaetzlich isoliert und hat hoechsten Stack, damit der Border sichtbar bleibt.
App-Container hat unteren Abstand, damit er nicht in den Footer läuft.
Scroll-Container nutzt ein Footer-Height-Offset, damit der Footer-Border sichtbar bleibt und Scrollen aktiv ist.
Nav und Footer sind auf z-50, Content-Container explizit auf z-0.

Etappe: Paid-Aktivierung Start

Nach erfolgreicher Paid-Aktivierung startet die gewaehlte App sofort aus dem Modal.

Etappe: Games Aktivierung Mapping

Games-Modal aktiviert/paid jetzt den ersten Game-Slug, damit die Games-Ansicht nicht im Freischaltungs-Kreis haengt.
Free-Tier fuer Games nutzt nun den ersten noch nicht aktivierten Game-Slug und blockt, wenn alle belegt sind.

Etappe: App-Name in User-Apps

User-Apps speichern jetzt appName zusaetzlich zur appId (Activation, Billing, GrammarAI, Admin-Add, Seed).

Etappe: Backfill appName

Script backend/scripts/backfillUserAppNames.js fuellt fehlende appName in User-Apps nach.

Etappe: QR‑Shortdoorbell prüfen

Owner‑Profile und QR‑Erzeugung
Server‑seitige QR‑Generierung
Tier‑Regeln, Radius/GPS‑Validierung
Keine Kontaktanzeige im Free‑Tier
Integration in dev‑Proxy (nach Server‑Start)

Audit: AblaufProtokoll Verifikation (2026-01-20)

Geprueft per statischer Code-Inspektion (ohne Runtime-Tests). Abweichungen zum aktuellen Stand:

Dev-Start via Concurrently: npm run dev nutzt scripts/dev.js (kein nodemon/concurrently mehr).
Login sichtbar auf Landingpage: Quick-Login ist nicht mehr vorhanden (spaeter wieder entfernt).
App-Start Static Routing + Dashboard Label: Priorisierung public/dist/build ist im aktuellen backend/server.js nicht vorhanden.
Public-Ordner deaktiviert: Root xxpublic/ ist nicht vorhanden; frontend-svelte buildt nach ../public/ui.
Einbettung rueckgebaut + Games umbenannt: Blood/Wasser/Games sind aktuell wieder eingebettet (frontend-svelte/src/apps/*).
Landing stabilisiert + doppelte Assets entfernt: frontend-svelte/src/apps/BloodApp.svelte und frontend-svelte/src/apps/WasserReminderApp.svelte sind vorhanden (nicht entfernt).
Blood/Wasser/Games Assets in frontend-svelte/public/*: Verzeichnisse assets/, games/, wasser/ existieren nicht mehr.
Shortener-URL Schema: UI und Backend nutzen weiterhin /s/ (backend/server.js, apps/shortener/src/components/Dashboard.svelte).
QR-URL nur Slug / Slug-Validierung: aktueller QR-Generator nimmt echte URLs, kein Slug-Input im UI.
GrammarAI Fix (Translations Import): translations.ts wird nicht importiert; apps/grammarAi/WebApp/src/lib/i18n.js nutzt shared/i18n.js.
I18n-Quellen: Es existieren noch Übersetzungsdateien im Repo (z.B. apps/blood/WebApp/src/lib/lang, apps/wasserReminder/public/wasser/js/languages, apps/shortener/public/languages, apps/WordClock/timeTexts.json).
Sensitive Dateien entfernt: anmeldeDaten.txt ist noch im Root vorhanden.

Etappe: App-Flags (running/translated/isSvelte)

App-Schema um flags erweitert (backend/models/App.js).
Sync-Script setzt fehlende Flags standardmaessig (backend/scripts/syncAppRegistry.js).
npm run db:sync:apps ausgefuehrt.

Etappe: Svelte-Fallbacks in DB seed

Script backend/scripts/seedSvelteFallbacks.js erstellt (Svelte t()/translate() Fallbacks als de).
28 Sprachen per Copy-Backfill gesetzt (keine externen Quellen).
Script in Root-package.json als db:seed:svelte-fallbacks registriert.
npm run db:seed:svelte-fallbacks ausgefuehrt.

Etappe: WordClock State API

WordClock-Logik serverseitig bereitgestellt (backend/utils/wordClock.js).
Endpoint /api/v1/wordclock/state liefert Matrix + aktive Positionen.
WordClock-Frontend ruft den Server-State zyklisch ab (apps/WordClock/WebApp/src/App.svelte).

Naechste Schritte (fixe Reihenfolge)

Games (2048+/Wordle+/Fruits+) serverseitig + i18n komplett
QrCodeGenerator serverseitig (Payload-Logik) + i18n komplett
Shortener serverseitig (Validation/URL-Logik) + i18n komplett
Blood/WasserReminder/GrammarAi serverseitig + i18n komplett

Etappe: Games (2048+/Wordle+/Fruits+) serverseitig + i18n komplett

2048+ Logik auf Server verlagert (Session + Moves + AI) und Client auf API umgestellt.
Wordle+ nutzt Server-Sessions fuer Tageswort, Gueltigkeitspruefung und Farben; Client sendet Guesses.
Fruits+ Match-3 Engine serverseitig (Swaps, Powerups, Matches, Bonuspunkte) inkl. Hint-API; Client rendert nur noch State.