rebreak-monorepo/docs/specs/diga/05-software-lifecycle-architektur-soup-v0.md

Dok 05 — Software-Lifecycle, Architektur & SOUP (v0)

Bezug: IEC 62304 §4.3 (Software-Sicherheitsklassifizierung), §5.1 (Software- Entwicklungsplanung), §5.3 (Software-Architektur), §5.3.3 + §8.1.2 (SOUP), §8 (Konfigurationsmanagement) Norm-Kontext: ISO 14971 (Risiko), MDR Anh. I GSPR §17, Anh. II (Technische Doku) Status: Entwurf v0 — Architektur + SOUP aus dem Code/Graph abgeleitet. Kein freigegebener Lifecycle-Plan, keine bestätigte Klassifizierung. Drafting: Claude (aus Code-Manifesten + graphify-Knowledge-Graph). Validierung durch Regulatory-/QM-Profi ausstehend. Einordnung: Liefert die Architektur- + SOUP-Basis für Dok 05b (Verifikation) und Dok 05d (Traceability). Klassifizierung (§1) ist Vorschlag — finale Klasse via Dok 02 (BfArM-Beratung). Andockpunkte: Dok 03 (Requirements), Dok 04 (Risiko-Akte), Dok 08 (DSFA).

---

0. Ehrliche Einordnung

Architektur (§2) und SOUP-Liste (§3) sind aus den realen Package-Manifesten (package.json) und dem graphify-Knowledge-Graph abgeleitet — d. h. sie spiegeln, was tatsächlich im Code referenziert wird, nicht eine Wunsch-Architektur. Verisonen sind die in package.json deklarierten Ranges; die exakt aufgelösten Versionen stehen in pnpm-lock.yaml und müssen für den finalen SOUP-Record dort gepinnt abgelesen werden. Die Sicherheitsklassifizierung (§1) ist ein begründeter Vorschlag, keine bestätigte Einstufung — das ist Dok-02-/BfArM-Sache.

Scope v0: vollständig für die zwei DiGA-Kern-Komponenten Backend (Nitro-API) und Native-App (Expo/React Native). Die Desktop-Schutz-Apps (rebreak-magic-mac SwiftUI, rebreak-magic-win Tauri/Rust), admin und marketing sind als Komponenten benannt, ihre SOUP-Detaillierung folgt in v1.

---

1. Software-Sicherheitsklassifizierung (IEC 62304 §4.3) — Vorschlag

IEC 62304 klassifiziert je Software-Item nach möglichem Schadensbeitrag: A (keine Verletzung möglich), B (nicht-schwere Verletzung), C (Tod/schwere Verletzung).

Software-Item	Vorgeschl. Klasse	Begründung (→ Dok 04 Risiko)
Lyra-Krisen-Pfad (crisis-filter.ts, SOS-Coach, LLM-Antwort)	B (ggf. C)	R-LYRA-01 (verpasste Krise/Suizidalität, S4) — Fehlverhalten kann zu unterlassener Hilfe in akuter Krise beitragen. Klasse durch Profi/BfArM bestätigen.
Schutz/Blocker (DNS-/NEFilter, Setup, Cooldown)	B	R-FALSE-01 (falsche Sicherheit bei inaktivem Schutz) — Fehlfunktion untergräbt die therapeutische Schutzwirkung, ohne direkte Verletzung.
Selbstbindung/Release (Magic, Device-Lock)	B	R-BYP-03 (legitimer Ausstieg scheitert) — fehlerhafte Sperre kann Nutzer aussperren.
Community/DM, Profil, Streak, Mail-Schutz	A–B	Keine direkte Verletzungsgefahr; Anonymitäts-/Datenschutz-Relevanz über Dok 08.

⚠️ Vorschlag, nicht bestätigt. Die Gesamt-Systemklasse richtet sich nach dem höchsten Item (hier B, mit C-Prüfbedarf für den Krisen-Pfad). Bestätigung = Dok 02.

---

2. Software-System-Architektur (IEC 62304 §5.3)

2.1 Komponenten-Dekomposition

ReBreak System (pnpm-Monorepo)
│
├─ rebreak-native        Patienten-App (Expo / React Native, iOS + Android)   [KERN]
│   ├─ app/, components/, hooks/, stores/ (Zustand), lib/, locales/
│   └─ modules/rebreak-protection   nativer Schutz-Layer
│        ├─ ios/   NEFilter (Content/URL-Filter), PacketTunnel  (Swift)
│        └─ android/ DnsFilter VPN-Service + a11y-Layer          (Kotlin)
│
├─ backend               Standalone-API (Nitro/Nitropack, Node ESM)           [KERN]
│   ├─ server/api/        HTTP-Handler (coach/SOS, magic, streak, profile, mail …)
│   ├─ server/utils/      crisis-filter, cooldownToken, lyraMemoryExtract …
│   ├─ server/db/         Prisma-DB-Layer (devices, cooldown, streak …)
│   ├─ prisma/            Schema + Migrations (PostgreSQL, Schema `rebreak.*`)
│   └─ imap-idle/         IMAP-IDLE-Daemon (Mail-Agent, Auto-Delete Trigger-Mails)
│
├─ rebreak-magic-mac     Desktop-DNS-Schutz (SwiftUI)              [Legend, v1-SOUP]
├─ rebreak-magic-win     Desktop-DNS-Schutz + SYSTEM-Tamper-Service (Tauri 2 / Rust) [Legend, v1-SOUP]
├─ admin                 Moderation/Admin-UI (Nuxt SSR)           [intern, v1-SOUP]
└─ marketing             Marketing-Site + /preview (Nuxt)         [nicht-DiGA, v1-SOUP]

2.2 Zentrale Schnittstellen (Datenflüsse)

• App ↔ Backend: HTTPS (REST) + SSE-Streaming (Lyra-Antworten, react-native-sse).
• Backend ↔ LLM: Groq (groq-sdk) für Lyra Pro; OpenAI-SDK-kompatibler Pfad (openai) für Legend/Haiku. → Drittland-Transfer, Dok 08 R-DATA-05.
• Backend ↔ DB: Prisma + pg → PostgreSQL (Schema rebreak.*).
• Backend ↔ Push: APNs (@parse/node-apn, VoIP) + Expo Push (expo-server-sdk).
• Backend ↔ Mail: IMAP (imapflow) für Trigger-Mail-Erkennung/-Löschung.
• App ↔ OS-Schutz: NEFilter (iOS) / VPN-DnsFilter (Android) über rebreak-protection.
• Auth/Sessions: Supabase (@supabase/supabase-js) + JWT (jose).
• Zahlungen: Stripe (stripe) — Pro/Legend-Tiers.

2.3 Architektur-Belege aus dem Graph

God-Nodes (höchste Konnektivität) bestätigen die Architektur-Hubs: usePrisma() (DB-Backbone, 299 Kanten), blocker/protection (Schutz-Hub), useColors() (UI-Theming-Bridge). Die Krisen-/Schutz-Pfade sind über Dok 05d code-verknüpft.

---

3. SOUP-Liste (IEC 62304 §5.3.3, §8.1.2)

SOUP = Software of Unknown Provenance (Drittanbieter-Bibliotheken). Versionen = package.json-Ranges; finaler Record pinnt aus pnpm-lock.yaml. „Risiko-Hinweis" markiert Bibliotheken mit erhöhter Sicherheits-/Datenschutz-/Verfügbarkeits-Relevanz.

3.1 Backend (Nitro-API) — Runtime-SOUP

SOUP	Version	Zweck	Risiko-Hinweis
@prisma/client + @prisma/adapter-pg	^7.2.0	ORM / DB-Zugriff	Datenintegrität (Gesundheitsdaten)
pg	^8.16.3	PostgreSQL-Treiber	Datenintegrität
@supabase/supabase-js	^2.39.7	Auth / Sessions	Auth-Sicherheit
jose	^6.0.0	JWT-Signatur (u. a. Cooldown-Token)	Sicherheits-kritisch (Manipulationsschutz, REQ-Cooldown)
groq-sdk	^0.7.0	Lyra-LLM (Pro)	Drittland-Transfer (Dok 08 R-DATA-05) + Verfügbarkeit (Krisen-Pfad)
openai	^4.65.0	LLM-Pfad (Legend/Haiku-kompatibel)	Drittland-Transfer + Verfügbarkeit
imapflow	^1.2.18	IMAP-Zugriff (Mail-Agent)	Datenschutz-Oberfläche (Dok 08)
@parse/node-apn	^8.1.0	APNs Push (VoIP/Calls)	Zustellung
expo-server-sdk	^6.1.0	Expo Push Notifications	Zustellung
resend	^4.0.0	Transaktions-E-Mail	Datenschutz (PII in Mail)
stripe	^17.0.0	Zahlungen (Pro/Legend)	PCI / Zahlungsdaten
franc	^6.2.0	Sprach-Erkennung (Text)	Niedrig
zod	^3.23.8	Eingabe-Validierung	Robustheit (positiv)

3.2 Native-App (Expo/RN) — sicherheits-/schutzrelevante SOUP (Auswahl)

Die App hat ~60 Runtime-Dependencies; hier die schutz-/sicherheits-/datenrelevanten. Vollständige Liste = apps/rebreak-native/package.json.

SOUP	Version	Zweck	Risiko-Hinweis
expo + expo-modules-core	^54.0.34 / ^3.0.30	App-Framework / Native-Bridge	Plattform-Basis
react-native	0.81.5	UI-Runtime	Plattform-Basis
expo-local-authentication	~17.0.8	Biometrie (App-Lock)	Schutz-Gate (REQ-PROT)
expo-notifications	~0.32.17	Push (u. a. Schutz-Tamper-Warnung)	Schutz-Signalisierung
@react-native-async-storage/async-storage + react-native-mmkv	^2.1.2 / ^3.1.0	lokaler State (u. a. Bypass-Flag everActiveHere)	R-FALSE-01-relevant
@supabase/supabase-js	^2.46.0	Auth / Session / Realtime	Auth-Sicherheit
react-native-webrtc + react-native-callkeep + react-native-voip-push-notification	^124 / ^4.3 / ^3.3	VoIP-Calls (Peer-Support)	Verfügbarkeit/Datenschutz
react-native-sse	^1.2.1	Lyra-Streaming-Empfang	Krisen-Pfad-Verfügbarkeit
i18next + react-i18next	^23.16 / ^15.1	Lokalisierung (DE/EN/FR/AR)	Korrektheit (Krisen-Texte)
zustand	^5.0.0	App-State-Stores	Robustheit
valibot	^1.2.0	Eingabe-Validierung	Robustheit (positiv)

3.3 Build-/Test-Tooling (kein Runtime-SOUP, IEC §5.1.9)

nitropack, prisma (CLI), typescript, vitest + @vitest/coverage-v8, expo-CLI, @babel/core, tailwindcss/nativewind. Build-Zeit-Werkzeuge — relevant für Reproduzierbarkeit des Builds, nicht als Runtime-SOUP zu bewerten.

3.4 SOUP-Anomalie-Bewertung (§7.1.2) — offen

Für jede sicherheits-relevante SOUP (Risiko-Hinweis oben) ist noch eine dokumentierte Bewertung bekannter Anomalien (CVEs, Issue-Tracker, EOL-Status) zu erstellen. Bislang nicht durchgeführt → offener Punkt (siehe §5).

---

4. Software-Entwicklungs-Lifecycle & Konfigurationsmanagement (§5.1, §8)

Aspekt	Ist-Zustand
Repo / Struktur	pnpm-Monorepo, ein Git-Repository (rebreak-monorepo)
Versionskontrolle	Git; Branches + Commits; Konfig-Items über package.json/Lockfile versioniert
Build	Backend: prisma generate + nitro build → .output. App: EAS / Expo prebuild
CI/CD	GitHub Actions → Build-Artefakt → scp auf Hetzner → pm2-Restart (deploy-staging.yml)
Secrets	Infisical (infisical run-Wrapper) — keine .env-Dateien im Repo
DB-Migrationen	Prisma Migrations (baselined); Schema rebreak.* (PostgreSQL)
Release-Versionierung	App: package.json + app.config.ts + native Manifeste; Changelog via NEXT_RELEASE.md
Test	Vitest (Backend, 21 Dateien), Maestro E2E (App), Lyra-Eval-Suite (Dok 05b/05c)

Lücken (§5.1): Kein formaler, freigegebener Software-Entwicklungsplan als eigenes Dokument; CI deckt Backend-Deploy ab, aber Maestro/E2E läuft nur lokal (Dok 05b §4.2).

---

5. Offene Punkte (Richtung formaler IEC-62304-Konformität)

1. Klassifizierung bestätigen (§1) — via Dok 02 / BfArM-Beratung; Krisen-Pfad auf B vs. C prüfen.
2. SOUP-Versionen pinnen — exakt aus pnpm-lock.yaml statt package.json-Ranges.
3. SOUP-Anomalie-Bewertung (§3.4) je sicherheits-relevanter Bibliothek erstellen.
4. v1-SOUP für rebreak-magic-mac/win (inkl. Rust-Crates des SYSTEM-Tamper-Service), admin, marketing ergänzen.
5. Formaler Software-Entwicklungsplan (§5.1) als eigenes Dokument.
6. Architektur-Detaillierung je Software-Item bis Unit-Ebene + Schnittstellen- Spezifikation (§5.3.x) für die Klasse-B/C-Items (Krisen-/Schutz-Pfad).

---

v0-Erst-Entwurf. Architektur + SOUP sind code-belegt (Manifeste + Graph); Klassifizierung und Anomalie-Bewertung sind Vorschläge bzw. offen. Nicht ohne Regulatory-/QM-Validierung als Teil der finalen Technischen Akte verwenden.