rebreak-monorepo/docs/specs/diga/03-requirements-v0.md

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).	blocklist/download.get.ts, url-filter/blocklist.bin.get.ts	R-PROT-01
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-PROT-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-PROT-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.

---

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 bis zu 3 Geräte (iPhone/iPad/Mac) 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

[Gründer-Entscheidung] Ob RebreakMagic (geräteweite Selbstbindung via DNS-Profil / MDM) Teil der zertifizierten DiGA-Funktion ist oder ein abgegrenztes Zusatz- Feature außerhalb des Medizinprodukt-Scopes, ist eine Scoping-Entscheidung mit hohem Klassifizierungs-Einfluss. [Profi-Validierung] mit BfArM/Regulatory-Berater.

---

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-PROT-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	57 (REQ-IDs)
davon M (Muss)	33
davon sicherheits-/risiko-verknüpft	41
Bereiche	10 (Schutz, Magic, Mail, Lyra, SOS, Streak, Community, Auth, Demografie, NFR)

---

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.