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: Repo-Init-Stand (0.1.0). Dieses Lastenheft setzt den fachlichen Rahmen und die Module; viele Detail-Felder und der Technologie-Stack sind bewusst 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?).
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).

4. Module (R1–R12)

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)

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 eigenständiges, schlankeres Programm zum Sammeln und Auswerten von Praxis-Daten, bevor der volle Dexman-Funktionsumfang (Rentabilität/ Prognose/Feedback) zum Einsatz kommt. Niedrigschwelliger Einstieg; die gesammelten Daten speisen später Dexman. Ebenfalls als Spezial-Tool (R10/A-6) gedacht.

4.1 R1 Mandant/Kunde — Datenmodell-Grundsatz

• 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.

Felder (MVP, R1-F##):

ID	Feld	Typ	Hinweis
R1-F01	id	ULID	interner Schlüssel (sortierbar)
R1-F02	anzeigename	Text	sprechend (Praxis-/MVZ-Name), G-3
R1-F03	crm_id / crm_link	Text/URL	Referenz ins CRM (Single Source, S-1)
R1-F04	typ	Enum	praxis · mvz · sonstige (admin-editierbar)
R1-F05	lifecycle_status	Enum	lead · onboarding · aktiv · ruhend · archiviert (§5.2)
R1-F06	verantwortlich	Ref → R7	betreuende:r Berater:in
R1-F07	angelegt_am / geaendert_am	Zeit	Audit-Basis (R8)

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

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 typ (R1-F04); Items admin-editierbar
R2-F04	phase	Enum	fachliche Phase: 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.

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).

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)

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.

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	(geplant, OP-BERATDOK-1) Wann fand die Beratung statt (Datum/Uhrzeit) — ≠ angelegt_am
R6-F12	ort	Enum + Text	(geplant, OP-BERATDOK-1) Wo: beim_kunden · bei_medidentas · video_call; bei Präsenz mit Adresse, bei Video mit Plattform/Hinweis
R6-F13	dauer_minuten	Zahl	(geplant, OP-BERATDOK-1) Wie lange dauerte der Termin (Minuten)
R6-F14	analyse_programm	Text/Ref	(geplant, OP-BERATDOK-1) mit welchem Analyse-/Beratungsprogramm wurde die Beratung durchgeführt
R6-F15	empfehlung_gefolgt	Enum	(geplant, OP-BERATDOK-1) ja · nein · offen — folgt der Kunde der Empfehlung? Bei nein Begründung/Abweichung dokumentieren (VVG-Beratungsverzicht/abweichender Kundenwunsch)
R6-F16	risiken_aufgeklaert	Bool + Text	(geplant, OP-BERATDOK-1) Bestätigung, dass der Kunde über alle Risiken aufgeklärt wurde (G-4-Nachweis)
R6-F17	unterlagen_uebermittlung	Enum + Text	(geplant, OP-BERATDOK-1) Wie hat der Kunde die Unterlagen erhalten — papier_persoenlich · post · email · nextcloud_link · sonstige (mit Detail); Nachweis der Aushändigung/Übermittlung (G-4)
R6-F18	angaben_kundenursprung	Bool + Text	(geplant, OP-BERATDOK-1) 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	(geplant, OP-BERATDOK-1) 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. Bei Verzicht: F06/F11–F18 entfallen, die Verzichtserklärung wird selbst ablagefähig (R3) + signaturpflichtig (R4) erfasst; G-4-Nachweis bleibt Pflicht
R6-F20	kundenerklaerung	Bool + Text	(geplant, OP-BERATDOK-1) 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, geplant): 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, geplant): 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, geplant): 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).

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).

MVP-Grenze (OP-DOCGEN-1-Rest): der MVP legt eine deterministische Text-Fassung ab (auditierbar); die finale Binär-/PDF-Formularerzeugung (Pixel-Layout) und der erweiterte Kundendatenbogen (Anschrift, Rechtsform, Bankverbindung …) folgen. 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, geplant): Eine Wiedervorlage trägt heute ein freies verantwortlich-Feld (R5-F08, E-Mail-String; Erinnerung geht an diesen Empfänger). Offen ist die echte Delegations-Orchestrierung: Zuweisen/Neu-Zuweisen an einen Benutzer (R7) aus der benutzer-Tabelle (statt freier Text), eine gefilterte Sicht „meine Wiedervorlagen" (mir zugewiesen), Benachrichtigung bei (Neu-)Zuweisung und ein Audit-Nachweis der Delegation (wer hat wann an wen delegiert, G-4). 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). RBAC: Benutzer-Verwaltung (/api/benutzer*) nur admin (sonst 403). REST: GET /api/ich, GET /api/benutzer, PUT/DELETE /api/benutzer/:email. Rest offen (OP-AUTH-1): Access-Application/Policies (Deploy), RBAC je Mandant, 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.

5. Prozess & Lifecycle

5.1 Standard-Prozess (Mandanten-Lebenszyklus)

Erstkontakt → Onboarding → Beratung → Unterschrift → Ablage → Wiedervorlage/Betreuung → Archiv.

5.2 Lifecycle-Status ≠ fachliche Phase

Wie bei vergleichbaren Workflow-Systemen sind Lifecycle-Status (Lead → … → archiviert) und fachliche Phase (welcher Arbeitsschritt) getrennt zu denken — ein Mandat kann „aktiv" sein und trotzdem in der fachlichen Phase „Unterschrift ausstehend" hängen. (Vermeidet das Erraten der Phase aus dem Status.)

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.

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-/Binär-Formularerzeugung offen (OP-DOCGEN-1)
A-8	Meeting-Transkription/-Zusammenfassung (R11) über Standard-Tool angebunden (Notion/Plaud/Krisp o. ä.), nicht nachgebaut (G-1); Eigenbau nur Aufgaben-/Delegations-Orchestrierung.	Richtung gesetzt; 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. Rest offen: PDF-/Binär-Formularerzeugung (Pixel-Layout) + erweiterter Kundendatenbogen (Anschrift/Rechtsform/Bank) + native Provider-Vorausfüllung + 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-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	Das Beratungsprotokoll (R6) braucht 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. Geplant (Felder spezifiziert §4.6; Modell/UI/D1 noch zu bauen); juristische Endabnahme der Pflichtfelder offen (Compliance.md).
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)	Eigenständiges, schlankes Programm als Vorstufe zu Dexman: Daten sammeln + auswerten (niedrigschwelliger Einstieg), die später Dexman speisen. Als Spezial-Tool (R10/A-6) gedacht. Zu klären: konkreter Datenumfang/Kennzahlen, Abgrenzung zu Dexman (was bleibt Dentmarking, was wird Dexman), Datenquellen/Import, Daten-Übernahme nach Dexman, EU-Residenz/DSGVO, Lizenz-/Aktivierungsmodell (OP-EXT-1). Tool-Spec folgt (spezialtools/Dentmarking.md, geplant).
OP-TOOLSPEC-1	Verfeinerung / Detail-Lastenheft Dexman & Dentmarking	Die Spezial-Tool-Spezifikationen vertiefen: für Dexman die offenen Detailfragen (OP-DEX-1..5) ausarbeiten (Kennzahlen-Katalog, Prognose-Methodik, Datenquellen PVS/Bank/DATEV, Behandler-Sichtbarkeit/BetrVG, Lizenz); für Dentmarking eine eigene Tool-Spec (spezialtools/Dentmarking.md) anlegen (Datenmodell/Kennzahlen, Erfassungs-/Auswertungs-Oberflächen, Abgrenzung & Daten-Übergabe zu Dexman, OP-DENTMARK-1). Gemeinsam: Manifest/Scopes/Isolation je Tool über den Tool-Vertrag (OP-EXT-1). Eigene Arbeitspakete je Tool, iterativ.
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	Heute trägt eine Wiedervorlage (R5) nur ein freies verantwortlich-Feld (R5-F08, E-Mail-String; Erinnerung geht dorthin). Offen: echte Delegation — Zuweisen/Neu-Zuweisen an einen Benutzer (R7) aus der benutzer-Tabelle (validierte Referenz statt Freitext), gefilterte Sicht „meine Wiedervorlagen", Benachrichtigung bei (Neu-)Zuweisung und Audit der Delegation (wer→wem, wann; G-4). Bindet R5↔R7; speist UC-4/UC-6. Geplant (Modell teils vorhanden, Workflow/UI zu bauen).
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 (Beratungs-/Arbeitszeit)	Erfassung der abrechenbaren Beratungs-/Projektzeiten je Mandant (Grundlage für Honorar-/Rechnungsstellung, vgl. OP-INVOICE-1). G-1 integrate-before-build: Standard-Werkzeug bevorzugen (z. B. SevDesk-Zeiterfassung, clockodo, Toggl) statt Eigenbau; Medidentas referenziert/triggert, hält keine Doppel-Wahrheit. Zu klären: Tool-Wahl, EU-Residenz/AVV, Zuordnung Zeit→Mandant/Beratung (R6), Übergabe an die Rechnungsstellung. Abzugrenzen vom internen Agenten-Timesheet (betrieb/Timesheet.md, Tooling-Aufwand ≠ Kundenleistung).
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-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).