577a478c2d
- 05: Software-Lifecycle/Architektur/SOUP, code-belegt aus package.json-Manifesten + graphify-Graph; IEC-62304-Klassifizierungs-Vorschlag (B, ggf. C Krisen-Pfad) - 05d: Traceability Anforderung<->Risiko<->Code fuer Lyra- + Schutz/Selbstbindungs- Strang (27 graph-abgeleitete traceability-Kanten) - 00: 05 + 05d im Dossier-Plan registriert - 05b: Gap 'Fehlende Traceability-Matrix' verweist jetzt auf 05d Alle v0-Entwuerfe; Regulatory-/QM-Validierung ausstehend. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
186 lines
11 KiB
Markdown
186 lines
11 KiB
Markdown
# 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.*
|