docs(diga): Dok 05 (Architektur+SOUP) + 05d (Traceability-Matrix) v0
- 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>
This commit is contained in:
chahinebrini
parent
80b6e2399b
commit
577a478c2d
@ -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) |
|
||||
|
||||
185
docs/specs/diga/05-software-lifecycle-architektur-soup-v0.md
Normal file
185
docs/specs/diga/05-software-lifecycle-architektur-soup-v0.md
Normal file
@ -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.*
|
||||
@ -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):**
|
||||
|
||||
173
docs/specs/diga/05d-traceability-matrix-v0.md
Normal file
173
docs/specs/diga/05d-traceability-matrix-v0.md
Normal file
@ -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.*
|
||||
Loading…
x
Reference in New Issue
Block a user