diff --git a/docs/specs/diga/00-dossier-plan.md b/docs/specs/diga/00-dossier-plan.md index 7edf1bf..e89c975 100644 --- a/docs/specs/diga/00-dossier-plan.md +++ b/docs/specs/diga/00-dossier-plan.md @@ -28,8 +28,9 @@ macht BfArM-Beratung + Regulatory-Berater produktiv) → dann Profi validieren l | 02 | Klassifizierung (Rule 11 → I/IIa) | MDR Anh. VIII | Profi (BfArM-Beratung) | offen — **Kostenhebel** | | 03 | Anforderungen / Requirements | IEC 62304 | Claude (aus App) | **v0 angelegt** (57 REQ-IDs) | | 04 | Risikomanagement-Akte | ISO 14971 | Claude-Erstliste + du | **v0 angelegt** (Erstliste) | -| 05 | Software-Lifecycle + Architektur + SOUP | IEC 62304 | Claude (aus Code) | offen | +| 05 | Software-Lifecycle + Architektur + SOUP | IEC 62304 | Claude (aus Code) | **v0 angelegt** (Architektur + SOUP code-belegt) | | 05b | Software-Verifikation: Test-Nachweis | IEC 62304 §5.5–5.7 | Ahmed (Test-Agent) | **v0 angelegt** | +| 05d | Traceability-Matrix (Anf. ↔ Risiko ↔ Code ↔ Test) | IEC 62304 §5.1.1/§5.5.2/§7.4 | Claude (aus Graph) | **v0 angelegt** (Lyra-Strang) | | 06 | Klinische Bewertung (Plan + Report) | MDR Anh. XIV | Profi + Uni Bremen | offen | | 07 | Gebrauchsanweisung / Labeling | MDR | Claude-Entwurf | offen | | 08 | DSFA + IT-Sicherheit | BfArM-DiGA-Anf. | Claude-Struktur + Profi | **v0 angelegt** (hans-mueller) | diff --git a/docs/specs/diga/05-software-lifecycle-architektur-soup-v0.md b/docs/specs/diga/05-software-lifecycle-architektur-soup-v0.md new file mode 100644 index 0000000..5d6620e --- /dev/null +++ b/docs/specs/diga/05-software-lifecycle-architektur-soup-v0.md @@ -0,0 +1,185 @@ +# 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.* diff --git a/docs/specs/diga/05b-test-verifikation-v0.md b/docs/specs/diga/05b-test-verifikation-v0.md index 008dc09..77856a6 100644 --- a/docs/specs/diga/05b-test-verifikation-v0.md +++ b/docs/specs/diga/05b-test-verifikation-v0.md @@ -195,7 +195,7 @@ Anforderung (Dok 03) ### 3.2 Ist-Zustand der Traceability -Derzeit existiert keine formale Traceability-Matrix. Die Verbindung zwischen Tests und Anforderungen ist implizit: +Eine *formale, validierte* Traceability-Matrix existiert noch nicht. Ein graph-abgeleiteter v0-Erst-Entwurf für den Lyra-/Krisen-Strang liegt in **Dok 05d** vor (INFERRED-Zeilen noch zu bestätigen); für die übrigen Stränge ist die Verbindung zwischen Tests und Anforderungen weiterhin implizit: - Die Kommentare in den Maestro-YAML-Flows beschreiben *was* geprüft wird, aber referenzieren keine Anforderungs-IDs. - Die Vitest-Tests referenzieren keine Risiko-IDs aus Dok 04. @@ -229,7 +229,7 @@ Derzeit existiert keine formale Traceability-Matrix. Die Verbindung zwischen Tes | Kein Testplan-Dokument | IEC 62304 §5.6.1 verlangt einen dokumentierten Softwaresystem-Testplan mit Testmethodik, Abbruchkriterien, Akzeptanzkriterien | | Keine Soll-Ergebnis-Definition | Testfälle haben Assertions, aber keine formal dokumentierten "erwarteten Ergebnisse" als eigenständiges Artefakt | | Keine Ergebnis-Protokolle | Kein archivierter Pass/Fail-Record mit Build-Version, Datum, Tester-Identität | -| Fehlende Traceability-Matrix | Kein Mapping Tests ↔ Anforderungen ↔ Risiken | +| Traceability-Matrix nur teilweise | Erst-Entwurf für den Lyra-/Krisen-Strang in **Dok 05d** (graph-abgeleitet, INFERRED-Zeilen noch zu validieren). Übrige Stränge (Schutz/Blocker, Mail, Anonymität, Onboarding) fehlen noch. | | Kein API-Integrationstest (HTTP-Roundtrip) | Vitest-Tests testen nur DB-Layer-Funktionen, nicht die vollständigen HTTP-Handler-Chains inkl. Auth-Middleware | **Funktionale Lücken (Tests fehlen, aber nicht zwingend CI-Blocker):** diff --git a/docs/specs/diga/05d-traceability-matrix-v0.md b/docs/specs/diga/05d-traceability-matrix-v0.md new file mode 100644 index 0000000..9725567 --- /dev/null +++ b/docs/specs/diga/05d-traceability-matrix-v0.md @@ -0,0 +1,173 @@ +# Dok 05d — Traceability-Matrix: Anforderung ↔ Risiko ↔ Code ↔ Verifikation (v0) + +**Bezug:** IEC 62304 §5.1.1 (Software-Entwicklungsplan — Traceability), §5.5.2 +(Verifikation je Anforderung), §7.4 (Risikokontrollmaßnahmen ↔ Software) +**Norm-Kontext:** ISO 14971 Risikomanagement, MDR Anh. I (GSPR §17 — Software) +**Status:** Entwurf v0 — **maschinell aus dem Code-/Doc-Knowledge-Graph abgeleitet** +(graphify). Kein formaler, signierter Traceability-Record. +**Drafting:** Claude (aus Code + Dossier). Validierung durch Regulatory-/QM-Profi +ausstehend. +**Einordnung:** Schließt die in **Dok 05b §4.2** als *kritisch / DiGA-blockierend* +markierte Lücke **„Fehlende Traceability-Matrix (Tests ↔ Anforderungen ↔ Risiken)"** +— in dieser v0 für die **zwei sicherheitskritischsten Stränge: (a) Lyra/Krise** +(Dok 04 R-LYRA-01) und **(b) Schutz/Selbstbindung** (R-FALSE-01, R-BYP-03). +Andockpunkte: Dok 03 (Requirements), Dok 04 (Risiko-Akte), Dok 05c (Lyra-Eval), +Spec Protection Coverage & Streak. + +--- + +## 0. Ehrliche Einordnung (bitte zuerst lesen) + +Diese Matrix ist **kein** geprüfter Verifikationsnachweis. Sie ist eine aus dem +Knowledge-Graph (`graphify-out/graph.json`) abgeleitete **Erst-Verknüpfung** zwischen +Dossier-Artefakten und tatsächlichen Code-/Test-Symbolen. Jede Zeile trägt ein +Konfidenz-Flag: + +- **EXTRACTED (1.0)** — die Quelle benennt das Artefakt **wörtlich** (z. B. nennt die + Risiko-Akte die Datei `crisis-filter.ts`). Belastbar. +- **INFERRED (0.8–0.95)** — **Modell-Schlussfolgerung** aus funktionaler Übereinstimmung. + Plausibel, aber **durch einen Menschen zu bestätigen**, bevor sie als Nachweis gilt. + +Was hier **fehlt** und für einen formalen IEC-62304-Record noch nötig ist +(vgl. Dok 05b §4.2): Soll-Ergebnis-Definition je Testfall, archiviertes Pass/Fail- +Protokoll mit Build-Version + Datum, sowie die Ausweitung auf die noch offenen Stränge +(Mail-Schutz REQ-MAIL, Anonymitäts-Invariante, Onboarding/Streak-Vollabdeckung). + +--- + +## 1. Traceability-Logik (IEC 62304) + +``` +Anforderung (Dok 03) + └─ Risiko + Risikomaßnahme (Dok 04, ISO 14971) + └─ Code-Artefakt (Implementierung der Maßnahme) + └─ Verifikation (Test + Soll-Metrik, Dok 05b/05c) +``` + +Für den Lyra-/Krisen-Strang konkret: + +``` +REQ-LYRA (Dok 03 — Lyra KI-Coach & Krisen-Behandlung, höchste Sicherheitsrelevanz) + └─ R-LYRA-01 (Dok 04 — verpasste Krise/Suizidalität, S4, Top-Risiko) + └─ Maßnahme: Deterministischer Krisen-Keyword-Pre-Filter (crisis-filter.ts) + ├─ detectCrisis() backend/server/utils/crisis-filter.ts + ├─ getCrisisFallback() backend/server/utils/crisis-filter.ts + └─ SAFETY-REQ-LLM-001 (Dok 05c — Krisenreferenz-Pflicht, Recall 100 %) + └─ Verifikation: crisis-filter.test.ts → Metrik „Crisis-Detection-Recall" (Ziel 100 %) + +REQ-LYRA wird realisiert in: + ├─ CoachScreen() apps/rebreak-native/app/lyra.tsx (UI) + ├─ parseLyraResponse() apps/rebreak-native/lib/lyraResponse.ts (Reply-Parsing) + └─ sos-session.post.ts backend/server/api/coach/ (SOS-Coach-API) +``` + +--- + +## 2. Traceability-Matrix — Lyra-/Krisen-Strang (v0) + +| DiGA-Artefakt (Anforderung / Risiko / Metrik) | Quelle | → Code-/Test-Artefakt | Datei | Relation | Konfidenz | +|---|---|---|---|---|---| +| REQ-LYRA — Lyra KI-Coach & Krisen-Behandlung | `03-requirements-v0.md` | `detectCrisis()` | `backend/server/utils/crisis-filter.ts` | implementiert durch | INFERRED (0.90) | +| REQ-LYRA — Lyra KI-Coach & Krisen-Behandlung | `03-requirements-v0.md` | `sos-session.post.ts` | `backend/server/api/coach/sos-session.post.ts` | implementiert durch | INFERRED (0.85) | +| REQ-LYRA — Lyra KI-Coach & Krisen-Behandlung | `03-requirements-v0.md` | `CoachScreen()` | `apps/rebreak-native/app/lyra.tsx` | implementiert durch | INFERRED (0.85) | +| REQ-LYRA — Lyra KI-Coach & Krisen-Behandlung | `03-requirements-v0.md` | `parseLyraResponse()` | `apps/rebreak-native/lib/lyraResponse.ts` | implementiert durch | INFERRED (0.85) | +| R-LYRA-01 — verpasste Krise/Suizidalität (S4) | `04-risiko-akte-v0.md` | `detectCrisis()` | `backend/server/utils/crisis-filter.ts` | mitigiert durch | INFERRED (0.95) | +| Maßnahme: Krisen-Keyword-Pre-Filter (`crisis-filter.ts`) | `04-risiko-akte-v0.md` | `crisis-filter.ts` | `backend/server/utils/crisis-filter.ts` | implementiert durch | **EXTRACTED (1.0)** | +| Maßnahme: Krisen-Keyword-Pre-Filter (`crisis-filter.ts`) | `04-risiko-akte-v0.md` | `detectCrisis()` | `backend/server/utils/crisis-filter.ts` | implementiert durch | **EXTRACTED (1.0)** | +| SAFETY-REQ-LLM-001 — Krisenreferenz-Pflicht (Recall 100 %) | `05c-lyra-eval-v0.md` | `detectCrisis()` | `backend/server/utils/crisis-filter.ts` | implementiert durch | INFERRED (0.95) | +| SAFETY-REQ-LLM-001 — Krisenreferenz-Pflicht (Recall 100 %) | `05c-lyra-eval-v0.md` | `getCrisisFallback()` | `backend/server/utils/crisis-filter.ts` | implementiert durch | INFERRED (0.95) | +| Crisis-Detection-Recall — Haupt-Metrik (Ziel 100 %) | `05c-lyra-eval-v0.md` | `crisis-filter.test.ts` | `backend/tests/crisis/crisis-filter.test.ts` | verifiziert durch | INFERRED (0.95) | +| Lyra Persona — Single Source of Truth | `ops/LYRA_PERSONA.md` | `CoachScreen()` | `apps/rebreak-native/app/lyra.tsx` | realisiert in | INFERRED (0.80) | + +**Lesart:** „implementiert durch" = das Code-Symbol setzt die Anforderung um; +„mitigiert durch" = das Code-Symbol ist die Risikokontrollmaßnahme (ISO 14971); +„verifiziert durch" = der Test weist die Soll-Metrik nach. + +--- + +## 2b. Traceability-Matrix — Schutz-/Selbstbindungs-Strang (v0) + +Zweiter Strang: die geräteweite Zugangserschwerung (REQ-PROT), die Selbstbindung +(REQ-MAGIC), der manipulationssichere Cooldown und die zugehörigen Risiken +R-FALSE-01 (falsche Sicherheit bei inaktivem Schutz) und R-BYP-03 (Selbstbindung +wird zur Falle). + +``` +REQ-PROT (Dok 03 — geräteweite Zugangserschwerung) + ├─ Android: DnsFilter.process() (DNS-NXDOMAIN-Blocking) + ├─ iOS: RebreakProtectionModule.applyWebContentLayer() (NEFilter) + ├─ Setup: SetupFlows.tsx (Schutz-Aktivierung) + └─ State: protection / isAllLayersOn() (Layer-Status) + └─ R-FALSE-01 (Dok 04 — falsche Sicherheit bei inaktivem Schutz) + ├─ isAllLayersOn() (erkennt teil-/inaktiven Schutz) + └─ wasProtectionEverActiveHere() (Bypass-Detection-Flag) + +REQ-MAGIC (Dok 03 — Selbstbindung, 24h-Cooldown) + ├─ register.post.ts / findActiveDeviceLock() (Bindung) + └─ R-BYP-03 (Dok 04 — legitimer Ausstieg scheitert) + └─ requestDeviceRelease() / request-release.post.ts (Mitigation: Release-Pfad) + +Server-time-authoritativer Cooldown (Dok 03 — Uhr-Manipulation-Schutz) + └─ signCooldownToken() / verifyCooldownToken() (backend/server/utils/cooldownToken.ts) + +Spec Protection Coverage & Streak (DiGA-Kernmetrik) + ├─ streak.ts (Streak-DB-Layer) + └─ addStreakEvent() (append-only protection_state_log) +``` + +| DiGA-Artefakt (Anforderung / Risiko / Metrik) | Quelle | → Code-Artefakt | Datei | Relation | Konfidenz | +|---|---|---|---|---|---| +| REQ-PROT — Schutz/Blocker (geräteweite Zugangserschwerung) | `03-requirements-v0.md` | `protection` | `apps/rebreak-native/lib/protection.ts` | implementiert durch | INFERRED (0.85) | +| REQ-PROT — Schutz/Blocker (geräteweite Zugangserschwerung) | `03-requirements-v0.md` | `isAllLayersOn()` | `apps/rebreak-native/lib/protection.ts` | implementiert durch | INFERRED (0.85) | +| REQ-PROT — Schutz/Blocker (geräteweite Zugangserschwerung) | `03-requirements-v0.md` | `.applyWebContentLayer()` | `…/ios/RebreakProtectionModule.swift` | implementiert durch | INFERRED (0.80) | +| REQ-PROT — Schutz/Blocker (geräteweite Zugangserschwerung) | `03-requirements-v0.md` | `.process()` | `…/android/…/filter/DnsFilter.kt` | implementiert durch | INFERRED (0.85) | +| REQ-PROT — Schutz/Blocker (geräteweite Zugangserschwerung) | `03-requirements-v0.md` | `SetupFlows.tsx` | `apps/rebreak-native/components/blocker/SetupFlows.tsx` | implementiert durch | INFERRED (0.80) | +| R-FALSE-01 — falsche Sicherheit bei inaktivem Schutz | `04-risiko-akte-v0.md` | `isAllLayersOn()` | `apps/rebreak-native/lib/protection.ts` | mitigiert durch | INFERRED (0.90) | +| R-FALSE-01 — falsche Sicherheit bei inaktivem Schutz | `04-risiko-akte-v0.md` | `wasProtectionEverActiveHere()` | `apps/rebreak-native/lib/protection.ts` | mitigiert durch | INFERRED (0.85) | +| REQ-MAGIC — Selbstbindung (Lock-Modus, 24h-Cooldown) | `03-requirements-v0.md` | `findActiveDeviceLock()` | `backend/server/db/devices.ts` | implementiert durch | INFERRED (0.85) | +| REQ-MAGIC — Selbstbindung (Lock-Modus, 24h-Cooldown) | `03-requirements-v0.md` | `register.post.ts` | `backend/server/api/magic/register.post.ts` | implementiert durch | INFERRED (0.85) | +| R-BYP-03 — Selbstbindung wird zur Falle | `04-risiko-akte-v0.md` | `requestDeviceRelease()` | `backend/server/db/devices.ts` | mitigiert durch | INFERRED (0.90) | +| R-BYP-03 — Selbstbindung wird zur Falle | `04-risiko-akte-v0.md` | `request-release.post.ts` | `backend/server/api/magic/devices/[deviceId]/request-release.post.ts` | mitigiert durch | INFERRED (0.85) | +| Server-time-authoritativer Cooldown (Uhr-Manipulation-Schutz) | `03-requirements-v0.md` | `signCooldownToken()` | `backend/server/utils/cooldownToken.ts` | implementiert durch | INFERRED (0.90) | +| Server-time-authoritativer Cooldown (Uhr-Manipulation-Schutz) | `03-requirements-v0.md` | `verifyCooldownToken()` | `backend/server/utils/cooldownToken.ts` | implementiert durch | INFERRED (0.90) | +| Spec Protection Coverage & Streak (DiGA-Kernmetrik) | `protection-coverage-streak.md` | `streak.ts` | `backend/server/db/streak.ts` | implementiert durch | INFERRED (0.80) | +| protection_state_log (append-only Schutz-Transitions-Log) | `protection-coverage-streak.md` | `addStreakEvent()` | `backend/server/db/streak.ts` | implementiert durch | INFERRED (0.85) | + +--- + +## 3. Herkunft & Reproduzierbarkeit + +Diese Matrix ist 1:1 aus den Traceability-Kanten in `graphify-out/graph.json` +abgeleitet (Kanten-Feld `traceability: true`, **27 Kanten** — 12 Lyra-/Krise, +15 Schutz-/Selbstbindung; letztere mit `strand: "protection"`). Erzeugung: graphify- +Knowledge-Graph über `backend/`, `apps/rebreak-native/` und `docs/specs/diga/`. +Vor der Verknüpfung lagen Dossier-Schicht (LLM-extrahiert) und Code-Schicht +(AST-extrahiert) in **getrennten Graph-Komponenten** — exakt die in Dok 05b §3.2 +beschriebene implizite, nicht formalisierte Traceability. Nach Einzug dieser Kanten +liegen `REQ-LYRA` und `REQ-PROT` mit der gesamten nativen + Backend-Implementierung +(SOS, DNS-/NEFilter, Device-Lock, Cooldown, Streak) in **einer** Komponente. + +> ⚠️ **Automatisch erzeugt ≠ validiert.** Die INFERRED-Zeilen müssen vor jeder +> Verwendung als Nachweis durch einen Regulatory-/QM-Profi bestätigt werden. + +--- + +## 4. Offene Schritte (Richtung formaler IEC-62304-Record) + +1. **INFERRED-Zeilen menschlich bestätigen** oder verwerfen (Regulatory-Review). +2. **Soll-Ergebnis je Testfall** als eigenständiges Artefakt definieren + (Dok 05b §4.2 — bislang nur Assertions im Test). +3. **Ergebnis-Protokoll** pro Release: Build-Version, Datum, Pass/Fail je Test-ID + (Vitest-/Maestro-JUnit-XML archivieren). +4. **Restliche Stränge ergänzen:** Mail-Schutz (REQ-MAIL), Anonymitäts-Invariante, + Onboarding/Streak-Vollabdeckung analog verknüpfen. *(Lyra + Schutz/Selbstbindung + sind in dieser v0 abgedeckt.)* +5. **Test-ID-Rückverweise im Code** ergänzen (Vitest-`describe` / Maestro-YAML- + Kommentar referenziert `REQ-XXX` / `R-XXX`), damit die Matrix künftig aus dem + Code selbst regenerierbar ist statt aus Graph-Inferenz. + +--- + +*v0-Erst-Entwurf. Deckt bewusst nur den höchst-sicherheitsrelevanten Lyra-/Krisen- +Strang ab. Die Konfidenz-Flags sind Teil des Dokuments und dürfen beim Übernehmen +in die finale Akte nicht entfernt werden, bevor die jeweilige Zeile validiert ist.*