HANDOFF — Medidentas

Zuerst lesen. Kompakter Gesamtstand + offene Punkte für jede neue Session. Danach docs/fachlich/Lastenheft.md (Master-Spec) und docs/konventionen/agents.md (Way-of-Working).

---

1. Was ist Medidentas?

Plattform zur Koordination des Kunden-Lebenszyklus eines beratungs-/vermittlungsnahen Betriebs: Kundenonboarding · Dokumenten-Verwaltung (NextCloud) · Unterschriftenverwaltung (DocuSign/PandaDoc) · Wiedervorlagen · Beratungsdokumentation. Leitgedanke: Standardwerkzeuge anbinden statt nachbauen (G-1); der Eigenwert liegt in der Orchestrierung und der lückenlosen, rechtssicheren Dokumentation.

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

2. Aktueller Stand (Version 0.10.0 — live auf app.medidentas.com + Self-Service-Onboarding (R2 §4.5))

• ✅ Way-of-Working etabliert: CLAUDE.md (Leitplanke) + docs/konventionen/agents.md (Konventionen), übernommen aus dem bewährten Taktano-Vorgehen, ergänzt um G-1 Standardwerkzeuge-bevorzugen.

• ✅ Doku-Struktur: docs/ mit fachlich/ · architektur/ · betrieb/ · konventionen/ · glossar/ · zielgruppen/ · produkt/ (je _category_.json für die Sidebar) + Landkarte docs/README.md.

• ✅ Fachlicher Rahmen: Lastenheft mit Modulen R1–R12, Use-Cases UC-1..8, Lifecycle, offenen Punkten.

• ✅ Workshop-Anforderungen eingearbeitet (20.01.2026): anonymisierte Anforderungsquelle docs/fachlich/Anforderungen-Workshop-2026-01-20.md (Themen W1–W10). Daraus neu: R11 Meeting-Doku & Aufgaben (Konzept docs/architektur/Meeting-Doku-und-Aufgaben.md), R12 Dokumenten-Automatisierung, UC-7/UC-8; R6 geschärft (Textbausteine, KI-Check). OP-DOMAIN-1 bestätigt (Finanz-/Versicherungs- & Praxisberatung für (Zahn-)Arztpraxen).

• ✅ Architektur-Skizzen: NextCloud-Dokumente (A-1), Unterschriften/eIDAS (A-2), Audit-Log (G-4), Stack (A-4, offen) als erste Design-Dokumente.

• ✅ System-Charakter (docs/architektur/System-Charakter.md): „Was für eine Anwendung ist Medidentas?" — Archetyp (Case-Management + Orchestrierung), eigengebauter Kern, „System of Engagement, nicht of Data", Schichten-/„eine-Wahrheit"-Modell. Einstieg vor den Use-Cases.

• ✅ Doku-Rendering: Docusaurus-Site (docs-site/) inkl. Mermaid, lokaler Volltextsuche und Glossar-Sprechblasen (Single-Source glossar.mjs → generierte Glossar.md).

• ✅ Governance: Compliance-, Risiko-, Sanity-Checkliste- und Timesheet-Docs angelegt.

• ✅ CI/CD: ci.yml (Doku-Konsistenz + Docs-Build + CI-Gate) und docs-deploy.yml (Cloudflare Pages); .gitattributes (union-Merge-Logs), Session-Start-Hook, check-doc-consistency.sh.

• ✅ Erweiterbarkeit (Spezial-Tools): Tool-Host-Konzept (A-6/R10) + docs/architektur/Erweiterbarkeit-Spezialtools.md (Manifest-Vertrag, Isolation, Lebenszyklus).

• ✅ Dexman — Detail-Lastenheft (docs/spezialtools/Dexman.md): Praxis-Rentabilität, Umsatzprognose, Behandler-Feedback; inkl. Wettbewerbsanalyse medipulse.de und dentaler Kennzahlen/PVS-Recherche.

• ✅ Stack entschieden (OP-STACK-1): Cloudflare (Workers + D1 + Queues + Cron, Angular-Client, Cloudflare Access) wie Taktano — Begründung/Details in docs/architektur/Stack.md.

• ✅ MVP-Scope & Slice-Plan (docs/fachlich/MVP-Scope.md): vertikale Slices, priorisiertes Backlog, Akzeptanzkriterien; Slice 1 = Mandant (R1) + Onboarding (R2) mit Feldern R1-F##/R2-F## (Lastenheft §4).

• ✅ Slice 1 gebaut (0.2.0) — Mandant (R1) + Onboarding (R2) end-to-end auf Cloudflare:

  • server/ — Cloudflare Worker (Hono), Drizzle/D1-Schema (mandant/onboarding/ onboarding_item) + idempotente Migration (schemaVersion), Repository-Vertrag (D1- + In-Memory- Adapter), abgeleiteter Fortschritt (G-2, nicht gespeichert), Logger-Wrapper (PII-Scrubbing), version.ts (APP_VERSION='0.2.0') + generierte build-number.ts. 19 Vitest-Tests + Typecheck grün.
  • client/ — Angular 19 (standalone): Cockpit-Liste (Fortschritt je Mandant) + Mandant-Detail (Onboarding-Items abarbeiten, Status setzen, Lifecycle). ng build grün.
  • API: GET/POST /api/mandanten, GET/PATCH /api/mandanten/:id, POST /api/mandanten/:id/onboarding, PATCH /api/onboarding-items/:itemId, GET /api/health.
  • CI: neue Jobs server-test + client-build unter dem aggregierten CI Gate; version.ts-Check im Doku-Konsistenz-Skript reaktiviert.
  • Offen (bewusst, Folge-Slices): echte D1-Anlage/database_id + Deploy (wrangler), Cloudflare-Access/ Rollen (R7/OP-AUTH-1), Audit-Log-Persistenz (R8/OP-AUDIT-1), generierte Drizzle-Migrationen (OP-DATA-1).

• ✅ Slice 2 gebaut (0.3.0) — Dokumente / NextCloud (R3 + R9):

  • server/ — NextCloudClient-Vertrag (WebDAV-Impl + FakeNextCloud für Tests), Ablage-Pfadlogik (domain/ablage.ts), D1-Tabelle dokument + Migration v2, Dokument-Dienst (provisionieren · idempotenter Abgleich · Status + Item-Propagation · Hochladen). 33 Vitest-Tests grün.
  • API: GET/POST /api/mandanten/:id/dokumente[/provisionieren], POST /api/dokumente/:id/abgleich, PATCH /api/dokumente/:id, PUT /api/dokumente/:id/datei. Ohne NextCloud-Config → 503 (G-1).
  • client/ — Dokumente-Sektion im Mandant-Detail (provisionieren, Status, Abgleich, Hochladen).
  • OP-DOC-1 MVP entschieden: WebDAV + App-Passwort + Ordner je Mandant + Pull-Abgleich; Config via Worker-Secrets NEXTCLOUD_URL/USER/APP_PASSWORD (.dev.vars, nie im Repo). Rest offen: OAuth2 (RISK-16), OCS-Group-Folders (R7), Webhooks.

• ✅ Slice 4 gebaut (0.4.0) — Unterschriften / E-Signatur (R4 + A-2 + R9):

  • server/ — Provider-Abstraktion SignaturProvider (+ FakeSignatur für Tests/Staging), begründete Niveau-Matrix (domain/signatur-niveau.ts: Vollmacht→QES, Vertrag→AES, Mandat→SES), D1-Tabelle signatur_vorgang + Migration v3, Signatur-Dienst (anfordern · idempotenter Abgleich · bei Abschluss Rückablage signierte Fassung → NextCloud, Dok→unterschrieben, Item→geprüft). 43 Vitest-Tests grün.
  • API: POST /api/dokumente/:id/signatur, GET /api/mandanten/:id/signaturen, POST /api/signaturen/:id/abgleich. Ohne Provider/NextCloud → 503.
  • client/ — „Signieren"-Aktion je Dokument + Unterschriften-Sektion (Niveau, Status, Abgleich).
  • OP-SIGN-1 MVP: Abstraktion + Niveau-Matrix entschieden; Provider via SIGNATUR_PROVIDER (MVP fake). Rest offen: konkreter DocuSign/PandaDoc-Adapter + Webhooks + Datenresidenz/AVV.

• ✅ Slice 6 gebaut (0.5.0) — Audit-Log quer (R8, G-4):

  • server/ — append-only D1-Tabelle audit_event (Migration v4) + SHA-256-Hash-Verkettung (domain/audit.ts, pruefeKette erkennt Änderung und Löschung), monotone Audit-IDs; AuditRecorder quer in alle Dienste verdrahtet (Mandant/Onboarding/Dokument/Signatur), PII-arm (nur IDs/Status/Enums, G-5). 53 Vitest-Tests grün.
  • API: GET /api/mandanten/:id/audit, GET /api/audit, GET /api/audit/verify.
  • client/ — „Verlauf"-Sektion im Mandant-Detail.
  • OP-AUDIT-1: Hash-Chain + Retention-Matrix entschieden. Rest offen: Cold-Storage-Archiv (R2), Restore, Concurrency-Härtung der globalen Kette. RISK-5 gemindert (Score 6 → 3).

• ✅ Slice 3 gebaut (0.6.0) — Wiedervorlagen (R5, A-5):

  • server/ — D1-Tabelle wiedervorlage (Migration v5), Benachrichtigungs-Abstraktion (Interface + Log-Default + Fake), Wiedervorlage-Dienst (anlegen/liste/fällige/erledigen/ synchronisieren aus Dokument-Fristen/Erinnerungen versenden), Cloudflare-Cron (scheduled, stündlich, RISK-6 idempotent via erinnert_am). Audit-Events quer (R8). 62 Vitest-Tests grün.
  • API: GET /api/wiedervorlagen (Fälligkeits-Cockpit über alle Mandanten), GET/POST /api/mandanten/:id/wiedervorlagen[/synchronisieren], PATCH /api/wiedervorlagen/:id, POST /api/wiedervorlagen/erinnerungen.
  • client/ — „Fällig & offen"-Sektion im Cockpit (über alle Mandanten) + Wiedervorlagen-Sektion im Mandant-Detail (anlegen/erledigen). A-5 gebaut; E-Mail/Push-Adapter offen (Verfeinerung). RISK-6 in Arbeit (Reconciliation umgesetzt).

• ✅ Slice 5 gebaut (0.7.0) — Beratungsdokumentation (R6, Workshop W5):

  • server/ — Pflichtthemen + Default-Bausteine je Themenbereich (domain/beratung-themen.ts, schärft OP-DOMAIN-1), KI-Prüfer-Abstraktion (ki/pruefer.ts/RegelPruefer, OP-AI-1), D1-Tabelle beratungsdoku (Migration v6), Beratungsdoku-Dienst (anlegen · bearbeiten · prüfen (ki_geprüft, RISK-14) · freigeben → erzeugt R3-Dokument). Vollständigkeit abgeleitet (G-2). Quer auditiert. 74 Vitest-Tests grün.
  • API: GET/POST /api/mandanten/:id/beratungsdoku, PATCH /api/beratungsdoku/:id, POST /api/beratungsdoku/:id/{pruefen,freigeben}.
  • client/ — Beratungsdoku-Sektion im Mandant-Detail (Themenbereich, Inhalt, KI-Check mit fehlenden Themen, Freigeben).
  • OP-AI-1: Abstraktion + Regel-Check + Haftungsgrenze (pruefstatus) gebaut; echtes Medidentas-GPT (EU-Residenz) offen. RISK-14 in Arbeit. OP-DOMAIN-1-Restpunkt (R6-Pflichtthemen) abgeleitet.

• ✅ Slice 7 gebaut (0.8.0) — Identität & Rollen (R7, OP-AUTH-1):

  • server/ — Cloudflare-Access-Identität (auth/identitaet.ts): liest den von Access gesetzten Header cf-access-authenticated-user-email, löst ihn über die Benutzer-Tabelle zur Rolle auf (berater/backoffice/admin, R7-F02), mit Bootstrap-Admin (Deploy) und Default-Rolle für noch nicht zugewiesene Nutzer. D1-Tabelle benutzer (Migration v7), Benutzer-Repo-Methoden. Authn-Middleware (/api/*): ohne Identität bei AUTH_ENFORCED=true → 401, sonst Dev-Akteur. RBAC: Benutzer-Verwaltung nur für admin (sonst 403). Audit-Actor ist jetzt die echte Identität statt system (G-4 geschärft, RISK-8 gemindert). 83 Vitest-Tests grün.
  • API: GET /api/ich (Identität+Rolle), GET /api/benutzer, PUT /api/benutzer/:email, DELETE /api/benutzer/:email (alle Verwaltungs-Routen admin-only). GET /api/health nennt authEnforced.
  • client/ — angemeldeter Nutzer (E-Mail · Rolle) im Header; Admin-Bereich „Benutzer & Rollen" im Cockpit (nur für Admins: Rolle zuweisen/entfernen). ng build grün.
  • OP-AUTH-1 MVP entschieden: Cloudflare Access als Standard-IdP/SSO (G-1, wie Taktano) + eigenes leichtes Rollenmodell in D1; Config via AUTH_ENFORCED/AUTH_BOOTSTRAP_ADMIN/ AUTH_DEFAULT_ROLLE. Rest offen: Access-Application/Policies in der CF-Konsole (Deploy), feingranulare Mandant-Sichtbarkeit (RBAC je Mandant), SCIM/Gruppen-Sync.

• ✅ Slice 8 gebaut (0.9.0) — Dokumenten-Automatisierung (R12, Workshop W3 / UC-8):

  • server/ — Mapping-Engine (domain/dokumentvorlagen.ts): Vorlagen-Katalog je Dokumenttyp (dienstleistungsauftrag/makler_allein_auftrag/steuerberatervollmacht/sepa_lastschriftmandat/ existenzgruendung_checkliste/kundenunterlagen_einwilligung) + Feld-Mapping aus dem Stammsatz (G-2, zentrale Quelle) + sprechende Benennung. D1-Tabelle dokumentgenerierung (Migration v8), Dienst (api/dokumentgenerierung-service.ts: vorbereiten → erzeugen/ablegen (rendert Fassung → NextCloud-PUT → erzeugt R3-Dokument) → zur Unterschrift (R4-Übergabe, Niveau aus Matrix)). Status signiert abgeleitet (G-2) aus dem Signatur-Vorgang. Quer auditiert (R8). 92 Vitest-Tests grün.
  • API: GET/POST /api/mandanten/:id/dokumentgenerierung, POST /api/dokumentgenerierung/:id/{erzeugen,unterschrift}. Ohne NextCloud → 503.
  • client/ — Sektion „Dokumenten-Automatisierung" im Mandant-Detail (Typ wählen → befüllen → erzeugen → zur Unterschrift; Feld-Zusammenfassung + Status).
  • OP-DOCGEN-1 MVP: Mapping-Engine + Benennung + Ablage + R4-Übergabe gebaut; MVP rendert eine deterministische Text-Fassung. Rest offen: PDF-/Binär-Formularerzeugung, erweiterter Kundendatenbogen (Anschrift/Rechtsform/Bank), native Provider-Vorausfüllung. A-7 gebaut.

MVP-Kern (Slices 1–8) ist jetzt feature-complete (R1–R9, R12). Der Sprung auf 1.0.0 ist eine bewusste Meilenstein-Entscheidung — offen davor: Deploy-Reife (echte D1-Anlage, Cloudflare-Access- Application/Policies, echte Integrations-Adapter statt Fakes). Details: nächste Schritte §5.

3. Letzte Entscheidungen (mit IDs)

• G-1 Standardwerkzeuge bevorzugen als zentrales Leitprinzip (Nutzer-Vorgabe: „nach Möglichkeit auf Standardwerkzeuge zurückgreifen").
• A-1 Dokumente → NextCloud (kein Eigenbau-DMS).
• A-2 Unterschriften → DocuSign oder PandaDoc über Provider-Abstraktion (Anbieterwahl offen).
• A-3 Kundenstamm → CRM extern; Medidentas referenziert (S-1).
• OP-PM-1 union-Merge für CHANGELOG/HANDOFF/Timesheet; branch-abgeleitete Session-IDs.
• A-6 / R10 Plattform um Spezial-Tools erweiterbar (Tool-Host + Manifest-Vertrag, Isolation je Tool).
• Dexman als erstes Spezial-Tool spezifiziert (Mitbewerber medipulse.de analysiert). Sharpt OP-DOMAIN-1: Mandanten = Zahnarzt-/Arztpraxen / MVZ, Anwender = Praxisberatungs-Kontext (final bestätigen).
• A-4 Stack = Cloudflare (06-27, Nutzer-Entscheidung): Workers + D1 + Queues + Cron, wie Taktano. Schließt OP-STACK-1; eröffnet Folge-OPs OP-AUDIT-1 (D1+R2-Retention), OP-OBS-1, OP-DATA-1, OP-AUTH-1.
• Deploy-Architektur (28.06., OP-DEPLOY-1): eine Subdomain app.medidentas.com — ein Worker bedient UI + /api über Static Assets (wrangler [assets] + SPA-Fallback in index.ts). Begründung: ein Origin → Cloudflare Access schützt UI und API in einer Policy, kein CORS. Domain medidentas.com gekauft, Transfer an HQ ausstehend. Repo ist deploy-fertig (manueller app-deploy.yml-Workflow); sofort testbar über *.workers.dev. Runbook: docs/architektur/Deploy.md.
• MVP-Plan: erster vertikaler Slice = Mandant + Onboarding (R1/R2), dann Dokumente → Wiedervorlagen → Unterschriften → Beratungsdoku; Audit-Log quer ab Slice 1.
• Workshop 20.01.2026 (Anwender-Betrieb): Domäne bestätigt (Finanz-/Versicherungs- & Praxisberatung für (Zahn-)Arztpraxen) → schließt OP-DOMAIN-1. Neu: R11 (Meeting-Doku & Aufgaben, Prio 1 des Kunden), R12 (Dokumenten-Automatisierung), UC-7/8, OPs OP-MEET-1/OP-DOCGEN-1/OP-AI-1, FR-4 (MyID). CRM: Ist=Daylite, Zielrichtung HubSpot — aber Build-vs-Buy offen (Medidentas hält zunehmend „eine Wahrheit"; OP-CRM-1 geschärft). Neue Risiken RISK-14 (KI-Beratungsdoku-Haftung), RISK-15 (PII in US-/Cloud-KI-Diensten).

4. Offene Punkte (Kurzform — Detail im Lastenheft §11)

ID	Kurz	Nächster Schritt
OP-DOMAIN-1	✅ Bestätigt: Finanz-/Versicherungs- & Praxisberatung für (Zahn-)Arztpraxen	Restpunkt: R6-Pflichtfelder je Themenbereich aus Regulatorik (§34d/f/i, VVG §61–62, FinVermV §18) ableiten.
OP-ONBOARD-1	Self-Service-Onboarding (Slice 9)	✅ Einladungslink + öffentl. Formular + SES-Einwilligung (auditiert) gebaut. Manuell offen: Cloudflare-Access-Bypass für /onboarding*+/oeffentlich*, Turnstile-Keys, Einwilligungstext juristisch prüfen (RISK-18), echte NextCloud/Signatur statt DEMO_MODE.
OP-DEPLOY-1	Deploy-Reife & Domain (architektur/Deploy.md)	✅ Wired (28.06.): D1 EU (c58623e3…) in wrangler.toml, Custom-Domain-Route app.medidentas.com, AUTH_ENFORCED=true; Cloudflare Access (Zero Trust) aktiv (Policy „HQ + MK"); GitHub-Secrets gesetzt. Offen: AUTH_BOOTSTRAP_ADMIN als Worker-Secret (Admin-Erstzugang), NextCloud-/Signatur-Secrets (sonst 503), erster Deploy-Run + Smoke-Test. HQ-Eigentümer-Zuordnung = org. Folgepunkt. EU-Residenz Pflicht (G-5/RISK-17).
OP-MEET-1	Meeting-/Transkriptions-Tool (R11)	Tool wählen (Notion/Plaud/Krisp), EU-Residenz+AVV, Aufgaben-Sync ins CRM/Medidentas.
OP-DOCGEN-1	✅ MVP gebaut (Slice 8): Mapping-Engine + Benennung + NextCloud-Ablage + R4-Übergabe	Rest: PDF-/Binär-Formularerzeugung, erweiterter Kundendatenbogen, native Provider-Vorausfüllung.
OP-DOCGEN-2	Manuelle Detail-Ausformulierung bei Individualverträgen (Dienstleistungsauftrag, Makler-Allein-Auftrag)	Feld-Mapping reicht nicht: Vertragsdetails (Leistung/Vergütung/Sonderabreden) vor Unterschrift manuell ausformulieren/freigeben (Mensch im Prozess, RISK-14). Workflow „Entwurf → manuell ausformuliert → freigegeben“ + Audit (G-4) klären; dann R4 (AES/QES). Bezug OP-DOCGEN-1/OP-SIGN-1.
OP-AI-1	✅ Abstraktion + Regel-Check + Haftungsgrenze gebaut (Slice 5)	Rest: echtes Medidentas-GPT (Modell/Anbieter, EU-Residenz).
OP-BERATDOK-1	Beratungsprotokoll-Pflichtangaben (R6, geplant)	Strukturierte Rahmendaten: wann (R6-F11), wo (R6-F12: beim Kunden/bei Medidentas je m. Adresse / Video-Call), Dauer (F13), Analyse-Programm (F14), Empfehlung gefolgt? (F15, sonst Begründung), Risikoaufklärung bestätigt (F16), Unterlagen-Übermittlung (F17: Papier/Post/E-Mail/NextCloud), Angaben/Gesundheitsbogen vom Kunden 1:1 übernommen (F18, §19 VVG), Verzicht auf Beratungsdoku (F19, §6 Abs. 3/§61 Abs. 2 VVG — gesonderte Erklärung), Schlusserklärung Kunde (F20 — verstanden/aufgeklärt/Hinweise selbst gegeben/exakt empfohlenes Produkt/zufrieden; begrenzter Beweiswert RISK-20). Regulatorisch geboten (IDD/§34d·VVG §61–62/§19, §18 FinVermV), G-4. Modell/UI/D1 bauen; jur. Endabnahme offen.
OP-WV-1	Wiedervorlagen delegieren/zuweisen an Mitarbeiter (R5↔R7)	Heute nur freies verantwortlich (R5-F08, E-Mail-String). Bauen: Zuweisen/Neu-Zuweisen an Benutzer (R7, validierte Ref), „meine Wiedervorlagen"-Sicht, Benachrichtigung bei (Neu-)Zuweisung, Audit der Delegation (wer→wem, G-4). Speist UC-4/UC-6.
OP-CRM-1	CRM: Daylite→HubSpot oder Eigenlösung	Build-vs-Buy entscheiden; Daylite-Migration inkl. Wiedervorlagen.
OP-SIGN-1	✅ Abstraktion + Niveau-Matrix gebaut (Slice 4)	Rest: konkreter Anbieter (DocuSign/PandaDoc) + HTTP-Adapter/Webhooks + AVV.
OP-STACK-1	✅ Erledigt: Cloudflare	— (Folge-OPs: OP-AUDIT-1, OP-OBS-1, OP-DATA-1, OP-AUTH-1).
OP-DOC-1	✅ MVP gebaut (Slice 2): WebDAV + App-Passwort + Ordner + Abgleich	Rest: OAuth2 (RISK-16), OCS-Group-Folders, Webhooks.
OP-AUTH-1	✅ MVP gebaut (Slice 7): Cloudflare Access + Rollen (benutzer-Tabelle) + RBAC + echter Audit-Actor	Rest: Access-Application/Policies (Deploy), RBAC je Mandant, SCIM/Gruppen-Sync.
OP-AUDIT-1	✅ Gebaut (Slice 6): append-only + Hash-Chain + Verify	Rest: Cold-Storage-Archiv (R2), Restore, Concurrency-Härtung.
OP-TIME-1	Zeiterfassung (abrechenbare Beratungs-/Arbeitszeit je Mandant)	Standard-Tool wählen (G-1: SevDesk-Zeiterfassung/clockodo/Toggl), EU-Residenz/AVV, Zeit→Mandant/Beratung zuordnen, Übergabe an Rechnungsstellung (OP-INVOICE-1). Abzugrenzen vom internen Agenten-Timesheet.
OP-INVOICE-1	Rechnungsstellung & Mahnwesen	SevDesk als Standard-Werkzeug prüfen (Rechnung + Mahnwesen + DATEV, GoBD/§147 AO, EU/DE) — anbinden statt nachbauen (G-1); Medidentas liefert Leistungs-/Zeitdaten (OP-TIME-1) + Mandanten-Referenz (A-3), SevDesk = Single Source der Belege. API/Sync, AVV/Residenz klären.
OP-DSGVO-1	Datenschutz-Konzept	AVV, Residenz, Löschkonzept.
OP-EXT-1	Tool-Vertrag (Erweiterbarkeit)	Manifest-Schema, Scopes/Events, Isolation, Lizenz.
OP-DEX-1..5	Dexman-Detailfragen	PVS/Bank/DATEV-Integration, Prognose-Methodik, Benchmarks, Behandler-Sichtbarkeit (BetrVG), Lizenzmodell.
OP-DENTMARK-1	Dentmarking (Spezial-Tool, Vorstufe Dexman)	Schlankes Tool zum Daten sammeln + auswerten vor Dexman; Daten speisen später Dexman. R10/A-6. Klären: Datenumfang/Kennzahlen, Abgrenzung↔Dexman, Import, Daten-Übernahme, DSGVO/EU, Lizenz (OP-EXT-1). Tool-Spec geplant (spezialtools/Dentmarking.md).
OP-TOOLSPEC-1	Verfeinerung / Detail-Lastenheft Dexman & Dentmarking	Dexman vertiefen (OP-DEX-1..5: Kennzahlen, Prognose, PVS/Bank/DATEV, BetrVG, Lizenz); für Dentmarking eigene Spec spezialtools/Dentmarking.md (Datenmodell/Kennzahlen, Oberflächen, Abgrenzung+Datenübergabe Dexman). Manifest/Scopes/Isolation je Tool (OP-EXT-1). Iterativ, je Tool eigenes Arbeitspaket.

5. Nächste Schritte (Vorschlag)

1. ✅ Slice 1 gebaut (0.2.0, s. §2). Deploy-Reife herstellen: echte D1-Datenbank anlegen (wrangler d1 create medidentas → database_id in server/wrangler.toml), Worker + Client deployen (Cloudflare Access davor, OP-AUTH-1).
2. Slice 6 (Audit-Log quer, R8) anfangen — zustandsändernde Aktionen aus Slice 1 protokollieren (G-4 von Anfang); OP-AUDIT-1 (Store/Retention auf D1+R2).
3. ✅ MVP-Kern (Slices 1–6) komplett (s. §2). Weg zu 1.0.0: Deploy-Reife — echte D1-Anlage (wrangler d1 create), Cloudflare Access + Rollen (R7/OP-AUTH-1, Slice 7; macht actor im Audit real), echte Integrations-Adapter (DocuSign/PandaDoc, OAuth2-NextCloud, E-Mail, Medidentas-GPT) statt Fakes/Defaults.
4. Dann 1.0.0 taggen (bewusste Meilenstein-Entscheidung) — alternativ vorher Spezial-Tool Dexman (R10) oder die Workshop-Module R11/R12 (Meeting-Doku, Dok-Automatisierung).

6. Repo-Setup / Betrieb

• Doku-Site Deploy: Cloudflare Pages, Projekt medidentas-docs (siehe docs-site/wrangler.toml, .github/workflows/docs-deploy.yml). Benötigt Repo-Secrets CLOUDFLARE_API_TOKEN + CLOUDFLARE_ACCOUNT_ID (Pages: Edit). Bis Secrets/Domain gesetzt sind, ist der Deploy-Job ein bekannter offener Setup-Punkt.
• Branch-Protection / Auto-Merge / Squash-only / delete-branch-on-merge: als Repo-Settings setzen (agents.md §6.5) — nicht per Datei abbildbar.

---

Pflege: Bei jedem PR §2 (Stand) und §4 (OPs) nachziehen; CHANGELOG-Eintrag je PR; Timesheet-Session aktualisieren.