# 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.*