Lastenheft — Medidentas

Master-Spezifikation für Medidentas. Diese Datei ist die maßgebliche fachliche Quelle der Wahrheit ("Was bauen wir?"). Sie wird gemeinsam mit HANDOFF.md (Stand/offene Punkte) gepflegt. IDs sind über das Repo durchsuchbar (docs/konventionen/agents.md §3).

Hinweis zum Reifegrad: Dieses Lastenheft setzt den fachlichen Rahmen und die Module und wird mit der Umsetzung fortgeschrieben. Der Technologie-Stack ist entschieden (A-4: Cloudflare Workers + D1 + Angular), die App ist live auf app.medidentas.com (Stand 0.127.1); verbleibende Detail-Felder sind als offene Punkte (§11) markiert und werden mit Begründung nachgezogen.

Anforderungsquelle (Workshop 20.01.2026): Wesentliche Teile dieser Spec sind aus dem Prozess-Workshop mit dem Anwender-Betrieb abgeleitet — strukturiert und PII-bereinigt in Anforderungen-Workshop-2026-01-20.md (Themen W1–W10 → Mapping auf Module/UC/OP). Daraus neu: R11 (Meeting-Doku & Aufgaben), R12 (Dokumenten-Automatisierung), UC-7/UC-8; geschärft: R6, A-3/OP-CRM-1, OP-DOMAIN-1 (bestätigt).

---

1. Zweck & Leitprinzip

Was für eine Anwendung ist das? Den Anwendungs-Charakter (Case-Management + Orchestrierung, eigengebauter Kern, "System of Engagement, nicht of Data") beschreibt ../architektur/System-Charakter.md — empfohlener Einstieg vor den Use-Cases.

1.1 Zweck

Medidentas koordiniert den Kunden-Lebenszyklus eines beratungs-/vermittlungsnahen Betriebs — von der Kundenanlage bis zum betreuten, archivierten Mandat. Es orchestriert dabei bewährte Standard-Werkzeuge (NextCloud für Dokumente, DocuSign/PandaDoc für Unterschriften, CRM für Kundenstamm) zu einem lückenlosen, rechtssicheren Ablauf: Onboarding, Dokumenten-Verwaltung, Unterschriften, Wiedervorlagen, Beratungsdokumentation.

1.2 Leitprinzip (Selbsterklärbarkeit + Standardwerkzeuge)

• G-3 Selbsterklärbarkeit: sprechende, eindeutige Begriffe (Beratungs-/Back-office-Sprache) in UI und Doku.
• G-1 Standardwerkzeuge bevorzugen: anbinden statt nachbauen; der differenzierende Mehrwert liegt in der Orchestrierung zwischen den Werkzeugen, nicht im Nachbau eines DMS oder Signatur-Tools.

1.3 True North (drei Leitfragen)

1. Wo steht der Kunde im Prozess?
2. Was ist offen und fällig?
3. Ist alles vollständig & rechtssicher dokumentiert?

Jede Funktion muss ≥1 dieser Fragen direkter, schneller oder genauer beantworten (docs/betrieb/Sanity-Checkliste.md).

2. Kern-Use-Cases

ID	Use-Case	Beschreibung
UC-1	Kunden onboarden	Neuen Mandanten anlegen (CRM-Link), Pflicht-Stammdaten & -Dokumente anfordern, Onboarding-Fortschritt verfolgen.
UC-2	Dokumente verwalten	Dokumente in NextCloud ablegen/anfordern/abrufen; Medidentas hält Referenz + Status (vollständig? aktuell?).
UC-3	Unterschriften einholen	Dokument zur E-Signatur (DocuSign/PandaDoc) senden, Status verfolgen, unterschriebenes Dokument zurück in NextCloud ablegen.
UC-4	Wiedervorlagen steuern	Termine/Fristen/Erinnerungen je Mandant setzen, Fälliges sichtbar machen, an Verantwortliche zustellen.
UC-5	Beratung dokumentieren	Beratungsgespräche rechtssicher protokollieren (Beratungsprotokoll), auditierbar ablegen.
UC-6	Status überblicken	Cockpit: True-North-Antworten (wo steht wer · was ist fällig · ist alles vollständig?). Mandanten-Pipeline/Board (Liste/Board je Lifecycle-Status, Filter, Statuswechsel per Karte; §5.2). Aggregiertes Cockpit "Alles Offene" über alle Mandanten (GET /api/offene-punkte; §6).
UC-7	Meeting protokollieren & Aufgaben delegieren	Team-/Kundengespräch automatisch zusammenfassen, Aufgaben im Gespräch an Verantwortliche delegieren, zentral + kundenverknüpft führen (R11).
UC-8	Dokumente automatisch erzeugen & signieren	Standarddokumente aus den Stammdaten einmalig befüllen, sprechend benennen, in NextCloud ablegen und direkt zur E-Signatur geben (R12 + R4).

3. Globale Prinzipien (G-n)

ID	Prinzip
G-1	Standardwerkzeuge bevorzugen (integrate-before-build); Eigenbau begründen.
G-2	Everything-as-Code / Single Source of Truth; derived State nie doppelt speichern.
G-3	Selbsterklärbarkeit (sprechende Begriffe in UI + Doku).
G-4	Rechtssichere, lückenlose Dokumentation (append-only, auditierbar, nicht reverse-engineerbar).
G-5	Datenschutz & Datenminimierung by design (DSGVO/revDSG, EU-/CH-Residenz, PII minimal).
G-6	Datensparsamkeit & Scrubbing-at-Source (ingress): PII am Eingang (API-Grenze, Import, Webhook, Log-Wrapper) auf das Nötigste reduzieren, pseudonymisieren oder verwerfen — Default ist nicht speichern; jede neue PII-Persistenz wird begründet.
G-7	Betriebskosten automatisch ziehen (cost-pull-at-source): laufende Infra-/Cloud-/KI-Kosten je Dienst direkt aus dessen Billing-/Usage-API pullen (Cron + on-demand), nicht von Hand pflegen; manuelle Erfassung nur Fallback.
G-8	Weltmodell / Data Dictionary: eine Definition je Entität/Wertobjekt, überall gleich strukturiert (UI · API/DTO · Persistenz · Doku); Wertobjekte zusammengesetzt und atomar — kanonisch Anschrift = strasse · plz · ort (MED-D-85).

4. Module (R1–R13)

ID	Modul	Zweck	Standard-Werkzeug (G-1)
R1	Mandant / Kunde	Zentraler Träger des Lebenszyklus; Stammdaten-Referenz + CRM-Link.	CRM (extern)
R2	Onboarding & Prozess	Checklisten/Phasen, Pflicht-Items, Fortschritt; orchestriert R3–R6. Stammdatenerfassung per Web-Formular (§4.5); Self-Service per Einladungslink + SES-Einwilligung ✅ gebaut (Slice 9).	Eigenentwicklung (Orchestrierung)
R3	Dokumente	Ablage, Anforderung, Abruf, Vollständigkeit; Referenz + Status; Standard-Ordnerstruktur je Mandant.	NextCloud
R4	Unterschriften	E-Signatur-Anforderung & -Status je Dokument, eIDAS-Niveau; signierte Rückablage (Kennung "SIG").	DocuSign / PandaDoc
R5	Wiedervorlagen	Termine/Fristen/Erinnerungen, Fälligkeits-Sicht, Zustellung.	Scheduler + E-Mail/Notification
R6	Beratungsdokumentation	Rechtssichere Beratungsprotokolle, Textbausteine, KI-Vollständigkeits-/Rechtssicherheits-Check, auditierbare Ablage.	Eigenentwicklung + R3-Ablage + KI (OP-AI-1)
R7	Benutzer & Rollen	Berater · Back-office · Admin; Berechtigungen; angemeldeter Nutzer → Audit-Actor. ✅ MVP gebaut (Slice 7, 0.8.0)	Cloudflare Access (Standard-IdP/SSO, G-1) + Rollen in D1
R8	Audit-Log & Compliance	Append-only Änderungshistorie, Retention, Nachweis.	Eigenentwicklung (G-4)
R9	Integrationen	Konnektoren: NextCloud, Signatur-Provider, CRM, E-Mail, Meeting-/Transkriptions-Tool.	Provider-Abstraktionen
R10	Tool-Host / Erweiterbarkeit	Registriert/aktiviert/isoliert Spezial-Tools (z. B. Dexman) je Mandant/Tenant.	Eigenentwicklung (dünner Host)
R11	Meeting-Doku & Aufgaben/Delegation	Gespräche zusammenfassen, Aufgaben delegieren, zentral + kundenverknüpft führen; "eine Wahrheit".	Transkriptions-Tool anbinden (OP-MEET-1) + Eigenentwicklung
R12	Dokumenten-Automatisierung	Standarddokumente aus Stammdaten befüllen, benennen, ablegen, an R4 übergeben. ✅ MVP gebaut (Slice 8, 0.9.0)	Eigenentwicklung (Mapping-Engine) + R3-Ablage + R4-Übergabe (OP-DOCGEN-1)
R13	Leistungszeit	Abrechenbare Beratungs-/Arbeitszeit je Mandant erfassen (dünnes Ledger), aus R6 ableiten, für die Abrechnung (SevDesk) aggregieren. ✅ gebaut (Slice 13, 0.14.0)	Eigenentwicklung (dünnes Ledger) + Export an SevDesk (OP-TIME-1/OP-INVOICE-1); ≠ ArbZG (OP-TIME-2)

Detail-Felder (Rx-F##) werden je Modul nachgezogen, sobald das Datenmodell (§4.x künftig) verfeinert wird. Heute auf Modul-Ebene gehalten, um Decision-Sprawl zu vermeiden.

4.4 R10 Erweiterbarkeit — Spezial-Tools

Die Plattform ist um fachliche Spezial-Tools erweiterbar (A-6): optional zubuchbare, fachlich abgeschlossene Fähigkeiten, die in den Kern eingehängt werden, dessen Mandanten-Kontext (R1), Rollen (R7), Audit-Log (R8) und Integrationen (R9) nutzen und eigene Datenquellen, Logik und Oberflächen mitbringen. Erstes Tool: Dexman (Praxis-Rentabilität, Umsatzprognose, Behandler-Feedback). Vertrag/Isolation/ Lebenszyklus: ../architektur/Erweiterbarkeit-Spezialtools.md; Tool-Spec: ../spezialtools/Dexman.md.

Dentmarking ist eine Vorstufe zu Dexman (OP-DENTMARK-1): ein Fragebogen-basiertes Betriebskennzahlen-Gutachten je Praxis (18 Kennzahlen vs. Benchmark, Potentialrechnung, Befunde) als niedrigschwelliger Beratungs-/Lead-Einstieg; die gesammelten Daten speisen später Dexman. Ebenfalls Spezial-Tool (R10/A-6). Tool-Spec liegt vor: ../spezialtools/Dentmarking.md (DM-1..DM-8) inkl. vollständig extrahierter Alt-Excel-Logik (../spezialtools/Dentmarking-Excel-Logik.md). Umsetzungspfad entschieden (D-27): Modul im bestehenden Worker/D1; neue Kern-Entität praxis (Objekt/Betriebsstätte, 1:n unter dem Mandanten) und Geschäftsjahr-bezogene Faktentabelle praxis_jahreswert (generisches Periodenmodell, Quellen-Kennung) — dasselbe Datenmodell trägt später Dexman (BWA/PVS-Quellen, feinere Perioden).

4.1 R1 Mandant/Kunde — Datenmodell-Grundsatz

• Mandant = natürliche Person (D-45). Die geschäftliche Einordnung (Praxis/MVZ/Gesellschaft) sitzt an der Praxis/Gesellschaft (R1-F28), nicht am Mandanten.
• Kunde = Name + CRM-Link (extern). Das CRM bleibt Single Source der Kundenstammdaten; Medidentas dupliziert sie nicht, sondern referenziert (crm_id) und cached höchstens das, was für die Prozess-Sicht nötig ist.
• Ein Mandat/Vorgang (Lebenszyklus-Instanz) hängt am Kunden und trägt den Prozess-Zustand.
• Die Person hält 0..n Praxen/Gesellschaften (R1-F20 ff., 1:n).

Felder (MVP, R1-F##):

ID	Feld	Typ	Hinweis
R1-F01	id	ULID	interner Schlüssel (sortierbar)
R1-F02	anzeigename	Text	sprechend; abgeleitet aus R1-F08..F10 (Schema "Nachname Titel Vorname"), sonst Einrichtungs-/Freitextname (D-31, G-2/G-3)
R1-F03	crm_id / crm_link	Text/URL	Referenz ins CRM (Single Source, S-1)
R1-F04	typ	—	entfällt (D-45): Mandant ist natürliche Person; geschäftliche Einordnung → objektart an der Praxis/Gesellschaft (R1-F28). Migration v23 DROP COLUMN mandant.typ.
R1-F05	lifecycle_status	Enum	lead · onboarding · aktiv · ruhend · archiviert (§5.2)
R1-F06	verantwortlich	Ref → R7	betreuende:r Berater:in; Scope-Anker für RBAC je Mandant (D-48, 0.46.0)
R1-F07	angelegt_am / geaendert_am	Zeit	Audit-Basis (R8)
R1-F08	nachname	Text?	natürliche Person; treibt Anzeigename + Ablage-Anfangsbuchstaben-Ebene (D-31, v18)
R1-F09	titel	Text?	akad. Titel (z. B. "Dr."), Teil des Anzeigenamens
R1-F10	vorname	Text?	natürliche Person
R1-F11	betreuungsmodell	Enum	intensiv · standard · basis — internes Leistungsversprechen der Kanzlei (nicht Kundenwert), rein intern (nur Cockpit/Detail, nie in Kundendokumenten, G-5), neutral dargestellt (kein Ampelschema — das ist der Aktenreife vorbehalten). Default standard, manuell pflegbar; Änderung auditiert (mandant.betreuungsmodell.geaendert). Fokus-Sortier-Tiebreak: intensiv < standard < basis. (D-35, v21)
R1-F13	iban_privat	Text?	private IBAN der natürlichen Person (MED-D-71, v30). Bank-PII (G-5) — normalisiert (ohne Leerzeichen, Großbuchstaben) + Mod-97-validiert (domain/iban.ts). Getrennt von der Entitäts-IBAN (R1-F29). Feld-Verschlüsselung/Retention offen: MED-KB-6.

Derived (nicht speichern, G-2): "Onboarding vollständig?", "nächste Fälligkeit" — aus R2/R5 abgeleitet.

Praxis/Gesellschaft (D-27, gebaut in 0.27.0 — Dentmarking T1; verallgemeinert D-45): Praxen/Gesellschaften unter der natürlichen Person (0..n) — Träger der Geschäftsjahr-Betriebsdaten (Dentmarking) und später der Dexman-Auswertung. Deckt Praxen und Gesellschaften/Beteiligungen ab (objektart, R1-F28). Das Geschäftsjahr kann vom Kalenderjahr abweichen.

ID	Feld	Typ	Hinweis
R1-F20	id	ULID	interner Schlüssel
R1-F21	mandant_id	Ref → R1	Träger (natürliche Person, 1:n)
R1-F22	name	Text	sprechend (G-3)
R1-F28	objektart	Enum	praxis · mvz · gesellschaft (D-45, v23) — geschäftliche Einordnung; treibt die Onboarding-Default-Vorlage (R2-F03)
R1-F23	typ	Enum	einbehandler · mehrbehandler · mvz_standort (operativer Praxis-Typ; treibt u. a. Dentmarking-Benchmarks)
R1-F24	rechtsform	Text	optional (Einzelpraxis/BAG/MVZ-GmbH …)
R1-F25	standort	Text	Ort/Adresse, PII-arm (G-5), optional
R1-F29	iban	Text?	Entitäts-IBAN der Praxis/Gesellschaft (MED-D-71, v30), separat von der privaten IBAN (R1-F13). Bank-PII (G-5), normalisiert + Mod-97-validiert. Feld-Verschlüsselung/Retention offen: MED-KB-6.
R1-F26	geschaeftsjahr_beginn_monat	Zahl 1–12	1 = Kalenderjahr (OP-DM-7)
R1-F27	angelegt_am / geaendert_am	Zeit	Audit-Basis (R8: praxis.angelegt/praxis.geaendert)

Stammdaten-Versionierung (MED-D-179, G-4). Jede Aktualisierung eines versionierten Mandant-Stammdatenfeldes (Name/Kontakt/Anschrift/private IBAN/CRM) erzeugt eine neue, append-only, per-Mandant hash-verkettete StammdatenVersion (Tabelle stammdaten_version, Migration v44): vollständiger snapshot der versionierten Felder je Version, version (ab 1), quelle (berater/self_service/onboarding/import/migration), actor, angelegt_am (= gültig-ab; gültig-bis = Beginn der Folgeversion), vorher_hash→hash (eigene Kette, domain/audit.ts-Primitiven). Frühere Werte (alte Anschriften/IBAN …) bleiben erhalten (Nutzer-Vorgabe; GoBD/§147 AO). Bewusst PII-tragend — der eine sanktionierte Ausnahmefall zur PII-armen Audit-Regel. Zugriff kontrolliert: die Historie ist mandantenscoped (nur über /api/mandanten/:id/stammdaten-versionen, RBAC-gebunden wie der übrige Mandant) und jeder Lesezugriff wird auditiert (stammdaten_version ∈ ZUGRIFF_SENSIBEL, protokolliereZugriff, D-50) — historische PII wird lazy geladen, nicht mit dem Mandanten eager mitgezogen (G-6). Weiterhin offen (Compliance): Feld-/At-Rest-Verschlüsselung der Snapshots und die konkrete Retention/Löschfrist — als benannter Kundenklärungspunkt MED-KB-6 geführt (keine unilateral gesetzte Frist). Versioniert im Repo-Chokepoint updateMandant/createMandant → lückenlos über alle Schreibpfade; reine lifecycle_status/verantwortlich-Änderungen erzeugen keine Version. Bestands-Mandanten bekommen v1 per idempotentem App-Level-Backfill. Folge-Slice: Praxis-Stammdaten (R1-F30..F32/F29)

• die Onboarding-Grunddaten (R1-F44..F49, MED-D-284) analog versionieren — heute liegen diese plain am Stammsatz (nicht in der fixen VERSIONIERTE_FELDER-Kette; ein Anhängen bräche bestehende per-Mandant-Ketten, daher ein per-Version-Schema-Marker als Voraussetzung). Datensparsam (MED-D-284): die Steuer-ID (§139b AO) wird bewusst NICHT erhoben. Trägt die Kunden-Self-Service-Anforderung FR-1.

Onboarding-Grunddaten-Felder (R1-F44..F49, MED-D-284) — alle string | null (optional, keine Pflicht), plain am mandant (NICHT hash-versioniert, s. o.); Abbildung Formular→Stammdaten über ONBOARDING_STAMM_REGELN:

ID	Feld	Typ	Wertobjekt	Bedeutung / Regeln
R1-F44	handynummer	string | null	Kontakt	mobile Nummer, getrennt vom Festnetz-telefon (F14); öffentlich erhoben
R1-F45	steuernummer	string | null	Steuer	Steuernummer (NICHT Steuer-ID §139b AO); öffentlich erhoben; keine Format-Erzwingung (DE/AT/CH)
R1-F46	steuerberaterName	string | null	Steuerberater	Name der Steuerberater:in — PII einer dritten Person → nicht auf der öffentlichen Strecke (Art. 14 DSGVO, RISK-34); interne Erfassung = Slice B
R1-F47	steuerberaterKanzlei	string | null	Steuerberater	Kanzlei (dito)
R1-F48	steuerberaterEmail	string | null	Steuerberater	E-Mail (dito)
R1-F49	steuerberaterTelefon	string | null	Steuerberater	Telefon (dito)

Bewusst KEIN Feld: Steuer-ID (§139b AO) und Ausweisnummer (§20 PAuswG) — der Personalausweis bleibt ein Upload-Nachweis (Onboarding-Dokument), keine strukturierten Ausweisdaten (Datensparsamkeit G-6).

Hash-Kette je Mandant (append-only; jede Version kettet an den hash der Vorgängerversion — Manipulation einer alten Version bricht die Kette ab der Stelle, analog Audit-Log.md):

Bankverbindungen — 1:n Bankkonto (R1-F33 ff., MED-D-195, Akten-Cockpit S3a). Ein Mandant hat 0..n Bankkonten (Tabelle bankkonto, Migration v45) — löst das frühere Einzel-IBAN-Feld ab (R1-F13 privat / R1-F29 Entität bleiben als Alt-Felder erhalten; verlustfreier, idempotenter Backfill über quell_schluessel

• UNIQUE-Index). Bank-PII (G-5/G-6): IBAN normalisiert (domain/iban.ts) + Inhaber-Name; Feld-/At-Rest- Verschlüsselung + Retention offen als MED-KB-6 (s. RISK-28). Kein Löschen — Archivieren via Prüfstatus (append-only, G-4).

Feld	Name	Typ	Bedeutung
R1-F33	id	ULID	Bankkonto-Identität
R1-F34	mandant_id	Ref → R1	Träger (natürliche Person, Kontext-Anker, immer gesetzt)
R1-F35	praxis_id	Ref → Praxis?	Kontext Gesellschaft/Praxis; null = privat
R1-F36	inhaber	Text	Kontoinhaber-Name (Bank-PII)
R1-F37	iban	Text	IBAN, normalisiert + Mod-97-validiert (Bank-PII)
R1-F38	zeichnungsberechtigt	Text?	wer ist zeichnungsberechtigt (Freitext, optional)
R1-F39	pruefstatus	Enum	neu → geprüft → archiviert (berater-getrieben; Archivieren statt Löschen)
R1-F40	sepa_gueltig	Bool	SEPA-Lastschriftmandat gültig? (getrennte Achse vom Prüfstatus)
R1-F41	quelle	Enum	Herkunft: backfill (aus Alt-IBAN-Feld) · manuell (im UI angelegt)
R1-F42	quell_schluessel	Text?	stabiler Backfill-Schlüssel (UNIQUE, dedupt Doppelläufe); manuell = null
R1-F43	angelegt_am / geaendert_am	Zeit	Audit-Basis

Prüfstatus-Zustandsmaschine (zwei getrennte Achsen: pruefstatus steuert Sichtung/Archiv, sepa_gueltig ist orthogonal — ein Konto kann in jedem Prüfstatus SEPA-gültig/-ungültig sein):

4.5 R2 Onboarding & Prozess — Datenmodell

Ein Onboarding hängt am Mandanten und besteht aus Pflicht-Items (Stammdaten/Dokumente/Aufgaben). Der Fortschritt wird aus den Items abgeleitet (G-2), nicht als Flag gehalten.

ID	Feld	Typ	Hinweis
R2-F01	id	ULID
R2-F02	mandant_id	Ref → R1
R2-F03	vorlage	Enum	Onboarding-Vorlage je objektart der (ersten) Praxis/Gesellschaft (R1-F28, D-45); ohne Praxis → gesellschaft (Basis); Items admin-editierbar
R2-F04	phase	Enum	Onboarding-Teilschritt (innerhalb der Lifecycle-Stufe onboarding; keine eigene Achse, s. architektur/Prozessmodell.md §2 / MED-D-79/151): stammdaten · dokumente · beratung · abschluss (≠ Lifecycle, §5.2)
R2-F05	items[]	Liste	die Pflicht-Items (s. u.)

Onboarding-Item (R2-F1x):

ID	Feld	Typ	Hinweis
R2-F10	item_id	ULID
R2-F11	bezeichnung	Text	sprechend, G-3 (z. B. "Personalausweis", "Einwilligung Datenschutz")
R2-F12	kategorie	Enum	stammdatum · dokument · aufgabe
R2-F13	pflicht	Bool	Pflicht vs. optional
R2-F14	status	Enum	offen · angefordert · erhalten · geprüft · entfällt (sprechend, G-3)
R2-F15	dokument_ref	Ref → R3	falls kategorie=dokument (NextCloud-Referenz)
R2-F16	faellig_am	Zeit	erzeugt bei Bedarf eine Wiedervorlage (R5)

Status-Enums sind logik-tragend (treiben Ableitung/Lifecycle) → fix; Vorlagen/Item-Kataloge sind Taxonomie → admin-editierbar.

Pflicht-Nachweise der Onboarding-Phase (MED-D-70). Die Onboarding-Phase gilt erst als vollständig, wenn je Mandant diese personenbezogenen Pflicht-Bausteine vorliegen: Einwilligung in die Datenverarbeitung · Personalausweis · Kundenfragebogen · SEPA-Mandat · Dienstleistungsauftrag — plus die private IBAN der natürlichen Person. Die IBAN(s) der Gesellschaften/Entitäten werden separat je Praxis/Gesellschaft geführt (getrennt von der privaten IBAN; eine Person kann 0..n Entitäts-IBANs haben, R1/D-45). Quelle: domain/onboarding-vorlagen.ts (Default-Katalog je objektart, admin-editierbar gedacht). Offen (KB/G-5): ob IBANs/Personalausweis über die Onboarding-Checkliste hinaus strukturiert persistiert werden (Bank-/ Ausweis-PII → Verschlüsselung, Zweckbindung, Aufbewahrung) — siehe Kunden-Besprechungspunkte.md MED-KB-6 und HANDOFF.md §4 (Default: nur Checklisten-Nachweis, keine Roh-PII-Persistenz, G-6).

Stammdatenerfassung per Web-Formular (Workshop W2): Statt PDF-Kundendatenbogen ein Browser-Formular, das der Kunde selbst (oder vor Ort/online) ausfüllt. Beim Absenden wird der Mandant einmalig erfasst ("eine Wahrheit", G-2) → CRM-Anlage (R1/A-3) und automatische Anlage des NextCloud-Kundenordners (R3). Diese Stammdaten sind die Datenquelle für die Dokumenten-Automatisierung (R12) und die Auto-Befüllung der Beratungsdoku (R6-F07).

Self-Service per Einladungslink ✅ gebaut (Slice 9, 0.10.0): Berater/Backoffice erzeugt im Tool eine Einladung (onboarding_einladung: tokenisierter Link, an einen Lead gebunden, mit Ablauf). Die Praxis öffnet …/onboarding/<token> (öffentlich, außerhalb Cloudflare Access — Bypass-Policy nötig, OP-ONBOARD-1; Bot-Schutz via Turnstile, optional), erfasst die Stammdaten und erteilt die Einwilligung als SES (einfache elektronische Signatur: Ankreuzen + Name + Absenden). Der Vorgang wird append-only auditiert (G-4, PII-arm via Inhalts-Hash); die Einwilligungs-Fassung wird als R3-Dokument

• SES-Signaturvorgang (R4) abgelegt. Rechtlich: SES genügt für die DSGVO-Einwilligung (Art. 6/7); formgebundene Verträge → AES/QES (OP-SIGN-1). Der Einwilligungstext ist juristisch zu prüfen (RISK-18).

Weiterentwicklung — persistentes Kunden-Self-Service-Portal (geplant, MED-D-279/MED-OP-PORTAL-1): die heutige einladungsbasierte Einmalstrecke wird um ein persistentes Kunden-Login ergänzt (Kunde pflegt Infos jederzeit selbst, sieht seinen Stand). Der Datenpfad bleibt identisch: Einreichung ist „submitted" ≠ tatsächlicher Datenstand, Übernahme erst nach 4-Augen-Freigabe des Beraters (feldweise, versioniert, Quelle portal) — nutzt die bestehende feld-sichtung/uebernahme-Maschine (G-1/G-2). Auth passwortlos/ Magic-Link; neue Entitäten portal_konto/portal_anmelde_token/portal_session. Gate vor Go-Live: DSGVO/ AVV + Auth-Freigabe (MED-KB-13), Zero-Trust-Ausnahme (RISK-33), Mail-Versand (OP-DM-8). Design: docs/architektur/Kunden-Self-Service-Portal.md.

4.2 R3 Dokumente — Referenz-Modell

• Die Datei liegt in NextCloud; Medidentas speichert Referenz (Pfad/File-ID), Typ, Status (angefordert · erhalten · geprüft · unterschrieben · abgelaufen) und Metadaten — nicht die Datei-Kopie. Details: docs/architektur/Dokumentenverwaltung-NextCloud.md.
• Standard-Ordnerstruktur je Mandant (Workshop W2): Beim Anlegen eines Mandanten wird automatisch ein Kundenordner mit fester Unterstruktur erzeugt (z. B. Persönliche Daten, Verträge, Beratungsdoku, Korrespondenz). Erzeugte/signierte Dokumente (R12/R4) werden sprechend benannt und automatisch in den passenden Unterordner abgelegt. Struktur ist admin-konfigurierbar (OP-DOC-1).

Felder (Slice 2, R3-F##):

ID	Feld	Typ	Hinweis
R3-F01	id	ULID
R3-F02	mandant_id	Ref → R1
R3-F03	onboarding_item_id	Ref → R2	optional — verknüpftes Dokument-Pflicht-Item (treibt Item-Status-Propagation)
R3-F04	bezeichnung	Text	sprechend (G-3)
R3-F05	typ	Enum	reserviert (Dokumenttyp, z. B. Ausweis/Vertrag/Einwilligung) — noch nicht gebaut
R3-F06	nextcloud_pfad	Text	stabiler Verweis (WebDAV-Pfad); null bis abgelegt (S-2)
R3-F07	status	Enum	angefordert · erhalten · geprüft · unterschrieben · abgelaufen (sprechend, G-3)
R3-F08	gueltig_bis	Zeit	optional (Frist → Wiedervorlage R5)
R3-F09	angelegt_am / geaendert_am	Zeit	Audit-Basis (R8)
R3-F10	upload_link	Text	(MED-D-55, v25) öffentlicher OCS-Upload-Link (File Drop); null bis erzeugt
R3-F11	upload_token	Text	(MED-D-55, v25) NextCloud-Share-Token (Referenz zum Widerruf/Abgleich)

Datei-CRUD über WebDAV (R9/A-1, OP-DOC-1 MVP): Anlegen der Ordnerstruktur, Hochladen (PUT) und idempotenter Abgleich (Existenz-Check → Status nachführen, RISK-6). Dokument-Status propagiert auf das verknüpfte Onboarding-Item (R2-F14) → "eine Wahrheit". Detail: architektur/Dokumentenverwaltung-NextCloud.md.

Öffentlicher Upload-Link + Webhook (MED-D-55, 0.49.0): je Dokument ein OCS-Share ("File Drop", shareType=3) auf …/Eingang/<dokumentId> → der Kunde lädt ohne NextCloud-Account hoch (POST /api/dokumente/:id/upload-link, idempotent). Ein Webhook (POST /oeffentlich/nextcloud/webhook, Shared-Secret) meldet neue Dateien und hebt angefordert → erhalten (Push statt Polling, RISK-6). NextCloud = ein technischer Service-User (App-Passwort; OAuth2 verworfen — kein client_credentials).

4.3 R4 Unterschriften — eIDAS-Niveau je Dokumenttyp

• Jeder Unterschrifts-Vorgang trägt ein Signatur-Niveau (SES/AES/QES, CH: ZertES). Niveau ist je Dokumenttyp begründet festzulegen (Verträge ggf. QES, Einwilligungen ggf. SES). Details: docs/architektur/Unterschriften.md, OP-SIGN-1.
• End-to-end-Fluss (UC-8): befülltes Dokument (R12) → Provider (DocuSign/PandaDoc) → signierte Variante mit Kennung "SIG" automatisch zurück nach NextCloud (R3). Ziel: sofort unterschriftsreif, auch bei Vor-Ort-/Online-Konsultation (Workshop W4).

Felder (Slice 4, R4-F##) — Signatur-Vorgang:

ID	Feld	Typ	Hinweis
R4-F01	id	ULID
R4-F02	dokument_id	Ref → R3	das zu signierende Dokument
R4-F03	provider	Text	docusign · pandadoc · fake (Provider-Abstraktion A-2)
R4-F04	niveau	Enum	SES · AES · QES (eIDAS; CH: ZertES) — aus begründeter Matrix je Dokumenttyp (OP-SIGN-1, RISK-2)
R4-F05	status	Enum	vorbereitet · gesendet · signiert · abgelehnt · abgelaufen (sprechend, G-3)
R4-F06	external_id	Text	Envelope-/Dokument-ID beim Provider
R4-F07	signiert_pfad	Text	NextCloud-Pfad der signierten Fassung (Rückablage, G-4)
R4-F08	angelegt_am / geaendert_am	Zeit	Audit-Basis (R8)

Niveau-Matrix (MVP, begründet): Vollmacht → QES (Schriftform) · Vertrag/Auftrag → AES · Mandat/Einwilligung → SES. Bei Abschluss Rückablage der signierten Fassung nach NextCloud + Dokument-Status unterschrieben (R3) + Onboarding-Item geprüft (R2). Detail: architektur/Unterschriften.md.

4.6 R6 Beratungsdokumentation — Textbausteine, KI-Check, Auto-Befüllung

Aus dem Workshop (W5) konkretisiert. Eine Beratungsdoku hängt am Mandanten/Vorgang und gehört zu einem Themenbereich (mehrere je Mandant möglich).

ID	Feld	Typ	Hinweis
R6-F01	id	ULID
R6-F02	mandant_id	Ref → R1
R6-F03	themenbereich	Enum	praxisfinanzierung · sachversicherung · krankenversicherung · geldanlage (admin-editierbarer Katalog; §3 der Workshop-Doku)
R6-F04	vorlage	Ref	Protokoll-Vorlage je Themenbereich (einheitlicher Briefbogen, FR-2)
R6-F05	bausteine[]	Liste	verwendete Textbausteine (sprechend, G-3)
R6-F06	inhalt	Text	Protokolltext (baustein- + KI-gestützt vorformuliert)
R6-F07	kontext_quelle	Ref	Auto-Befüllung aus CRM (Stammdaten) und/oder Meeting-Protokoll (R11)
R6-F08	pruefstatus	Enum	entwurf · ki_geprüft · freigegeben (sprechend, G-3) — KI-Check ist Hinweis, nicht Freigabe
R6-F09	dokument_ref	Ref → R3	finale, ablagefähige Fassung (NextCloud); ggf. → R4 zur Signatur
R6-F10	angelegt_am / geaendert_am	Zeit	Audit-Basis (R8), append-only (G-4)
R6-F11	termin_am	Zeit	(gebaut, Slice 10) Wann fand die Beratung statt (Datum/Uhrzeit) — ≠ angelegt_am
R6-F12	ort	Enum + Text	(gebaut, Slice 10) Wo: beim_kunden · bei_medidentas · video_call; bei Präsenz mit Adresse, bei Video mit Plattform/Hinweis
R6-F13	dauer_minuten	Zahl	(gebaut, Slice 10) Wie lange dauerte der Termin (Minuten)
R6-F14	analyse_programm	Text/Ref	(gebaut, Slice 10) mit welchem Analyse-/Beratungsprogramm wurde die Beratung durchgeführt
R6-F15	empfehlung_gefolgt	Enum	(gebaut, Slice 10) ja · nein · offen — folgt der Kunde der Empfehlung? Bei nein Begründung/Abweichung dokumentieren (VVG-Beratungsverzicht/abweichender Kundenwunsch)
R6-F16	risiken_aufgeklaert	Bool	(gebaut, Slice 10) Bestätigung, dass der Kunde über alle Risiken aufgeklärt wurde (G-4-Nachweis); ergänzende Details im Protokolltext (F06)
R6-F17	unterlagen_uebermittlung	Enum	(gebaut, Slice 10) Wie hat der Kunde die Unterlagen erhalten — papier_persoenlich · post · email · nextcloud_link · sonstige; Nachweis der Aushändigung/Übermittlung (G-4)
R6-F18	angaben_kundenursprung	Bool	(gebaut, Slice 10) Bestätigung, dass die Angaben — insb. Gesundheitsbogen — und alle weiteren Angaben vom Kunden bereitgestellt und vom Berater 1:1 (unverändert) übernommen wurden. Haftungsrelevant für die vorvertragliche Anzeigepflicht (§19 VVG); G-4-Nachweis
R6-F19	dokumentationsverzicht	Bool + Ref → R3/R4	(gebaut, Slice 11) Verzicht auf die Beratungsdokumentation durch den Kunden — nur per gesonderter, ausdrücklicher schriftlicher Erklärung zulässig (§6 Abs. 3 / §61 Abs. 2 VVG) inkl. Hinweis auf mögliche Nachteile bei der Beweisführung. Workflow: verzichtErteilen rendert die Verzichtserklärung, legt sie ablagefähig ab (R3) + signaturpflichtig (R4, SES), terminiert das Protokoll (freigegeben) und blendet die Pflichtinhalte (F06/F11–F18) aus; G-4-Nachweis via Inhalts-Hash
R6-F20	kundenerklaerung	Bool	(gebaut, Slice 10) Schlusserklärung des Kunden: bestätigt, dass er alles verstanden hat, über alles aufgeklärt wurde, selbst alle sachdienlichen Hinweise gegeben hat, exakt das empfohlene Produkt wünscht und mit der Beratung zufrieden ist. Compliance-Caveat (RISK-20): vorformulierte Pauschal-Bestätigungen haben begrenzten Beweiswert (BGH) und ersetzen die eigene Beratungsdoku nicht — juristisch zu prüfen; G-4-Nachweis

• KI-Vollständigkeits-/Rechtssicherheits-Check (OP-AI-1): prüft je Themenbereich, ob die regulatorisch geforderten Punkte adressiert sind (z. B. Risiken erläutert, Empfehlung begründet), und ergänzt übliche Aufklärungen. Haftungsgrenze: Der Check ist eine Assistenz — die fachlich-rechtliche Endkontrolle bleibt beim Berater (RISK-14). Pflichtfelder folgen aus der Regulatorik (Compliance.md, R6).
• Ziel-Effizienz: 5–10 Min statt 30 (Workshop); erreicht durch Auto-Befüllung (R6-F07) + Bausteine (R6-F05). Sofort unterschriftsreif über R4.
• Rahmendaten des Beratungstermins (Pflichtangaben, OP-BERATDOK-1, gebaut Slice 10): Jedes Protokoll hält wann (R6-F11 termin_am), wo (R6-F12 ort: beim Kunden / bei Medidentas — je mit Adresse — oder Video-Call), wie lange (R6-F13 dauer_minuten), womit (R6-F14 analyse_programm), ob der Kunde der Empfehlung folgt (R6-F15 empfehlung_gefolgt, bei Abweichung mit Begründung), ob über alle Risiken aufgeklärt wurde (R6-F16 risiken_aufgeklaert) und wie der Kunde die Unterlagen erhalten hat (R6-F17 unterlagen_uebermittlung: Papier persönlich · Post · E-Mail · NextCloud-Link · sonstige). Zusätzlich bestätigt der Berater, dass die Angaben — insbesondere der Gesundheitsbogen — und alle weiteren Angaben vom Kunden bereitgestellt und 1:1 (unverändert) übernommen wurden (R6-F18 angaben_kundenursprung; haftungsrelevant für die vorvertragliche Anzeigepflicht §19 VVG).
• Verzicht auf die Beratungsdokumentation (R6-F19 dokumentationsverzicht, OP-BERATDOK-1, gebaut Slice 11): Der Kunde kann auf die Beratungsdokumentation verzichten — zulässig nur durch gesonderte, ausdrückliche schriftliche Erklärung (§6 Abs. 3 / §61 Abs. 2 VVG) mit Hinweis, dass dies seine Beweisführung bei späteren Schadenersatzansprüchen erschweren kann. Bei Verzicht entfallen die Protokoll-Pflichtfelder (F06/F11–F18); die Verzichtserklärung selbst wird ablagefähig (R3) und signaturpflichtig (R4) erfasst, der G-4-Nachweis bleibt Pflicht.
• Schlusserklärung des Kunden (R6-F20 kundenerklaerung, OP-BERATDOK-1, gebaut Slice 10): Der Kunde bestätigt, dass er alles verstanden hat, über alles aufgeklärt wurde, selbst alle sachdienlichen Hinweise gegeben hat, exakt das empfohlene Produkt wünscht und mit der Beratung zufrieden ist. Compliance-Caveat (RISK-20): Solche vorformulierten Pauschal-Bestätigungen haben nach der Rechtsprechung (BGH) begrenzten Beweiswert und ersetzen die eigene, konkrete Beratungsdokumentation nicht (Gefahr unwirksamer/überraschender Klauseln, Umkehr der Dokumentationslast). Daher als Ergänzung, nicht als Ersatz, führen — Formulierung juristisch prüfen.
• Diese Angaben sind regulatorisch geboten (Beratungsdokumentation IDD/§34d GewO·VVG §61–62, Beratungsprotokoll §18 FinVermV) und Teil des lückenlosen, auditierbaren Nachweises (G-4). Detail/Endabnahme: betrieb/Compliance.md.

Gebaut (Slice 5, 0.7.0): Pflichtthemen + Default-Bausteine je Themenbereich (server/src/domain/beratung-themen.ts, schärft OP-DOMAIN-1) — praxisfinanzierung · sachversicherung · krankenversicherung · geldanlage. KI-Prüfer-Abstraktion (ki/pruefer.ts, OP-AI-1) mit regelbasiertem Default-Check (RegelPruefer) — pruefstatus: entwurf → ki_geprüft (Assistenz, RISK-14) → freigegeben (Mensch). Freigabe erzeugt die ablagefähige Fassung als Dokument (R3, Status erhalten) → fließt in die Dokumenten-/Signatur-Pipeline (R4). Vollständigkeit wird abgeleitet (G-2), nicht gespeichert. REST: GET/POST /api/mandanten/:id/beratungsdoku, PATCH /api/beratungsdoku/:id, POST /api/beratungsdoku/:id/{pruefen,freigeben}.

4.7 R11 Meeting-Doku & Aufgaben/Delegation — Datenmodell

Aus dem Workshop Priorität 1 (W1). Ein Meeting erzeugt ein Protokoll und daraus Aufgaben, die an Verantwortliche delegiert werden — zentral (nicht per E-Mail) und mit Kunde/Vorgang verknüpfbar ("eine Wahrheit", G-2).

Stand (0.58.0, MED-D-82 — Kern gebaut): Entität Meeting (F01–F08, mandant-scoped, quelle=manuell) steht; die Aufgabe (F10–F16) ist als Wiedervorlage (R5, quelle='aufgabe') realisiert — "Aufgabe = auch ohne Meeting nutzbar = reine Wiedervorlage" umgesetzt (G-2, kein Parallel-Store): verantwortlich→R7-Delegation, faelligAm, Rücksprung über quelleRef=aufgabe:<meetingId>:<kennung> (F16). Offen: echte Transkription (quelle=transkription) — Standard-Tool + EU-Residenz/AVV (OP-MEET-1, RISK-15); der eigene Status in_arbeit (F14) ist zugunsten der R5-Status offen/erledigt/entfällt (noch) nicht separat geführt.

ID	Feld	Typ	Hinweis
R11-F01	id	ULID
R11-F02	titel	Text	sprechend (z. B. "Dienstagsbesprechung 20.01.")
R11-F03	art	Enum	team · kundengespräch · videocall
R11-F04	mandant_id	Ref → R1	optional (nur bei Kundenbezug)
R11-F05	quelle	Enum	transkription (Tool, OP-MEET-1) · manuell
R11-F06	zusammenfassung	Text	KI-/Tool-generiertes Protokoll (Hinweis-Status, nachbearbeitbar)
R11-F07	aufgaben[]	Liste	die delegierten Aufgaben (s. u.)
R11-F08	angelegt_am	Zeit	Audit-Basis (R8)

Aufgabe (R11-F1x) — auch eigenständig (ohne Meeting) und als Wiedervorlage (R5) nutzbar:

ID	Feld	Typ	Hinweis
R11-F10	aufgabe_id	ULID
R11-F11	beschreibung	Text	sprechend, G-3
R11-F12	verantwortlich	Ref → R7	delegiert an Teammitglied
R11-F13	mandant_id	Ref → R1	optional (kundenverknüpft)
R11-F14	status	Enum	offen · in_arbeit · erledigt (sichtbar erledigt, kein Medienbruch)
R11-F15	faellig_am	Zeit	erzeugt bei Bedarf eine Wiedervorlage (R5)
R11-F16	quelle_meeting	Ref → R11	Rücksprung ins Protokoll ("woher kommt die Aufgabe?")

G-1-Abwägung: Die Transkription/Zusammenfassung wird über ein Standard-Tool angebunden (A-8, OP-MEET-1: Notion/Plaud/Krisp o. ä.), nicht nachgebaut. Eigenentwicklung ist nur die Aufgaben-/ Delegations-Orchestrierung und die Verknüpfung Protokoll↔Mandant↔Wiedervorlage (der differenzierende Mehrwert). Build-vs-Buy zu CRM: Aufgaben können je nach OP-CRM-1-Entscheidung im CRM oder in Medidentas geführt werden — entscheidend ist "eine Wahrheit", nicht der Ort.

4.8 R12 Dokumenten-Automatisierung — Formularbefüllung & -erzeugung

Aus dem Workshop (W3). Aus einem Kundendatenbogen (R1/R2-Stammdaten) werden Standarddokumente automatisch befüllt, benannt und abgelegt (R3), dann zur Signatur (R4) gegeben. Gebaut (Slice 8, 0.9.0): Mapping-Engine domain/dokumentvorlagen.ts (Vorlagen-Katalog je Dokumenttyp + Feld-Mapping aus dem Stammsatz, sprechende Benennung) + api/dokumentgenerierung-service.ts (vorbereiten → erzeugen/ablegen → zur Unterschrift). Status signiert wird aus dem Signatur-Vorgang abgeleitet (G-2). REST: GET/POST /api/mandanten/:id/dokumentgenerierung, POST /api/dokumentgenerierung/:id/{erzeugen,unterschrift}.

ID	Feld	Typ	Hinweis
R12-F01	id	ULID
R12-F02	mandant_id	Ref → R1	Datenquelle für die Befüllung
R12-F03	dokumenttyp	Enum	dienstleistungsauftrag · makler_allein_auftrag · steuerberatervollmacht · sepa_lastschriftmandat · existenzgruendung_checkliste · kundenunterlagen_einwilligung (admin-editierbarer Katalog)
R12-F04	vorlage_ref	Ref	Template (Felder-Mapping → OP-DOCGEN-1)
R12-F05	feld_mapping	Map	Stammdaten-Feld → Formularfeld (zentrale Quelle, kein Doppeleintrag, G-2)
R12-F06	erzeugtes_dokument_ref	Ref → R3	sprechend benannt (<Typ>_<Nachname>_<…>), in NextCloud abgelegt
R12-F07	signatur_ref	Ref → R4	optionaler Anstoß der E-Signatur
R12-F08	status	Enum	vorbereitet · erzeugt · abgelegt · zur_unterschrift · signiert

Eigenbau begründet (G-1): Eine generische Template-/Mapping-Engine über die eigenen Stammdaten und NextCloud ist kein Standard-Produkt von der Stange (DocuSign/PandaDoc liefern Signatur + einfache Felder, aber nicht das Mapping aus dem CRM-Stammsatz in mehrere hauseigene Formulare). Wo der Signaturanbieter Vorausfüllung nativ kann, wird sie genutzt (OP-DOCGEN-1).

Stand OP-DOCGEN-1 (0.32.0): erzeugte Dokumente werden als PDF abgelegt (pdf-lib im Worker, D-28; Blockmodell in server/src/pdf/) und sind über GET /api/dokumente/:id/datei abrufbar. Rest offen: erweiterter Kundendatenbogen (Anschrift/Rechtsform/Bank) · native Provider-Vorausfüllung · Binär-Hausformular-PDF-Templates · manuelle Detail-Ausformulierung bei Individualverträgen (OP-DOCGEN-2). eIDAS-Niveau je Typ kommt aus der R4-Matrix (Vollmacht→QES, Auftrag→AES, Mandat/Einwilligung→SES).

4.10 R5 Wiedervorlagen — Fristen & Erinnerungen (A-5)

Terminierte Erinnerungen/Fristen je Mandant (Slice 3) — beantwortet True North #2 ("was ist offen und fällig?"). Erinnerungen werden Cron-getrieben über eine Benachrichtigungs-Abstraktion (A-5) zugestellt (Default: strukturierter Log-Kanal; E-Mail/Push als Verfeinerung).

ID	Feld	Typ	Hinweis
R5-F01	id	ULID
R5-F02	mandant_id	Ref → R1
R5-F03	betreff	Text	sprechend (G-3)
R5-F04	faellig_am	Zeit	epoch ms
R5-F05	status	Enum	offen · erledigt · entfällt
R5-F06	quelle	Enum	manuell · onboarding_item · dokument_frist
R5-F07	quelle_ref	Text	Item-/Dokument-ID (idempotente Ableitung)
R5-F08	verantwortlich	Ref → R7	optional
R5-F09	erinnert_am	Zeit	letzte Erinnerung (Cron-Idempotenz, RISK-6)
R5-F10	angelegt_am / geaendert_am	Zeit	Audit-Basis (R8)
R5-F11	erledigt_am	Zeit	optional

Fälligkeits-Cockpit (UC-6): GET /api/wiedervorlagen listet offene, fällige Wiedervorlagen über alle Mandanten. Materialisierung aus Fristen (R3 gueltig_bis) per …/synchronisieren (idempotent). Cron (scheduled, stündlich) versendet fällige Erinnerungen idempotent (erinnert_am, RISK-6).

• Delegation/Zuweisung an Mitarbeiter (OP-WV-1, ✅ gebaut Slice 12): R5-F08 verantwortlich wird per POST /api/wiedervorlagen/:id/zuweisen gesetzt — die E-Mail muss ein bekannter Benutzer (R7) sein (validierte Referenz statt Freitext), null hebt die Zuweisung auf. Bei (Neu-)Zuweisung Benachrichtigung an den Zuständigen und ein Audit-Nachweis der Delegation (wiedervorlage.zugewiesen, wer→wem, G-4). Die gefilterte Sicht "meine Wiedervorlagen" (GET /api/wiedervorlagen/meine, nach aktueller Identität) liegt im Cockpit. Bindet R5 ↔ R7; speist UC-4/UC-6.

4.8a R7 Benutzer & Rollen — Cloudflare Access + RBAC (OP-AUTH-1)

Identität kommt vom Standard-IdP (G-1): Cloudflare Access authentifiziert vor dem Worker und setzt den Header cf-access-authenticated-user-email. Medidentas hält kein Passwort, nur die Rollenzuordnung je E-Mail (D1-Tabelle benutzer). Der angemeldete Nutzer wird zum Audit-Actor (R8-F03, G-4).

ID	Feld	Typ	Hinweis
R7-F01	email	Text (PK)	Identität aus Cloudflare Access (lowercase)
R7-F02	rolle	Enum	berater · backoffice · admin
R7-F03	anzeigename	Text?	optional, frei
R7-F04	angelegt_am	Zeit	epoch ms

Auflösung (auth/identitaet.ts): Header → E-Mail → Rolle aus benutzer; Bootstrap-Admin (AUTH_BOOTSTRAP_ADMIN) sticht die Tabelle (Deploy-Erstzugang); unbekannte Nutzer erhalten die Default-Rolle (AUTH_DEFAULT_ROLLE, Default berater). AUTH_ENFORCED=true → ohne Access- Identität 401; lokal (false) Dev-Akteur (admin). REST: GET /api/ich, GET /api/benutzer, PUT/DELETE /api/benutzer/:email.

Rechte-Matrix (0.46.0, D-48 — domain/rechte.ts, eine Wahrheit G-2): RBAC läuft über eine zentrale Rolle×Fähigkeit-Matrix statt der früheren binären admin-Prüfung — berater/backoffice werden dadurch unterscheidbar.

Fähigkeit	admin	backoffice	berater
benutzer_verwalten / einstellungen_verwalten / playbooks_verwalten	✓	–	–
mandant_sehen_alle	✓	✓	– (nur eigene)
mandant_bearbeiten	✓	✓	✓ (nur eigene)
mandant_zuweisen	✓	✓	–

RBAC je Mandant (0.46.0, D-48): R1-F06 (= Mandant.verantwortlich) ist der Scope-Anker — ein berater sieht/bearbeitet nur Mandanten, für die er verantwortlich ist, plus noch unzugeordnete (verantwortlich = null → gemeinsamer Lead-Pool, verhindert "Mandanten verschwinden" bei Bestandsdaten); backoffice/admin sehen alle. Durchsetzung an zwei Chokepoints: service.sichtbareMandanten(akteur) für die Aggregate (/api/mandanten, /api/offene-punkte, /api/aktenreife) und eine Middleware auf /api/mandanten/:id* (Fremd-Mandant → 404, kein Existenz-Leak; Schreiben verlangt mandant_bearbeiten). Scharfschaltung per Feature-Flag (Tenant-Einstellung rbac_mandant_scope_aktiv, Default aus) — erst Zuständigkeiten vergeben, dann aktivieren, im Störfall ohne Deploy zurückdrehen. Zuweisung: POST /api/mandanten/:id/zuweisen { email|null } (Guard mandant_zuweisen, validierte R7-Referenz, Audit mandant.zugewiesen). Rest offen (OP-AUTH-1): Access-Application/Policies (Deploy), feingranulare Sub-Entitäts-Guards (Routen mit eigener Objekt-ID), SCIM/Gruppen-Sync.

4.9 R8 Audit-Log — append-only & hash-verkettet (G-4)

Quergeschnittenes, append-only Ereignisprotokoll über alle zustandsändernden Aktionen (Slice 6). Manipulationssicher durch SHA-256-Hash-Verkettung; PII-arm (G-5: nur IDs/Status/Enums).

ID	Feld	Typ	Hinweis
R8-F01	id	ULID (monoton)	streng monoton → Lese- = Ketten-Reihenfolge
R8-F02	ts	Zeit	Server-Zeit (UTC, epoch ms)
R8-F03	actor	Text	angemeldete E-Mail (R7) oder system (Cron)
R8-F04	mandant_id	Ref → R1	optional
R8-F05	entitaet	Text	mandant · onboarding · onboarding_item · dokument · signatur
R8-F06	entitaet_id	Text
R8-F07	aktion	Text	sprechend (z. B. onboarding.gestartet, signatur.signiert)
R8-F08	details	JSON-Text	PII-armer Diff/Kontext (G-5)
R8-F09	trace_id	Text	Korrelation über Dienste/Webhooks
R8-F10	vorher_hash	Text	Hash des Vorgänger-Events
R8-F11	hash	Text	SHA-256(vorher_hash|ts|actor|mandant_id|entitaet|entitaet_id|aktion|details)

Integrität: GET /api/audit/verify prüft die gesamte Kette (erkennt Änderung und Löschung). Retention/Archiv je Entitätstyp (GoBD/§147 AO etc.) + Cold-Storage-Export sind in OP-AUDIT-1 definiert. Detail: architektur/Audit-Log.md.

4.11 R13 Leistungszeit — Zeiterfassung & Abrechnungsbasis (OP-TIME-1)

Erfasst die abrechenbare Beratungs-/Arbeitszeit je Mandant als dünnes Ledger im Kern (Ansatz A, Build-vs-Buy-Entscheidung 2026-07-01): Medidentas besitzt den Domänenkontext (wer × Mandant × ggf. Beratung), die Rechnung entsteht extern (SevDesk, OP-INVOICE-1). Abzugrenzen von der internen Agenten- Timesheet (Tooling-Aufwand) und von der gesetzlichen Arbeitszeiterfassung (ArbZG → OP-TIME-2).

ID	Feld	Typ	Bemerkung
R13-F01	id	ULID
R13-F02	mandant_id	Ref → R1
R13-F03	benutzer_email	Ref → R7	wer die Zeit geleistet hat (authentifizierte Identität)
R13-F04	datum	Zeit	Leistungstag (epoch ms)
R13-F05	dauer_minuten	Zahl
R13-F06	taetigkeit	Text	sprechend (G-3)
R13-F07	beratung_ref	Ref → R6	optional; gesetzt bei Auto-Seed aus dem Beratungsprotokoll
R13-F08	abrechenbar	Bool	Default true
R13-F09	abgerechnet	Bool	an SevDesk übergeben/fakturiert (OP-INVOICE-1)
R13-F10	angelegt_am / geaendert_am	Zeit	Audit-Basis (R8), append-only (G-4)
R13-F11	auftrag_ref	Ref → Beratungsauftrag	optional; manuelle Mandat-Zuordnung am Timer (MED-D-157)

• Auto-Seed (G-2, wenig Tipparbeit): aus R6-F11 termin_am + R6-F13 dauer_minuten wird je Beratungsprotokoll genau ein Zeiteintrag abgeleitet (idempotent über beratung_ref).
• Abrechnungsvorschau (GET /api/mandanten/:id/abrechnungsvorschau): summiert offene, abrechenbare (noch nicht abgerechnet) Minuten/Stunden — die Export-Vorstufe für SevDesk (OP-INVOICE-1). Nach der Fakturierung werden die Einträge als abgerechnet markiert. Jede Zustandsänderung ist auditiert (G-4).
• Stunden-Übersicht auf der Kundenkarte (GET /api/mandanten/:id/leistungszeit/uebersicht): abgeleitete Aufteilung geleistet → abgerechnet → bezahlt (+ offen), rein abgeleitet (G-2). bezahlt kommt aus der Rechnungs-/Zahlungsseite (SevDesk, OP-INVOICE-1) und ist bis zu deren Anbindung 0 (kein Doppel-Pflegen des Zahlungsstatus) — der Andockpunkt ist im Feld bezahltMinuten vorbereitet.

Aktiver Timer (Erweiterung von R13, OP-TIME-3): genau ein laufender/pausierter Zeiterfassungs-Timer je eingeloggtem Benutzer — löst die vorherige rein clientseitige, pro-Browser-Tab-lokale Stoppuhr ab (mehrere gleichzeitig geöffnete Mandanten hatten sonst unabhängige, sich gegenseitig ignorierende Uhren; der gemeldete Fehler "Zeiterfassung nur auf dem aktiven Kunden, der vorne ist"). Serverseitig eine Zeile je Benutzer (G-2); ephemer bis zum Buchen, dann entsteht der eigentliche R13-Leistungszeit-Eintrag oben.

Aktualisierung MED-D-275 (durchlaufender Timer, autoritativ in docs/architektur/Zeiterfassung-Segmente-und-Push.md): Der Timer blockiert nicht mehr beim Wechsel auf einen anderen Mandanten (das frühere MED-D-172-„anderer Mandant"-Verhalten ist abgelöst) — er folgt dem Vordergrund-Mandanten und schreibt die Vordergrund- Historie in die neue Tabelle timer_segment (mandant_id nullable = „nicht zugeordnet"). Die aktiver_timer-Zeile unten bleibt „eine je Benutzer"; mandant_id = aktueller Vordergrund. Gebucht wird über buchenVerteilt (je Zeile eine append-only Leistungszeit, freie Zuweisung an beliebige Mandanten).

ID	Feld	Typ	Bemerkung
R13-F12	benutzer_email	Ref → R7	PK — genau eine Zeile je Benutzer
R13-F13	mandant_id	Ref → R1	der aktuelle Vordergrund-Mandant (Wechsel blockiert nicht mehr, MED-D-275; Historie in timer_segment)
R13-F14	basis_ms	Zahl	aufgelaufene Zeit aus bereits pausierten Segmenten
R13-F15	segment_start_am	Zeit | null	Start des laufenden Segments; null = pausiert
R13-F16	gestartet_am	Zeit	Beginn dieser Timer-Session (Anzeige)
R13-F17	aktualisiert_am	Zeit

Öffnet ein Benutzer einen anderen Mandanten, während der Timer läuft, blockiert das nicht (MED-D-275, autoritativ s. o.): das bisherige timer_segment wird geschlossen und ein neues Vordergrund-Segment für den neuen Mandanten geöffnet — der Timer folgt dem Vordergrund. aktiver_timer.mandant_id trägt dabei stets den aktuellen Vordergrund-Mandanten (bei „nicht zugeordnet" bleibt der letzte non-null-Wert erhalten; nur das timer_segment darf mandant_id = NULL führen — es wird nie NULL in aktiver_timer geschrieben). Buchen (buchenVerteilt): der Server aggregiert die (editierbaren) timer_segment-Zeilen je mandant_id und schreibt genau eine append-only leistungszeit-Zeile pro Mandant; jeder mandant_id = NULL-Rest muss vor dem Buchen einem Mandanten zugewiesen oder verworfen werden (keine Zeile-je-Segment, keine verlorene nicht-zugeordnete Zeit). Kommentar/Abrechenbar/Mandat-Zuordnung bleiben reine Client-Eingaben, die erst beim Buchen in den Leistungszeit-Eintrag fließen (kein zusätzlicher Server-Zustand für diese Entwurfsfelder, G-2).

5. Prozess & Lifecycle

5.1 Standard-Prozess (Mandanten-Lebenszyklus)

Lead → Onboarding → Aktiv → Ruhend/Archiviert. Das Diagramm zeigt den lifecycleStatus (§5.2/ Prozessmodell.md §2/§3 — die verbindliche Referenz) — die grobe, personenbezogene Achse. Die frühere, mandantenweite prozessphase-Achse ist retiriert (MED-D-151); ihre feine beratung/unterschrift-Granularität lebt seither ausschließlich je Beratungsauftrag (§5.1a). Dokumente & Unterschriften (inkl. Ablage) sind eine quer-liegende Achse (Prozessmodell.md §6, MED-D-80), keine eigene Phase auf keiner der beiden Achsen.

Einstieg & Abgrenzung (MED-D-70). Der eigentliche Mandanten-Prozess beginnt mit dem Onboarding (Erhebung der Pflicht-Nachweise, §4.5). Kommt ein Kunde als Lead herein und hat noch kein Onboarding, wird der Mandant direkt mit angelegt (Status lead, verantwortlich = null → gemeinsamer Lead-Pool); das Onboarding wird später als eigene Phase nachgeholt. So sind Lead-Erfassung und Beratung möglich, bevor die formale Onboarding-Strecke durchlaufen ist. OP-LEAD-1 gelöst (Slice C2a, MED-D-106, 0.72.0): das öffentliche Lead-Formular fragt optionales Produkt-Interesse ab (siehe §5.1a) — bei Einreichung entsteht je gewähltem Produkt direkt ein Beratungsauftrag samt Playbook, ohne manuellen Zwischenschritt "erst Mandant/Praxis anlegen, dann Dentmarking starten".

5.1a Beratungsaufträge — 3-Ebenen-Modell (MED-D-95, Katalog MED-D-99)

Ein Mandant kann mehrere Beratungs-Produkte gleichzeitig in unterschiedlichen Stadien haben (z. B. ein abgeschlossenes Dentmarking-Gutachten und eine laufende Kapitalanlage-Beratung) — der grobe, personenweite lifecycleStatus kann das nicht abbilden. Deshalb gibt es eine zweite Ebene, quer zum Lifecycle-Status: Person (R1, unverändert) → Beratungsauftrag (0..n je Mandant: ein Produkt aus dem 9-Produkt-Katalog + eigener Status anbahnung → beratung → unterschrift → laufend → abgeschlossen) → Artefakte (Beratungsdoku, Dokumente, Unterschriften, Wiedervorlagen, Gutachten — je Auftrag gebunden, Slice B). Dentmarking ist dabei ein Produkt-Typ unter mehreren, kein separater Erstkontakt-Mechanismus mehr. Vollständiges Modell, Produkt-Katalog und Fahrplan (Slices A–C2b ✅, C2b-Rest/C3 offen): architektur/Beratungsauftraege.md.

5.2 Lifecycle-Status ≠ Auftrags-Status

Genau zwei Prozess-Achsen bleiben, seit MED-D-151 die frühere prozessphase retiriert hat (§5.1): Lifecycle-Status (Lead → … → archiviert, personenbezogen, funktioniert auch ohne jeden Beratungsauftrag) und Auftrags-Status (je Beratungsauftrag, §5.1a). Ein Mandat kann "aktiv" sein und trotzdem einen Auftrag haben, der bei "Unterschrift ausstehend" hängt — beide Achsen bleiben getrennt (vermeidet das Erraten der einen aus der anderen).

Autoritative Achsen-Landkarte: architektur/Prozessmodell.md §2 (MED-D-79/151) bündelt beide Achsen an einer Stelle. Onboarding.phase (R2-F04) ist ein Teilschritt innerhalb der Lifecycle-Stufe onboarding, keine eigene Achse.

Mandanten-Pipeline / Board (UC-6, gebaut 0.16.0, Lanes seit 0.83.0/MED-D-151): Das Cockpit zeigt alle Mandanten wahlweise als Liste oder als Pipeline-Board — Lanes je Lifecycle-Status (Lead · Onboarding · Aktiv · Ruhend; Archiviert ausgeblendet), Karten mit abgeleitetem Onboarding-Fortschritt (G-2) und einer kompakten Auftrag-Status-Chip-Zusammenfassung je Karte (löst das Mehrfach-Auftrag-Problem aus §5.1a direkt am Board). Suche (Name) + Typ-Filter greifen in beiden Ansichten. Der Status lässt sich je Karte direkt ändern (PATCH /api/mandanten/:id, auditiert als mandant.geaendert, G-4). Rein client-seitig abgeleitet aus GET /api/mandanten — kein neuer Store.

Lifecycle-Guard & Playbooks (§5.1, gebaut 0.19.0, retiriert/umgebaut 0.83.0/MED-D-151): Der Lifecycle-Status wird beim Eintritt in aktiv erstmals geguarded: PATCH /api/mandanten/:id prüft (domain/lifecycle.ts) vollständiges Onboarding + keine offenen Unterschriften — fasst die zwei früheren Phasen-Engine-Guards zusammen und liefert bei Verstoß 409; jeder andere Übergang bleibt frei, rückwärts als Korrektur immer. Beim Eintritt in onboarding/aktiv erzeugt das Mandanten-Playbook (nur noch 2 Einträge: nachfassen/jahrescheck) idempotent die passenden Folge-Wiedervorlagen (R5, Quelle playbook). Die frühere, produkt-nahe Granularität (termin@Beratung, ruecklauf@Unterschrift) feuert seither als Code-Katalog am Beratungsauftrag (domain/auftrag-playbook.ts §AUFTRAG_STATUS_PLAYBOOK) bei dessen Statuswechsel — nicht mehr am Mandanten. Auditiert (mandant.geaendert, G-4, MED-D-24-Muster). Der aktive Orchestrierungs-Kern (G-1) — kein Fremdsystem.

Playbooks admin-editierbar (gebaut 0.20.0, reduziert 0.83.0/MED-D-151): Der Mandanten-Playbook- Katalog liegt persistiert im Store (playbook-Tabelle, Migration v13, remappt in v41) und ist über admin-geschützte Routen (/api/playbooks, RBAC R7) pflegbar — Aufgaben je Lifecycle-Stufe (onboarding/aktiv) anlegen/ändern/(de)aktivieren/löschen; der Guard liest nur aktive Einträge. Editor im Cockpit (Admin-Bereich). Änderungen auditiert (playbook.angelegt/geaendert/entfernt, G-4). Das Auftrag-Status-Playbook (§5.1a) ist bewusst kein Store-Eintrag, sondern ein Code-Katalog (kleinere Fläche als admin-editierbar, Nutzerentscheidung MED-D-151).

5.3 Klärfälle / Unterbrechungen

Ein Vorgang kann an jeder Stelle unterbrochen werden (fehlende Unterlage, Rückfrage, Eskalation) → dokumentieren, Wiedervorlage setzen, zurück / Sprung zu anderem Schritt / Abbruch. Jede Unterbrechung ist auditierbar (G-4).

6. Optimierungs-/Steuerungsziel

Anders als bei einem Produktions-Scheduler ist das Ziel hier Vollständigkeit & Termintreue, nicht Durchsatz-Maximierung: nichts fällt durch (keine vergessene Wiedervorlage, keine fehlende Unterschrift, keine unvollständige Beratungsdoku), und Fristen werden gehalten. Das Cockpit (UC-6) macht genau das sichtbar.

Aggregiertes Cockpit "Alles Offene" (UC-6, gebaut 0.17.0): GET /api/offene-punkte bündelt mandantenübergreifend alle offenen Punkte in fünf Kategorien — offene Wiedervorlagen · fehlende Dokumente · ausstehende Unterschriften · unvollständige Beratungsdoku · offene Onboarding-Pflicht-Items — mit Zählern je Kategorie und Rücksprung zum Mandanten (überfällige zuerst). Rein abgeleitet (G-2), kein neuer Store; im Cockpit als Kachel-Filter + Liste. Genau die operative "nichts fällt durch"-Sicht.

Mandant-Ansicht (UC-6, gebaut 0.18.0): druck-/exportierbare Gesamtansicht je Mandant (/mandant/:id/akte) — Stammdaten · Onboarding · Dokumente · Unterschriften · Beratungsdoku · Leistungszeit · Wiedervorlagen · Audit-Trail, mit abgeleiteter Aktenreife-Ampel (detail().aktenreife, G-2: reif ⇔ keine offenen Punkte). Beantwortet True North #3 tief für einen Mandanten. Druck via @media print (App-Shell/Buttons ausgeblendet). Rein lesend, kein neuer Store.

7. Nicht-funktionale Anforderungen

• Rechtssicherheit/Audit (G-4): append-only Audit-Log, definierte Retention, manipulationssicher.
• Datenschutz (G-5): EU-/CH-Datenresidenz, PII-Minimierung, AV-Verträge mit Dritt-Diensten.
• Verfügbarkeit: Ausfall eines externen Dienstes (NextCloud/Signatur) darf den Prozess nicht korrumpieren — Status idempotent nachführbar (Webhooks + Reconciliation).
• Selbsterklärbarkeit (G-3): ohne Schulung bedienbar.

8. Architektur (Überblick)

Detail je Thema in docs/architektur/. Kern-Entscheidungen:

ID	Entscheidung	Status
A-1	Dokumente in NextCloud (WebDAV/OCS-API), kein Eigenbau-DMS.	gesetzt; WebDAV-Anbindung gebaut (Slice 2, 0.3.0) — architektur/Dokumentenverwaltung-NextCloud.md
A-2	Unterschriften via DocuSign oder PandaDoc über Provider-Abstraktion.	gesetzt; Abstraktion + Niveau-Matrix gebaut (Slice 4, 0.4.0); konkreter Anbieter offen (OP-SIGN-1)
A-3	Kundenstamm im CRM (extern); Medidentas referenziert. Ist = Daylite; Zielrichtung HubSpot (native DocuSign-Integration). Build-vs-Buy offen: ob ein externes CRM nötig ist, wenn Medidentas selbst "die eine Wahrheit" hält.	gesetzt (Referenz-Prinzip); Anbieter/Build-vs-Buy offen (OP-CRM-1)
A-4	Technologie-Stack = Cloudflare (Workers + D1 + Queues + Cron, Angular-Client, Cloudflare Access), wie Taktano.	gesetzt (06-27), Detail architektur/Stack.md
A-5	Wiedervorlagen über Standard-Scheduler/Queue + E-Mail/Notification.	gebaut (Slice 3, 0.6.0): Cloudflare-Cron + Benachrichtigungs-Abstraktion (Log-Default; E-Mail/Push offen)
A-6	Erweiterbarkeit via Spezial-Tools (Tool-Host R10, Manifest-Vertrag, Isolation).	Konzept gesetzt; Vertrag offen (OP-EXT-1)
A-7	Dokumenten-/Formular-Engine (R12): Template + Stammdaten-Mapping → Standarddokumente, Benennung, NextCloud-Ablage, Signatur-Übergabe. Eigenbau begründet (kein Standard deckt Mapping aus eigenem Stammsatz in mehrere Hausformulare).	✅ Mapping-Engine + Ablage + Signatur-Übergabe gebaut (Slice 8); ✅ PDF-Erzeugung gebaut (0.32.0, pdf-lib/D-28)
A-8	Meeting-Transkription/-Zusammenfassung (R11) über Standard-Tool angebunden (Notion/Plaud/Krisp o. ä.), nicht nachgebaut (G-1); Eigenbau nur Aufgaben-/Delegations-Orchestrierung.	🟡 Kern gebaut (MED-D-82): Orchestrierung Protokoll→Aufgaben→Wiedervorlagen (R5) steht (GespraechsAuswerter-Fake-Seam); Transkriptions-Tool/Residenz offen (OP-MEET-1)

9. Vereinfachungen (S-n)

ID	Vereinfachung
S-1	Kunde = Name + CRM-Link (keine eigene Kundenstamm-Pflege; CRM ist Single Source).
S-2	Dokumente als Referenz auf NextCloud (keine eigene Datei-Speicherung).
S-3	"Onboarding vollständig?" abgeleitet aus Pflicht-Items, nicht als eigenes Flag gespeichert (G-2).

10. Out of Scope (vorerst)

• Eigenes DMS / eigene Datei-Speicherung (→ NextCloud).
• Eigenes Signatur-Backend (→ DocuSign/PandaDoc).
• Eigene Transkriptions-/Spracherkennungs-Engine (→ Standard-Tool anbinden, A-8/OP-MEET-1).
• Persönliche Produktivitäts-Tools (Workshop W10): E-Mail-Diktat (Whisper/Wispr), Grammatik (Grammarly), E-Mail-Vorsortierung, persönliche ChatGPT-Nutzung — sind individuelle Tool-Einrichtung, keine Plattform-Funktion.
• Buchhaltung / Faktura (ggf. später via Standard-Tool, FR).

11. Offene Punkte (OP)

ID	Offener Punkt	Worum es geht
OP-DOMAIN-1	Branche / Regulatorik	✅ Bestätigt (Workshop 20.01.2026): Anwender = Finanz-/Versicherungs- & Praxisberatung für (Zahn-)Arztpraxen/MVZ (Praxisfinanzierung, Existenzgründung, Sach-/Kranken­versicherung, Geldanlage, Tilgungssurrogate). Mandanten = Ärzte/Praxen. Regulatorik treibt die R6-Pflichtfelder: §34d GewO/§61–62 VVG (IDD), §34f GewO/§18 FinVermV, §34i GewO. Detail: betrieb/Compliance.md. Restpunkt → Beratungsdoku-Pflichtthemen je Themenbereich ✅ abgeleitet (Slice 5) (beratung-themen.ts); juristische Endabnahme der Kataloge offen.
OP-DEPLOY-1	Deploy-Reife & Domain	Domain medidentas.com ist im Cloudflare-Account (Zone aktiv) → Custom-Domain-Deploy nicht mehr blockiert; HQ-Eigentümer-Zuordnung = organisatorischer Folgepunkt. Subdomain app.medidentas.com (ein Worker bedient UI + /api via Static Assets — ein Origin für Cloudflare Access, kein CORS), D1-Anlage EU (wrangler d1 create medidentas --location weur), Cloudflare-Access-Application/Policy + AUTH_ENFORCED=true, CLOUDFLARE_API_TOKEN + CLOUDFLARE_ACCOUNT_ID als CI-/Deploy-Secrets. EU-Datenresidenz Pflicht (G-5/RISK-17). Runbook: architektur/Deploy.md.
OP-ONBOARD-1	Self-Service-Onboarding (öffentlich)	✅ gebaut (Slice 9): Einladungslink + öffentliches Formular (/onboarding/<token>, /oeffentlich/*) + SES-Einwilligung (auditiert). Offen / manuell: Cloudflare-Access-Bypass-Policy für /onboarding* + /oeffentlich* (sonst greift Access davor), Turnstile (TURNSTILE_SITEKEY/TURNSTILE_SECRET), juristische Prüfung des Einwilligungstexts (RISK-18), echte NextCloud/Signatur statt DEMO_MODE-Fakes.
OP-MEET-1	Meeting-/Transkriptions-Tool	Auswahl Standard-Tool (Notion/Plaud/Krisp …) für Transkription + Zusammenfassung; DSGVO/EU-Residenz + AVV (RISK-15); Anbindung Protokoll→Aufgaben→CRM/Medidentas (R11, A-8). Keine vollständige Aufzeichnung, nur Zusammenfassung; Hinweis-/Einwilligungspflicht.
OP-DOCGEN-1	Formular-/Template-Engine	✅ Mapping-Engine + Benennung + NextCloud-Ablage + R4-Übergabe gebaut (Slice 8, 0.9.0): Vorlagen-Katalog je Dokumenttyp, Feld-Mapping aus dem Stammsatz (G-2), sprechende Benennung, abgeleiteter signiert-Status. ✅ PDF-Erzeugung gebaut (0.32.0, D-28): pdf-lib im Worker + eigene Layout-Schicht (Blockmodell), R12-Dokumente und Dentmarking-Gutachten werden als PDF in NextCloud abgelegt, Download über GET /api/dokumente/:id/datei. Rest offen: erweiterter Kundendatenbogen (Anschrift/Rechtsform/Bank) · native Provider-Vorausfüllung · Binär-Hausformular-PDF-Templates (Befüllung bestehender Formulare) · manuelle Detail-Ausformulierung bei Individualverträgen (OP-DOCGEN-2). Bezug R12/R3/R4.
OP-DOCGEN-2	Manuelle Detail-Ausformulierung (Individualverträge)	Dienstleistungsauftrag (dienstleistungsauftrag) und Makler-Allein-Auftrag (makler_allein_auftrag) lassen sich nicht rein per Feld-Mapping erzeugen: die individuellen Vertragsdetails (Leistungsumfang, Vergütung/Courtage, Laufzeit, Sonderabreden) müssen vor der Unterschrift manuell ausformuliert/geprüft werden (Mensch im Prozess, vgl. Haftungsgrenze RISK-14). Die R12-Engine (OP-DOCGEN-1) erzeugt einen Entwurf; ein manueller Ausformulierungs-/Freigabeschritt bleibt verbindlich, bevor R4 (AES/QES je Niveau-Matrix, OP-SIGN-1) übergeben wird. Zu klären: Status/Workflow "Entwurf → manuell ausformuliert → freigegeben" für diese Dokumenttypen, Vorlagen-Bausteine/Platzhalter, Audit-Nachweis der Freigabe (G-4). Bezug R12/R4/OP-DOCGEN-1.
OP-GWG-1	Geldwäschegesetz: Verpflichteten-Status & Identifizierungsprozess	Klären, ob durch Vermittlung von Lebensversicherungen/Anlageprodukten (§ 34d/§ 34f GewO) der Status als GwG-Verpflichteter (§ 2 Abs. 1 Nr. 8 GwG) greift. Falls ja: Identifizierungsprozess (§§ 11 ff. GwG) definieren — Standard = Vor-Ort-Identifizierung durch den Berater im Termin (Ausweis; dokumentiert beim Mandanten (R3) + Audit R8, G-4), VideoIdent/PostIdent nur als Fallback für terminlose Digitalstrecken; QES-Flow (OP-SIGN-1) enthält die Identifizierung implizit. Aufzeichnungs-/Aufbewahrungspflichten ins Löschkonzept. Entschieden: D-30 (Abgrenzung Einwilligung ≠ Unterschrift ≠ Identverifikation). Bezug RISK-25, betrieb/Compliance.md.
OP-AI-1	KI-gestützte Beratungsdoku	✅ Abstraktion + regelbasierter Check gebaut (Slice 5, 0.7.0): pruefstatus entwurf→ki_geprüft→freigegeben; Haftungsgrenze verankert (Assistenz ≠ Freigabe, RISK-14). Rest offen: echtes "Medidentas-GPT" (Modell/Anbieter, EU-Datenresidenz, Prompt-/Briefing-Pflege). Bezug R6, OP-DSGVO-1.
OP-BERATDOK-1	Beratungsprotokoll — Rahmendaten/Pflichtangaben	✅ Gebaut (Slice 10, 0.11.0): Modell + Migration v10 + Service + API + Client. Das Beratungsprotokoll (R6) trägt strukturierte Pflichtangaben zum Termin: wann (R6-F11 termin_am), wo (R6-F12 ort: beim Kunden / bei Medidentas — je mit Adresse — oder Video-Call), wie lange (R6-F13 dauer_minuten), verwendetes Analyse-/Beratungsprogramm (R6-F14), folgt der Kunde der Empfehlung? (R6-F15, bei nein mit Begründung/Abweichung), Risikoaufklärung bestätigt (R6-F16) wie die Unterlagen übermittelt wurden (R6-F17: Papier/Post/E-Mail/NextCloud-Link) und dass alle Angaben (insb. Gesundheitsbogen) vom Kunden stammen und 1:1 übernommen wurden (R6-F18, §19 VVG) sowie ein optionaler Verzicht auf die Beratungsdokumentation (R6-F19, §6 Abs. 3/§61 Abs. 2 VVG — nur per gesonderter schriftlicher Erklärung; bei Verzicht entfallen F06/F11–F18, die Verzichtserklärung wird R3/R4-erfasst) sowie eine Schlusserklärung des Kunden (R6-F20 — alles verstanden/aufgeklärt, sachdienliche Hinweise selbst gegeben, exakt das empfohlene Produkt gewünscht, mit der Beratung zufrieden; begrenzter Beweiswert/kein Doku-Ersatz, RISK-20). Regulatorisch geboten (IDD/§34d GewO·VVG §61–62/§19, §18 FinVermV) + G-4-Nachweis. ✅ Slice 11 ergänzt: Dokumentationsverzicht-Workflow (F19 → R3-Ablage + R4-SES-Signatur, Pflichtinhalte ausgeblendet) + Audit je Feldänderung (beratungsdoku.aktualisiert, PII-arm). Rest offen: juristische Endabnahme der Texte (Einwilligung/Verzicht/Schlusserklärung, RISK-18/20).
OP-EXT-1	Tool-Vertrag (Erweiterbarkeit)	Manifest-Schema, Scope-/Event-Katalog, Persistenz-Isolation, Aktivierungs-/Lizenzmodell. Detail: architektur/Erweiterbarkeit-Spezialtools.md.
OP-DEX-1..5	Dexman-Detailfragen	PVS/Bank/DATEV-Integration, Prognose-Methodik, Benchmark-Quellen, Behandler-Sichtbarkeit (BetrVG), Lizenzmodell. Detail: spezialtools/Dexman.md §10.
OP-DENTMARK-1	Dentmarking (Spezial-Tool, Vorstufe Dexman)	✅ Tool-Spec erstellt (2026-07-03): spezialtools/Dentmarking.md (DM-1..DM-8: Fragebogen · Kennzahlen-Engine · Benchmarks · Potential · Auswertung · Gutachten · Befunde · Dexman-Übergabe) + vollständig extrahierte Alt-Excel-Logik spezialtools/Dentmarking-Excel-Logik.md (Feldkatalog 111 Fragen, 18 Kennzahl-Formeln, Benchmark-Werte, Potentialrechnung, VBA-Abläufe, Befunde B-1..B-11). Datenumfang/Kennzahlen und Abgrenzung↔Dexman damit geklärt (Selbstauskunft-Gutachten vs. laufendes Controlling). Umsetzungspfad entschieden (D-27): Modul im Kern-Worker/D1, Kern-Entität praxis (Objekt) + Geschäftsjahr-Faktentabelle praxis_jahreswert (Dexman-fähig), Slices T1–T5. T1 ✅ gebaut (0.27.0), T2 ✅ gebaut (0.28.0: Fragenkatalog v1, Erhebung + Jahreswerte, idempotenter Import**), T3 ✅ gebaut (0.29.0: Kennzahlen-Engine mit Formel-Varianten alt/korrigiert, Benchmark v1, Potential/Mehrgewinn), T4 ✅ gebaut (0.30.0: Gutachten-Beleg + Befunde → Wiedervorlagen; Verbesserungs-Bilanz Alt-Excel→Neu in spezialtools/Dentmarking.md §13). T5 ✅ gebaut (0.31.0: öffentlicher Fragebogen per Einladungslink — fragebogen_einladung v17, /fragebogen/<token> + GET/POST /oeffentlich/fragebogen/:token, DSGVO-Einwilligung Pflicht, Turnstile-Option, Erhebung Kanal formular idempotent)**. Offen: PDF-Fassung (OP-DOCGEN-1); manuell: Access-Bypass /fragebogen* (RISK-19). Rest offen: OP-DM-1..7 (fachliche Bestätigung der Formel-Korrekturen, Benchmark-Quellen/-Stand, Dexman-Übergabeformat, Alt-Daten-Migration/DSGVO-Bereinigung → RISK-23, Marke/Fragebogen-Hosting, Lizenz OP-EXT-1, Geschäftsjahr-/Benchmark-Jahresbezug) + Umsetzung.
OP-TOOLSPEC-1	Verfeinerung / Detail-Lastenheft Dexman & Dentmarking	Dentmarking-Teil ✅ erledigt (eigene Tool-Spec inkl. Datenmodell/Kennzahlen, Oberflächen-Bausteinen, Abgrenzung & Daten-Übergabe zu Dexman — siehe OP-DENTMARK-1). Offen: Dexman vertiefen (OP-DEX-1..5: Kennzahlen-Katalog, Prognose-Methodik, Datenquellen PVS/Bank/DATEV, Behandler-Sichtbarkeit/BetrVG, Lizenz). Gemeinsam: Manifest/Scopes/Isolation je Tool über den Tool-Vertrag (OP-EXT-1).
OP-SIGN-1	E-Signatur-Provider & -Niveau	✅ Abstraktion + begründete Niveau-Matrix gebaut (Slice 4, 0.4.0) (Vollmacht→QES, Vertrag→AES, Mandat→SES). Rest offen: konkreter Anbieter (DocuSign vs. PandaDoc) + HTTP-Adapter/Webhooks + Datenresidenz/AVV. Detail: architektur/Unterschriften.md.
OP-STACK-1	Technologie-Stack	✅ Entschieden (06-27): Cloudflare (Workers + D1 + Queues + Cron). Detail: architektur/Stack.md. Folge-OPs: OP-AUDIT-1, OP-OBS-1, OP-DATA-1, OP-AUTH-1, OP-EXT-1.
OP-DOC-1	NextCloud-Integrationsweg	✅ MVP entschieden + gebaut (Slice 2, 0.3.0): WebDAV + App-Passwort + Ordner je Mandant + idempotenter Abgleich. Rest offen: OAuth2 (RISK-16), OCS-Group-Folders (R7), Webhooks. Detail: architektur/Dokumentenverwaltung-NextCloud.md.
OP-AUTH-1	Identität & Rollen	✅ MVP gebaut (Slice 7, 0.8.0): Cloudflare Access (Standard-IdP, G-1) + Rollen berater/backoffice/admin in D1 (benutzer) + RBAC + echter Audit-Actor. Rest offen: Access-Application/Policies (Deploy), RBAC je Mandant, SCIM/Gruppen-Sync.
OP-AUDIT-1	Audit-Log-Architektur	✅ Gebaut (Slice 6, 0.5.0): append-only D1-Store + SHA-256-Hash-Verkettung + Verify; Retention-Matrix definiert. Rest offen: Cold-Storage-Archiv (R2), Restore, Concurrency-Härtung. Detail: architektur/Audit-Log.md.
OP-WV-1	Wiedervorlagen delegieren/zuweisen	✅ Gebaut (Slice 12, 0.13.0): POST /api/wiedervorlagen/:id/zuweisen setzt R5-F08 verantwortlich auf einen validierten Benutzer (R7) (null = entziehen), benachrichtigt den neuen Zuständigen und schreibt wiedervorlage.zugewiesen (wer→wem, G-4). Gefilterte Sicht "meine Wiedervorlagen" (GET …/meine) im Cockpit + Zuweisen-Steuerung im Mandant-Detail. Bindet R5↔R7; speist UC-4/UC-6.
OP-CRM-1	CRM-Anbindung & Build-vs-Buy	Ist = Daylite (nur Kalender; Wiedervorlagen ungenutzt). Zielrichtung HubSpot (native DocuSign-Integration). Build-vs-Buy: Da Medidentas zunehmend selbst "die eine Wahrheit" hält (Stammdaten, Aufgaben, Darlehensübersicht, Beratungsdoku), ist offen, ob ein externes CRM nötig bleibt oder die CRM-Funktion in Medidentas aufgeht (Spannung G-1 ↔ S-1). API, Sync-Richtung, Daylite-Migration (inkl. Wiedervorlagen-Übernahme) klären.
OP-TIME-1	Zeiterfassung (abrechenbare Leistung)	✅ Gebaut (Slice 13, 0.14.0) als R13 Leistungszeit — Entscheidung Ansatz A (dünnes Ledger + Export) statt reiner Tool-Anbindung: der differenzierende Wert ist die Verknüpfung Zeit×Mandant×Beratung, die ein externes Tool nicht nativ kennt. Erfassung je Mandant, Auto-Seed aus R6-F13, Abrechnungsvorschau als SevDesk-Export-Vorstufe (OP-INVOICE-1), append-only Audit (G-4), EU/D1. Abzugrenzen vom internen Agenten-Timesheet. Rest: konkreter SevDesk-Push (OP-INVOICE-1).
OP-TIME-2	Gesetzliche Arbeitszeiterfassung (ArbZG)	Getrennt von OP-TIME-1 (Entscheidung 2026-07-01). Erfassung von Beginn/Ende/Pausen je Mitarbeiter — Pflicht nach BAG 2022 / EuGH (ArbZG-Novelle ausstehend). Anderes Datenmodell, Mitarbeiter-PII, BetrVG-Mitbestimmung (RISK-21), ggf. eigenes Standard-Tool (G-1). Tool-/Umfangswahl offen; nicht Teil des Mandanten-Lebenszyklus.
OP-INVOICE-1	Rechnungsstellung & Mahnwesen	Honorar-/Leistungsabrechnung gegenüber Mandanten inkl. Mahnwesen (Zahlungsverzug/Dunning). G-1 integrate-before-build: SevDesk als Standard-Werkzeug prüfen (Rechnung + Mahnwesen + DATEV-Export, GoBD-konform, EU/DE-Hosting) — anbinden statt nachbauen; Medidentas liefert Leistungs-/Zeitdaten (OP-TIME-1) und Mandanten-Referenz (A-3/CRM), SevDesk bleibt Single Source der Belege. Zu klären: SevDesk-API/Sync-Richtung, AVV/Datenresidenz, GoBD-Aufbewahrung (vgl. §147 AO), Schnittstelle zu OP-TIME-1 und zum Mandantenstamm (R1).
OP-MANDGRP-1	Mandanten-Gruppierung ("Klammer")	Mehrere Mandanten zu einer Gruppe zusammenfassen (z. B. "Eheleute Müller" aus Peter Müller + Gertrud Müller-Ehrentraut). Personen werden einzeln betreut, jeder Mandant zeigt direkte Querverweise auf die anderen Mitglieder. Ablage (D-32, Variante A, vorläufig): eigene Ordner je Person + gemeinsamer Gruppenordner; Kundenbestätigung ausstehend (Abweichung von Vorgabe). Neue Kern-Entität mandant_gruppe (R1). Zu klären: Gruppen-Bezeichnung/-Rollen, Rechte, gemeinsame vs. persönliche Dokumente, Wiedervorlagen/Beratungsdoku gruppenübergreifend? Mit D-31 (Ablage-Restruktur) ein Slice.
OP-IMPORT-1	Datenübernahme bestehende Kunden-Ablage	Import eines vorhandenen Datei-/Ordnerbestands mit ggf. abweichenden Konventionen in die neue Struktur (D-31). Kern: Namens-Parsing in nachname/titel/vorname, Mapping/Normalisierung der Fremd-Ordnerlogik auf Mandanten/<Buchstabe>/…/<Standard-Unterordner>, Dedup/Zuordnung zu bestehenden Mandanten/Gruppen, idempotenter Re-Import (importSchluessel-Muster wie Dentmarking T2). DSGVO/PII: keine Klartext-PII ins Repo (G-5, RISK-22/23), AVV/EU-Residenz je Ablageort. Offen: Quelle/Format (NextCloud↔NextCloud, Fremd-DMS, Dateisystem-Dump, CSV+Dateien?).
OP-SKILL-1	Mitarbeiter-Skills, Aufgaben-Matching & Lernziele	Skill-Katalog (versionierte, admin-pflegbare Stammdaten) + Mitarbeiter→Skills (R7) + Prozess/Aufgabe→erforderliche Skills (Nachfassen/Erinnern R5, inhaltliche Arbeiten R6/R12). Matching: passende Aufgaben je Mitarbeiter aus "erforderlicher Skill ∩ Mitarbeiter-Skills" → speist R5-Zuweisung (OP-WV-1) + "Meine Aufgaben" (True-North-Frage 2 rollengerecht). Lernziel: Skill als Lernziel markierbar; ein kompetenter Bearbeiter kann einen Lernenden (Lernziel = dieser Skill) als Zweit-Zuweisung dazunehmen (Mentoring/Shadowing, Audit G-4). Wahrscheinlich Teilmodul unter R7. Compliance: RISK-26 (Beschäftigten-PII/BetrVG).
OP-RUHEND-1	Ruhende Mandate — Workflow	Der Status ruhend existiert bereits (R1-F05 lifecycle_status). Offen ist der Workflow drumherum: Ruhen mit Grund + geplantem Wiedervorlage-/Reaktivierungsdatum (speist R5); Wiedervorlagen/Erinnerungen pausieren, solange ruhend (keine Mahnläufe an ruhende Mandate), bei Reaktivierung wieder aufleben; Reaktivierung als eigener auditierter Übergang (ruhend → aktiv), klar abgegrenzt von archiviert (endgültig); Reporting "ruhende Mandate". Bezug R1/R5, G-4.
OP-ABC-1	ABC-Klassifizierung mit Codenamen	Neues Mandant-Feld ABC-Stufe (A/B/C, erweiterbar) — reine Priorisierung/Wertigkeit, unabhängig von lifecycle_status und dem Auftrags-Status; steuert später Betreuungsintensität / Wiedervorlage-Takt / Reporting. Konfigurierbare Codenamen je Stufe (admin-pflegbar), damit die Einstufung im Kundengespräch nicht anstößig wirkt (intern A/B/C, angezeigt der neutrale Codename; Roh-Stufe nur für berechtigte Rollen R7 sichtbar — G-3 sprechend, aber diskret). Compliance: Kundenklassifizierung ist PII-nah und bei automatisierter Wirkung ggf. begründungspflichtig → Zweckbindung/Transparenz (Risiko bei Umsetzung aufnehmen). Bezug R1/R7.
OP-UX-1	Usability-Backlog (abgeschlossen)	✅ Vollständig gebaut (Usability-Review 2026-07-02). P1 (0.22.0, D-20): Toast-Feedback · Lade-Zustände · Löschen-Bestätigung. P2 (0.23.0, D-21): Access-Logout · Abschnitts-Navigation im Mandant-Detail · Typ-Klartext (Praxis/MVZ) · Bestätigung vor Archivieren · A11y-Grundgerüst. P3a (0.24.0, D-22): vertiefte A11y — Skip-Link · Fokusring (:focus-visible) · Fokus-Management bei Routenwechsel · aria-pressed/aria-label/role="progressbar". P3b (0.25.0, D-23): Bulk-Aktionen für Wiedervorlagen (POST /api/wiedervorlagen/sammelaktion, teilfehler-tolerant, einzeln auditiert). P3c (0.26.0, D-24): Undo bei Lifecycle-Wechseln (Aktions-Toast; kompensierende Gegenbuchung als eigener Audit-Eintrag, G-4).
OP-DSGVO-1	Datenschutz-Konzept	AVV mit NextCloud-Hosting & Signatur-Provider, Datenresidenz, Löschkonzept/Retention.
OP-OBS-1	Observability/Logging	Logger-Wrapper, strukturierte Logs, OTel-Backend (sobald Code existiert).
OP-DOCS-1	Doku-Konsistenz	laufende Pflicht (agents.md §5/§6) — semantischer Teil agentengeführt.
OP-PM-1	Merge-Strategie/Log-Hygiene	union-Merge-Logs + Glätten (umgesetzt im Init).

12. Future Releases (FR)

ID	Idee
FR-1	Self-Service-Portal für Kunden (Dokumente hochladen, Status sehen, unterschreiben). Vorstufe: Web-Kundendatenbogen (R2, Workshop W2).
FR-2	Vorlagen-/Textbaustein-Bibliothek für Beratungsprotokolle (speist R6-F04/F05).
FR-3	Reporting/Analytics über Durchlaufzeiten & Fristen-Einhaltung.
FR-4	MyID — digitale Identitäts-/Dokumentenmappe (Ausweis, Grundbuch, Krankenakte, Patientenverfügung … mit selektiver Freigabe an Dritte). Separates Produktpotenzial für gehobenes Klientel; Workshop W9. Eigenes Datenschutz-/Geschäftsmodell-Thema, nicht Teil des Kern-Lebenszyklus.

---

Pflege: Neue Entscheidung → ID vergeben, hier + in HANDOFF.md §4 eintragen, CHANGELOG-Eintrag je PR (docs/konventionen/agents.md §6).