Medidentas Digital — Sanity-Checkliste (North Star) — (Stand 0.127.1, 2026-08-27)
Zweck. Diese Liste ist der Realitäts-Check für Produkt & Code: Beantwortet Medidentas die zentralen Fragen des Back-office / der Beratung jederzeit, schnell und korrekt? Jedes Feature, jeder Prozessschritt, jedes Dokument wird daran gemessen. Pflegen: bei jeder größeren Änderung den Status unten aktualisieren (✅/🟡/⛔) und Lücken benennen.
Die Top-3-Leitfragen (immer beantwortbar)
- Wo steht der Kunde im Prozess? — Onboarding-/Beratungs-Status je Mandant: welcher Schritt, was fehlt?
- Was ist offen und fällig? — Wiedervorlagen, ausstehende Unterschriften, fehlende Dokumente/Angaben.
- Ist alles vollständig & rechtssicher dokumentiert? — Beratungsdoku · Unterschriften · Belege: lückenlos, auditierbar, DSGVO-konform.
Jede neue Funktion sollte mindestens eine dieser Fragen direkter, schneller oder genauer beantworten — sonst kritisch hinterfragen.
Status & wo beantwortet (lebend)
| # | Frage | Wo im Produkt | Status | Lücken / nächste Schritte |
|---|---|---|---|---|
| 1 | Wo steht der Kunde? | Mandanten-Liste als Landing (Cockpit-Modus „Mandanten", Default; filterbar nach Lifecycle-Status/Betreuungsmodell/offene Fakturierung + Namenssuche, MED-D-267) · Cockpit Fokus/Leitstand (UC-6) · prozessgegliederter Mandant + Arbeitssicht mit Aktendeckel + Lifecycle-Stufen-Registern (D-41/D-44) · Aktenreife-Aggregat GET /api/aktenreife (D-43) · Lifecycle-Status (Person) + Auftrags-Status (je Beratungsauftrag) getrennt, seit MED-D-151 nur noch zwei Achsen (Lastenheft §5, Prozessmodell.md §2) | ✅ | — |
| 2 | Was ist offen/fällig? | Wiedervorlagen-Register + Cockpit inkl. Delegation (R5/R7) · offene Pflicht-Items je Onboarding-Teilschritt (R2) · ausstehende Unterschriften (R4) · "Nächste Schritte"-Leiste (D-46) · Formular-SLA-/Sichtungs-Wiedervorlagen (MED-D-67/89) · Cockpit-Fokus-Filter: Mandant-Suche + Kategorie-Chips + „Zu fakturieren" (offene abrechenbare Zeit, MED-D-252) | ✅ | — |
| 3 | Alles vollständig & dokumentiert? | Beratungsdoku R6 + Pflichtangaben (R6-F11..F20) · Audit-Hash-Kette (R8) · Zugriffslog (D-50) · Aktenreife je Lifecycle-Stufe (jeStufe, MED-D-151) | 🟡 | Der DocuSign-Adapter ist gebaut und der Kern live gegen die Demo verifiziert (MED-D-238/239: JWT/Envelope/Webhook-Write-back; Fremdformulare Weg A/B); offen bleibt die Prod-Umschaltung für echte Rechtswirkung (Consent/Hosts/DEMO_MODE=false + AVV, OP-SIGN-1) und der reale E-Mail-Versand (OP-DM-8). Bis dahin bleibt der Fake-Adapter der Default (MED-KB-5). Direkter/schneller auf Frage 3 (MED-D-262/263): Fremdformular-Vorlagen werden aus den echten DocuSign-Templates gewählt (statt getippter GUID) und deren tatsächliche Felder gegen das Weltmodell gematcht → korrekt registrierte, vorbefüllbare Formulare mit weniger Fehlbedienung; offen bleibt die Verifikation gegen den echten Account und die Prod-Rechtswirkung. |
Legende: ✅ beantwortet · 🟡 teilweise · ⛔ offen.
Anwendung
- Review/PR: Trägt die Änderung zu Frage 1–3 bei? Falls nein: bewusst begründen.
- Doku: Lastenheft §1.3 referenziert diese Liste; neue Module/OPs hier einordnen.
- Standardwerkzeug-Check (G-1): Löst die Funktion etwas, das ein Standard-Tool schon kann? Dann anbinden statt nachbauen.
Security-/Setup-Sanity
Zweiter, technischer Realitäts-Check — "Ist alles gesetzt?" Heute abgesichert durch: Server-Vitest +
tsc-Typecheck (server/), Client-Produktions-Build (ng build,client/), Doku-Konsistenz-Check + Docs-Build — alle als CI-Jobs unter dem aggregiertenCI Gate(docs/betrieb/Test-Uebersicht.md). Repo-Settings (Squash-only · Auto-Merge · delete-branch-on-merge · Branch-Protection) sind weiterhin Agenten-/Nutzer-Pflicht (agents.md §6.5); Ausbau (Dependency-Audit, SBOM, gepinnte Actions) bleibt offen.