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.

Status (0.9.0): Slices 1–8 sind feature-complete (R1–R9, R12 — getestet + dokumentiert; 92 Vitest-Tests). Der Sprung auf 1.0.0 ist eine bewusste Meilenstein-Entscheidung und wartet nur noch auf die Deploy-Reife: echte D1-Anlage, Cloudflare-Access-Application/Policies (R7/OP-AUTH-1 ist code-seitig gebaut) und echte Integrations-Adapter (DocuSign/PandaDoc, OAuth2-NextCloud, E-Mail, Medidentas-GPT, PDF-Formularerzeugung R12/OP-DOCGEN-1) statt der MVP-Fakes/-Defaults. Bis dahin 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), 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 + Typ (praxis/mvz); Lifecycle startet auf lead/ onboarding (R1-F02/F03/F04/F05).
  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)​

Fachliche Phase (R2-F04: stammdaten/dokumente/beratung/abschluss) wird getrennt vom Lifecycle-Status geführt (Lastenheft §5.2) — nicht aus dem Status erraten.

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

FrageAnzeige
Wo steht der Kunde?Mandanten-Liste mit lifecycle_status + Phase + 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-/Binär-Formularerzeugung offen
9Meeting-Doku & Aufgaben — Transkriptions-Tool anbinden, Protokoll → Aufgaben/Delegation, kundenverknüpft#2R111, OP-MEET-1offen (Workshop-Prio 1)
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).