chahine/rebreak-monorepo
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
rebreak-monorepo/docs/specs/diga/03-requirements-v0.md
chahinebrini 21c1e31877 docs(diga): Nacht-Session — Eval-Records, Akte 10/11, Magic-Scope-Entscheidung 
- Lyra-Eval Live-Runs (2x): Crisis-Recall-Gate auf Produktionsmodell
  (Groq llama-3.3-70b) BESTANDEN (6/6=100%); gpt-4o-mini-Fallback 83%
  -> Modellwahl sicherheitsrelevant -> Model-Pinning vorgeschlagen.
  Records unter docs/specs/diga/eval-records/.
- 05d: Mail- + Anonymitäts-Strang (+18 Zeilen); username-GAP verifiziert
  + Fix dokumentiert. 04 (R-LYRA-01, R-DATA-07) + 05b nachgezogen.
- Dok 07 Gebrauchsanweisung, Dok 09 PMS-Plan, Dok 10 QMS-Templates (v0).
- Scope-Entscheidung Gründer 2026-06-11: RebreakMagic (inkl. Desktop)
  vorerst NICHT im zertifizierten DiGA-Scope (01/03/07 umgesetzt).
- graphify-Artefakte (Hook-Rebuild) mitgenommen.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-06-11 06:36:33 +02:00

23 KiB
Raw Blame History

Anforderungen / Requirements — Rebreak · v0 (Entwurf)

Dok 03 der DiGA-Technischen-Akte. Norm-Bezug: IEC 62304 §5.2 (Software- Anforderungsanalyse), MDR Anh. I (GSPR §17 — Software). Erstellt von Dr. Marlene Brandt (diga-regulatory). Drafting — Validierung durch Regulatory-/QM-Profi ausstehend.

Methodik: Die Anforderungen sind aus dem bestehenden, funktionsfähigen Produkt abgeleitet (apps/rebreak-native/, backend/) — wir dokumentieren den Ist-Stand nachvollziehbar, wir erfinden keine Soll-Funktionen. Jede Anforderung hat eine stabile ID (REQ-<Bereich>-<Nr>) als Anker für die Traceability-Matrix.

Andockpunkte:

  • Dok 01 Zweckbestimmung — jede REQ dient dem dort beschriebenen Zweck (Schutz / Begleitung / Motivation). Claims in §2/§3 von Dok 01 sind [Gründer-Entscheidung].
  • Dok 04 Risiko-Akte — sicherheitsrelevante REQs sind dort als Risikomaßnahme gespiegelt (Spalte „Risiko-Bezug").
  • Dok 05b Test-Verifikation (Ahmed) — die REQ-IDs sind der Mapping-Anker, den Ahmed für Test-IDs in Maestro-Flows und Vitest-Describes referenzieren wird (05b §3.3). Diese Liste schließt diese Lücke (05b §3.2: „Dok 03 noch nicht erstellt").
  • Dok 08 Datenschutz (Hans) — datenschutz-relevante REQs verweisen auf die dortigen Befunde (Art.-9-Daten, Anonymität, Mail-Agent).

0. Lesehilfe

  • Typ: F = funktional · NF = nicht-funktional (Qualität/Constraint).
  • Priorität: M = Muss (Kern-/Sicherheitsfunktion) · S = Soll · K = Kann.
  • Quelle: Datei/Endpoint, aus dem die Anforderung abgeleitet ist (Nachweis).
  • Risiko-Bezug: verknüpfte Risiko-ID aus Dok 04 (sofern sicherheitsrelevant).
  • [Gründer-Entscheidung] = inhaltliche Festlegung liegt beim Gründer.
  • [Profi-Validierung] = muss von Regulatory-/QM-Profi bestätigt werden.

Wichtige Einordnung [Profi-Validierung]: Welche dieser REQs sicherheits- relevant im Sinne IEC 62304 sind (und damit die Software-Sicherheitsklasse B/C mitbestimmen), ist mit dem Regulatory-Profi festzulegen. Die hier mit M + Risiko-Bezug markierten REQs sind der Kandidaten-Kreis.

1. Schutz / Blocker (geräteweite Zugangserschwerung)

Kern-Wirkmechanismus 1 (Dok 01 §5.1). Quelle: lib/protection.ts, modules/rebreak-protection/, backend/server/api/protection/*, …/blocklist/*, …/url-filter/*, …/cooldown/*.

ID Typ Prio Anforderung Quelle Risiko-Bezug
REQ-PROT-001 F M Das System blockt den Zugriff auf bekannte Glücksspiel-Domains (globale Blocklist, Größenordnung ~208–330k Domains, inkl. nicht-lizenzierter Offshore-Seiten); die Blockierung erfolgt per DNS-NXDOMAIN-Antwort (kein Sinkhole / keine Block-Page — siehe Hinweis unter Tabelle). blocklist/download.get.ts, url-filter/blocklist.bin.get.ts R-FALSE-01, R-DATA-09
REQ-PROT-002 F M iOS: Schutz Schicht 1 ist ein geräteweiter URL-Filter (NEFilter via System-/MDM-Profil oder PacketTunnel-VPN); er bleibt aktiv, auch wenn die App geschlossen/aus dem App-Switcher entfernt ist. protection.ts: isNeFilterActive/activateUrlFilter R-FALSE-01
REQ-PROT-003 F M Android: Schutz arbeitet über lokales DNS-VPN (Schicht 1, Filterung ohne externen Traffic) + Accessibility-Service als Tamper-Lock (Schicht 2). protection.ts: activate/activateFamilyControls R-FALSE-01, R-BYP-01
REQ-PROT-004 F S iOS Schicht 2 (Auffangnetz): kuratierte länderabhängige Top-Gambling-Liste (≤50 Domains, ManagedSettings/webContent), greift falls Schicht 1 nicht aktiv ist. protection.ts: applyWebContentFilter, protection/webcontent-domains.get.ts R-FALSE-01
REQ-PROT-005 F S Die Liste der Schicht 2 wechselt automatisch beim Wechsel in ein anderes Land (Erkennung über Mobilfunk-Netz/MCC). protection.ts: syncWebContentDomains R-FALSE-02
REQ-PROT-006 F M Deaktivierung des Schutzes ist nicht unmittelbar möglich: Sie löst einen serverseitig verankerten Cooldown aus (24 h iOS-Magic / 6 h Android), während dessen der Schutz aktiv bleibt. cooldown/request.post.ts, protection.ts: requestDeactivation R-BYP-01
REQ-PROT-007 NF M Der Cooldown ist server-time-authoritativ (JWT-Claim cooldown_ends_at), um Manipulation der lokalen Geräteuhr zu verhindern. protection.ts (Header-Kommentar), cooldown/status.get.ts R-BYP-02
REQ-PROT-008 F M Nach abgelaufenem Cooldown muss ein legitimer Schutz-Ausstieg funktionieren (Android: Device-Admin + Tamper-Lock werden vor disable() entfernt, damit Deinstallation/Abschaltung möglich ist). protection.ts: forceDisable R-BYP-03
REQ-PROT-009 F S Self-Healing: Wird der Filter (VPN/NEFilter) durch OS-Kill/Reinstall/User-Aktion inaktiv, reaktiviert das System ihn bei App-Start/Foreground (reconcileVpn), sofern er aktiv sein soll. protection.ts: reconcileVpn R-FALSE-03
REQ-PROT-010 F S Bypass-Erkennung: Sagt das Backend protectionShouldBeActive=true, läuft aber weder VPN noch NEFilter und ist das Gerät nicht MDM-managed, signalisiert das System die Phase recoveringFromBypass. protection.ts: getCombinedState R-FALSE-03, R-BYP-01
REQ-PROT-011 F K Pro/Legend-Nutzer können eigene Trigger-Domains zum persönlichen Schutz (Schicht 1) hinzufügen (Pro 10 / Legend 20 Slots, rückfüllbar, gemeinsamer Pool Web+Mail). custom-domains/*, 05b §2.2 R-FALSE-04
REQ-PROT-012 F M Eine einmal hinzugefügte Custom-Domain kann der Nutzer nicht selbst entfernen (Anti-Impuls-Halt); nur das Rebreak-Team kann sie entfernen. custom-domains/[id].delete.ts (admin-gated), COACH_SYSTEM_PROMPT R-BYP-04
REQ-PROT-013 NF M Die Blocklist-Synchronisation auf das Gerät muss erfolgen; der Nutzer wird darüber informiert, dass frisch hinzugefügte Domains erst nach Foreground-Pull/DNS-Cache-Ablauf greifen (kein sofortiger Schutz). useBlocklistSync.ts, MEMORY: blocklist.bin Sync-Lag R-FALSE-05

[Gründer-Entscheidung] REQ-PROT-006: Die konkreten Cooldown-Dauern (24 h / 6 h) sind eine therapeutisch begründete Produktfestlegung — in der klinischen Bewertung (Dok 06) mit der Uni Bremen zu plausibilisieren.

Design-Entscheidung Block-Mechanismus (Stand 2026-06-10): Geblockte Domains werden per DNS-NXDOMAIN abgewiesen — bewusst kein Sinkhole / keine branded Block-Page / kein Redirect auf eine Hinweisseite. Begründung: (a) eine Block-Page über HTTPS scheitert an der TLS-Zertifikats-Wall (Browser-Fehler statt sauberer Hinweis), (b) ein Sinkhole/ Redirect erzeugt eine zentral beobachtbare Liste „dieser Nutzer wollte auf Casino X" → Fingerprinting-/Privacy-Risiko bei Art-9-Betroffenen. NXDOMAIN ist damit auch eine Risiko-Mitigation (Stigma-/Detection-Schutz) — als solche in Dok 04 (R-DATA-09) gespiegelt. [Gründer-Entscheidung] bestätigt.

2. Selbstbindung (RebreakMagic / Lock-Modus)

Kern-Wirkmechanismus 1, stärkste Stufe (Dok 01 §5.1). Quelle: backend/MAGIC_API.md, backend/server/api/magic/*, COACH_SYSTEM_PROMPT.

ID Typ Prio Anforderung Quelle Risiko-Bezug
REQ-MAGIC-001 F S Nutzer können mehrere Geräte (iPhone/iPad/Mac, Windows) per RebreakMagic in einen Lock-Modus versetzen, in dem der Schutz nicht mehr einfach in den OS-Einstellungen abschaltbar ist. magic/register.post.ts, MAGIC_API.md R-BYP-01
REQ-MAGIC-002 F M Das Lösen des Lock-Modus erfordert einen 24-Stunden-Cooldown (request-release → releaseAvailableAt = +24h), währenddessen der Schutz aktiv bleibt; der Cooldown ist jederzeit abbrechbar. magic/devices/[deviceId]/request-release.post.ts R-BYP-01
REQ-MAGIC-003 NF M RebreakMagic-Setup setzt einen authentifizierten Rebreak-Account voraus (JWT); kein anonymer Lock. magic/register.post.ts (Bearer-Auth) —
REQ-MAGIC-004 NF S Selbstbindung darf den legitimen, dokumentierten Ausstiegsweg nicht dauerhaft verschließen (24 h Cooldown ist der vorgesehene Pfad — siehe Warnhinweis Dok 07). MAGIC_API.md: processMagicReleases R-BYP-03
REQ-MAGIC-005 F K Desktop-Schutz (Legend): macOS- (rebreak-magic-mac, SwiftUI) und Windows-Client (rebreak-magic-win, Tauri/Rust) erzwingen geräteweiten DNS-Glücksspiel-Filter (DoH/AdGuard) inkl. Browser-DoH-Bypass-Gegenmaßnahmen; ein SYSTEM-Tamper-Service hält den Schutz unter Windows aktiv. rebreak-magic-mac/, rebreak-magic-win/, MEMORY: chromium-dns-bypass R-FALSE-01, R-BYP-01
REQ-MAGIC-006 F K Desktop-Hard-Lock: Das DNS-Schutzprofil ist non-removable verankert (Removal-Password / Profil-Lock); das Klartext-Passwort wird dem Nutzer nur beim dokumentierten Offboarding (Kündigung/Account-Löschung) offengelegt — server-zeitgesteuerte Deaktivierung als Release-Pfad. rebreak-magic-mac/ Profile-Lock, MEMORY: magic-hardlock-offboarding R-BYP-03

Scope-Entscheidung Gründer (2026-06-11): RebreakMagic (geräteweite Selbstbindung via DNS-Profil / MDM, inkl. Desktop-Clients) ist vorerst NICHT Teil der zertifizierten DiGA-Funktion — es bleibt ein abgegrenztes, optionales Zusatz-Feature außerhalb des Medizinprodukt-Scopes. Die REQ-MAGIC-Zeilen bleiben zur Produkt- Vollständigkeit dokumentiert, zählen aber nicht zum Verifikationsumfang der Akte. Entscheidung ist nach der BfArM-Beratung revidierbar. [Profi-Validierung] der Abgrenzungs-Formulierung.

3. Mail-Schutz (Trigger-Mail-Entfernung)

Kern-Wirkmechanismus 1 (Dok 01 §5.1). Quelle: backend/imap-idle/, backend/server/utils/mail-classifier.ts, …/api/mail/*, …/mail-connections/*.

ID Typ Prio Anforderung Quelle Risiko-Bezug
REQ-MAIL-001 F S Das System überwacht verbundene Postfächer in Echtzeit (IMAP-IDLE-Daemon, kein Polling) und scannt bei neuer Mail auf Glücksspiel-/Casino-Absender. imap-idle/index.mjs, mail/scan-internal.post.ts R-MAIL-01
REQ-MAIL-002 F S Erkannte Trigger-Mails werden entfernt, bevor die Geräte-Benachrichtigung triggert; scannt alle Ordner (Inbox, Spam, Papierkorb, Archiv). COACH_SYSTEM_PROMPT (Mail-Schutz), mail-classifier.ts R-MAIL-01
REQ-MAIL-003 F M Die Klassifikation ist primär deterministisch (gewichteter Score; Hard-Block ab Score ≥ 80; Mittelband 25–79 deterministische Schwelle); LLM nur in definiertem Mittelband-Fall. mail-classifier.ts: SCORE_HARD_BLOCK_THRESHOLD=80 R-MAIL-02, R-MAIL-03
REQ-MAIL-004 F M Eine Whitelist verhindert das Löschen legitimer Mails (Whitelist-Hit → kein Block, Score 0). mail-classifier.ts: whitelistHit R-MAIL-02
REQ-MAIL-005 NF M Es werden keine Mail-Inhalte (Body) gelesen/persistiert — nur Absender & Betreff zur Klassifikation. [Profi-Validierung] + Hans (Dok 08 §2.1): Umfang im Code/VVT zu belegen. COACH_SYSTEM_PROMPT, Dok 08 §2.1 R-DATA-02
REQ-MAIL-006 NF M Postfach-Zugriff nur nach ausdrücklicher Einwilligung (consent_at); Connections ohne Consent werden gehalten, aber nicht gescannt. mail-connections/consent.post.ts, Dok 08 §2.1 R-DATA-03
REQ-MAIL-007 NF M Credentials (App-Passwörter, OAuth-Tokens) werden AES-256-GCM at rest verschlüsselt; OAuth wird bevorzugt. Dok 08 §2.1 (Code-verifiziert durch Hans) R-DATA-01

4. Lyra (KI-Coach) & Krisen-Behandlung

Kern-Wirkmechanismus 2 (Dok 01 §5.2). Höchste Sicherheitsrelevanz. Quelle: backend/server/api/coach/*, apps/rebreak-native/lib/sosPrompts.ts, …/sosConstants.ts, app/help/crisis.tsx.

ID Typ Prio Anforderung Quelle Risiko-Bezug
REQ-LYRA-001 F M Im SOS-Modus begleitet Lyra deeskalierend durch akuten Spielimpuls (kurze, validierende, nicht-wertende Antworten) und führt nach 2–3 Schritten zu Atemübung oder Ablenkungs-Spiel. sosPrompts.ts: SOS_BOOT, sos-stream.post.ts R-LYRA-01
REQ-LYRA-002 F M Lyra muss sich gegenüber dem Nutzer als KI / kein Therapeut/Arzt zu erkennen geben, wenn relevant. COACH_SYSTEM_PROMPT („Du bist KEIN Therapeut…") R-LYRA-02
REQ-LYRA-003 F M Bei ernsthaften Krisen muss Lyra auf professionelle Hilfe verweisen (DE: check-dein-spiel.de / 0800 1372700; AT; CH). COACH_SYSTEM_PROMPT („BEI ERNSTHAFTEN KRISEN…") R-LYRA-03
REQ-LYRA-004 F M Die App stellt unabhängig von Lyra eine statische Krisen-/Hilfe-Seite mit Hotlines (BZgA 0800 1 372 700, Seelsorge, Notruf 112) bereit — auch wenn der LLM ausfällt. app/help/crisis.tsx R-LYRA-03, R-LYRA-04
REQ-LYRA-005 NF M Bei LLM-/Upstream-Fehler im SOS-Stream muss das System sauber degradieren (definierter Fehler 502/503, Frontend-Fallback auf /coach/message) und darf nicht stumm hängen. sos-stream.post.ts (Fehlerpfade) R-LYRA-04
REQ-LYRA-006 NF M Lyra darf keine Demografie-/Profildaten aus dem Gespräch extrahieren oder als strukturierte DiGA-Daten speichern (strikte Trennung Narrativ ↔ Profilfeld). COACH_CASUAL_SYSTEM_PROMPT, MEMORY: demographics-Trennung R-DATA-04
REQ-LYRA-007 NF M An den LLM-Provider (Groq/USA bzw. OpenRouter) dürfen keine direkten Identifikatoren (Klarname, E-Mail, User-ID) übermittelt werden. [Profi-Validierung] + Hans (Dok 08 §2.2, K1): Payload zu belegen. Dok 08 §2.2 R-DATA-05
REQ-LYRA-008 F S Im SOS-Modus unterlässt Lyra Sales-/Pricing-/Gründer-Story-/RebreakMagic-Inhalte (Krisen-Fokus-Lock). COACH_SYSTEM_PROMPT (SOS-MODE LOCK) R-LYRA-05
REQ-LYRA-009 F S Lyra vermeidet pathologisierendes Vokabular („süchtig"/„Sucht") — bewusste Tonalitäts-Entscheidung. COACH_SYSTEM_PROMPT (Sprache & Haltung) —
REQ-LYRA-010 NF M SOS-Sessions werden für die DiGA-Auswertung gespeichert (voller Chat-Verlauf, Art-9-Daten). [Profi-Validierung] + Hans (Dok 08): Rechtsgrundlage/Löschkonzept. prisma SosSession, sos/session.post.ts R-DATA-06

[Profi-Validierung] Kritisch (vgl. Dok 05b §1.4, §2.1): Für REQ-LYRA-001/003 existiert keine LLM-Eval-Suite — d.h. korrekte Krisen-Erkennung und korrekter Hotline-Verweis sind aktuell nicht reproduzierbar verifiziert. Eine Anforderung ohne Verifikation ist für ein Medizinprodukt unzureichend (IEC 62304 §5.3/§5.6). Diese Lücke ist in Dok 04 als Top-Risiko geführt (R-LYRA-01/-03).

5. SOS-Werkzeuge (Atemübung, Spiele, Urge-Logging)

Kern-Wirkmechanismus 2/3 (Dok 01 §5.2/§5.3). Quelle: sosConstants.ts, app/urge.tsx, app/games.tsx, backend/server/api/urge/*, …/sos/session.post.ts.

ID Typ Prio Anforderung Quelle Risiko-Bezug
REQ-SOS-001 F M Der SOS-Screen ist niedrigschwellig erreichbar (Header-Dropdown / SOS-Navigation). 05b §2.1, app/urge.tsx R-LYRA-04
REQ-SOS-002 F S Geführte 4-7-8-Atemübung (4 s ein / 7 s halten / 8 s aus, 3 Runden) mit visuellem Guide. sosConstants.ts: BREATH_PHASES, TOTAL_ROUNDS —
REQ-SOS-003 F S Ablenkungs-Spiele (Memory, TTT, Snake, Tetris) als bewusste Überbrückung der ~15–20-min-Impulsphase — kein Glücksspiel. app/games.tsx, games/* R-SOS-01
REQ-SOS-004 F S Urge-/Überwindungs-Erfassung: Emotion, wasOvercome, breathingDone werden geloggt (DiGA-Auswertung). prisma UrgeLog, urge/index.post.ts R-DATA-06
REQ-SOS-005 F K SOS-Insights/-Aggregation für den Nutzer (Muster über Sessions). profile/me/sos-insights.get.ts —

[Gründer-Entscheidung] REQ-SOS-003: Spiele als therapeutisches Ablenkungs-Element sind eine Produkt-/Wirkmechanismus-Aussage — in Dok 06 (klinisch) zu untermauern, und in Dok 04 (R-SOS-01) auf das Risiko „Spielmechanik triggert" zu prüfen.

6. Streak / Protected Days (Motivation & Tracking)

Kern-Wirkmechanismus 3 (Dok 01 §5.3). Quelle: prisma Streak/StreakEvent, backend/server/api/streak/*, stores/blockerStats.ts.

ID Typ Prio Anforderung Quelle Risiko-Bezug
REQ-STREAK-001 F S Das System zählt geschützte/spielfreie Tage (currentDays, longestDays) und protokolliert Ereignisse (started/reset/milestone/relapse). prisma Streak/StreakEvent, streak/index.* R-FALSE-06
REQ-STREAK-002 F K Geschätzte Ersparnis (avgMonthlySavings) und Meilenstein-Badges als Motivation. prisma Streak.avgMonthlySavings, DiGaMilestoneModal.tsx —
REQ-STREAK-003 NF S Ein neu registrierter Nutzer hat einen plausiblen (nicht-null/nicht-fehlerhaften) Streak-Wert (Regressions-Guard). 05b §2.4 onboarding/new-user-streak-guard —

[Profi-Validierung] REQ-STREAK-001 (R-FALSE-06): Die Anzeige „X spielfreie Tage" darf keine falsche Gewissheit erzeugen — die Zählung basiert auf App-Signalen, nicht auf einem lückenlosen Verhaltensnachweis (Bargeld/Fremdgerät unerfasst). Labeling in Dok 07.

7. Community / DM / Anrufe

Begleitend (Dok 01 §5.3, anonyme Community). Quelle: backend/server/api/community/*, …/chat/*, …/calls/*, app/dm.tsx, app/call.tsx.

ID Typ Prio Anforderung Quelle Risiko-Bezug
REQ-COMM-001 F K Anonyme Community (Posts, Kommentare, Likes, Domain-Voting) — Nutzer ausschließlich per Nickname sichtbar. community/*, MEMORY: Anonymität-Nickname R-DATA-07
REQ-COMM-002 F K Direktnachrichten (DM) zwischen Nutzern, inkl. Realtime-Empfang. chat/dm.post.ts, chat/dm/[userId].get.ts R-DATA-07
REQ-COMM-003 F K Peer-Anrufe (VoIP/WebRTC) zwischen Nutzern (Vertrauensperson-Unterstützung). calls/ring.post.ts, calls/ice-servers.get.ts —
REQ-COMM-004 F M Moderationsprozess: Melden/Löschen einzelner Posts, Ban-Mechanismus. admin/moderation/* R-DATA-07
REQ-COMM-005 NF M Anonymitäts-Invariante: Klarname/E-Mail/Username erscheinen in keiner API-Response, Realtime-Payload, Push-Notification oder Log. [Profi-Validierung] + Hans (Dok 08 §2.4): zu belegen (05b §2.3: ungetestet). MEMORY: Anonymität, Dok 08 §2.4 R-DATA-07

8. Authentifizierung, Geräte-Limit & Onboarding

Quelle: backend/server/api/auth/*, …/devices/*, app/(auth)/*, app/onboarding/*.

ID Typ Prio Anforderung Quelle Risiko-Bezug
REQ-AUTH-001 F M E-Mail-basierte Authentifizierung (Login/Signup/Reset) via Supabase (self-hosted, Hetzner DE). auth/login.post.ts, Dok 08 §2.5 R-DATA-01
REQ-AUTH-002 F M Geräte-Limit (Pro 1 / Legend 3); Gerätewechsel lockt das alte Gerät + Email-Notify, um Impuls-Bypass über Zweitgeräte zu verhindern. devices/check-lock.post.ts, device-lock-email.ts R-BYP-01
REQ-AUTH-003 F S Geräte-Freigabe (Release) mit Bestätigungs-/Approval-Flow. devices/[id]/request-release.post.ts, devices/approvals/* R-BYP-01
REQ-AUTH-004 F S Onboarding führt durch Schutz-Aktivierung (iOS: NEFilter/VPN; Android: a11y einmalig). app/onboarding/index.tsx, MEMORY: android-protection-onboarding R-FALSE-01
REQ-AUTH-005 NF M App-Lock (Biometrie) für den App-Zugang ist optional verfügbar. stores/appLock.ts, components/AppLockGate.tsx —

9. Demographie (DiGA-Evidenz-Daten)

Quelle: backend/server/api/profile/me/demographics.*, app/profile/edit.tsx.

ID Typ Prio Anforderung Quelle Risiko-Bezug
REQ-DEMO-001 F S Erfassung freiwilliger Demografie (Geburtsjahr, Geschlecht, Beschäftigungsstatus, Bundesland, optional Beruf/Branche) für die DiGA-Wirksamkeitsauswertung. demographics.patch.ts, demographics.zod.test.ts R-DATA-06
REQ-DEMO-002 NF M Erfassung strikt user-initiiert über das Profil-Formular; keine Kopplung der App-Nutzung an die Preisgabe (Freiwilligkeit). MEMORY: demographics user-initiated, Dok 08 §2.5 R-DATA-04
REQ-DEMO-003 NF M Eingabe-Validierung (Zod) für alle Felder, Grenzen, Enum-Werte. demographics.zod.test.ts (05b §2.5) —
REQ-DEMO-004 F S Nutzer kann eigene Demografie-Daten löschen. demographics.delete.ts R-DATA-06

10. Querschnittliche nicht-funktionale Anforderungen

ID Typ Prio Anforderung Quelle Risiko-Bezug
REQ-NFR-001 NF M Art-9-Daten (Suchterkrankung, Krisen, mentale Gesundheit) werden mit höchster Schutzstufe behandelt; Hosting DE/EU (Hetzner, Supabase self-hosted). Dok 08 §1, §2.5 R-DATA-*
REQ-NFR-002 NF M Drittland-Transfers (Groq/USA, Cloudflare, Stripe) erfordern SCC + TIA + (Groq) Zero-Data-Retention. Owner: Hans (Dok 08 §2.2/§2.3). Dok 08 §2.2/§2.3 R-DATA-05
REQ-NFR-003 NF M Betroffenenrechte: Auskunft/Export (Art. 15/20) + echtes Cascade-Delete (Art. 17) inkl. OAuth-Token-Revoke. Owner: Hans (Dok 08 H4). user/delete.delete.ts, Dok 08 §2.7 R-DATA-08
REQ-NFR-004 NF M Verfügbarkeit der Schutzfunktion: degradiert sicher bei Backend-Ausfall (Schutz bleibt lokal aktiv; konservativ „kein Cooldown" angenommen statt Schutz aufzuheben). protection.ts: getCooldownStatus catch R-FALSE-03
REQ-NFR-005 NF S Mehrsprachigkeit (DE primär; EN/TR/AR vorhanden) inkl. Krisen-Hotlines je Land. lib/i18n.ts, sos-stream.post.ts: LANG R-LYRA-03
REQ-NFR-006 NF S SOUP-/3rd-party-Komponenten sind inventarisiert und gepflegt (→ Dok 05). package.json —

11. Offene Punkte & Abgrenzungen

  • Sicherheitsklassen-Zuordnung je REQ (IEC 62304 §4.3, Klasse A/B/C) ist noch offen — [Profi-Validierung]. Kandidaten für die höchste Klasse: alle M-REQs in §1 (Schutz), §4 (Lyra/Krise), §3 (Mail-Block-Korrektheit).
  • Verifikationsnachweis je REQ wird in Dok 05b (Ahmed) geführt; aktuell bestehen dort dokumentierte Lücken (insb. Lyra-Eval, Schutzwirkung-E2E, Anonymitäts-Invariante).
  • Genauer Mail-Verarbeitungsumfang (Body-Lesen? Treffer-Persistenz?) ist von Hans (Dok 08 §2.1) als „zu verifizieren" markiert — REQ-MAIL-005 hängt daran.
Status Wert
Requirements gesamt 64 (REQ-IDs)
davon M (Muss) 35
davon S (Soll) / K (Kann) 21 / 8
davon sicherheits-/risiko-verknüpft 43
Bereiche 10 (Schutz, Magic, Mail, Lyra, SOS, Streak, Community, Auth, Demografie, NFR)

Scope-Hinweis Desktop (REQ-MAGIC-005/006): Der Mac-/Windows-Desktop-Schutz („Rebreak Magic") ist als Legend-Zusatzfunktion geführt und in Dok 05 §2.1 als Komponente benannt (SOUP-Detail v1 offen). Per Gründer-Entscheidung 2026-06-11 vorerst NICHT im zertifizierten DiGA-Scope — abgegrenztes Zusatz-Feature, wie RebreakMagic insgesamt (s. Kasten oben unter §2). Nach BfArM-Beratung revidierbar.

v0-Entwurf. Diese Liste ist der Traceability-Anker für Dok 04 (Risiko) und Dok 05b (Test). Sicherheitsklassen, Vollständigkeit und Verifikationszuordnung bedürfen der Profi-Validierung.