21c1e31877
- 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>
269 lines
23 KiB
Markdown
269 lines
23 KiB
Markdown
# 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.*
|