Design-Entscheidungen — Mandanten-Akte (Akten-Cockpit)
Zielgruppe: Produkt/Management + Design/IT-Dev. Zweck: Das Warum hinter dem Akten-Cockpit- Redesign — als ADR-Log (AD-001…AD-015) aus dem Design-Prozess (claude.ai/design-Handoff „Akten-Cockpit 1a (Detail)"), in die Produktdoku eingearbeitet und je Entscheidung mit ihrer Umsetzung im Repo (MED-D-ID · Komponente · Status) verknüpft. Stand: Version
0.99.12.Quellen der Wahrheit (im Repo archiviert): der Pixel-Prototyp + die Spec liegen unter
docs/design/akten-cockpit-handoff/—akte-patterns.md(verbindliche Maße/Tokens, das Wie), die.dc.html(Markup-Referenz),screenshots/01–17(Soll- Zustände). Dieses Doc trägt das Warum; die Spec das Wie; der Slice-/Bauplan steht inarchitektur/Akten-Cockpit-Redesign.md.
Kernaussage (BLUF)
Das Akten-Cockpit dreht den Mandanten von einer Reiter-Sammlung zu einer fokussierten Dreiteilung — Person (links: Lebenszyklus-Ring) · Arbeit (Mitte: fünf Reiter) · Nächstes (rechts: Aufgaben + Timer) —, mit sekundären Ansichten als Overlays statt Reitern. Fünfzehn Design-Entscheidungen tragen das: sie trennen Lebenszyklus (Person) von Prozessphase (je Beratungsauftrag) (AD-001), machen den Dokumentstatus zu einem zustandsgetriebenen Signatur-Flow (AD-003/-008), bündeln allen Versand in einen Unterschriften- Assistenten (AD-006/-007) und halten den Mandanten append-only (AD-012/-013). Alle mit ✅ markierten Entscheidungen sind gebaut und live (Akten-Cockpit-Redesign S1–S6, MED-D-188…200); die mit 💡 markierten sind konzeptionell beschlossen und teils an die reale Signatur-Anbindung (DocuSign) gekoppelt.
Legende: ✅ gebaut & live · 🟡 teilweise / UI-Mapping (voller Umfang folgt) · 💡 beschlossen, noch offen.
Die Entscheidungen (AD-001 … AD-015)
AD-001 · Lebenszyklus ≠ Prozessphase — ✅ · Umsetzung: MED-D-95 (3-Ebenen-Modell), MED-D-151/-191 (LifecycleRing).
Zwei getrennte Skalen: der Lebenszyklus der Person (Lead → Onboarding → Aktiv → Ruhend → Archiviert) lebt
im Avatar-Ring; die Prozessphase je Beratungsauftrag (in Anbahnung → in Beratung → zur Unterschrift →
abgeschlossen) lebt nur auf Mandats-Karten/-Overlay. Warum: Ein Kunde hat mehrere Mandate in verschiedenen
Phasen — eine vermischte Skala erzeugt widersprüchliche Anzeigen. Folge: „Mandats-Status" ist für den Ring
verboten. (Repo-Realisierung: AuftragStatus = anbahnung · beratung · unterschrift · laufend ·
abgeschlossen — fünfstufig, feiner als die vierstufige Design-Skala; LifecycleStatus unverändert.)
AD-002 · Sekundäre Ansichten sind Overlays, keine Reiter — ✅ · Umsetzung: MED-D-191 (5-Reiter-IA + Overlay-Shell), MED-D-200 (Mandat-Overlay). Stammdaten, 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 · Alle Dokumente · Fristen & Aufgaben · Praxen). Warum: Verwaiste Vollansichten (kein aktiver Reiter, kein Zurück) brachen die Orientierung. Folge: Kein Reiter „Zeiterfassung"/„Verlauf"/ „Stammdaten" mehr.
AD-003 · Dokumentstatus-Wording: Fehlt → Erhalten → Geprüft — ✅ · Umsetzung: MED-D-192 (StatusSlider), labels.ts.
Slider-Beschriftung in Prozessrichtung, gleiche Wortfamilie wie die Ablage-Pills. Ersetzt „Geprüft · Da ·
Nötig · Später". Warum: G-3 (ein Begriff überall); „Da" kollidierte mit „Bereitgestellt", die alte
Reihenfolge las sich gegen die Prozessrichtung.
AD-004 · Erforderlichkeit als Checkbox, nicht als Slider-Zustand — ✅ · Umsetzung: MED-D-192 (RequirementCheckbox + Trenner). „Später" flog aus dem Slider; jede Dokumentzeile trägt vorn eine Checkbox (erforderlich / vorerst nicht erforderlich), Abgewählte sortieren unter den Trenner „VORERST NICHT ERFORDERLICH". Fortschritt (x/n) zählt nur Erforderliche. Warum: „Später" im Nenner machte 100 % unerreichbar; Erforderlichkeit ist eine andere Dimension als der Bearbeitungsstand.
AD-005 · „abgelaufen" ist Systemzustand, kein Slider-Wert — 🟡 · Umsetzung: MED-D-192 (Ablauf-Chip); 💡 offen: Ablauf erzeugt automatisch eine Aufgabe. Gültigkeitsdatum überschritten ⇒ Status fällt automatisch auf „Fehlt" + roter Chip „abgelaufen". Warum: Der Slider ist, was der Berater festlegt; abgelaufen ist, was das System feststellt — der Slider bleibt dreistufig. Offen: die automatische Folge-Aufgabe bei Ablauf.
AD-006 · Ein Unterschriften-Assistent für alle Formulare — ✅ · Umsetzung: MED-D-198 (3-Schritt-Assistent). Ein 3-Schritte-Overlay (Prüfen → Versenden → Verfolgen) ist der einzige Versandweg — aus Aufgabenkarte, Dokumentzeile und Bankverbindung. Schritt 1 prüft Pflichtdaten (Readiness-Gate) und erfasst Fehlendes inline. Warum: Versand war über drei Orte verstreut; die SEPA-Aufgabe „Senden" war eine Sackgasse ohne IBAN — der Assistent macht die Lücke zum ersten Schritt statt zur Blockade.
AD-007 · Vor-Ort-Signatur als gleichwertige Versandart — ✅ · Umsetzung: MED-D-198 (Vor-Ort-/Demo-Abschluss, Sicherheitsriegel gegen echte Provider); geführte Strecke + Write-back-Automatik: MED-D-227.
Schritt 2 bietet „Per E-Mail senden" und „Vor Ort unterschreiben" (In-Person-Signing, Host = Berater):
Übergabe → Kunden-Signaturansicht → Danke → Ergebnis (Slice B, MED-D-227 — Vollflächen-Takeover statt
Ein-Klick). Warum: Kein Medienbruch im Beratungstermin. Bei AES/QES zeigt der Assistent den zusätzlichen
ID-Check an. Die Vor-Ort-Unterschrift landet auf erhalten (Prüfung offen), nicht unterschrieben —
die Attrappe erzeugt keine rechtsgültige Signatur (G-4/MED-KB-5); bei Abschluss werden SEPA-Mandat und
auslösende Aufgabe automatisch nachgezogen (Write-back-Automatik).
AD-008 · DocumentRow ist zustandsgetrieben (Signatur-Envelope) — 🟡 · Umsetzung: MED-D-192 (zustandsgetriebene Aktionen, UI-Mapping); der reale versendet-Envelope-Zustand kommt mit der DocuSign-Anbindung (OP-SIGN-1).
Aktionen je Zustand, nie alle gleichzeitig: Fehlt → „Zur Unterschrift →"; versendet → „wartet auf Signatur" +
„Erinnern" + „↑ Signiert hochladen"; Erhalten/Geprüft → keine Send-Aktionen. Warum: Statische Buttons je
Zeile erzeugten widersprüchliche Anzeigen. Status: die Zustandslogik ist gebaut; der versendet-Flag läuft
bis zur echten Provider-Anbindung als UI-Mapping (S2-Entscheidung, MED-D-192).
AD-009 · Formular-Rücklauf mit Prüf-Schritt, keine stille Übernahme — 🟡 · Umsetzung: MED-D-89 (Feld-Sichtung/Korrekturschleife für öffentliche Formulare); der Signatur-Formular-Rücklauf-Diff ist 💡 offen (mit DocuSign). Zurückgelesene Formularwerte landen in einer Rücklauf-Prüfung (Diff alt→neu, „Übernehmen" je Feld), nie direkt in den Stammdaten. Warum: Vier-Augen-Prinzip, Auditierbarkeit. Status: das Muster existiert für die Kundenstrecken (MED-D-89); der Signatur-Envelope-Rücklauf folgt mit der DocuSign-Anbindung.
AD-010 · Fremdformulare: PDF im Admin-Bereich, Felder im Feld-Editor — 🟡 · Umsetzung: MED-D-235 (Weg A,
Slice 1) — Rücklauf 💡 offen (MED-OP-FORM-5).
Externe Formulare (Bank/Partner) werden als PDF hochgeladen, ihre AcroForm-Felder im Feld-Editor je Feld
einem Weltmodell-Attribut (G-8) zugeordnet und aus den Stammdaten vorbefüllt (pdf-lib, G-1; signiert
wird danach über DocuSign); beim Mandanten erscheint die Pill „Fremdformular". Status: Slice 1 gebaut (Auslesen · Mapping ·
Prefill · Uf; MED-D-235), der Wert-Rücklauf in die Stammdaten über den Feld-Sichtungs-Pfad (MED-D-89) ist
der Folge-Slice (MED-OP-FORM-5). Detail: Fremdformulare.md.
AD-011 · Bankverbindungen: n Konten, zwei Status-Dimensionen, SEPA je Konto — ✅ · Umsetzung: MED-D-195 (1:n-Bankkonto-Entität), MED-D-196 (BankRow). 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). Die Signatur-Anfrage geht an die zeichnungsberechtigte Person. Warum: „neu & ohne SEPA … archiviert" war ein Kreuzprodukt — zwei orthogonale Felder bleiben konsistent und filterbar.
AD-012 · Append-only: „archivieren", nie „löschen" — ✅ · Umsetzung: G-4, MED-D-196 (Swipe-to-Archive). Inhalte eines Mandanten werden nie gelöscht, nur archiviert; Archiviertes bleibt versioniert erhalten. UI-Verb ist überall „archivieren". Folge: Swipe-to-Archive auf BankRow (Peek-Teach + dezentes „‹"); archivierte Zeilen sind nicht wischbar.
AD-013 · Stammdaten sind feld-versioniert — ✅ · Umsetzung: MED-D-179 (Versionierung), MED-D-197 (VersionedField). Jede Änderung erzeugt eine Version (v1…vN); je Feld ist die Historie abrufbar; Overlay-Kopf „Stand: vN · Datum", Speichern-Button „Speichern → vN+1". Quellen (Self-Service, Onboarding, Formular-Rücklauf) werden mitgeführt. Warum: Auditierbarkeit ist Produktversprechen.
AD-014 · Self-Service: Kunde sieht Dokumentstatus, Uploads erzeugen Versionen — ✅ · Umsetzung: MED-D-170, MED-D-197 (Self-Service-Karte im Stammdaten-Overlay). Die Self-Service-Strecke 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 — ✅ · Umsetzung: MED-D-172 (ein Server-Timer je Benutzer), MED-D-191 (Zeiten-Overlay). 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) — der Mandant zeigt nur Status.
Konvention (aus dem Handoff übernommen)
Jede im Design-/Chat-Prozess getroffene Entscheidung bekommt sofort einen AD-Eintrag (fortlaufende
Nummer, ✅/🟡/💡, Entscheidung + Warum + Folge + Umsetzung im Repo). Die Spec
(akte-patterns.md) beschreibt das Wie (Maße,
Zustände), dieses Log das Warum. Technische Bau-Entscheidungen laufen zusätzlich als MED-D-n im
betrieb/Decision-Log.md — die AD-Nummern hier sind die Design-Perspektive
darauf, kein Ersatz.