# 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.*
