Zum Hauptinhalt springen

MVP-Scope & Slice-Plan — Medidentas

Zweck. Schärft den Weg vom Repo-Init (0.1.0) zum MVP (1.0.0): Was ist drin, in welcher Reihenfolge, und woran erkennen wir "fertig". Ergänzt das Lastenheft (Master-Spec) um die Umsetzungs- Sicht (vertikale Slices, Backlog, Akzeptanz). Datenmodell-Felder sind im Lastenheft §4 (Rx-F##) kanonisch; hier referenziert.

Stack (entschieden 06-27): Cloudflare — Workers + D1 + Queues + Cron, Angular-Client, Cloudflare Access. Detail: ../architektur/Stack.md.

1. MVP-Ziel (1.0.0)​

Ein:e Berater:in kann den Kunden-Lebenszyklus einer Praxis lückenlos durch das System führen — vom Anlegen über Onboarding und Dokumente bis zur Unterschrift — und das System beantwortet jederzeit die True-North-Fragen:

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

MVP-Definition: Slices 1–5 (unten) sind umgesetzt, getestet (on-demand + CI) und dokumentiert → Versionssprung auf 1.0.0. Dieser MVP-Kern (Slices 1–5) ist längst übertroffen — der Sprung auf 1.0.0 ist eine bewusste Meilenstein-Entscheidung und wartet heute nur noch auf die echten Integrations-Adapter (E-Signatur DocuSign/PandaDoc MED-KB-5, E-Mail-Versand OP-DM-8, CRM) statt der austauschbaren Fakes (G-1) plus die HQ-Eigentümer-Zuordnung der Domain.

Status (0.127.1, 2026-08-27): Slices 1–13 sind umgesetzt (R1–R13 — getestet + dokumentiert; 692 Vitest-Tests / 57 Dateien + Client-Build; Slice 9 ist im Kern gebaut, echte Transkription bleibt offen, s. Backlog-Tabelle unten), dazu Dentmarking T1–T7 (D-27), Beratungsaufträge Slices A–C2b (3-Ebenen-Modell Person · Auftrag · Artefakte, 9-Produkt-Katalog, Status-Playbook + Cockpit-Kontext, MED-D-95/99/101/104/106/151) und UX-Wellen 1–10 (+ laufende Welle-11-Politur, B27/B28) inkl. World-2-Token-Rollout (kein zweifarbiger Übergangszustand mehr, MED-D-128…130), Akten-Cockpit-Redesign (MED-D-188…200) und Overlay-Dialog-A11y (MED-D-202). Die App ist live auf app.medidentas.com (Cloudflare Worker + D1 EU, Cloudflare Access, Auto-Deploy). Bis 1.0.0 laufen die externen Integrationen über austauschbare Provider-Abstraktionen (G-1).

2. Nicht-Ziele im MVP (bewusst später)​

  • Dexman (Spezial-Tool, Controlling/Prognose) — erst nach dem Kern-MVP (docs/spezialtools/Dexman.md).
  • Kunden-Self-Service-Portal (FR-1): Auth-Backend gebaut (Portal S2, 0.125.0, MED-D-283 — passwortlose Magic-Link-Routen, flag-gated/dormant); Nicht-Ziel für 1.0.0 bleibt das Kunden-UI (S3 Dashboard / S4 Einreichung) sowie die produktive Aktivierung (S5-Gate). Vorlagen-Bibliothek (FR-2), Reporting/Analytics (FR-3).
  • Mehr-Mandanten-/Tenant-Trennung über das Nötigste hinaus (erst bei Bedarf, RISK-10).

3. Prinzip: vertikale Slices​

Jeder Slice ist end-to-end (Datenmodell → Worker-API → Client-UI → Test → Doku) und liefert für sich True-North-Wert. Kein "erst alle Backends, dann alle UIs". Jeder Slice ist branch-/PR-weise (agents.md §7).

4. Slice 1 (JETZT) — Mandant + Onboarding​

Liefert: True North #1 (wo steht der Kunde?) + #2 (was ist offen?) für die Onboarding-Phase. Modulbezug: R1 (Mandant) + R2 (Onboarding). Use-Case UC-1.

4.1 Was der Nutzer kann (Funktionsumfang)​

  1. Mandant anlegen — Anzeigename + CRM-Link; Lifecycle startet auf lead/onboarding (R1-F02/F03/F05). (Der frühere Mandant-Typ praxis/mvz (R1-F04) ist per D-45 entfallen — der Mandant ist eine natürliche Person; Praxis/Gesellschaft ist eine eigene Entität mit objektart.)
  2. Onboarding starten — Vorlage je Typ wählen → erzeugt die Pflicht-Items (Stammdaten/Dokumente/ Aufgaben, R2-F03/F05).
  3. Items abarbeiten — je Item Status setzen: offen → angefordert → erhalten → geprüft (oder entfällt), sprechend (R2-F14, G-3).
  4. Fortschritt sehen — "Onboarding zu X % / es fehlen: …" — abgeleitet aus den Pflicht-Items (G-2).
  5. Cockpit-Liste — alle Mandanten mit Status + "was fehlt" + nächster Fälligkeit (Vorstufe R5).

4.2 Lifecycle & Phase (Slice 1)​

Onboarding-Teilschritt (R2-F04: stammdaten/dokumente/beratung/abschluss) läuft innerhalb der Lifecycle-Stufe onboarding — kein eigenständiger dritter Zustand. Die frühere, mandantenweite Mandant.prozessphase-Achse ist retiriert (MED-D-151): die feine Granularität lebt seither ausschließlich je Beratungsauftrag (Beratungsauftrag.status, MED-D-95), getrennt vom Lifecycle-Status geführt (Lastenheft §5.2 · architektur/Prozessmodell.md §2) — nichts aus dem Status erraten.

4.3 Cockpit-Slice (True-North-Antworten)​

FrageAnzeige
Wo steht der Kunde?Mandanten-Liste mit lifecycle_status + Auftrag-Status-Zusammenfassung + Fortschritts-%
Was ist offen?je Mandant: Liste der offenen Pflicht-Items (+ fällige zuerst)

4.4 Technische Umsetzung (Cloudflare)​

  • D1-Tabellen: mandant, onboarding, onboarding_item (Felder = Lastenheft R1/R2), schemaVersion
    • idempotente Migration.
  • Worker-API: CRUD Mandant/Onboarding/Item; Fortschritt/"was fehlt" wird berechnet (nicht gespeichert).
  • Client (Angular): Mandanten-Liste (Cockpit) + Mandant-Detail (Onboarding-Items).
  • Versionierung: APP_VERSION in server/src/version.ts (→ 0.2.0 mit Slice 1), Build-Nummer auto-gestempelt; danach version.ts-Check im Doku-Konsistenz-Skript reaktivieren.

4.5 Akzeptanzkriterien (Definition of Done) — ✅ erfüllt (0.2.0)​

  • Mandant anlegen/lesen/ändern über die UI; Daten in D1 persistiert (D1-Adapter) + idempotent migrierbar.
  • Onboarding-Vorlage (je Typ) erzeugt Pflicht-Items; Item-Status setzbar (sprechende Labels, G-3).
  • Fortschritt + "was fehlt" abgeleitet (kein gespeichertes Flag, domain/progress.ts) und in der UI sichtbar.
  • Cockpit-Liste beantwortet True North #1 + #2 (Fortschritt + offene Items je Mandant).
  • Tests/CI grün (server: 19 Vitest + Typecheck; client: ng build) + Doku (HANDOFF/Lastenheft/CHANGELOG/Timesheet) gepflegt.
  • Keine realen PII im Repo (synthetische Beispiele); Audit-Felder (R1-F07 angelegt_am/geaendert_am) gesetzt.

Bewusst noch offen (Folge-Slices): echte D1-Anlage/database_id + wrangler-Deploy, Cloudflare-Access /Rollen (R7/OP-AUTH-1), Audit-Log-Persistenz (R8/OP-AUDIT-1, Slice 6), generierte Drizzle-Migrationen (OP-DATA-1). Die D1-Anbindung ist über den Repo-Vertrag gekapselt; Tests laufen gegen den In-Memory-Adapter.

5. Backlog (priorisiert)​

SliceInhaltTrue NorthModuleAbhängig vonStatus
1Mandant + Onboarding#1, #2R1, R2—✅ gebaut (0.2.0)
2Dokumente / NextCloud — Item-Dokumente in NextCloud anfordern/ablegen, Status zurück#2, #3R3, R91, OP-DOC-1✅ gebaut (0.3.0)
3Wiedervorlagen — Fälligkeiten/Erinnerungen (Cron), Fälligkeits-Cockpit#2R51✅ gebaut (0.6.0)
4Unterschriften — Dokument zur E-Signatur (Provider-Abstraktion), Status, Rückablage#3R4, R92, OP-SIGN-1✅ gebaut (0.4.0)
5Beratungsdokumentation — Protokoll + Textbausteine + KI-Check + Freigabe→Dokument#3R61✅ gebaut (0.7.0)
6Audit-Log (quer) — append-only Event-Store auf D1 + Hash-Verkettung + Verify#3R81, OP-AUDIT-1✅ gebaut (0.5.0); Cold-Storage-Archiv/Restore offen
7Identität & Rollen — Cloudflare Access + Rollenmodell + RBAC + echter Audit-ActoralleR71, OP-AUTH-1✅ gebaut (0.8.0); Access-Policies/Deploy offen
8Dokumenten-Automatisierung — Standarddok. aus Stammdaten befüllen/benennen/ablegen, an R4 übergeben#2, #3R121, 2, 4, OP-DOCGEN-1✅ gebaut (0.9.0); PDF-Erzeugung nachgezogen (OP-DOCGEN-1/D-28)
9Meeting-Doku & Aufgaben — Transkriptions-Tool anbinden, Protokoll → Aufgaben/Delegation, kundenverknüpft#2R111, OP-MEET-1🟡 Kern gebaut (0.58.0, MED-D-82): Meeting-Protokoll → Aufgaben → Wiedervorlagen (R5, delegiert, G-2); echte Transkription offen (OP-MEET-1)
10Beratungsprotokoll-Pflichtangaben (R6-F11..F20)#3R65✅ gebaut (0.11.0)
11Dokumentationsverzicht-Workflow (OP-BERATDOK-1)#3R610✅ gebaut (0.12.0)
12Wiedervorlagen-Delegation/Zuweisung (OP-WV-1)#2R5, R73, 7✅ gebaut (0.13.0)
13Leistungszeit — abrechenbare Zeit je Mandant (dünnes Ledger, OP-TIME-1)#3R131✅ gebaut (0.14.0)
späterDexman (Spezial-Tool)eigener ZweckR10MVP-Kern, OP-EXT-1nach 1.0.0

Audit-Log (Slice 6) ist "quer": ab Slice 1 schreiben alle zustandsändernden Aktionen Events — der Store wird mit Slice 1 minimal angelegt und mit OP-AUDIT-1 (Retention/Archiv) ausgebaut (G-4 von Anfang).

5.1 Fachliche Workshop-Prioritäten ↔ technische Slices​

Der Anwender priorisiert (Workshop 20.01.2026, Anforderungen-Workshop-2026-01-20.md §5): (1) Meeting-Doku + Aufgaben, (2) Kundenerfassung + Dokumenten-Automatisierung, (3) CRM-Konsolidierung, später Dexman/MyID. Der technische Slice-Plan startet dennoch mit R1/R2 (Slice 1) als Fundament — ohne Mandanten-/Stammdatenmodell sind weder die Automatisierung (Slice 8) noch die kundenverknüpften Aufgaben (Slice 9) tragfähig. Die fachliche Reihenfolge bestimmt, was nach dem Fundament zuerst kommt: Slice 9 (Meeting/Aufgaben) und Slice 8 (Dokumenten-Automatisierung) rücken damit vor die rein internen Ausbaustufen. Endgültige Slice-Reihenfolge wird vor Slice 2 mit dem Nutzer bestätigt.

6. Offene Punkte, die Slices freischalten​

  • Slice 2: OP-DOC-1 (NextCloud-Integrationsweg).
  • Slice 4: OP-SIGN-1 (Anbieter + eIDAS-Niveau je Dokumenttyp).
  • Slice 6/7: OP-AUDIT-1 (Retention/Archiv auf R2), OP-AUTH-1 (Access + Rollen).
  • Quer: OP-DOMAIN-1 (Praxis-Kontext bestätigen → konkretisiert die Onboarding-Vorlagen + Beratungsdoku- Pflichtfelder).