chahinebrini
7f529c3be3
feat(privacy): Coach-Payload an LLM-Provider pseudonymisieren (Art.9/DSGVO)
...
Schliesst hans-muellers K1-Befund (Datenschutz-Audit): der Coach-Prompt
sendete Identifier + Art.9-nahe Daten an US-LLMs (Gemini/OpenAI/Anthropic).
- message.post.ts: Geburtsjahr/exaktes Alter -> Altersgruppe (Dekaden-Bucket);
Stadt komplett entfernt (Bundesland bleibt). Geschlecht/Familienstand/Beruf/
Nickname unveraendert (gewollte Personalisierung; Nickname = Pseudonym).
- lyraMemoryExtract.ts: Extraction-Prompt reduziert Dritt-Klarnamen auf Rolle
("Frau Maria" -> "seine Frau"), keine Orte/Arbeitgeber im Memory-Content.
- 08-datenschutz-audit: Payload-Audit-Platzhalter durch Vorher/Nachher-Tabelle
ersetzt, K1 erledigt, ZDR-Update (DPA/SCCs deemed-signed, TIA offen).
Pseudonymisierung zaehlt jetzt als zweite Schutzmassnahme neben ZDR fuer die TIA.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-07 08:35:13 +02:00
chahinebrini
96e1b8368c
feat(lyra): deterministisches Krisen-Sicherheitsnetz (R-LYRA-01)
...
LLM-unabhaengiges Sicherheitsnetz fuer Lyras SOS-Pfad, schliesst das
Top-Risiko der Risiko-Akte (verpasste Krise, ISO 14971 R-LYRA-01).
Backend:
- crisis-filter.ts: deterministische Krisen-/Suizid-Erkennung (DE primaer,
EN/FR/AR Grundabdeckung) auf den letzten User-Nachrichten, synchron, kein LLM
- sos-session.post: liefert crisisLevel sofort an die App (vor Stream-Start)
- sos-stream: sendet bei Krise zuerst 'crisis_chips' (BZgA/112/Telefonseelsorge);
Fallback an 3 Stellen (LLM-Fehler/Abbruch/keine Chips) -> nie leerer Screen
- 43/43 Unit-Tests (crisis.json positiv, harmless.json False-Positive-Guard)
Frontend (urge.tsx):
- permanente rote Krisen-Bar oben, durch LLM-Chips nicht ueberschreibbar
(eigener State-Slot), Hotline-Chips als tel:-Links
- neue Locale-Strings DE/EN
Risiko-Akte: R-LYRA-01 Restrisiko HOCH -> MITTEL.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-07 07:56:34 +02:00
chahinebrini
ac05e255da
feat(diga): Technische-Akte Runde 1+2 — Requirements, Risiko-Akte, Datenschutz-Audit, Lyra-Eval
...
DiGA-Dossier weiter aufgebaut (docs/specs/diga/):
- 03 Requirements (57 REQ-IDs aus dem Code, Traceability-Anker)
- 04 Risiko-Akte (ISO 14971 Erstliste; R-LYRA-01 = verpasste Krise als Top-Risiko)
- 05b Test-Verifikation (Maestro/Vitest-Inventar, IEC-62304-Luecken)
- 05c Lyra-Eval (Suite-Doku)
- 08 Datenschutz-Audit (hans-mueller; Groq/Art.9, DSFA-Pflicht, Mail-Agent, Anonymitaet)
- 00 Dossier-Plan Status aktualisiert
Lyra-Eval-Suite: backend/tests/eval/ (30 Prompts, 5 Kategorien, Vitest-Runner,
Mock-Modus ohne Key; Live-Run misst Crisis-Recall).
Konvergenter Befund aller 3 Agents: Lyras Krisen-Pfad haengt zu sehr am LLM
(R-LYRA-01 + fehlender SOS-Handler-Fallback) -> deterministisches Sicherheitsnetz noetig.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-07 07:38:11 +02:00
chahinebrini
90f63eb21e
feat(diga): Regulatory-Doku-Agent + Technische-Akte-Start (Zweckbestimmung)
...
DiGA/MDR-Vorbereitung als eigener Workstream:
- Neuer Agent 'diga-regulatory' (Dr. Marlene Brandt) — owns docs/specs/diga/,
draftet die Technische Akte (Zweckbestimmung, MDR-Klassifizierung, ISO 13485/14971,
IEC 62304, klinische Bewertung, Labeling, PMS, QMS-Templates). Ergänzt hans-mueller
(Datenschutz) + rebreak-strategist (Business); validiert nicht selbst (Profi-Grenze).
- docs/specs/diga/00-dossier-plan.md — Plan + Arbeitsteilung (Claude draftet, Gründer
entscheidet, Profi validiert) + 10-Dokumente-Landkarte mit Status.
- docs/specs/diga/01-zweckbestimmung-v0.md — Keystone-Entwurf (Intended Use, Indikation
F63.0, 3-Ebenen-Wirkmechanismus, Abgrenzung kein Therapieersatz, Klassifizierungs-Hinweis).
Naechste Aufgaben fuer den Agent (aus dem Code, ohne Gruender-Input): 03 Requirements,
04 Risiko-Erstliste, 05 SOUP + Architektur.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-07 06:39:13 +02:00
