Ablage-Reiter = Spiegel der NextCloud/R2-Dokumente — die Ablage-Hauptliste zeigt nur noch tatsächlich abgelegte Dokumente (Referenzen mit gesetztem nextcloudPfad); provisionierte, aber noch nicht abgelegte Referenzen stehen als ausklappbare „erwartete Dokumente"-Unterliste darunter, mit erhaltenen Intake-Aktionen (Datei hochladen · Upload-Link · zur Unterschrift) → wandern in den Spiegel, sobald eine Datei/Unterschrift eingeht. Kein Onboarding-Platzhalter maskiert sich mehr als abgelegtes Dokument. Visuelle Option A (Filter über nextcloudPfad); echte NextCloud-Live-Spiegelung = MED-OP-FILES-1. Reine Client-Sicht, kein Server-/Migrations-Belang. | ✅ (visuell; Live-Spiegelung offen, MED-OP-FILES-1) | Client · MED-D-288 (R3/R9) | Mandant → Reiter „Alle Dokumente" · mandant-detail.component.ts (abgelegteDokumente/erwarteteDokumente) · styles.css (.md-erwartet) | 0.127.1 |
Gutachten-Block im Mandate-Reiter nur bei Praxen — der eigenständige Dentmarking-Gutachten-Block erscheint im „Mandate"-Reiter nur noch, wenn Praxen vorhanden sind ([hidden]-Gate um praxen().length === 0 erweitert) — kein leeres Gutachten steht mehr alleinstehend im Reiter. | ✅ | Client · MED-D-287 | Mandant → Reiter „Mandate" · mandant-detail.component.ts (id="dentmarking") | 0.127.1 |
Gesprächsprotokoll als eigener Reiter — die Gesprächsnotizen / Meeting-Doku (R11) sind aus der linken Sidebar-Rail (dort seit MED-D-273) in einen eigenen Reiter „Gesprächsprotokoll" neben „Praxen" gewandert — mehr Platz für Protokoll-Erfassung + Aufgaben-Ableitung. Reine Client-Umstrukturierung (Register + [hidden]-Panel), Komponente/Bindings unverändert. | ✅ | Client · MED-D-281 (R11) | Mandant-Detail → Reiter „Gesprächsprotokoll" · mandant-detail.component.ts (md-mandant-meetings) | 0.123.1 |
Durchlaufender Timer + Zeitbuchungs-Overlay — der Zeiterfassungs-Timer folgt dem Mandanten (statt beim Wechsel zu blockieren) und schreibt mit, welcher Mandant wann im Vordergrund war (timer_segment). Der Cockpit-Chip „⏱ Zeit buchen" (oder die Push-Benachrichtigung) öffnet die Aufschlüsselung je Mandant + „nicht zugeordnet": Minuten/Tätigkeit editierbar, freie Zuweisung an beliebige Mandanten (auch nie geöffnete, z. B. Telefonat), „Buchen & stoppen" (geräteübergreifend) / „weiterlaufen" → je Zeile eine append-only Leistungszeit. Live-Push (daten-los, VAPID/WebCrypto, PII-frei; /sw.js + PWA-Manifest; opt-in; dormant ohne VAPID-Secret) hält die Benachrichtigung aktuell und erlaubt geräteübergreifendes Stoppen. Härtung MED-D-276: Segment-Konsistenz aller Timer-Aktionen, Direkt-Buchung verweigert Fehlzuordnung über mehrere Mandanten (→ verteiltes Overlay), Push non-blocking + Endpoint-Allowlist + kein user_agent (G-6). | 🟡 (Push live nach VAPID-Secret; server-seitiger Rest-Zeit-Schutz beim verteilten Buchen offen, MED-D-276) | Server+Client · MED-D-275/276 | Cockpit „⏱ Zeit buchen" · Mandant-Timer · timer-service.ts/push-service.ts/zeitbuchung-overlay.component.ts | 0.122.0 |
| Mandant „Mandate"-Reiter aufgeräumt — Beratungsmandat anlegen läuft über „+ Mandat" oben rechts + Overlay (statt inline-Form); „Formulare zum Ausfüllen" ist in den Reiter „Alle Dokumente" verschoben (fachlich Dokumente); Gesprächsnotizen / Meeting-Doku sind in die linke Sidebar gewandert (immer griffbereit, statt der Self-Service-Kurzfassung; volles Self-Service-Panel bleibt im Basis-Reiter). | ✅ | Client · MED-D-273 | Mandant → Reiter „Mandate"/„Alle Dokumente" + Rail · mandant-auftraege.component.ts/mandant-detail.component.ts | 0.121.0 |
Neuer Mandant als Overlay — „+ Neuer Mandant" (Cockpit-Kopfleiste · Mandanten-Leerzustand · Command-Palette) öffnet die Anlege-Form als Overlay (geteilte md-overlay-Hülle: Scrim + Dialog-Semantik + Fokus-Falle) statt in die Verwaltung zu navigieren. Felder Anzeigename/Nachname/Titel/Vorname/E-Mail/CRM-Link; nach Anlegen lädt die Mandanten-Liste neu + „Öffnen"-Toast in den neuen Mandanten. Server-Endpunkt POST /api/mandanten unverändert. Aus der Verwaltung entfernt. | ✅ | Client · MED-D-271 | Cockpit → „+ Neuer Mandant" · neuer-mandant-overlay.component.ts | 0.121.0 |
Statistiken als eigener Cockpit-Bereich — vierter Cockpit-Modus „Statistiken" (neben Mandanten/Fokus/Leitstand) als wachsender Sammelort für Zahlen & Trends. Erstes Widget: Fragebögen — Statistik & Completion-Flow (DM-9: Trichter Erstellt→Begonnen→Eingereicht + Status-Pillen + offene Zwischenstände), aus der Verwaltung hierher verschoben (G-2). Admin-gated (G-5, praxisbezogene Daten); Nicht-Admins sehen einen Hinweis. Rein Client, vorhandener GET /api/fragebogen/statistik-Endpunkt. | ✅ | Client · MED-D-269 | Cockpit → Modus „Statistiken" · cockpit.component.ts | 0.120.0 |
Mandanten-Liste als Einstieg — der Cockpit-Landing zeigt per Default den Modus „Mandanten": eine durchblätterbare, alphabetische Liste aller Mandanten mit Namenssuche + Filter-Chips Lifecycle-Status (Lead/Onboarding/Aktiv/Ruhend/Archiviert) · Betreuungsmodell (intensiv/standard/basis) · „Zu fakturieren" + Reset; je Zeile Name · Lifecycle · Betreuung · Fortschritt-% (+ offene Fakturierung), Klick öffnet die Akte. Fokus (Aufgabenstrom) und Leitstand (Vorschau) sind eine Umschaltung weiter. Rein abgeleitet aus GET /api/mandanten (kein neues Backend, keine neue Route). Beantwortet True North #1 direkter. | ✅ | Client · MED-D-267 | Cockpit-Landing → Modus „Mandanten" · cockpit.component.ts | 0.119.0 |
DocuSign-Templates ziehen + echte Felder anzeigen — bei der Fremd-Formular-Vorlagen-Registrierung (Verwaltung) wählt der Admin das DocuSign-Template aus einem Dropdown (statt GUID zu tippen) mit Refresh-Button (Lade-Kreisel); bei Auswahl zeigt die App die echten Felder (Tabs) des Templates und matcht sie gegen die Weltmodell-Attribute (✓ erkannt → vorbefüllbar, ⚠ unbekannt → Kunde füllt selbst). Zwei neue Provider-Lesemethoden listeTemplates/templateFelder (DocuSign-Adapter; Fake-Stub für Test), Admin-Routen …/docusign-templates[/:id/felder]. Reine Lese-Aufrufe, kein Envelope. Freitext-GUID bleibt Fallback. Gehärtet (MED-D-263): Templatewechsel bereinigt die auto-erkannten Attribute (nur die tatsächlich neu hinzugefügten, manuelle Auswahl bleibt), veraltete Feld-Antworten werden per monotoner Anfrage-ID verworfen (auch A→B→A), listeTemplates paginiert über nextUri (>2000 Templates), Fehler nennen den DocuSign-Response-Body. +4 Vitest (644→648). Grenze: live gegen echten DocuSign-Account erst beim Testen. | ✅ | Server+Client · MED-D-262/263 | Verwaltung „Fremd-Formular-Vorlagen" · signatur/docusign.ts · verwaltung.component.ts | 0.118.1 |
Selbst-Rollenwahl in der UI (interim, Admin-Bootstrap) — Verwaltung-Karte „Meine Rolle": der eingeloggte Nutzer wählt seine eigene Rolle (berater/backoffice/admin) und schaltet damit die Admin-Sektion (Benutzer & Rollen, Playbooks, Fremd-Formular-Vorlagen, Einstellungen) frei. POST /api/ich/rolle setzt die eigene Rolle bewusst ohne Admin-Guard (bricht den Bootstrap-Deadlock: leere benutzer-Tabelle + kein AUTH_BOOTSTRAP_ADMIN → sonst niemand Admin); append-only auditiert. Interim + als RISK-31 geflaggt (Privilege-Escalation, nur hinter Cloudflare Access vertretbar; Rückbau vorgesehen). Nutzer-Entscheidung „freie Selbst-Wahl". +2 Vitest (642→644). | ✅ (interim) | Server+Client · MED-D-260 (R7/RISK-31) | Verwaltung „Meine Rolle" · app.ts (POST /api/ich/rolle) · verwaltung.component.ts | 0.117.0 |
Hausformular auf ausfüllbare DocuSign-Fassung routen (Kunde füllt in DocuSign → AD-009, MED-OP-FORM-6 Baustein 2) — eine Weg-B-Vorlage (ausfüllbares DocuSign-Template, MED-D-248) lässt sich optional mit einem Hausformular-Dokumenttyp verknüpfen (FremdformularVorlage.dokumenttyp, Migration v49). Ist verknüpft, startet das Versenden eines solchen Hausformulars ohne abgelegte Datei automatisch diese ausfüllbare Fassung statt der flachen PDF (Helper versuchAusfuellbaresTemplate: Prefill aus Stammdaten → anfordernAusTemplate → Identitäts-Mapping am bestehenden Dokument → AD-009-Rücklauf greift; Template-Niveau; PII-arm auditiert). Der Kunde füllt die offenen Felder selbst in DocuSign, seine Eingaben fließen über AD-009 (MED-D-247) zurück. Kein Match → flache PDF bleibt (MED-D-256). Verwaltung-UI: Dropdown „Ausfüllbare Fassung von (Hausformular)". +3 Vitest (637→640). Nicht-Code-Voraussetzung: das echte DocuSign-Template muss angelegt + verknüpft werden, dann greift das Routing live. | ✅ (Baustein 2) | Server+Client · MED-D-257 (MED-OP-FORM-6) | Akte „Unterschriften-Assistent" (Versenden) · Verwaltung „Fremd-Formular-Vorlagen" · signatur-service.ts (versuchAusfuellbaresTemplate) · fremdformular-vorlage-service.ts · Migration v49 | 0.116.0 |
Eigenformular beim Versenden erzeugen + vorbefüllen (Makler-Alleinauftrag & Co.) — wählt der Berater im Unterschriften-Assistenten ein Hausformular ohne abgelegte PDF (z. B. „Makler-Alleinauftrag"), erzeugt der Server die PDF jetzt beim Versenden aus der Vorlage (vorlageFuerBezeichnung → befuelleVorlage aus den Stammdaten → erzeugePdf → Ablage + nextcloudPfad am bestehenden Dokument), dann läuft die Signatur normal — statt des 422 „keine abgelegte Datei". Nutzt die vorhandene R12-Engine (G-1/G-2), reine pure Funktionen + NextCloud-Client, kein neuer Dienst; append-only auditiert (dokument.eigenformular_erzeugt, PII-arm). Echte Fremdformulare ohne Hausvorlage bleiben kein_inhalt. +2 Vitest (635→637). Grenze: die PDF ist eine flache Stammdaten-Tabelle; Kunden-Rücklauf (Anschrift/Geburtsdatum → AD-009) = Weg-B-Fassung (DocuSign-Template), offen als MED-OP-FORM-6. | ✅ (Baustein 1) | Server · MED-D-256 (R12→R4, MED-OP-FORM-6) | Akte „Unterschriften-Assistent" → signatur-service.ts (erzeugeEigenformular) · dokumentvorlagen.ts (vorlageFuerBezeichnung) | 0.115.0 |
DocuSign-Signaturfehler sprechend statt opaker 500 (Live-Bugfix) — beim „Versenden" im Unterschriften-Assistenten reichten die Routen jeden DocuSign-Wurf als unbehandelten 500 durch → generische Toasts „Verbindung zum Server fehlgeschlagen" / „Anfrage fehlgeschlagen". Jetzt prüft SignaturService beim echten Provider vorab (PDF-Bytes/Empfänger) und fängt Provider-Würfe ab: typisierte Gründe → 422 (fehlende Datei „… bitte zuerst eine PDF-Fassung erzeugen/hochladen" bzw. fehlender Empfänger) und 502 (sanitisierter DocuSign-Grund, PII-arm geloggt). Client: Interceptor bevorzugt bei 5xx die Server-Klartextmeldung; der Assistent zeigt den konkreten Grund. Prod-Diagnose (D1): DocuSign läuft (2 signiert/1 gesendet), alle Erfolge mit abgelegter Datei → fileless Dokument = wahrscheinlichster Auslöser. +5 Vitest (628→633). | ✅ | Server+Client · MED-D-254 (OP-SIGN-1) | Akte „Unterschriften-Assistent" · signatur-service.ts · app.ts (signaturFehlerAntwort) · fehler.interceptor.ts | 0.114.1 |
Cockpit-Fokus entschlackt + Mandant-Filter/-Suche + „Zu fakturieren" — die Fokus-Seite („Was ist jetzt zu tun?") wurde aufgeräumt und um gezielten Mandant-Zugriff erweitert. (A) Entschlacken: „Als Nächstes" nach Mandant gruppiert (alle offenen Züge eines Kunden zusammen, restGruppen); „Brennt"-Rail je Mandant eine Zeile (dedupliziert: schlimmster Rückstand + Punkte-Zähler); Kontext-Liste „Offen bei diesem Mandanten" auf 6 gekappt (+N weitere). (1+2) Sichtbare Filterleiste: Mandant-Suche (Freitext) + Kategorie-Chips (5 Offen-Kategorien an/aus) schränken alle Bahnen ein (Tagestakt-Ring bleibt ungefiltert) — löst die zuvor nur in der Command-Palette versteckte Filterung ab; „Zurücksetzen" + eigener Leerzustand. (3) „Zu fakturieren"-Filter: abgeleiteter Wert MandantCockpit.offeneFakturierungMinuten (Summe dauerMinuten je Mandant mit abrechenbar && !abgerechnet, G-2, nicht persistiert); ein Chip listet die Mandanten mit offener abrechenbarer Zeit (meiste zuerst, „Xh Ymin", Absprung in die Akte) → „wo sind Rechnungen offen?" in einem Klick. Echte Rechnung bleibt extern (SevDesk, OP-INVOICE-1; Definition zu bestätigen: MED-KB-12). +1 Vitest (627→628). | ✅ | Server+Client · MED-D-252 | Cockpit „Fokus" · service.ts (offeneFakturierungMinuten) · cockpit.component.ts · styles.css (.mw-fchip) | 0.114.0 |
Akten-Cockpit — Design-System exakt übernommen (Handoff "Akten-Cockpit 1a Detail") — präzise Rekonziliation des gebauten Cockpits (MED-D-188) gegen den finalen Prototyp. LifecycleRing als 5 diskrete SVG-Bögen (statt Conic-Gradient) + Tooltip "Lebenszyklus des Kunden … Schritt N von 5"; Umbenennung "Mandats-Status" → "Lebenszyklus des Kunden" (AD-001, für die Person verbotener Begriff); volles Rail-Stammdaten-Grid (Anzeigename·E-Mail·Telefon·Geburtsdatum·Anschrift·CRM·Bankverbindungen); "Anstehende Aufgaben"-TaskCards + live-rotes "N blockierend"-Pill in die Kontext-Spalte (redundante "Jetzt dran"-Mittelkarte entfernt); direkt editierbare Stammdaten im Overlay ("Speichern → vN", versioniert+auditiert — löst die MED-D-147-Read-only-Sperre auf Nutzerwunsch ab; Server-PATCH um telefon/geburtsdatum/strasse/plz/ort erweitert, Anschrift atomar/G-8); Versions-Pille "Stand: vN · Datum"; VersionedField-Historie "vN · bis Datum · Wert · Quelle"; Design-Wording in Bank/Self-Service/Mandat-Overlay/Unterschriften-Assistent (Schritt-N-von-3, IBAN-Formatvorschlag, Ergebniskarten, CTA-Formularzahl). Compliance-Flag: Steuernummer/Steuer-ID des Prototyps bewusst zurückgestellt (§139b AO/DSGVO → RISK-30/MED-KB-10). Ehrlich deferiert: AD-014-Upload-Liste + AD-006-Empfänger-Feld. +1 Vitest (599→600); tsc(Client+Server)+vitest+ng build+Doku-Check grün | ✅ | Server+Client · MED-D-241 (MED-OP-AKTE-2) | mandant-detail.component.ts · styles.css · versioned-field/-einladungen/-auftraege/-unterschriften-assistent.component.ts · api.service.ts · app.ts · service.ts · app.test.ts | 0.107.0 |
Editierbarer Empfänger im Unterschriften-Assistenten (AD-006) — der Versenden-Schritt hat jetzt ein editierbares Empfänger-Feld (Name + E-Mail), vorbelegt aus dem Mandant-Kontakt (real gebunden); der Berater kann es korrigieren, z. B. auf die zeichnungsberechtigte Person des gewählten Kontos (Hinweis „… bei Bedarf auf diese Person ändern" aus Bankkonto.zeichnungsberechtigt/inhaber). E-Mail für Remote-Versand Pflicht (Button-Disable + Server-400), vor Ort optional. Ein optionaler empfaenger-Override läuft durch alle Schichten (Client → api.service → Routen → SignaturService, Override schlägt den Mandant-Default); der Provider-Vertrag (unterzeichner) trug ihn schon (kein Provider-Change, G-1). Kein neues PII persistiert (nur Versand, G-5/G-6). Löst die in MED-D-241 deferierte AD-006-Deferral auf. MED-D-244-Nachlese (Sicherheit): beide Signatur-Routen tragen jetzt den ladeDokScope-Guard (fremder Mandant → 404, kein Existenz-Leak) — der Empfänger-Override kann kein fremdes Dokument mehr adressieren; vor Ort ohne Empfänger-E-Mail (In-Person eingebettet). +3 Vitest (600→603); tsc(Client+Server)+vitest+ng build+Doku-Check grün | ✅ | Server+Client · MED-D-243/MED-D-244 (löst AD-006, MED-OP-AKTE-2) | signatur-service.ts · app.ts (leseEmpfaenger + ladeDokScope) · mandant-unterschriften-assistent.component.ts · api.service.ts · signatur.test.ts | 0.109.1 |
"Über den Link hochgeladen"-Statusliste (AD-014) — das Self-Service-Panel (mandant-einladungen) zeigt mandantweit die angeforderten/erhaltenen Dokumente der Self-Service-Pipeline: angefordert → "noch kein Upload" (amber-Pill), erhalten → "hochgeladen, zu prüfen" (grün) + Prüfen-Aktion (→ geprüft, propagiert auf Onboarding-Item + LifecycleRing). Löst die in MED-D-241 deferierte AD-014-Liste auf; der Prototyp meint damit angeforderte Dokumente + Upload-Status, nicht je-Token-Uploads. Reine Client-Sicht über die bestehenden Endpunkte api.dokumente + api.dokumentStatusSetzen — keine neue Persistenz/Migration/Public-Endpunkt (G-1/G-2/G-8). ng build + check-doc-consistency.sh grün; 600 Vitest unverändert (getestete Endpunkte) | ✅ | Client · MED-D-242 (löst AD-014, MED-OP-AKTE-2) | mandant-einladungen.component.ts (reuse api.dokumente/dokumentStatusSetzen) | 0.108.0 |
DocuSign-Kern live verifiziert (Demo-E2E + Webhook-Write-back in Prod) — der echte Adapter gegen demo.docusign.net: JWT-Grant+Consent, Envelope real angelegt (c4fe2244…), status/erinnern, Webhook-HMAC-Verify, void-Cleanup — alles grün (MED-D-238). Dabei pkcs8PemToBuffer delimiter-tolerant gehärtet (Session-Demo-Key hatte kaputten PEM-Footer; +1 Vitest). Webhook-Write-back in Produktion belegt (MED-D-239, via Cloudflare-MCP-D1-Query): 2 vollständig durchgelaufene docusign-Vorgänge (Vorgang signiert + Dokument unterschrieben + signierte Fassung in R2 + Audit signatur.signiert); Auslöser = Webhook bewiesen via Audit-actor=system + 54-s-Push-Timing; Endpoint fail-closed (401 ohne HMAC). Der deployte Private-Key ist wohlgeformt. Offen: Prod-Umschaltung für echte Rechtswirkung (Consent/Hosts/DEMO_MODE=false) + AVV/US-Transfer; die embedded-In-Person-Strecke (MED-D-236) selbst noch nicht durchgeklickt | ✅ | Server · MED-D-238/239 (OP-SIGN-1) | signatur/docusign.ts (pkcs8PemToBuffer) · signatur/docusign.test.ts · Verifikation: Cloudflare-MCP D1 + curl | 0.106.2 |
| Mandant/Kunde anlegen & Stammdaten (natürliche Person; optionale Kontakt-E-Mail R1-F12; nach Anlage "Öffnen"-Sprung direkt in die Akte) | ✅ | R1/R1-F12 | Verwaltung · POST /api/mandanten · Migration v24 | 0.2.0 · 0.43.0 |
Onboarding-Grunddaten erweitert, datensparsam (Handynummer · Steuernummer · Steuerberater-Fundament) — 6 neue plain mandant-Felder (Migration v56, Wertobjekte Kontakt/Steuer/Steuerberater): mobile Nummer getrennt vom Festnetz, Steuernummer (NICHT Steuer-ID §139b), Steuerberater-Bezug (Name/Kanzlei/E-Mail/Telefon). Öffentlich auf der Onboarding-Strecke erhoben: nur die eigenen Kundendaten Handynummer + Steuernummer (STAMMDATEN_FELDER). Steuerberater-Felder bewusst NICHT öffentlich (PII einer dritten Person → Art.-14-DSGVO-Gate, RISK-34) — Spalten + ONBOARDING_STAMM_REGELN-Abbildung liegen als Fundament, öffentliche/interne Erhebung folgt mit dem Informationspfad in Slice B. Review-and-apply landet die erhobenen Felder 1:1 am Mandanten (G-4). Datensparsam (G-6): kein Steuer-ID-/Ausweisnummer-Feld — der Personalausweis bleibt Upload-Nachweis. Nicht hash-versioniert (fixe VERSIONIERTE_FELDER-Kette unangetastet). Einwilligungs-Fassung 2026-08-v2. +1 Vitest (→692). Slice A (Fundament); Slice B = Mehrschritt-Strecke + Steuerberater/Art.-14, Slice C = DocuSign-Einverständnis. | ✅ (Slice A — Steuerberater-Erhebung gated) | Server · MED-D-284 | schema.ts+migrate.ts (v56) · domain/{model,einwilligung,stammdaten-uebernahme}.ts · repo/* · Weltmodell-Data-Dictionary | 0.126.0 |
Onboarding-Kundenstrecke als klarer 3-Schritte-Flow (Slice B) — die öffentliche Onboarding-Seite führt statt einer flachen Seite jetzt durch ① Grunddaten erfassen → ② Übersicht „wo fehlt was?" → ③ Einwilligung & Absenden. Schritt ② = abgeleiteter Lücken-Report (G-2): fehlende Pflichtangaben (blockierend, „bitte ergänzen, bevor Sie einwilligen") getrennt von noch offenen optionalen Angaben (empfohlen) + aufklappbare Liste der erfassten Angaben. Schritt-Anzeige mit aria-current/✓, Weiter/Zurück, Zwischenspeichern auf Schritt 1, Absenden erst auf Schritt 3 (Gate unverändert). Beantwortet True North #1 direkter. Reine Client-Umstrukturierung über die bestehenden Endpunkte (kontext/entwurf/einreichen), kein Server-Belang; handynummer→tel-Autocomplete. ng build verifiziert. Offen: interne Steuerberater-Erfassung (Art.-14, Slice B-Rest), DocuSign-Einverständnis (Slice C). | ✅ (Slice B) | Client · MED-D-285 | onboarding-public.component.ts (Stepper) · pub-bausteine.ts | 0.127.0 |
| Onboarding starten (Objektart-Vorlage der ersten Praxis/Gesellschaft → Pflicht-Items, D-45) | ✅ | R2 | Mandant-Detail · POST …/onboarding | 0.2.0 |
S6-Feinschliff: Wording-Zentralisierung (Kunden-Feldmarkierung) — das Enum→Deutsch-Mapping von FeldMarkierung („weiß ich nicht"/„wird nachgeliefert") stand 3× dupliziert (lokale Map in formular-public, hartkodierter Chip-Text in pub-bausteine, Inline-Ternär in mandant-formulare) → eine Quelle MARKIERUNG_LABEL in labels.ts (G-3, analog B33), von allen dreien genutzt. Wertident; tsc/ng build grün. Damit S6-Feinschliff vollständig (mit MED-D-232) | ✅ | Client · MED-D-233 (S6-Feinschliff) | labels.ts · pub-bausteine.ts · formular-public.component.ts · mandant-formulare.component.ts | 0.104.3 |
S6-Feinschliff: Motion-Kurve zentralisiert + Reduced-Motion gehärtet — die Design-Ease-out-Kurve cubic-bezier(0.22,1,0.36,1) steht jetzt als ein Token --mw-ease (statt 6× Literal in styles.css/cockpit.component.ts, G-2); prefers-reduced-motion: reduce schaltet zusätzlich die dekorativen Entrance-Pops/Fades (.mw-card/.mw-cmd/.mw-cmd-overlay/.mw-empty) ab (WCAG 2.3.3). Wertident, kein visueller Unterschied; ng build grün | ✅ | Client · MED-D-232 (S6-Feinschliff) | styles.css · cockpit.component.ts | 0.104.2 |
Echte Vor-Ort-/In-Person-Signatur (DocuSign embedded) — bei echtem DocuSign signiert der Kunde eingebettet auf dem Berater-Gerät (captive/embedded recipient → kein E-Mail-Versand): SignaturProvider.vorOrtVorbereiten (In-Person-Envelope mit clientUserId, Host = Berater via DOCUSIGN_HOST_NAME/_EMAIL) + vorOrtSignaturUrl (recipient view). Der Assistent lädt die Signatur-URL in einen iFrame (sequenziell bei mehreren Dok.), erkennt den signing_complete-Redirect am same-origin-Sentinel /oeffentlich/signatur/vor-ort-fertig → abgleich+Write-back → Dokument erhalten (Prüfung offen, G-4). Behebt den irreführenden 409 („Vor Ort abschließen" gegen echten Provider); Demo-Banner/-Schnellabschluss nur noch beim Fake (istEcht-Gate). Sicherheitsriegel unverändert (echter Adapter ohne abschliessenDemo → Attrappe weiter 409). Host = eingeloggter Berater (MED-D-237: aus akteurVon(c).email+anzeigename, DOCUSIGN_HOST_* = Fallback; für korrekten DocuSign-Audit-Trail G-4 — Voraussetzung: Berater ist DocuSign-Account-Nutzer). +6 Vitest (598). DocuSign-Kern JWT/Envelope/Webhook inzwischen live verifiziert (MED-D-238/239); die embedded-In-Person-Strecke selbst noch nicht durchgeklickt → OP-SIGN-1. | ✅ (embedded-Strecke live-Nachweis offen) | Server+Client · MED-D-236/237 (OP-SIGN-1) | signatur/provider.ts · signatur/docusign.ts · api/signatur-service.ts · api/app.ts · index.ts · mandant-unterschriften-assistent.component.ts · api.service.ts | 0.106.1 |
Fremdformular-Feldmapping & Prefill (AD-010, Weg A — Slice 1) — fremde ausfüllbare PDFs (Bank-/Partner-Formulare wie die apoBank-EDÜ) tragen opake AcroForm-Feldnamen (fill_6…). Der Feld-Editor (Overlay im Unterschriften-Assistenten, löst den MED-D-230-Platzhalter-Toast ab) liest die Felder aus, lässt je Feld ein Weltmodell-Attribut wählen (WELTMODELL_ATTRIBUTE, G-8: person/kontakt/anschrift/bank/praxis) und befüllt das Formular aus den Stammdaten vor (verlustfreie R2-Rückablage, bleibt ausfüllbar). Weg A (Hybrid, G-1): nur das Mapping ist Eigenbau — Füllen via pdf-lib, Signieren via DocuSign. Persistenz = JSON-Spalte dokument.fremdformular_mapping (Migration v46, keine neue Entität, extrahierte Felder abgeleitet/G-2); Routen /api/dokumente/:docId/fremdformular (GET/PUT/POST, eigener RBAC-Guard, PII-arm). +17 Vitest (591); Adapter gegen echtes apoBank-PDF verifiziert. Rücklauf = Slice 2 offen (MED-OP-FORM-5); interaktive UI-Begehung steht aus. | ✅ | Server+Client · MED-D-235 (AD-010/MED-OP-FORM-5) | pdf/pdf-formular.ts · domain/fremdformular.ts · api/fremdformular-service.ts · mandant-feld-editor.component.ts · mandant-unterschriften-assistent.component.ts · api.service.ts · db/{schema,migrate}.ts · repo/* | 0.105.0 |
Akten-Cockpit: Fremdformular-Markierung + Feld-Editor-Hinweisbox (Delta D) — im Prüfen-Schritt (§2.5) wird jedes Dokument als Eigenformular (Bezeichnung = bekannte Vorlage aus DOKUMENTTYP_LABEL) oder Fremdformular klassifiziert (rein abgeleitet, keine neuen Enum-Flags). Fremdformulare tragen eine amber „Fremdformular"-Pill in der Dokumentliste; sind sie ausgewählt, ersetzt eine neutrale Hinweisbox „Im Feld-Editor öffnen →" die (bei unbekannter Feldstruktur nichtssagende) Formular-Vorschau — die Vorschau bleibt nur für Eigenformulare. Kein Eigenbau-Feld-Editor (G-1): der Button meldet ehrlich „folgt mit der DocuSign-Anbindung" (OP-SIGN-1/MED-KB-5). Rein Client; tsc/ng build grün | ✅ | Client · MED-D-230 (Akten-Cockpit-Delta D) | mandant-unterschriften-assistent.component.ts | 0.104.0 |
Akten-Cockpit: Prüfen-Schritt des Unterschriften-Assistenten ausgebaut (Delta C) — Schritt 1 (§2.5) zeigt bei ausgewähltem Dokument jetzt: Pflichtdaten-Checkliste (Name·E-Mail·Anschrift·Geburtsdatum, ✓ „aus Stammdaten"/● „fehlt", abgeleitet; fehlende → Verweis auf Self-Service/Formular, kein Stammdaten-Write wg. MED-D-147-Grenze), SEPA-Konto-Auswahlkarten (nur SEPA-Kontext) + „+ Neues Konto erfassen" via bestehende Bankkonto-Route (gewähltes Konto steuert den SEPA-Write-back), Formular-Vorschau (read-only, was das Dokument befüllt). Rein Client (Assistent lädt Bankkonten selbst, mandant-Input); tsc/ng build grün | ✅ | Client · MED-D-229 (Akten-Cockpit-Delta C) | mandant-unterschriften-assistent.component.ts · mandant-detail.component.ts | 0.103.0 |
Akten-Cockpit: Vor-Ort-Signatur → „erhalten" + geführte In-Person-Strecke + Write-back-Automatik (Slice B) — der Demo-/Vor-Ort-Abschluss landet jetzt (wie Sign-on-Paper) auf erhalten (Prüfung offen) statt unterschrieben/geprüft (Attrappe erzeugt keine rechtsgültige Signatur, G-4/MED-KB-5; gemeinsamer erhaltenAblegen-Helfer, idempotent, Audit signatur.vor_ort_abgeschlossen; echter DocuSign-Webhook-abgleich bleibt auf unterschrieben). Der Assistent führt die In-Person-Strecke (Übergabe → Kunden-Signaturansicht mit „Jetzt signieren" → Danke/Rückgabe → Schritt 3, Vollflächen-Takeover) statt Ein-Klick. Write-back-Automatik bei Abschluss: SEPA-Konto→gültig (ersetzt manuellen Button) + auslösende Aufgabe→erledigt (neuer aufgabeId-Einstieg), best-effort/idempotent, Ergebniskarte. Server-Vitest 571→572; tsc/vitest/ng build grün | ✅ | Server+Client · MED-D-227 (Akten-Cockpit-Delta B) | signatur-service.ts · signatur.test.ts · mandant-unterschriften-assistent.component.ts · mandant-detail.component.ts · labels.ts | 0.103.0 |
Akten-Cockpit: DocumentRow-Zustandsmaschine (AD-008) — die Dokumentzeile ist jetzt zustandsgetrieben statt statisch: fehlt -> „Zur Unterschrift ->" (oeffnet Assistent); offener Signatur-Vorgang -> amber „wartet auf Signatur"-Pill + „Erinnern" + „Signiert hochladen" (Sign on Paper); erhalten/geprueft -> keine Sendaktion; abgelaufen -> roter Chip + „war geprueft . gueltig bis"-Meta. „versendet" wird aus dem offenen Vorgang abgeleitet (G-2, kein neues Feld). Neue Endpunkte POST /api/signaturen/:id/erinnern (Reminder, DocuSign resend / Fake noop) + POST /api/signaturen/:id/signiert-hochladen (Sign on Paper -> Dokument „erhalten"). +8 Vitest, tsc/vitest/ng build gruen | ✅ | Server+Client · MED-D-223 (Akten-Cockpit-Delta A) | mandant-detail.component.ts · api.service.ts · labels.ts · signatur-service.ts · app.ts · signatur/provider.ts/fake.ts/docusign.ts · signatur.test.ts | 0.101.0 |
| Onboarding-Pflicht-Nachweise (Einwilligung Datenverarbeitung · Personalausweis · Kundenfragebogen · SEPA-Mandat · Dienstleistungsauftrag + IBAN privat; Entitäts-IBAN separat je Praxis/Gesellschaft) | ✅ | R2 · MED-D-70 | domain/onboarding-vorlagen.ts (Katalog je objektart) | 0.54.0 |
| Abgeleiteter Onboarding-Fortschritt (G-2) | ✅ | R2 | Cockpit/Detail | 0.2.0 |
| Self-Service-Onboarding per Einladungslink + SES-Einwilligung | ✅ | R2 | öffentl. /onboarding/:token | 0.10.0 |
Öffentliches Lead-Formular (Self-Service ohne Token, Turnstile → Mandant direkt als lead + Entität + Sichtungs-Wiedervorlage) | ✅ | R2 · MED-D-72 · OP-LEAD-1 | öffentl. /lead · GET/POST /oeffentlich/lead · lead-service.ts | 0.55.0 |
| IBANs strukturiert in den Stammdaten (private IBAN am Mandanten + separate Entitäts-IBAN je Praxis/Gesellschaft; normalisiert + Mod-97-validiert) | ✅ | R1 · MED-D-71 | Akte (Aktendeckel + Praxis-Zeile) · PATCH /api/mandanten/:id · PATCH /api/praxen/:id · Migration v30 · domain/iban.ts | 0.55.0 |
| Stammdaten-Versionierung (jede Aktualisierung der Mandant-Stammdaten erzeugt eine append-only, per-Mandant hash-verkettete Version; alte Anschriften/IBAN/Telefon bleiben erhalten; "Stand: vN"-Pille + Verlauf-Expander in der Akte; lückenlos über alle Schreibpfade — Berater/Self-Service/Onboarding — mit Herkunfts-Label; Praxis-Stammdaten + Steuernummer/Steuer-ID als Folge-Slice) | ✅ | R1 · MED-D-179 (G-4) | Akte-Rail · GET /api/mandanten/:id/stammdaten-versionen · Repo-Chokepoint updateMandant/createMandant · Migration v44 + Backfill · domain/stammdaten-version.ts | 0.91.0 |
| Onboarding-Fragebogen zwischenspeichern (wiederaufnehmbarer Entwurf) + Fertigstellungsgrad (live) | ✅ | R2 · MED-D-68 | PUT /oeffentlich/onboarding/:token · Migration v29 · onboarding-public.component.ts | 0.53.0 |
Lifecycle-Status setzen (Lead→Onboarding→Aktiv→Ruhend→Archiv), erstmals mit Guard (Eintritt in aktiv verlangt vollständiges Onboarding + keine offenen Unterschriften, MED-D-151) | ✅ | R1 | Detail · PATCH /api/mandanten/:id | 0.8.0 · 0.83.0 |
| Betreuungsmodell (internes Leistungsversprechen Intensiv/Standard/Basis — neutral, nicht Ampel; nur intern) | ✅ | R1-F11/D-35 | Cockpit (Fokus-Chip · Leitstand-Token/-Verteilung) · PATCH /api/mandanten/:id { betreuungsmodell } | 0.37.0 |
| Mandanten-Pipeline / Board (Liste/Board, Filter, Statuswechsel per Karte; Lanes = Lifecycle-Status, je Karte Auftrag-Status-Chip-Zusammenfassung) | ✅ | R1/UC-6 · MED-D-151 | Cockpit (Board → Verwaltung/Leitstand seit 0.37.0) | 0.16.0 · 0.21.0 · 0.83.0 |
Phasen-Engine + Playbooks (fachliche Prozessphase, POST …/phase) | ✅ abgelöst (MED-D-151, 0.83.0) — PROZESS_PHASE retiriert: grobe Achse jetzt LIFECYCLE_STATUS (Guard s. o.), feine Achse AUFTRAG_STATUS je Beratungsauftrag (Zeile unten); Mandanten-Playbook auf nachfassen@onboarding + jahrescheck@aktiv reduziert, die verwaisten termin/ruecklauf-Einträge leben als Code-Katalog am Beratungsauftrag | R1/§5.1 | domain/lifecycle.ts · domain/auftrag-playbook.ts | 0.19.0 → 0.83.0 |
Mandant = natürliche Person; Praxen/Gesellschaften (0..n) (Mandant ohne Typ; Objekt-Entität mit objektart praxis/mvz/gesellschaft, D-45) | ✅ | R1/R1-F28/D-45 | Anlage (Verwaltung) · Detail (Objektart-Select) · Migration v23 | 0.42.0 |
Praxen/Gesellschaften je Mandant (0..n Praxen/Gesellschaften, Objektart + operativer Typ, Geschäftsjahr-Beginn — Basis Dentmarking/Dexman, D-27/D-45; strukturierte Anschrift strasse/plz/ort als Wertobjekt, Legacy-standort als Read-Fallback, MED-D-87/G-8) | ✅ | R1/D-27 · MED-D-87 | Detail · GET/POST …/praxen · PATCH /api/praxen/:id · Migration v34 | 0.27.0 → 0.60.0 |
Dentmarking-Erhebung + GJ-Jahreswerte (Fragenkatalog v1 · idempotenter Import · Faktentabelle praxis_jahreswert) | ✅ | DM-1/T2, D-27 | Detail (Praxis → "Betriebsdaten") · …/praxen/:id/erhebungen · …/jahreswerte | 0.28.0 |
| Dentmarking-Kennzahlen vs. Benchmark + Potential (18 Kennzahlen · Formel-Varianten alt/korrigiert · Benchmark v1 · Mehrgewinn 25 %-Annahme) | ✅ | DM-2..4/T3 | Detail (Betriebsdaten → GJ-Chip) · GET …/praxen/:id/kennzahlen | 0.29.0 |
| Dentmarking-Gutachten + Befunde (eingefrorener Beleg mit Text-Fassung + R3-Referenz · Befunde → Wiedervorlagen; PDF seit 0.32.0) | ✅ | DM-6/7/T4 | Detail (Betriebsdaten → Gutachten) · …/praxen/:id/gutachten · …/gutachten/:id/befunde · …/befunde/:id/wiedervorlage | 0.30.0 |
Dentmarking-Fragebogen öffentlich (tokenisierter Link je Praxis × GJ · Katalog v1 in 6 Blöcken · DSGVO-Einwilligung Pflicht · Turnstile-Option · Einmal-Einreichung → Erhebung Kanal formular) | ✅ | DM-1/T5 | /fragebogen/<token> (öffentlich) · …/praxen/:id/fragebogen-einladungen · GET/POST /oeffentlich/fragebogen/:token | 0.31.0 |
| Dentmarking-Fragebogen: wiederaufnehmbar + Feld-Datenmodell (Zwischenspeichern/Fortsetzen über denselben Link · 3 Wichtigkeits-Klassen essenziell/wichtig/nice-to-have · gewichteter Ausfüll-Score · Feld-Markierung "weiß ich nicht"/"wird nachgeliefert" · Wertebereiche z. B. Behandler 1–500 · Öffnungszeiten-Raster · prominenter Kopf-Hinweis "mehr/vollständige Daten = aussagekräftigeres Gutachten" + "in mehreren Schritten ausfüllen" (MED-D-83)) | ✅ | DM-9/T6, D-33 · MED-D-83 | /fragebogen/<token> (Live-Score/Marker/Öffnungszeiten · .md-fb-hinweis) · PUT /oeffentlich/fragebogen/:token/entwurf · Migration v19 | 0.35.0 → 0.58.1 |
| Fragebogen-TTL, Ablauf-Hook & Completion-Statistik (TTL max 30 Tage, konfigurierbar in Tenant-Einstellungen · Cron-Ablauf-Hook mit Benachrichtigungs-Seam, Mail-Versand tbd · Statistik-Trichter erstellt→begonnen→eingereicht + offene Zwischenstände im Cockpit) | ✅ | DM-9/T7, D-34 | GET/PUT /api/einstellungen (admin) · GET /api/fragebogen/statistik · Cron · Migration v20 | 0.36.0 |
PDF-Erzeugung (OP-DOCGEN-1/D-28) (pdf-lib im Worker · Blockmodell-Layout · Gutachten- und R12-Dokumente als PDF in NextCloud · Download GET /api/dokumente/:id/datei · Öffnen/PDF-Links) | ✅ | R12/A-7, DM-6 | Detail (Dokumente/Gutachten) | 0.32.0 |
| Playbooks admin-editierbar (persistierter Store + Editor) | ✅ | §5.1/R7 | Cockpit (Admin) · /api/playbooks | 0.20.0 |
Akten-Cockpit — Self-Service-Link-Kurzfassung + Onboarding-4-Tasten-Umschalter (Design-Import via claude_design-MCP, Projekt "Mandanten-Akte verbessern", Mockup "Akten-Cockpit 1a (Detail)"). Linke Rail: Self-Service-Link-Karte (Status-Pill · Link · Kopieren/In-Stammdaten-übernehmen/Neuen-Link-Button), liest das bestehende <md-mandant-einladungen>-Signal per viewChild statt eigenem Zweit-Fetch (G-8). Onboarding-Items: 4-Tasten-Umschalter (Geprüft/Da/Nötig/Später) ersetzt das 5-wertige Dropdown — frontend-only über dem bestehenden ItemStatus (offen/angefordert teilen sich "Nötig"), keine Schema-Änderung. Bewusst NICHT übernommen: Tab-Split "Basis-Informationen"/"Praxen" (würde die frühere Merge-Entscheidung revidieren), Mandate-Detail als Modal statt Inline, der im Mockup selbst display:none gesetzte Aktenreife-Ring (bereits MED-D-164 descoped); übrige Register unverändert (ihre md-*-Klassen sind über .mw-scope auf dieselben Tokens gemappt wie mw-*). Gegen echte Seed-Daten via wrangler dev + Playwright verifiziert (Klick → Status + Fortschritt ändern sich server-seitig, danach zurückgesetzt) | ✅ | Client · MED-D-170 | mandant-detail.component.ts | 0.88.0 |
Akten-Cockpit-Redesign S1 — IA-Fundament & Overlay-Shell (erster Bau-Slice des Redesign-Programms MED-D-188, Handoff "Akten-Cockpit 1a (Detail)"). Reiter 6→5: Basis-Informationen (Standard-Tab; Jetzt-dran + Onboarding + Self-Service) · Mandate · Alle Dokumente · Fristen & Aufgaben · Praxen (eigener Reiter — löst die in MED-D-170 zurückgestellte Tab-Split-Entscheidung ein). Generische Overlay-Shell (.mw-scrim/.mw-overlay-panel, akte-patterns §2.4; ESC + Scrim-Klick schließen): Stammdaten und Zeiterfassung sind jetzt Overlays (geöffnet über "bearbeiten →" bzw. den Timer-Link "Erfasste Zeiten öffnen →") statt Nav-Reiter. LifecycleRing-Avatar (5-Segment-Conic-Ring, ringGradient()) ersetzt die flache Fortschrittsleiste. Mandat-/Assistent-Overlay bewusst zurückgestellt (Assistent = S5). tsc + ng build grün | ✅ | Client · MED-D-191 (MED-OP-AKTE-2) | mandant-detail.component.ts · styles.css | 0.92.0 |
Akten-Cockpit-Redesign S2 — Dokument-Zustandsmaschine (zweiter Bau-Slice, UI-Mapping ohne Server-/Enum-Change). Neue wiederverwendbare Komponente StatusSlider (md-status-slider, akte-patterns §2.1): dreiwertiger Pillenschalter Fehlt·Erhalten·Geprüft — ersetzt die vom Design verbotenen Wörter "Nötig"/"Da". An den Onboarding-Items (+ neue RequirementCheckbox: erforderlich ↔ entfällt, "vorerst nicht erforderliche" ans Ende unter Trenner, Slider aus) und an den Ablage-Dokumenten (ersetzt das Status-<select>; abgelaufen → roter Chip). Fortschritt zählt nur Erforderliches (bereits serverseitig, domain/progress.ts). Zu S5 verschoben (Assistent-abhängig): versendet/wartet-auf-Signatur-Pill, "Zur Unterschrift →", Fremdformular. tsc+ng build grün | ✅ | Client · MED-D-192 (MED-OP-AKTE-2) | status-slider.component.ts (neu) · mandant-detail.component.ts · styles.css | 0.93.0 |
Akten-Cockpit-Redesign S3a — 1:n-Bankkonten (Backend) (dritter Bau-Slice, Server-Hälfte von S3; hebt die frühere Zurückstellung MED-D-179 auf). Neue Entität Bankkonto (R1-F33): Inhaber · IBAN (normalisiert) · Zeichnungsberechtigung · zwei getrennte Achsen Prüfstatus (neu/geprüft/archiviert) + sepaGueltig · Praxis-Kontext (oder null=privat). Kein Löschen — Archivieren via Prüfstatus (append-only, G-4). Domain/Schema/Migration v45 (Tabelle + UNIQUE-Index quell_schluessel) / Repo (memory+d1, CRUD) / BankkontoService (auditiert, PII-arm) / Routen (GET/POST /api/mandanten/:id/bankkonten, PATCH /api/bankkonten/:id). Verlustfreier, crash-/nebenläufigkeitssicherer Backfill aus den Alt-Feldern mandant.ibanPrivat/praxis.iban (stabiler quellSchluessel + UNIQUE-Index + ON CONFLICT DO NOTHING; Alt-Felder zwei-phasig lesbar, kein DROP). Live gegen wrangler dev/miniflare verifiziert (Migration + Backfill angelegt:2, idempotent, CRUD + Validierung). BankRow-UI (Swipe-to-Archive) folgt als S3b. +12 Vitest; tsc+vitest grün | ✅ | Server · MED-D-195 (MED-OP-AKTE-2) | model.ts · enums.ts · schema.ts · migrate.ts · repo/* · index.ts · bankkonto-service.ts (neu) · app.ts · bankkonto.test.ts (neu) | 0.94.0 |
Akten-Cockpit-Redesign S3b — BankRow-UI (Swipe-to-Archive) (vierter Bau-Slice, UI-Hälfte von S3; schließt S3 ab). Neue wiederverwendbare Komponente BankRow (md-bankrow, akte-patterns §2.6) im Stammdaten-Overlay: je Bankkonto eine Zeile mit Inhaber · Kontext (privat/Praxis) · IBAN in 4er-Gruppen · Zeichnungsberechtigung; zwei getrennte Bedien-Achsen (Prüfstatus-Slider Neu/Geprüft + SEPA-Toggle). Swipe-to-Archive (Pointer-Drag über Schwelle → archivieren, Undo-Toast) + dezenter Desktop-/Tastatur-Archivieren-Button (Maus-Workflow, MED-D-193) + Peek-Teach (einmalig beim Overlay-Öffnen). Archivierte Konten schreibgeschützt/gedimmt unter Trenner — kein Löschen (append-only, G-4). "+ Konto"-Formular (Inhaber/IBAN/Kontext). ApiService bankkonten/bankkontoAnlegen/bankkontoAendern. Reine Client-Anbindung an die S3a-Routen (kein Server-Change). Live gegen wrangler dev + Playwright verifiziert (11/11: Render, Slider, SEPA, Anlegen, Desktop-Archiv, Swipe-Geste, append-only, 0 Konsolenfehler) | ✅ | Client · MED-D-196 (MED-OP-AKTE-2) | mandant-bankrow.component.ts (neu) · mandant-detail.component.ts · api.service.ts · styles.css | 0.95.0 |
Akten-Cockpit-Redesign S4 — VersionedField (Feld-Historie) (fünfter Bau-Slice; §2.7). Neue wiederverwendbare Komponente VersionedField (md-versioned-field) im Stammdaten-Overlay: je versioniertes Feld (Anzeigename · E-Mail · Telefon · Geburtsdatum · Straße/PLZ/Ort atomar · CRM) aktueller Wert + vN-Pille (Version der letzten Änderung) → aufklappbare Feld-Historie genau dieses Feldes (Wert/Zeit/Herkunft je Version, in der sich das Feld änderte). Historie client-seitig aus den bereits geladenen MED-D-179-Snapshots abgeleitet (kein Zweit-Fetch, G-2); stammVersionen eager geladen. Versions-Pille auch im Overlay-Kopf (Stand: vN). Ersetzt das read-only Feld-Grid. §2.8 Self-Service als erfüllt bewertet (Link-Verwaltung = MED-D-170; hochgeladene Dokumente im Reiter "Alle Dokumente"). Reine Client-Anbindung, kein Server-Change. Live gegen wrangler dev + Playwright verifiziert (9/9: Kopf-Pille, Feldhistorie v3/v2, unveränderte Felder ohne Pille, 0 Konsolenfehler) | ✅ | Client · MED-D-197 (MED-OP-AKTE-2) | versioned-field.component.ts (neu) · mandant-detail.component.ts · styles.css | 0.96.0 |
Akten-Cockpit-Redesign S5 — Unterschriften-Assistent (sechster Bau-Slice; §2.5; Server+Client). Neue Komponente UnterschriftenAssistent (md-unterschriften-assistent) als Overlay: 3 Schritte Prüfen · Versenden · Verfolgen + Vor-Ort-Strecke, eIDAS-Slider (SES/AES/QES, automatisch aus der Rechtsmatrix je Dokumenttyp oder manuell), Sammel-Umschlag (mehrere Dokumente client-seitig gebündelt), Frist → Wiedervorlage, durchgehend sichtbarer Attrappe-Hinweis (Demo gegen Fake-Provider, MED-KB-5). Einstiege: DocumentRow (⋯), Dokumente-Tab, BankRow "SEPA einholen" (setzt SEPA gültig bei Abschluss). Server: Vor-Ort-/Demo-Abschluss (SignaturProvider.abschliessenDemo? nur am Fake → echte Vorgänge nie fälschbar; vorOrtAbschluss + Route, 409 bei echtem Provider) + Niveau-Override; Write-back via bestehenden abgleich-Pfad (seit MED-D-227 landet Vor-Ort auf erhalten/Prüfung offen statt unterschrieben/geprüft; Ablage, Audit). +5 Vitest (552). Live gegen wrangler dev + Playwright verifiziert (9/9). Deferiert: versendet/nicht_erforderlich-Enum (S2-Entscheidung), auto SEPA-/Wiedervorlage-Verknüpfung. Echte DocuSign/PandaDoc + E-Mail = OP-SIGN-1/OP-DM-8 (später) | ✅ | Server+Client · MED-D-198 (MED-OP-AKTE-2) | mandant-unterschriften-assistent.component.ts (neu) · signatur-service.ts · provider.ts · fake.ts · app.ts · mandant-detail.component.ts · mandant-bankrow.component.ts · api.service.ts | 0.97.0 |
Akten-Cockpit-Redesign S6 — TaskCard (Feinschliff; Design vollständig) (letzter Slice; §2.9). Die Fristen-&-Aufgaben-Zeilen sind jetzt TaskCards mit Fälligkeits-Dringlichkeit: linke Akzent-Kante (rot=überfällig · amber=bald ≤7 Tage · neutral · grün=erledigt) + überfällig/bald fällig-Badge. Signatur-/SEPA-/rücklauf-bezogene offene Aufgaben bekommen den "Im Unterschriften-Assistenten →"-Einstieg (schließt die letzte Design-Kante TaskCard→Assistent). Reiner Präsentations-Feinschliff (bewusst kein Sub-Komponent — alle Bedienelemente erhalten). Damit sind alle 10 akte-patterns-Komponenten gebaut → das Akten-Cockpit-Redesign (MED-D-188) ist vollständig. Live gegen wrangler dev + Playwright verifiziert (9/9) | ✅ | Client · MED-D-199 (MED-OP-AKTE-2 ✅) | mandant-detail.component.ts · styles.css | 0.98.0 |
Konsistenz & Kundenstrecken-Politur (UX-Welle 11 Slice 3; App-Audit B33/B34/B32a — schließt MED-OP-UX-10 ab). B33 (G-8, eine Sprache): vier lokale Enum-Label-Maps nach labels.ts zentralisiert (Stammdaten-Herkunft, Artefakt-Typ, Offen-Kategorie, Bankkonto-Prüfstatus); der AuftragStatus heißt jetzt überall aus einer Quelle — Langform in der Akte ("in Beratung"), abgeleitete Kurzform im Leitstand ("Beratung"), statt zweier divergierender Vokabeln. B34 (Kundenstrecken): Consent-Checkboxen aller vier öffentlichen Strecken auf 24×24px-Touch-Ziel (WCAG 2.5.8); Absende-/Speicher-Fehler werden jetzt rot (statt amber-Warnoptik) und als role="alert" angesagt; die Turnstile- Script-Ladelogik ist entdoppelt (pub-bausteine.ts), die bewusste Turnstile-Ausnahme des rechtsverbindlichen Ausfüll-Formulars ist als Entscheidung dokumentiert. B32(a): die Status-Farbpalette deckt außerhalb des dunklen Akte-Scopes jetzt dieselben Stufen ab (kein farbloser "erhalten"-Status mehr). Reine Client-Änderung, live verifiziert (Leitstand-Chip via zentrales Label, Consent 24×24px, 0 Konsolenfehler) | ✅ | Client · MED-D-216 (MED-OP-UX-10 ✅) | labels.ts · cockpit/mandant-auftraege/mandant-bankrow/mandant-detail · lead/onboarding/fragebogen/formular-public · pub-bausteine.ts · styles.css | 0.99.12 |
Design-Handoff-Import + Pixel-Fidelity-Pass der Akte (MED-D-218/219). Der claude.ai/design-Handoff „Akten-Cockpit 1a (Detail)" liegt jetzt im Repo (docs/design/akten-cockpit-handoff/: verbindliche Spec akte-patterns.md, Pixel-Prototyp .dc.html, Screenshots 01–17) — die Pixel-Abnahme-Referenz, die im App-Audit noch fehlte; die Design-Entscheidungen (AD-001…AD-015) sind in docs/produkt/Design-Entscheidungen-Akte.md eingearbeitet. Fidelity-Pass: die live-Akte Pixel-für-Pixel gegen die Quelle abgeglichen, 8 Abweichungen behoben — BankRow-Motion auf die Design-Kurve (cubic-bezier(.22,1,.36,1)) + Peek-Plateau, IBAN .8rem, SEPA-Pill „ohne gültiges SEPA" in Amber, „‹"-Wisch-Chevron, Unterschriften-Assistent-Overlay 720px/z-70, Signaturniveau-Default SES, VersionedField-Toggle als „⟲ N frühere Werte"-Text-Link. 5 bewusste Divergenzen dokumentiert (u. a. DocumentRow-Send-Aktionen an die kommende DocuSign-Anbindung gekoppelt). Reine Client-/Doku-Änderung, live verifiziert (Computed-Styles + 0 Konsolenfehler) | ✅ | Client · MED-D-218/219 | styles.css · mandant-bankrow/versioned-field/overlay-shell/mandant-unterschriften-assistent/mandant-detail.component.ts · docs/design/… · docs/produkt/Design-Entscheidungen-Akte.md | 0.99.13 |
DocuSign-HTTP-Adapter (erster echter E-Signatur-Provider, OP-SIGN-1). Hinter der bestehenden SignaturProvider-Abstraktion spricht DocuSignSignatur die DocuSign-eSignature-REST-API direkt via fetch (das Node-SDK läuft nicht auf Cloudflare Workers). Auth = JWT Grant (RS256 in-Worker über WebCrypto/crypto.subtle, PKCS#8-Key erzwungen, Token-Cache). Envelope-Flow: anfordern lädt die Dokument-Bytes aus der Ablage (R4→R3), base64→Envelope mit Signer=Mandant + signHere-Tab + eventNotification; status fragt den Envelope ab und lädt bei Abschluss die kombinierte signierte Fassung (/documents/combined) in den bestehenden abgleich-Write-back. Connect-Webhook POST /oeffentlich/signatur/docusign-webhook (Push statt Pull; X-DocuSign-Signature-1 per HMAC-SHA256 konstant-zeit verifiziert, fail-closed ohne Key → 401; Pull-abgleich bleibt Fallback). QES→AES mit sichtbarem Hinweis (Dev-Account-Grenze). Sicherheitsriegel: kein abschliessenDemo → vorOrtAbschluss 409 (echte Vorgänge nie fälschbar). Dormant ohne Secret (docuSignKonfigAusEnv→null → Fallback fake/503; deploy-sicher). Nicht live verifiziert (kein Dev-Secret/Netz in der Build-Sandbox) — +10 Vitest gegen gemocktes fetch; Scharfschalt-Runbook Deploy.md §7d | 🟡 (gebaut, nicht live) | Server · MED-D-220 (OP-SIGN-1) | signatur/docusign.ts (neu) · signatur/docusign.test.ts (neu) · signatur/provider.ts · api/signatur-service.ts · api/app.ts · index.ts · repo/*.ts | 0.100.0 |
A11y-Restmeile: Tastatur-Reiter + vorgelesene Fehler + AA-Kontrast (UX-Welle 11 Slice 2; App-Audit B29–B31). B29: die 5 Akten-Reiter sind jetzt eine echte WAI-ARIA-Reiterleiste — role="tablist" + Beschriftung, roving tabindex und Pfeil-/Pos1-/Ende-Tastatur-Navigation (Reiterwechsel ohne Maus, Fokus wandert mit); role="tabpanel"/aria-controls bewusst nicht gesetzt (Reiter-Inhalt ist über mehrere [hidden]-Sektionen verstreut → kein 1 Panel je Reiter, ein einzelnes Panel wäre falsche ARIA). B30: role="alert" ergänzt außerhalb des Akten-Kerns — öffentliche Submit-Fehler (Lead/Onboarding/Fragebogen/Formular), der Audit-Trail-"Nachweis unvollständig" und die Dentmarking-/Verwaltungs-Fehler werden Screenreadern beim Erscheinen angesagt. B31: Light-Theme---mut (Sekundärtext) von #7c8a7e (~3,6:1) auf #5f6d62 (5,45:1, WCAG AA erfüllt) abgedunkelt. Reine Client-Änderung, live verifiziert (tablist + roving tabindex + ArrowRight/Home; --mut 5,45:1; 0 Konsolenfehler) | ✅ | Client · MED-D-215 (MED-OP-UX-10) | mandant-detail/lead-public/onboarding-public/fragebogen-public/formular-public/verwaltung/mandant-dentmarking/mandant-druckansicht.component.ts · styles.css | 0.99.11 |
| Peripherie-Ehrlichkeit: ehrliches Feedback an den Rändern der App (UX-Welle 11 Slice 1; App-Audit B27/B28). B27: der Unterschriften-Assistent meldet einen Teil-Fehlschlag beim Sammel-Versand jetzt ehrlich als "X von Y versendet — Rest fehlgeschlagen" (statt Totalausfall) und überführt die bereits versendeten Dokumente in den Verfolgen-Schritt. B28: die Druck-/Export-Akte, die Verwaltung und die Dentmarking-Betriebsdaten zeigen bei Ladefehler jetzt ein barrierefreies "… möglicherweise unvollständig / Erneut versuchen"-Banner statt still unvollständiger Daten (True North #2/#3). Reine Client-Änderung, live verifiziert (Route-500 → Banner, sauberer Load ohne Banner) | ✅ | Client · MED-D-213 (MED-OP-UX-10) | mandant-unterschriften-assistent/mandant-druckansicht/verwaltung/mandant-dentmarking.component.ts | 0.99.9 |
Latest-Load-Guard gegen überlappende Akten-Ladungen (CodeRabbit-Nachlese zu #245). mandant-detail#laden() feuert bei jeder Mutation neu; ein spät eintreffender Alt-Batch konnte frische Daten überschreiben oder den Ladefehler-Hinweis nach erfolgreichem Retry wieder aufblenden. Ein ladeGeneration-Zähler sorgt jetzt dafür, dass nur die jüngste Ladung wirkt. Deterministisch live verifiziert (Alt-Batch-500-Straggler nach Retry blendet das Banner korrekt nicht wieder ein). Zusätzlich: MED-D-145-konformer Straight-Quote-Sweep in CHANGELOG/Feature-Liste | ✅ | Client · MED-D-210 | mandant-detail.component.ts | 0.99.8 |
B26-Restschuld (substanziell): tab-übergreifende Nebendaten-Ladefehler + Lesetext-Floor (App-Audit B26-Rest, Nutzer-Wahl "Substanzielle Reste"). Sub-Loader: die letzten vier still schluckenden Loader der Akte (Dokument-Erzeugungen/Freie Dokumente/Zeit-Übersicht/Aufträge) zeigen bei Fehlschlag jetzt ein tab-übergreifendes "… konnte nicht geladen werden. Erneut versuchen"-Banner (role="alert") statt still unvollständiger Daten. Lesbarkeit: sechs echte Lesetext-Stile unter 0,7rem auf einen 0,7rem-Floor (≥11px) gehoben — Glyphen in fixen Boxen (Monospace-Quadrate/Avatar-Initialen) und dekoratives Brand-Micro-Type bleiben bewusst kompakt. Reine Client-Änderung, live verifiziert (auftraege-500 → Banner+Retry; Lesetext = 11,2px; 0 Overflow) | ✅ | Client · MED-D-209 (App-Audit B26) | mandant-detail.component.ts · styles.css | 0.99.7 |
B26-Aufräum: Leitstand-Lesbarkeit + sichtbare Nebendaten-Ladefehler + Waisen-Schutz (App-Audit B26-Teilmenge). B8: die Auftrag-Status-Chips im Leitstand-Lane-Kopf laufen nicht mehr aus dem 208px-Kopf, sondern kappen mit … (Volltext im Tooltip) — das offen-Label bleibt sichtbar. B18-Rest: scheitert der Bankkonten-/Praxen-Load, zeigt das Stammdaten-Overlay jetzt ein barrierefreies "… konnte nicht geladen werden. Erneut versuchen"-Banner statt "keine Konten". bdAnlegenUndBinden: scheitert das Verknüpfen nach dem Anlegen, wird neu geladen + ein Hinweis zeigt, wie man die (bereits angelegte) Doku nachbindet — keine stille Waise. Reine Client-Änderung, live verifiziert (392px-Chip → 0 Lane-Kopf-Overflow; Route-500 → Banner+Retry) | ✅ | Client · MED-D-208 (App-Audit B26) | cockpit.component.ts · mandant-detail.component.ts · mandant-auftraege.component.ts | 0.99.6 |
Welle-10-Abschluss-Politur: Farbregeln, sprechende Enums, Label-Drift, Kundenstrecken (UX-Welle 10 Slice 5; App-Audit B21–B25). B21: md-status-erhalten/-fehlt-Pillen bekommen eine Farbregel (blau/rot statt farblos-grau). B22: Onboarding-Item-Kategorie (ONBOARDING_KATEGORIE_LABEL) + Dok-Status im Unterschriften-Assistenten (DOKUMENT_STATUS_LABEL) zeigen jetzt Klartext statt roher Enums. B23: beratungsdoku.geprüft-Audit-Label ergänzt; MODELL_LABEL (cockpit) als Alias auf BETREUUNG_LABEL (kein Drift). B24: Fragebogen-Consent-* → (Pflicht); Turnstile-Callback-Cleanup in Onboarding-/Fragebogen-Strecke; formular-public bewusst ohne Turnstile (begründete Ausnahme). B25: stale In-Code-Kommentare nachgezogen. Reine Client-/Doku-Änderung, live verifiziert (Klartext-Pillen; erhalten=blau/fehlt=rot; 0 Konsolenfehler). Damit ist die Welle 10 (B14–B25) vollständig | ✅ | Client · MED-D-207 (MED-OP-UX-9) | styles.css · labels.ts · cockpit/fragebogen-public/onboarding-public/mandant-unterschriften-assistent/mandant-detail.component.ts | 0.99.5 |
A11y-Abschluss der Akte: Touch-Ziele ≥24px + vorgelesene Fehlertexte (UX-Welle 10 Slice 4; App-Audit B16/B19). B16: StatusSlider-Segmente, SEPA-/Prüfstatus-Schalter, Archivieren-Button und vN-Historien-Pille erreichen jetzt das 24×24px-Touch-Ziel (WCAG 2.5.8) — Optik bleibt kompakt, nur die Trefferfläche wächst. B19: der Lifecycle-<select> ist per aria-describedby mit seinem Fehlertext verknüpft, und alle dynamischen Fehler-Absätze der Akte tragen role="alert" (Screenreader liest sie beim Erscheinen vor). Reine Client-Änderung, live verifiziert (Touch-Höhen = 24px; Guard-Fehler wird angesagt + verknüpft) | ✅ | Client · MED-D-206 (MED-OP-UX-9) | styles.css · mandant-detail.component.ts | 0.99.4 |
Sichtbare Ladefehler in den Akte-Panels (UX-Welle 10 Slice 3; App-Audit B18). Die Register-Panels (Self-Service-Onboarding, Gesprächsnotizen, Ausfüll-Formulare, Beratungsaufträge) schluckten Ladefehler bisher still als "keine Daten". Jetzt zeigt jedes Panel bei Fehlschlag ein barrierefreies Banner (role="alert") "… konnte nicht geladen werden. Erneut versuchen" mit Retry-Button — statt einen echten Leerstand vorzutäuschen. Einheitliches ladeFehler-Signal-Muster; das role="alert" ist zugleich eine Down-Payment auf B19. Reine Client-Änderung, live verifiziert (erzwungenes 500 → Banner + Retry recovern) | ✅ | Client · MED-D-205 (MED-OP-UX-9) | mandant-einladungen/-meetings/-formulare/-auftraege.component.ts | 0.99.3 |
Ehrliches Playbook-Feedback beim Lifecycle-Wechsel (UX-Welle 10 Slice 2; App-Audit B15, True North #2). Konnte der Server nach einem Status-Wechsel die Standard-Wiedervorlage nicht anlegen (playbook_fehler, best-effort), meldete die App bisher trotzdem Erfolg. Jetzt trägt die PATCH-Antwort ein transientes playbookFehler-Flag; der Toast warnt bei true (… — ⚠ Standard-Aufgabe konnte nicht angelegt werden, "Rückgängig" bleibt), und die Verlaufs-Zeile bekommt ein ⚠-Präfix. Kleiner Server-Anteil (Flag im Ergebnis + Route) + Client-Toast/Label. +1 Vitest (553). Server-vertraglich + live verifiziert | ✅ | Server+Client · MED-D-204 (MED-OP-UX-9) | service.ts · app.ts · mandant-detail.component.ts · api.service.ts · labels.ts | 0.99.2 |
Overlay-Shell + Dialog-Barrierefreiheit (UX-Welle 10 Slice 1; App-Audit B14/B20). Neue wiederverwendbare AkteOverlayComponent (md-overlay) bündelt alle vier Akte-Overlays (Stammdaten · Zeiten · Signatur · Mandat) zu einem Bauteil mit echter Dialog-Semantik: role="dialog"/aria-modal/aria-label, Initial-Fokus ins Panel, Fokus-Falle (Tab bleibt im Overlay), Fokus-Rückgabe an den Auslöser, ESC. Ersetzt 4× dupliziertes Scrim/Panel/Kopf-Markup. Nebenbei: Mandat-Overlay-Kopf angeglichen (B2), doppelte ESC-Mechanik entfernt (B3), Mandat-Overlay reflowt auf Mobile — Schließen-Knopf wieder erreichbar (B17). Reine Client-Änderung. Live A11y-verifiziert (6/6: dialog-Attribute, Fokus-in/-Rückgabe, Tab-Falle über 40 Tabs, 0 Konsolenfehler) | ✅ | Client · MED-D-202 (MED-OP-UX-9) | overlay-shell.component.ts (neu) · mandant-detail.component.ts · mandant-auftraege.component.ts · styles.css | 0.99.1 |
Mandat-Overlay — Mandate-Reiter als kompakte Liste + Detail-Overlay (4. Design-Overlay, im Redesign-Slice S1 zunächst zurückgestellt, dann gebaut (MED-D-200) — seit MED-D-202 auf der geteilten AkteOverlayComponent; akte-patterns "Mandat-Overlay"). Der Mandate-Reiter zeigt jeden Beratungsauftrag nun als kompakte Zeile (Produkt · Praxis · Reife-Pille · Status-Pille · "Öffnen →") statt als lange ausgeklappte Karte; Klick öffnet die vollständige Auftrags-Akte im Scrim-Overlay (Stand-Select · Reife · inline-Beratungsdoku · Rahmendaten · Artefakte · Meta) — gleiches .mw-scrim/.mw-overlay-panel-Muster wie Stammdaten-/Zeiten-/Signatur-Overlay, ESC/Scrim-Klick schließt. Flacker-frei: In-Place-Reload hält das Overlay über Mutationen offen. Reine Client-Restrukturierung, kein Server-Change, keine Extraktion. Damit sind alle 4 Design-Overlays gebaut. Live gegen wrangler dev + Playwright verifiziert (9/9) | ✅ | Client · MED-D-200 (MED-OP-AKTE-2) | mandant-auftraege.component.ts | 0.99.0 |