Medidentas — Sanity-Checkliste (North Star)
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 (geplant) | Status | Lücken / nächste Schritte |
|---|---|---|---|---|
| 1 | Wo steht der Kunde? | Cockpit (UC-6) · Onboarding-Fortschritt (R2) · Lifecycle/Phase (Lastenheft §5) | ⛔ → geplant | Datenmodell R1/R2 + Status-Ableitung spezifiziert (Lastenheft §4); Umsetzung = Slice 1 (MVP-Scope.md). |
| 2 | Was ist offen/fällig? | Wiedervorlagen-Sicht (R5) · ausstehende Unterschriften (R4) · fehlende Dokumente (R3) | ⛔ → geplant | Offene Pflicht-Items in Slice 1; Fälligkeit/Zustellung in Slice 3 (R5). |
| 3 | Alles vollständig & dokumentiert? | Beratungsdoku (R6) · Audit-Log (R8) · Dokument-Vollständigkeit (R3) | ⛔ | Audit-Log quer ab Slice 1 (auf D1, OP-AUDIT-1); Beratungsdoku = Slice 5. |
Legende: ✅ beantwortet · 🟡 teilweise · ⛔ offen (noch kein Code — Pre-MVP).
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 (sobald App-Code existiert)
Zweiter, technischer Realitäts-Check — „Ist alles gesetzt?" Wird mit dem ersten Anwendungscode ausgebaut (Dependency-Audit, SBOM, gepinnte Actions, Repo-Settings). Heute (reine Doku-Phase) beschränkt auf: Doku-Konsistenz-Check + Docs-Build in der CI; Repo-Settings (Squash-only · Auto-Merge · delete-branch-on-merge · Branch-Protection) sind Agenten-/Nutzer-Pflicht (agents.md §6.5).