Design-Entscheidungen — Mandanten-Akte (Decision Log)
ADR-artiges Log der im Design-Prozess getroffenen Entscheidungen: was entschieden wurde, warum, und was daraus folgt. Für Claude Code: Einträge bei Implementierung in docs/produkt/ übernehmen bzw. dort einarbeiten. Status: ✅ im Prototyp umgesetzt · 💡 konzeptionell beschlossen, noch nicht gebaut.
AD-001 · Lebenszyklus ≠ Prozessphase ✅ Zwei getrennte Konzepte: Lebenszyklus des Kunden (Lead → Onboarding → Aktiv → Ruhend → Archiviert) hängt an der Person und lebt im Avatar-Ring; Prozessphase (in Anbahnung → in Beratung → zur Unterschrift → abgeschlossen) hängt am einzelnen Beratungsmandat und lebt nur auf Mandats-Karten/-Overlay. Warum: Ein Kunde kann mehrere Mandate in verschiedenen Phasen haben; eine vermischte Skala erzeugt widersprüchliche Anzeigen. Folge: Der Begriff „Mandats-Status" ist für den Ring verboten.
AD-002 · Sekundäre Ansichten sind Overlays, keine Reiter ✅ Stammdaten-Editor, Erfasste Zeiten, Mandat-Detail und der Unterschriften-Assistent öffnen als Overlay über dem Cockpit (ESC + Scrim-Klick schließen). Reiter bleiben den Kern-Arbeitsbereichen vorbehalten (Basis-Informationen, Mandate, Praxen, Alle Dokumente, Fristen & Aufgaben). Warum: Verwaiste Vollansichten (kein aktiver Reiter, kein Zurück) brachen die Orientierung — Audit A2/A3. Folge: Kein Reiter „Zeiterfassung"/„Verlauf"/„Stammdaten" mehr.
AD-003 · Dokumentstatus-Wording: Fehlt → Erhalten → Geprüft ✅ Slider-Beschriftung in Prozessrichtung, gleiche Wortfamilie wie die Ablage-Pills (angefordert/erhalten/geprüft). Ersetzt „Geprüft · Da · Nötig · Später". Warum: G-3 (ein Begriff überall); „Da" kollidierte mit Tooltip „Bereitgestellt", Reihenfolge las sich gegen die Prozessrichtung (Audit C16, D19).
AD-004 · Erforderlichkeit als Checkbox, nicht als Slider-Zustand ✅ „Später" flog aus dem Slider. Jede Dokumentzeile hat vorn eine Checkbox (erforderlich / vorerst nicht erforderlich); Abgewählte sortieren ans Gruppenende unter den Trenner „Vorerst nicht erforderlich". Fortschritt (x/n) zählt nur Erforderliche. Warum: „Später" im Nenner machte 100 % unerreichbar (Audit B11); Erforderlichkeit ist eine andere Dimension als der Bearbeitungsstand. Folge: Statt Drag-unter-eine-Linie (fummelig, nicht tastaturfähig) übernimmt die Sortierung den räumlichen Effekt automatisch.
AD-005 · „abgelaufen" ist Systemzustand, kein Slider-Wert ✅
Gültigkeitsdatum überschritten ⇒ Status fällt automatisch auf „Fehlt" zurück + roter Chip „abgelaufen" (Meta: „war geprüft · gültig bis TT.MM.JJJJ").
Warum: Der Slider ist, was der Berater festlegt; abgelaufen ist, was das System feststellt. Der Slider bleibt dreistufig schlank. ✅ Ablauf erzeugt eine Aufgabe — abgeleitet, nicht persistiert (MED-D-246): ein vorhandenes Dokument mit überschrittenem gueltigBis erscheint als abgeleiteter „erneuern"-Schritt (Aktenreife-Punkt dokument/Stufe aktiv/wichtig + TaskCard + überfälliger Cockpit-Punkt) — es wird keine Wiedervorlage/Aufgabe geschrieben (hält das Backlog sauber, G-2; Nutzer-Entscheidung). Verfeinerung ggü. dem ursprünglichen Wortlaut: der persistierte Status bleibt unverändert (geprüft), der Ablauf wird als roter Chip abgeleitet dargestellt.
AD-006 · Ein Unterschriften-Assistent für alle Formulare ✅ Ein 3-Schritte-Overlay (Prüfen → Versenden → Verfolgen) ist der einzige Versandweg — erreichbar aus Aufgabenkarte, Dokumentzeile und Bankverbindung. Schritt 1 prüft Pflichtdaten (Readiness-Gate) und erfasst Fehlendes inline (weiche Validierung, Übernahme in Stammdaten); Schritt 2 wählt Versandart, Signaturniveau (SES vorausgewählt), Frist/Erinnerung mit auto-Wiedervorlage, Sammel-Umschlag; Schritt 3 zeigt das Ergebnis und schreibt Status zurück. Warum: Versand war über drei Orte verstreut; die SEPA-Aufgabe „Senden" war eine Sackgasse solange die IBAN fehlte (Audit A5) — der Assistent macht die Lücke zum ersten Schritt statt zur Blockade.
AD-007 · Vor-Ort-Signatur als gleichwertige Versandart ✅ Schritt 2 bietet „Per E-Mail senden" und „Vor Ort unterschreiben" (DocuSign In-Person-Signing, Host = Berater): Übergabe-Screen (Akte ausgeblendet) → Kunden-Signaturansicht → Danke/Rückgabe → Ergebnis. Vor-Ort-Signatur setzt das Dokument sofort auf „Erhalten". Warum: Kein Medienbruch im Beratungstermin (DLA + SEPA direkt bei Mandatsanlage). Bei AES/QES zeigt der Assistent den zusätzlichen ID-Check an.
AD-008 · DocumentRow ist zustandsgetrieben (DocuSign-Envelope) ✅ Aktionen je Zustand, nie alle gleichzeitig: Fehlt → „Zur Unterschrift →"; versendet → Pill „wartet auf Signatur" + „Erinnern" + „↑ Signiert hochladen" (Sign on Paper: Scan wird derselben Sendung zugeordnet und schließt sie ab); Erhalten/Geprüft → keine Send-Aktionen. Warum: Statische Buttons an jeder Zeile erzeugten widersprüchliche Anzeigen (Audit B7: „abgelegt" + „Zur Unterschrift" gleichzeitig).
AD-009 · Formular-Rücklauf mit Prüf-Schritt, keine stille Übernahme ✅ (MED-D-247)
DocuSign-Formularfelder haben drei Rollen (vorbefüllt & gesperrt / vorbefüllt & korrigierbar / füllt der Kunde aus). Zurückgelesene Werte landen in einer Rücklauf-Prüfung (Diff alt → neu, „Übernehmen" je Feld), nie direkt in den Stammdaten.
Warum: Vier-Augen-Prinzip, Auditierbarkeit — Kundenkorrektur ≠ automatische Stammdatenänderung.
Gebaut (MED-D-247): Adapter liest form_data zurück (live gegen DocuSign Demo verifiziert); nur die verlustfrei rückschreibbaren Person/Kontakt/Anschrift-Felder sind Ziel (ATTRIBUT_ZU_STAMMZIEL, bank.*/praxis.* außen vor); die Werte werden on-demand abgeleitet, nichts persistiert bis zur bewussten Übernahme, dann versioniert (Quelle formular, G-4). Speist die bestehende Review-and-apply-Maschine (baueVorschlaege/bauePatch) — kein Zweitpfad (G-1/G-2). Client: „Rücklauf prüfen"-Overlay mit Diff-Liste + Checkbox je gültigem Feld.
AD-010 · Fremdformulare: PDF im Admin-Bereich, Felder im Feld-Editor ✅ Externe Formulare (Bank/Partner, z. B. EDÜ apoBank) werden im Admin-Bereich als PDF hochgeladen; Ausfüll- & Signaturfelder werden dort im Feld-Editor markiert und aus Stammdaten vorbefüllt. In der Akte: Pill „Fremdformular · PDF"; Versand/Signatur identisch zum Standard-Flow.
AD-011 · Bankverbindungen: n Konten, zwei Status-Dimensionen, SEPA je Konto ✅ Mehrere Konten je Mandant; je Konto Pflichtangaben Inhaber und Zeichnungsberechtigung. Zwei getrennte Dimensionen statt eines 5er-Enums: Prüfstatus (neu / geprüft / archiviert) × SEPA (gültig / ohne gültiges SEPA). Ein SEPA-Mandat gilt für genau ein Konto; die Signatur-Anfrage geht an die zeichnungsberechtigte Person (nicht automatisch an die Mandantin). Warum: „neu & ohne SEPA … alt/archiviert" war ein Kreuzprodukt — als zwei orthogonale Felder bleibt es konsistent und filterbar.
AD-012 · Append-only: „archivieren", nie „löschen" ✅ Akteninhalte (Konten, Dokumente, Stammdaten) werden nie gelöscht, nur archiviert; Archiviertes bleibt versioniert erhalten. UI-Verb ist überall „archivieren". Folge: Swipe-to-Archive auf BankRow (links wischen/ziehen legt „Archivieren" frei) mit zwei Affordanzen: einmalige Peek-Animation beim Öffnen + dezentes „‹" am Zeilenende. Archivierte Zeilen sind nicht wischbar.
AD-013 · Stammdaten sind feld-versioniert ✅ Jede Änderung erzeugt eine neue Version (v1…vN); je Feld ist die Historie abrufbar („⟲ N frühere Werte anzeigen": vN · bis Datum · Wert · Quelle). Overlay-Kopf zeigt „Stand: vN · Datum", der Speichern-Button „Speichern → vN+1". Quellen werden mitgeführt (Self-Service, Onboarding, Formular-Rücklauf). Warum: Auditierbarkeit ist Produktversprechen; alte Anschriften etc. bleiben nachvollziehbar.
AD-014 · Self-Service: Kunde sieht Dokumentstatus, Uploads erzeugen Versionen ✅ Die Self-Service-Strecke (Link „Aktualisierung anfordern", jetzt in der Stammdaten-Overlay-Karte) zeigt dem Kunden den Status der angeforderten Dokumente und erlaubt Uploads; jeder Upload erzeugt eine neue Version (Pill „neue Version · v2" + „Prüfen"-Aktion beim Berater).
AD-015 · Zeiterfassung: Sidebar-Karte + Overlay statt Reiter ✅ Timer als kompakte Karte in der rechten Spalte (Buchen auf 15 Min gerundet, transparent beschriftet); die vollständige Liste „Erfasste Zeit & Abrechnung" öffnet als Overlay. Abrechnung läuft extern (SevDesk) — die Akte zeigt nur Status.
Konvention für neue Einträge
Jede im Chat getroffene Design-Entscheidung bekommt sofort einen AD-Eintrag (fortlaufende Nummer, ✅/💡, Entscheidung + Warum + Folgen, 3–6 Zeilen). Die Spec (akte-patterns.md) beschreibt das Wie (Maße, Zustände), dieses Log das Warum — beide gehören ins Handoff-Paket.