Rosie — Architektur, Security, Betrieb

Rosie ist eine Vanilla-JS-PWA. Die Anwendung läuft als Node-Prozess auf einer Debian-Instanz bei Infomaniak in der Schweiz, davor Caddy als Reverse-Proxy mit automatischer Zertifikatsverwaltung. Persistenz erfolgt über libSQL/SQLite auf derselben Instanz (WAL-Modus), Objektspeicher über den S3-kompatiblen Objektspeicher von Infomaniak. Der Service Worker arbeitet mit einem CACHE_PREFIX pro Release. Der öffentlichen Website ist ein Schutzdienst vorgelagert — er hält keine Daten, die Schnittstelle läuft direkt auf die Schweizer Instanz.

• Hauptdomain: rosie-app.ch (inkl. www).
• Aliase / Mirror: rosie-planer.com — als 301-Redirect. Edge-Cache ~2 min stale-Window beachten (per-PoP-Lag, selbst-konvergierend). Sofortprüfung der Origin via ?cb=<random>.
• App-Subdomäne: die Anwendung läuft unter einem eigenen Namen, der direkt auf die Schweizer Instanz zeigt («nur DNS», ohne vorgelagerten Dienst).
• Kein Wildcard-Eintrag. *.rosie-app.ch existiert nicht — ein erfundener Name löst nicht auf. Das ist Absicht und schliesst die Subdomain-Übernahme aus.
• Vorgelagerter Schutzdienst nur für die öffentliche Website; er hält keine Kundendaten.

• sw.js mit CACHE_PREFIX, gestempelt aus shared/version.mjs (scripts/sync-version.mjs).
• Edge-Cache: ~2 min stale nach Deploy (per-PoP-Lag, selbst-konvergiert).
• immutable-Cache-Header (r166 B4) für versionierte Assets.
• Lazy-loaded Vendors via _loadVendor — XLSX, html2canvas (r166 B2).
• iOS-Splash-PNG-Pflicht — WebP-Drop seit r168 B8.
• Kein Background-Sync — bewusst: ein Replay ohne offenen Tab hätte keinen frischen JWT und riskierte ohne Idempotenz-Keys Doppelbuchungen. Die Chat-Outbox flusht nur bei geöffneter App (s. docs/OFFLINE.md).
• Web-Push auf iOS nur in installierter PWA — Add-to-Homescreen erzwingen.

• VAPID-Schlüssel (öffentlich / privat) liegen als Secrets auf der Instanz unter /etc/rosie/env.
• subscribeToPushNotifications ist ein idempotenter UPSERT.
• Quiet Hours werden respektiert.
• Ein/Aus pro Alarm-Kategorie: bounty · planPublished · adminAlert · messages · absenceResult.

• Nur ausgehend HTTPS 443.
• Freigabe für rosie-app.ch und die App-Subdomäne. Weitere Ziele sind nicht nötig — die App ruft von sich aus keine Dienste beim Kunden auf.
• Keine eingehenden Ports.
• WebSocket nicht erforderlich — die App ist polling-basiert (60 s).

Versand über SMTP auf ein Schweizer Postfach bei Hostpoint. Absender aller System-Mails ist support@rosie-app.ch — eine antwortbare Adresse, keine No-Reply-Sackgasse. SPF, DKIM und DMARC sind gesetzt; wir empfehlen, die Zustellung nach dem Erst-Setup einmal gegen den Spamfilter des Kunden zu testen.

• iOS 14.5+, Android 8.0+.
• PWA — kein App-Store-Paket.
• MDM kann bevorzugte Browser, Homescreen-Webclips und vertrauenswürdige Websites konfigurieren.
• Beachten: Web-Push auf iOS = installierte PWA Pflicht; iOS-Splash PNG (kein WebP).

Migrationen liegen unter database/migrations/ fortlaufend nummeriert und werden ausschliesslich vorwärts angewendet. Der jeweils aktuelle Stand steht im Verzeichnis selbst — diese Seite nennt bewusst keine Nummer, weil sie sonst beim nächsten Release falsch ist. Nach jedem Lauf folgt eine Schema-Verifikation. Die Migrationen sind so gebaut, dass sich eine leere Datenbank vollständig aus ihnen aufbauen lässt.

• Automatische Backups der Datenbank, verschlüsselt und ausser Haus abgelegt.
• Wiederherstellungsfenster 30 Tage mit stündlichen Wiederherstellungspunkten (RPO ≤ 1 Stunde).
• Objektspeicher wird eigenständig gesichert.
• Vollständiger Datenexport pro Mandant jederzeit über die Verwaltungsoberfläche.
• Keine geografische Redundanz. Es läuft bewusst eine Produktivinstanz — ein Neustart oder eine Aktualisierung bedeutet eine kurze Unterbrechung. Das ist ein bekannter, angenommener Kompromiss und ohne Architekturänderung nachrüstbar.

Zu jedem Release gehört ein Tag checkpoint-rNNN-deployed im Quellcode-Verwaltungssystem. Damit ist jederzeit belegbar, welcher Stand wann produktiv war.

• Server-seitige Tenant-Skopierung — tenant_id in jedem Query.
• In-Memory tenant-Globals werden bei Logout via _resetTenantCalendarData() geleert (6 Kalender-Globals).
• Cross-Tenant-Leak-Tests fixiert (blockDates-Lesson, vacations-Tenant-Reset).
• Persist-Trigger über Tenant-Marker companySettingsDirty.

• X-Worker-Version (r166 A10), X-Request-Id (r166 B1) in jeder Response.
• Web Vitals (r167 B5) → /api/analytics, keepalive-fetch, DNT respektiert.
• PII-Scrubbing-Regex (r166 A6) vor Analytics.
• k-Anonymität ≥ 4 für Aggregate-Charts.
• Logs liegen auf der Instanz (systemd/journald) und werden vom Hersteller ausgewertet; ein externer Verfügbarkeits-Monitor prüft die Erreichbarkeit und alarmiert.

• LCP / CLS / INP-Ziele als Performance-Budget.
• CLS-Fix r168 B8: width / height auf <img>-Tags.
• Lazy-Vendors via _loadVendor — XLSX / html2canvas.
• Battery-Save: Polling pausiert bei document.hidden (Visibility-Pause, r168 B3).

• KI-Anbieter: pro Mandant zuschaltbar; je Zweck ein fester Dienst, ohne automatischen Ausweichdienst (Fallback). Welcher Anbieter eingesetzt wird, steht im Sub-Bearbeiter-Verzeichnis des AVV — nicht hier, damit diese Seite bei einem Wechsel nicht falsch wird.
• Rate-Limit: 30 Anfragen pro Stunde pro User.
• PII-Sanitizer entfernt E-Mail, AHV-Nummer, IBAN, Telefon und Datum vor jedem Aufruf des KI-Dienstes.
• KI-Cron-Schedules 0 2 / 0 4 für Task-Pattern-Learner — Prompts ohne staff.id.
• Spracherkennung: übernimmt der Browser (Web Speech API); je nach Browser bzw. Betriebssystem geht die Aufnahme dafür an dessen eigenen Spracherkennungsdienst — ROSIE erhält und speichert keine Audioaufnahmen. Zur Befehls-Erkennung geht nur der erkannte Text an den KI-Dienst, mit Einwilligung (Art. 6 Abs. 6 revDSG).

Optionale Lizenz-Module: Qualitätsmanagement (QMS), Voice-to-Schedule, Lohnvorbereitung & Finanzen, Smart Matchmaker, Belastungs-Radar, Regio-Netzwerk. Aktivierung pro Tenant über Admin → Tools.

• Globaler ESC + Focus-Trap (r166 A8).
• ARIA-progressbar (r166 A9).
• 4 App-Sprachen: DE / FR / IT / EN.
• 14 Chat-Sprachen für die interne Kommunikation — die Übersetzung läuft im Gerät.

• Secrets liegen in /etc/rosie/env auf der Instanz, nur für den Dienstbenutzer lesbar: Signaturschlüssel der Sitzungen, VAPID-Schlüsselpaar, Zugangsdaten für Objektspeicher, SMTP und den KI-Dienst.
• JWT jährlich rotieren.
• VAPID-Rotation invalidiert Push-Subs (bekannte Schuld).
• Passwort-Hashing: PBKDF2-SHA-256 mit Salt, in vier verketteten Runden zu je 100 000 Iterationen (400 000 effektiv).

Die Einrichtung eines Mandanten erfolgt beim Hersteller auf der Schweizer Instanz. Beim Kunden ist keine Installation nötig — keine Server, keine Agenten, keine eingehenden Ports. Was hier steht, ist die Liste der Punkte, die tatsächlich auf der Kundenseite liegen.

Ablaufbeschreibungen liegen vor für: Anmeldefehler · Datenbankfehler · Deploy-Fehler · E-Mail-Zustellung · KI-Ausfall · Push-Zustellung · Migrationsfehler.

• Verschlüsselte Übertragung (TLS).
• Feldweise Verschlüsselung. Vertrauliche Felder wie Diagnosen, Arztzeugnisse, Mutterschutzangaben, AHV-Nummer und IBAN; stündliche Sicherungen verschlüsselt (age).
• Datenhaltung Schweiz (Infomaniak): Rechenleistung, Datenbank, Objektspeicher und Backups. Der vorgelagerte Schutzdienst der öffentlichen Website und der Zahlungsdienstleister stehen namentlich im Sub-Bearbeiter-Verzeichnis des AVV.
• AVV vorhanden.
• Keine Cookies / kein Tracking — DNT respektiert.
• Schlüsselvernichtung als operativer Widerruf; Löschung innert 30 Tagen nach Vertragsende mit schriftlichem Nachweis.
• SSO (SAML/OIDC) ist nicht verfügbar und in Evaluation; ein verbindlicher Termin besteht nicht. Anmeldung per E-Mail und Passwort, optional mit TOTP.