5 Commits

Author SHA1 Message Date
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
chahinebrini
d31e45e2a8 feat(streak): protection-coverage metric (DiGA core) replacing broken streak
The old streak was non-functional: streaks.current_days was always 0 (never
computed/incremented), and the profile page read me.streak (0) + account
created_at as the "since" date — showing "0 days protected since <signup>"
for everyone. This is the DiGA key metric, so it had to be rebuilt.

New model: optimistic protection-coverage based on actual VPN/MDM protection
state, never resets to 0.
- backend: append-only protection_state_log + migration; POST /api/protection/event
  (ingestion, deduped) + GET /api/protection/coverage (read-time compute, no cron);
  server-side cooldown_disable event on cooldown resolve. Generous >6h-off/day rule.
- frontend: report protection on/off transitions (initial + flips, deduped) from
  useProtectionState; rewrote profile StreakSection → half-donut (protected vs
  unprotected) + progress bar (current streak → personal record) + empty state.
- coverage starts fresh from deploy (no historical backfill — clean data for DiGA).
- spec: docs/specs/protection-coverage-streak.md (shared contract).
- old streaks/streak_events/profiles.streak left intact (coach/scores consumers).

Also adds go-to-market one-pagers under docs/marketing/.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-06 10:54:55 +02:00