HANDOFF — Medidentas

Zuerst lesen. Kompakter Gesamtstand + offene Punkte für jede neue Session. Danach docs/fachlich/Lastenheft.md (Master-Spec) und docs/konventionen/agents.md (Way-of-Working).

Erzeugt aus handoff.d/ — nie von Hand editieren (MED-D-359; Standard: drkv-com/everything-as-code-template docs/GitHub-Arbeitsweise.md §BP-2). Eine Session legt ihren §2-Block als handoff.d/<YYYY-MM-DD>-<branch-slug>.md an (neueste zuerst). Kopf/§1 = handoff.d/_kopf.md; Stand-Absatz + §3–§6 = handoff.d/_fuss.md (nur ändern, wenn sich der Stand wirklich ändert). Neue offene Punkte sind GitHub-Issues, keine neuen §4-Zeilen.

1. Was ist Medidentas?

Plattform zur Koordination des Kunden-Lebenszyklus eines beratungs-/vermittlungsnahen Betriebs: Kundenonboarding · Dokumenten-Verwaltung (NextCloud) · Unterschriftenverwaltung (DocuSign/PandaDoc) · Wiedervorlagen · Beratungsdokumentation. Leitgedanke: Standardwerkzeuge anbinden statt nachbauen (G-1); der Eigenwert liegt in der Orchestrierung und der lückenlosen, rechtssicheren Dokumentation.

True North: (1) Wo steht der Kunde im Prozess? (2) Was ist offen und fällig? (3) Ist alles vollständig & rechtssicher dokumentiert?

2. Aktueller Stand (neueste Einträge zuerst; Version: beim Deploy gestempelt, höchster Tag `v<semver>`)

#840 (2026-10-25): Öffentliche Token-Routen sind rate-limitiert (120 je Token, 300 je IP, 10 Minuten). Die Grenzwerte sind Annahmen; nach dem ersten Betrieb an rate_limit.gesperrt im Audit prüfen (Deploy.md §7e-2).

MED-D-831-2 (2026-10-25): #831 geschlossen; kein Schritt 2 (Ausfüllformular/Onboarding/Dexman-Monatsmeldung bewusst ohne Auswertungs-Stand).

MED-D-703 (2026-10-23): onboarding-public ist für neue Kunden abgelöst: Das Portal liefert die Standard-Kataloge (Angebot "onboarding"), sobald sie zugeordnet und einsatzbereit (Texte freigegeben) sind; bis dahin bleibt die alte Einladung. Hebel zum Umschalten: Zuordnung in der Verwaltung. Offen: Probelauf mit Testkunde, Rate-Limiting der Token-Routen (#840).

MED-D-660-3 (2026-10-23): Stundensätze und offener Betrag sind netto (Auftraggeber per Dialog); UI beschriftet "netto". Offen bleibt nur das Pflegen der Sätze in der Verwaltung.

MED-D-831 (2026-10-23): Auswertungs-Stand je Fragebogen, Schritt 1 gebaut (Dentmarking-Kennzahlen + Fragenkataloge, Kundenseite und Kunden-Detail). Offen (#831): Schritt 2 für Ausfüllformular, Onboarding-Stammdaten und Dexman-Monatsmeldung.

Mandats-Unterlagen-Matrix komplett (#832): Ankreuzen, Abwählen und Umbenennen je Zeile; Einstellungen mit einem Speichern-Knopf. Keine offenen Punkte.

Link-Gültigkeit (#739) gebaut: nach dem Deploy sind alle bestehenden Ausfüll-Formular- und Ablage-Upload-Links abgelaufen und müssen vom Berater einmalig erneuert werden („Link erneuern“ in der Akte). Offen: Rate-Limiting/Turnstile der Token-Strecken; Ablösung der Einzel-Links durch das Portal.

Katalog-Go-Live (Entscheidung 2026-10-18): Texte vorläufig freigeben und Kataloge live bringen — Ablauf und Voraussetzungen in docs/architektur/Onboarding-Texte-Freigabe.md („Go-Live“), Risiko RISK-40. Die Schritte 1–4 macht ein Admin in der Produktion; Blocker für rechtswirksame Unterschriften bleibt OP-SIGN-1 (DocuSign-Produktion + AVV).

MED-D-413 (2026-10-18): Kunden-Gruppe als Klammer gebaut (Migration v82, Panel "Gruppe" in der Akte). Offen: gemeinsamer Gruppenordner für geteilte Dokumente (#801).

MED-D-773/775 (2026-10-18): Audit-Aktionen-Katalog erzeugt (python3 scripts/audit_katalog_bauen.py nach neuen Audit-Aktionen ausführen; Doku-Check warnt sonst). Doku-Site ohne tote Links, onBrokenLinks: 'throw'. Offen: Aufbewahrungsfrist je Aktion nicht belegt (#773).

MED-D-425 (2026-10-18): "Warum?"-Texte als Entwürfe gebaut (Migration v88). Offen: Betrieb muss die Texte je Fragebogen in der Verwaltung prüfen und freigeben; Teil (b) "auswertungsgetriebener Ausfüllgrad" nicht gebaut.

MED-D-811 (2026-10-18): Gruppenart, Archivieren und Pflicht-Unterlagen gebaut (Migration v87). Offen: Welche Unterlagen je Gruppenart Pflicht sind, ist nicht festgelegt — Listen starten leer und werden in der Verwaltung gepflegt.

MED-D-801 (2026-10-18): Gemeinsamer Gruppenordner gebaut (Migration v84) — Kunden-Gruppierung #413 damit komplett. Offen: Löschen/Ersetzen gemeinsamer Dateien gibt es bewusst nicht (append-only); bei Bedarf eigenes Issue.

FK-4 Vollmachten (Beispieltexte) gebaut: drei neue Kataloge; die Beispieltexte müssen vor Live durch den echten Wortlaut ersetzt (Verwaltung → Textbausteine → Bearbeiten), geprüft und freigegeben werden. Weiter offen: Bedeutung von pma (unbelegt), Signatur-Niveau je Vollmacht (vorläufig SES).

MED-D-812 (2026-10-18) — „Akte" entfernt, „Aktenreife" → „Vollständigkeit" (#812, version:patch). Sichtbare Begriffe: „Kunde" + „Mandat". Route jetzt GET /api/vollstaendigkeit, Domain kunden-vollstaendigkeit.ts. Historische Logs behalten den Alt-Wortlaut. Offen: Full-Stack-E2E (e2e:fullstack:ci) läuft in der CI.

MED-D-804/805 (2026-10-18): shared/dexman-kern/lnk.ts: beitragspflichtigeEinmalzahlung und agKostenEinmal (§ 23a Abs. 3/4 SGB IV, Vorschlag), angeschlossen in rechne() (Sammeleintrag ÷ n, Rückfall Pauschale bei fehlenden Grenzen); PraxisDaten.unfallJahresbeitrag (Reiter Parameter), in rechne() je Monat 1/12 bei angestellten Personen. Offen: Bestätigung der Rechenregel durch den Steuerberater (Text nicht am Wortlaut geprüft; Abs. 2 und 5 nicht abgebildet), RISK-38 (#806). Die Dexman-Reihe aus #709/#710/#790 ist damit fachlich vollständig.

Mandats-Unterlagen-Matrix gebaut: Verwaltung zeigt Unterlage × Produkt als Ankreuz-Matrix (gleiche Vorlagen-API wie MED-D-630). Offen: Umbenennen einer Unterlage über alle Produkte hinweg (derzeit nur Neuanlage/Abwählen).

apoBank-Stammnummer (#779) gebaut: Migration v83, Katalog apobank_edue v2 (neue Fassung — bestehende Bestätigungen bleiben an v1; apoBank-Vorlage ggf. neu laden nicht nötig). Neu: Rückschreiben von Katalog-Antworten per Review-and-apply in der Akte. Vor Live: Datenschutzhinweise um die Stammnummer ergänzen (RISK-39).

Widerrufsbelehrung (#777) gebaut: neuer Textbaustein widerrufsbelehrung muss vor dem Live-Gang eingespielt (Verwaltung → „Aus Datei laden“) und von der Geschäftsführung freigegeben werden; ohne Freigabe und ohne Kunden-E-Mail kann der Katalog einwilligung_lastschrift nicht bereitgestellt/bestätigt werden. Anhänge sind ≤ 5 MiB je Mail (Cloudflare Email Service).

Kundenentscheidungen 2026-10-16 (Welle 1 #718 ✅, Welle 2a ✅): MED-D-404/417/660–667/687 — Details je Issue. Bau-bereit: #687 (klein), #413 (Gruppierung), #660 (Stundensätze + Betrag). Vor dem Bau Compliance klären: #665 Ausweis-Felder + #666 Steuer-ID (Weltmodell, Rechtsgrundlage, Löschfrist, RISK-30), #404 GwG-Status bestätigen lassen, #664 AVV DocuSign + Bestätigungstext, #663 Zweckbindung schriftlich. Offen: #667 Person/Praxis-Bezug und Buchungsbeginn; Welle 2b schriftlicher Fragenkatalog (#669 · #668 · #414 · #425), 2c Dexman (#424 · #374 · #375) — Plan #757.

MED-D-660 (2026-10-16): Stundensätze + Betrag gebaut (Migration v81). Offen: Sätze in der Verwaltung für alle Berater pflegen (sonst "ohne Stundensatz"); Netto/Brutto des Satzes ist nicht festgelegt.

MED-D-687 (2026-10-16): Praxis-Pflicht für Dentmarking/Praxisfinanzierung/Abrechnungsberatung/Praxisnachfolge gebaut (Katalog-Flag). Offen: Bestands-Mandate dieser Produkte ohne Praxis in der Kundenakte nachziehen (Hinweis "Praxis zuordnen" erscheint dort automatisch).

MED-D-749 (2026-10-16): SPA-Fallback gibt bedingte Header nicht mehr an den Asset-Layer weiter (kein 304 → 404 mehr beim Neuladen einer Client-Route). Offen: nach dem Deploy einmal F5 auf einer Akte in Produktion gegenprüfen (das Verhalten hinter Cloudflare Access war nie verifiziert); #754 Bundle-Budget; Kachel „Umsatz vs. Prognose"/„Top-Reserve"; #726; #713.

MED-D-774 (2026-10-16): Doku-Audit Doku-Review-2026-10.md (Bezugspunkt v0.164.1); B61–B64 behoben. Offen: B65 Katalog der Audit-Aktionen (#773, erzeugen statt pflegen) · B67 tote Links der Doku-Site (#775) · nächster Doku-Audit spätestens bei v0.174.x bzw. nach 90 Tagen.

MED-D-754 (2026-10-16): Start-Bundle von 1,00 MB auf ca. 548 kB — alle Routen außer dem Cockpit sind lazy (loadComponent); Budget-Warnung jetzt ab 700 kB, Fehler ab 1 MB. Merke für neue Seiten: immer loadComponent, nur das Cockpit bleibt statisch. Beim ersten Öffnen einer Akte lädt ihr Chunk nach (ca. 57 kB übertragen) — Vorladen (PreloadAllModules) bewusst nicht aktiviert, damit öffentliche Kundenseiten nichts Überflüssiges ziehen.

MED-D-764 (2026-10-16): Dexman-Kachel um „Umsatz vs. Plan" und die Wirkung der größten Reserve ergänzt (DEX-5 damit vollständig). Offen: Schwellen 5 %/15 % und die Auslegung „Top-Reserve = größte Wirkung" sind Annahmen → Bestätigung durch den Auftraggeber (#764, Label fachliche-bestätigung).

MED-D-710 (2026-10-16): Kassen-/Privatleistungen je Monat (Ist-Tabelle, dexman.leistung.kasse/.privat), Radio-Buttons für Bezugsbasis und Verzug der Kasse in Kompass und Klassisch (DexmanAnnahmenComponent), Rechenkern rechne() mit eingabe.leistungsmix/eingabe.annahmen. Beachten: Die Umsatzbeteiligung folgt jetzt der Bezugsbasis; Praxen mit erloesModus = zuflussbasiert sehen dadurch andere Personalkosten als vorher. Offen: Portal-Monatsmeldung kennt Kasse/Privat noch nicht (nur Berater erfassen); Verzug nur als Auswahl 0/3/4/5/6 (Praxis-Wert bleibt wählbar), kein freies Feld; die Wahl der Radio-Buttons wird nicht gemerkt (Reload = Praxis-Einstellung); Slice 3 (Mitarbeiterfelder) wartet weiter auf die Entscheidung zu den KV-Feldern (Art. 9, Aufbewahrung, RISK-38).

MED-D-790 (2026-10-16): Portal-Monatsmeldung um beteiligung.<personId> (Wert laufend;sonstiger Bezug) und leistung (Wert kasse;privat) erweitert (DexmanMonatsmeldungService, Portal-Komponente md-portal-dexman-meldung, Berater-Sichtung in md-dexman-ist); Sichtung je Feld, Annehmen schreibt die Fakten aus MED-D-709/710 mit Quelle portal. Fehler behoben: gespeicherte Werte wurden mit der Eingabe-Schreibweise gelesen (Cent-Beträge). Härtung: Annehmen im festgeschriebenen Monat → 409 (Umsatz eingeschlossen). Offen: § 23a SGB IV (sonstige Bezüge), Unfallversicherung (Form), Art.-9-Einordnung/Aufbewahrung (RISK-38), die Portal-Aufgabe erscheint weiter nur, solange der Berater die Umsätze nicht selbst erfasst hat (Beteiligung/Kasse allein löst keine Aufgabe aus).

MED-D-709 Slice 5 (2026-10-16): DexmanEingabe.beteiligungIst (BeteiligungIst: Person, Zuflussmonat, Lohnart, Betrag), Speicherung als dexman.beteiligung.laufend.<id>/.sonstig.<id> in praxis_jahreswert (Quelle berater), Dienst beteiligungErfassen, Route PUT /api/dexman/praxen/:id/beteiligung/:monat, Oberfläche md-dexman-beteiligung im Reiter Ist-Umsätze. Laufender Betrag ersetzt die Planung des Monats (auch 0); sonstiger Bezug nur als Auszahlung ohne Arbeitgeberanteile (Hinweis in Ergebnis.agKosten.hinweise). Offen: § 23a SGB IV (sonstige Bezüge, mit dem Steuerberater), Erfassung durch den Praxisinhaber über das Kundenportal (Monatsmeldung kennt Beteiligung nicht), Änderungshistorie nur im Audit (ein Wert je Person/Monat/Lohnart, wie die Ist-Umsätze), Unfallversicherung (Form offen), Art.-9-Einordnung/Aufbewahrung (RISK-38).

MED-D-709 Slice 4 (2026-10-16): rechne() nutzt agKostenMonat über eingabe.lnkParameter (Worker: stand() liefert sie aus lnk_parameter); Pauschale agAufschlag nur als Rückfall (keine Parameter, oder je Monat bei fehlendem Wert). Ergebnis.agKosten (Modus, Draft, unbelegt, Lücken, Hinweise), Anzeige im Reiter Personal (md-dexman-ag-kosten). Migration v80 ergänzt satz_kv_zusatz_durchschnitt (2,9 % ab 2026-01, BAnz AT 10.11.2025 B7). Beachten: Sammeleinträge tragen anzahlPersonen (Beispiel "ZFA-Team": 4), die Grenzen gelten je Person; Unfallversicherung ist 0 (Hinweis, Form des BG-Beitrags offen, keine belegte Prozentzahl); Sachsen gilt je Praxis. Nächster Slice: (5) Ist-Beteiligung je Monat und Lohnart (§ 23a SGB IV für sonstige Bezüge mit dem Steuerberater klären). Offen: Art.-9-Einordnung/Aufbewahrung (RISK-38), Zusatzbeitrag 2027 (BMG-Bekanntmachung), Rechengrößen 2027 (Bundesrat).

MED-D-709 Slice 3 (2026-10-16): Anstellung um beschaeftigungsart, kvStatus, kvZusatzbeitrag, pkvAgZuschuss, umlageU1/umlageU2 erweitert (alle optional, Vorgaben beim Speichern normalisiert), PraxisDaten.pvSachsen; Formular in dexman-baustein-form.component.ts (zweite Zeile je Zeitraum, nur Status angestellt). Nächste Slices: (4) Anschluss an rechne.ts (Pauschale agAufschlag ablösen, Parameter aus dem Repo statt LNK_SEED), (5) Ist-Beteiligung je Monat/Lohnart. Offen: Art.-9-Einordnung und Aufbewahrungsfrist der KV-Felder (RISK-38) vor Produktivnutzung; Sachsen-Zuordnung (Praxis vs. Mitarbeiter) und Form des Unfallversicherungs-Beitrags (nicht gebaut); kvZusatzbeitrag = null bedeutet "Durchschnitt aus der Verwaltung" (greift erst mit Slice 4).

MED-D-735 (2026-10-15): Dexman-Empfehlung → Vorschlag für die Beratungsdokumentation (R6), Berater entscheidet (übernehmen/ändern/verwerfen mit Grund/umgesetzt). Löst DEX-HV-1 (#735). Offen: DEX-HV-5 Cockpit-Kachel (#737, Option 1 gewählt — Kernaussage der Lage + Link, Beratungsmodus/Anzeige-Raster mitdenken); #749 (SPA-Fallback 404 bei bedingtem Neuladen, vor Fix in Produktion mit F5 auf einer Akte prüfen); #726 (CodeRabbit-Check grün ohne Review, bewusst vertagt).

MED-D-737 (2026-10-15): Dexman-Kachel in der Kundenakte (DEX-5, #737): Lage je Praxis ohne Klick; Beratungsmodus jetzt app-weit. Offen: „Umsatz vs. Prognose" und „Top-Reserve" als eigene Ampel-Zeilen der Kachel (Spezifikation DEX-5); das Start-Bundle liegt knapp über der Warnschwelle von 1 MB (Issue #754) — Kachel ist deshalb lazy; #749 (SPA-Fallback 404, vor Fix F5 in Produktion prüfen); #726.

MED-D-709 Slice 1+2 (2026-10-15): Rechenkern shared/dexman-kern/lnk.ts, Parameter-Persistenz lnk_parameter (Migration v72) + API + Verwaltungs-Karte; rechne.ts rechnet weiter mit der Pauschale agAufschlag. Nächste Slices: (3) Mitarbeiterfelder in der Anstellungs-Spanne + Praxisfelder, (4) Anschluss an rechne.ts (Pauschale ablösen, Parameter aus dem Repo statt LNK_SEED), (5) Ist-Beteiligung je Monat/Lohnart, (6) Kassen-/Privat-Monatseingabe + Radio-Buttons (#710). Offen: Umlagebasis, Übergangsbereich (volle AG-Sätze) und Sachsen-Zuordnung (Praxis oder Mitarbeiter) sind Annahmen im Code-Kommentar; sonstiger_bezug (§ 23a SGB IV) nicht gerechnet; Rechengrößen 2027 sind Kabinettsbeschluss (Bundesrat steht aus, als Draft im Seed), Zusatzbeitrag 2027 wartet auf die BMG-Bekanntmachung, Minijob-KV-Pauschale 17,5 % ab 2027 unbelegt; Datenschutz der KV-Felder (Art.-9-Einordnung, Aufbewahrung, RISK-38) vor Slice 3 klären. Alle Startwerte 2026 sind an amtlichen Quellen belegt (belegt: true). Hinweis: LNK_SEED (Kern) und der Seed in Migration v72 müssen übereinstimmen (Test migrate-v72.test.ts); Änderungen der Startwerte gehören in die Verwaltung oder eine neue Migration.

Portal-Freischaltung (2026-10-14, #677): Turnstile-Widget angelegt, Sitekey in wrangler.toml (dieser PR). Reihenfolge: (1) Deploy → GET /oeffentlich/portal/config nennt den Sitekey; (2) TURNSTILE_SECRET im Worker setzen (nie vor Schritt 1); (3) in der Access-App „Medidentas App Onboarding" app.medidentas.com/portal* ergänzen (/oeffentlich* ist dort bereits im Bypass); (4) Absender-Domain medidentas.com im Cloudflare Email Service onboarden (Dashboard). Offen: Schritte 2–4, danach Testlauf „Portal-Zugang einrichten → Magic-Link → Dashboard".

MED-D-726 (2026-10-14): Die fünf Review-Befunde zu MED-D-690 sind behoben (Fokus-Rückgabe, gemeinsamer Formular-Reset, pxFehler-Verwurf beim Öffnen, --card statt --panel2, tote CSS-Regeln) — mit Regressionstest. Offen bleibt die Ursache: der Pflicht-Check CodeRabbit meldet auch dann grün, wenn das Review am Rate-Limit abbrach (Issue #726, drei Handlungsoptionen: Spending Cap · Merge-Drosselung · Gate schärfen). Am 2026-10-14 betraf das 8 von 11 gemergten PRs. Bis das entschieden ist, bei Merge-Wellen damit rechnen, dass ungereviewter Code durchgeht.

MED-D-718 (2026-10-14): Kundentermin Welle 1 vorbereitet — Agenda #718 (#664 · #404 · #665 · #663 · #660 · #687). Offen: Termin vereinbaren; danach Ergebnisse je Issue nachtragen und umsetzen; Welle 2 (13 Punkte) planen. CodeRabbit-Review bleibt best effort (bei Rate-Limit Status trotzdem grün, Auftraggeber 2026-10-14). App-Audit veraltet → #713.

2026-10-14 — Dexman: Person + Anstellungs-Zeitspannen · Performance-Tabelle mit Festschreiben (MED-D-693/694)

Auftrag: „Die Mitarbeiter sollen als Person angelegt werden; die Gehälter etc. sind dann Zeitspannen, sodass wir viel einfacher Veränderungen und Ein-/Austritte verwalten können." + „Die Performance pro Mitarbeiter soll tabellarisch eingegeben werden — ältere Zeilen (Monate) sollen gesperrt werden können (festschreiben)." Drei Weggabelungen per Rückfrage entschieden (Spannen-Umfang · Speicherform · Festschreib-Semantik).
Was (MED-D-693): shared/dexman-kern/person.ts ist die eine Stelle für Person + Spannen (personDaten mit Read-Fallback auf die Alt-Form, anstellungIn, eintritt, austritt, personRahmen, verschiebeAbschnitte). PersonDaten = Identität + abschnitte[]; rechne()/findeHebel() fragen die je Monat gültige Spanne; pruefeBaustein('person', …) validiert die Spannen und leitet gueltigAb/gueltigBis daraus ab. Formular mit Spannen-Tabelle (Zeitraum anfügen/entfernen), Personal-Übersicht mit „Status heute" + Zeiträume-Zahl, Planungsereignisse aus den Spannen.
Was (MED-D-694): Monats-Tabelle in dexman-ist.component.ts (nur geänderte Monate werden gesendet), dexman_festschreibung (Migration v69) als append-only Log, festschreiben/festschreibungAufheben/ festschreibungsLog im Dienst, Guard in istErfassen (409), neue Fähigkeit dexman_festschreibung_aufheben in der R7-Matrix, Routen POST …/festschreiben, POST …/festschreibung/aufheben, GET …/festschreibung; stand liefert festgeschriebenBis + darfAufheben.
Abgrenzung: keine neue Entität für Praxis-Personal (bleibt Dexman-lokal, G-6) · keine Daten-Migration (Alt-Form wird gelesen) · Lohnsteuer-/SV-Rechnung weiter außen vor (OP-DEX-9) · Festschreiben greift heute für die Berater-Erfassung; Portal-/PVS-Wege laufen später durch denselben Guard.
Offen (Dexman): Monatsmeldung im Kundenportal (DEX-1a Stufe 1) · Excel-Import (DEX-13) · Bank/PVS (#373/#374) · Behandler-Vergleich (OP-DEX-4) · Cockpit-Kachel (DEX-5) · Empfehlungs-Rückmeldung in die Beratungsdoku R6 · Beratungsmodus-Widerspruch Doku↔Code (Systementwurf §4.7).
Geprüft: Server tsc + npm test grün (888 Tests / 72 Dateien), Client-Build grün, gemockte E2E 52/52, Full-Stack-E2E 18/18 (Tabelle + Festschreiben + 409 + Spannen gegen echte D1/R2), Doku-Konsistenz-Check ohne Hinweise.
Review-Nachlese (#688): main eingemergt (Konflikte in rechne.ts, e2e/dexman.spec.ts, Test-Uebersicht.md; main's Personen-Testhelfer auf Spannen portiert, Monatsbericht auf den 12-Monats-Bezug umgestellt). Zwei CodeRabbit-Befunde behoben: Berichtsmonat nur für abgeschlossene Monate des Planungszeitraums (sonst 400, kein Dokument/Audit) · Doku-Check 10 liest nur die Katalog-Tabellen in §10.5. Nicht re-queued: der PR trägt seit dem zweiten Commit MED-D-693/694, die noch kein Review gesehen haben — Auto-Merge/Queue entscheidet der Auftraggeber.

MED-D-736 (2026-10-14): Dexman-Beratungsmodus rundet Beträge auf 100 € (nur Anzeige) — löst den Doku↔Code-Widerspruch aus Issue #736 / DEX-HV-4 zugunsten der Doku. Offen: DEX-HV-1 (Empfehlung → Beratungsdoku R6, #735) und DEX-HV-5 (Cockpit-Kachel, #737); Hinweis für Cockpit-Kachel: Beratungsmodus und Anzeige-Raster mitdenken.

MED-D-701 (2026-10-14): docs/betrieb/Test-Uebersicht.md ist erzeugt — Fragmente in test.d/, Gesamtzahlen gemessen (scripts/testzahlen_messen.py, statisch, kein Testlauf). Damit ist der letzte handgepflegte Hot-File der Doku weg (Issue #701, Anlass: #691 ließ MED-D-672/674/677 still verschwinden). Offen: nach dem Merge prüfen, dass der Nachzieh-Ablauf die Zahlen stempelt (neuer Schritt in dokumente-nachziehen.yml, zusätzliche Pfad-Trigger auf *.test.ts/*.spec.ts).

MED-D-730/731 (2026-10-14): Mailkanal im Audit an allen Sendepfaden (4 ergänzt, 3 hatten ihn schon); Dentmarking-Ablauf-Hook und Wiedervorlagen-Zuweisung fangen Adapterfehler ab und halten zustellung im Audit; Portal-Wartezeit hängt an der abgeschickten statt der aktuell eingetippten Adresse. Offen: #731 Punkt 2 (Wartezeit je Adresse als Map) bewusst nicht umgesetzt.

MED-D-699/700 (2026-10-14): Dexman zeigt Plausibilitäts-Hinweise zur Planung (Rate unter Zinsen, Ist außerhalb der Beschäftigung, Ist ohne Plan); die Praxis meldet die Ist-Umsätze des Vormonats im Kundenportal, der Berater sichtet je Wert (Quelle portal). Offen: Personaländerungen in der Monatsmeldung (DEX-1a nennt sie, hier noch nicht); Hinweis "Zahlen anfordern" der Monatsaufgabe könnte auf das Portal verweisen; Rechtsgrundlage für Umsatz je Behandler (Beschäftigtendaten) bleibt in #658.

MED-D-709/710 (2026-10-14): Konzept (nur Doku) für AG-Kosten je Mitarbeiter und Monat sowie Kassen-/Privat-Zufluss in Dexman, Data Dictionary §3.2b. Offen: Primärbelege für AV 2,6 %, PV 3,6 % (SGB XI § 55) und Hälftung RV/AV (Volltext gesetze-im-internet.de war nicht abrufbar); Minijob-KV-Pauschale 17,5 % ab 2027 unbelegt; Werte 2027 (Rechengrößen, Zusatzbeitrag) noch nicht recherchiert; Rechenregel für sonstiger_bezug (§ 23a SGB IV, Steuerberater); Art.-9-Einordnung und Aufbewahrungsfrist der KV-Felder (RISK-38); Praxis- vs. Mitarbeiter-Zuordnung der Sachsen-PV-Regel und Form des Unfallversicherungs-Beitrags. Nächster Schritt: Umsetzung im Rechenkern + Verwaltung (Slices: Parameter-Entität → Mitarbeiterfelder → Rechenkern → Ist-Beteiligung → Radio-Button-Auswertung).

2026-10-14 — Konzept Onboarding über Fragenkataloge (MED-D-703)

Was: Konzeptdokument docs/architektur/Onboarding-Fragenkataloge.md aus den Standard-Onboarding-Formularen (Kundendaten-Erfassungsbogen, Lastschrift/SEPA, apoBank, Vollmachten) und den Nutzerentscheidungen.
Entschieden: Fragenkatalog je Altformular · Delta nur in der Abfrage · Nachweise am Kunden · Ablauf-Aufgabe 1 Monat vorher · Steuernummer/Steuer-ID als Eingaben · ein DocuSign-Vorgang je Katalog (V1) · Vollmachten als Plattform-Textbausteine.
Bausteintexte: Pflege in der Verwaltung, Startvorlagen aus den PDF. Kontaktsteuerberater: privat getrennt + je Praxis, Datenübernahme angeboten.
Abschnittsfreigabe als Standard-Prüfung; Fallback „Ausdruck + eigenhändige Unterschrift" für Fremdformulare ohne E-Signatur.
Offen: #704 (juristische Freigabe der Standardtexte, Vollmachtstexte fehlen), #707 (apoBank-Akzeptanz DocuSign).
Code-Abgleich + Slice-Plan S0–S9 im Konzept (§9/§10). Nächster Schritt: S0 (Weltmodell-Attribute) → S1 → S2 → S3.
S0a (Dictionary): Steuer-ID, Familienstand, Kinder (nur Vorname + Geburtsmonat/-jahr, Zweck Beratung und Prognose) als Stammdaten entschieden (Nutzer); Steuerberater zusätzlich je Praxis. G-6-Begründung offen: #715. S0b (Persistenz: Migration v73, Hash-Schema 4, Repo, Schutz-Test anpassen) folgt.
S0b-1 ✅ (gebaut): Mandant steuerId + familienstand (Migration v73, Hash-Kette Schema 3 unverändert, STAMM_ZIELE, Weltmodell-Attribute); Server 872/872 Tests, tsc grün. Offen/Nächster Schritt: S0b-2 (Steuerberater je Praxis, Kinder 1:n Vorname + Geburtsmonat), dann S1. Client-Typ Mandant (api.service.ts) noch ohne die neuen Felder; Live-Gate: G-6-Begründung #715.
S0b-2 ✅ (gebaut): praxis.steuerberater* + Tabelle mandant_kind (Migration v74, domain/kind.ts, Repo Memory+D1); Server 880/880 Tests, tsc grün. D1-Pfad (Migration v74 + D1Repo) bisher nur typgeprüft — Full-Stack-E2E läuft in der CI ab „Ready for review". Nächster Schritt: S1 (Feld: Bedingung, Wiederholungsgruppe, Rolle Kunde/Berater, Berechnungsfeld).
S1 ✅ (gebaut): shared/feld-kern/ + feld.ts-Erweiterungen + PubFeldEngine (Bedingungen, abgeleitete Felder); Server 895/895, Client-Build grün, gemockte E2E 46/46. Alle Erweiterungen optional → Bestands-Schemas unverändert. Offen: Rechenregeln der Rechenblätter (3 %, 50 %, Faktoren) fachlich bestätigen; Gruppen-Rendering + E2E-Spec mit S3. Nächster Schritt: S2 (Katalog-Entität + Zuordnung Beratungsangebot → Kataloge, FormularVorgang Status bestätigt/signiert).
S2 ✅ (gebaut): KatalogVorgang + KatalogService + Zuordnung angebot_katalog (Migration v75); Server 911/911, tsc grün. Abweichung vom Plan: eigene Entität statt FormularVorgang-Erweiterung (siehe Konzept §10). D1-Pfad (v75 + D1Repo) nur typgeprüft, Full-Stack-E2E in der CI. Annahme zu bestätigen: Bestätigung verlangt Pflichtangaben beider Rollen. Nächster Schritt: S3 (Delta-Berechnung, Routen, Kundenansicht in formular-public, Bestätigung mit E2E-Spec).
S3 ✅ (gebaut): Delta-Ansicht, Routen (öffentlich/Berater/Verwaltung), Kundenseite katalog-public; Server 922/922, gemockte E2E 51/51, ng build grün. Offen: Berater-Oberfläche (Akte) + Verwaltungs-Oberfläche für die Zuordnung, Übernahme in Stammdaten (Review-Weg), Gruppen-Vorbelegung (Kinder), Link-Ablauf/Rate-Limiting (RISK-39), Full-Stack-E2E mit S9. Nächster Schritt: S4 (Katalog-PDF als Ausgabe + ein DocuSign-Vorgang je Katalog, Write-back → signiert).
Link-Gültigkeit ✅ (Nutzervorgabe): Katalog-Link 14 Tage absolut, Erneuern rotiert den Token, 410 ohne Daten, nach Abschluss nur Status (Migration v76). Rest der öffentlichen Flächen als Issue #739 (Entscheidung offen: Ausfüll-Formular ohne Ablauf, Upload-Link mit optionalem Ablauf).
S4 ✅ (gebaut, Ausgabeart Bestätigungsblatt): Unterschrift je Katalog über den bestehenden Signatur-Dienst, Rückweg per Hook; Server 941/941, gemockte E2E 53/53. Zu entscheiden: Signatur-Niveau je Katalog (niveauFuer würde ‚Vollmacht‘ auf QES setzen); DocuSign-Live nicht getestet (nur Fake). Nächster Schritt: S5 (Nachweise katalogübergreifend mit Ablauf → Aufgabe 1 Monat vorher), S6 (Textbausteine + Kontaktsteuerberater-Erfassung), S7 (Fremdformular + Fallback eigenhändig), S8, S9.
S5 ✅ (gebaut): Nachweise am Kunden (Migration v77), Aufgabe 1 Monat vor Ablauf, Katalog-Integration, Berater-Routen; Server 953/953, gemockte E2E 53/53. Annahmen zu bestätigen: Meldebescheinigung ohne Ablauf; Nachweise blockieren die Bestätigung nicht; Personalausweis-Dokument heißt künftig „Personalausweis (Vorder- und Rückseite)“ nur bei Neuanlage (Altdokument behält seine Bezeichnung). Offen: Berater-Oberfläche (Anfordern/Ablaufdatum), Ablaufdatum aus Upload/Ausweis erfassen. Nächster Schritt: S6 (Textbausteine + Kontaktsteuerberater-Erfassung), dann S7, S8, S9.
S6 ✅ (gebaut): Textbausteine (Migration v78) + Ausgabeart Textbaustein + Verwaltungs-Oberfläche + Kontaktsteuerberater (privat/je Praxis, Übernahmeangebot); Server 976/976, gemockte E2E 57/57, ng build grün. Wichtig: es liegen keine Rechtstexte im Repo — die Texte aus den PDF werden über die Verwaltung eingespielt und müssen freigegeben werden (#704); Vollmachtstexte fehlen noch. Offen: Steuerberater-Oberfläche in der Akte, Startvorlagen einspielen, Katalog FK-4 (S9). Nächster Schritt: S7 (Fremdformular als Ausgabeart + Fallback eigenhändige Unterschrift), S8 (Abschnittsfreigabe), S9 (Standard-Satz).
S7 ✅ (gebaut): Fremdformular als Ausgabeart (pdfMapping, Vorlage in der Ablage, Hash eingefroren) + Fallback Ausdruck/„Original erwartet“ (Wiedervorlage, keine Migration); Server 986/986, gemockte E2E 58, ng build grün. Offen: echte apoBank-PDF hochladen + 15 fill_n-Felder mappen (S9), Berater-Oberfläche für Ausdruck/Original, Akzeptanz DocuSign bei der apoBank (#707). Nächster Schritt: S8 (Abschnittsfreigabe), S9 (Standard-Kataloge FK-1…FK-4).
S8 ✅ (gebaut): Sichtung je Abschnitt (Migration v79), Sammelfreigabe über alle Kataloge eines Kunden, Ablehnung mit Grund je Feld (öffnet den Katalog), Gate vor Unterschrift/Ausdruck; Server 993/993, gemockte E2E 59, ng build grün. Annahmen zu bestätigen: Unterschrift erst nach vollständiger Freigabe; Freigabe gilt nur für den jeweiligen Katalog-Vorgang. Offen: Berater-Oberfläche (Sichtung, Ausdruck, Zur-Unterschrift, Steuerberater, Nachweise), Mail bei Ablehnung. Nächster Schritt: S9 (Standard-Kataloge FK-1…FK-4; braucht #704-Texte und die apoBank-PDF).
Berater-Oberfläche ✅ (gebaut): Panel „Fragenkataloge“ in der Akte (Reiter Basis): Bereitstellen, Link, Sichtung je Abschnitt, Rückgabe mit Grund, Unterschrift/Ausdruck/Original erhalten, Wieder öffnen. Noch ohne Oberfläche: Berater-Antworten (Rolle Berater) erfassen, Nachweise anfordern/Ablaufdatum, Kontaktsteuerberater in der Akte, Katalog-Zuordnung zu Beratungsprodukten (nur Angebot ‚onboarding‘ wird angezeigt), Scan des Originals dem Katalog zuordnen. Nächster Schritt: S9.
BU-1 ✅ + S9-Texte: Akte-Panels Nachweise (anfordern, Ablaufdatum) und Kontaktsteuerberater (privat/je Praxis, Übernahmeangebot); Statusdokument Onboarding-Texte-Freigabe.md (alle Texte ⛔ nicht freigegeben). Offen: Antworten T-Q1…T-Q7, Wortlaut der Vollmachten (T-4…T-7), juristische Freigabe (#704); danach S9 (Kataloge FK-1…FK-4 anlegen). Noch ohne Oberfläche: Berater-Antworten erfassen, Katalog-Zuordnung zu Produkten, Scan→Katalog.
S9 Teil 1 ✅: Kataloge kundendaten, einwilligung_lastschrift, sepa_mandat registriert; Server 997/997. Zum Live-Gang nötig: Wortlaute T-1…T-3 in der Verwaltung einspielen und freigeben (#704); Kataloge dem Angebot ‚onboarding‘ zuordnen (Verwaltung); T-Q1/T-Q2 klären. Offen: FK-3 apoBank (PDF hochladen + Mapping), FK-4 Vollmachten (Wortlaut fehlt), Wiederholung je Bankkonto, Ablösung onboarding-public.
Entwurfstexte per Hydrate-Skript ✅: scripts/textbausteine-hydrate.mjs (Texte in scripts/textbausteine/*.md, nicht im Worker); Server 998/998. Für den Live-Gang: Skript laufen lassen → juristisch prüfen → freigeben (#704) → Kataloge dem Angebot ‚onboarding‘ zuordnen. UI-Weg ‚Aus Datei laden‘ in der Verwaltung ✅ (gleiche Regeln).
FK-3 apoBank ✅: Katalog apobank_edue + Verwaltung → Fremdformular-Vorlagen (Upload). Zum Live-Gang: den echten Vordruck (Stand 06/2023) in der Verwaltung hochladen; prüfen, dass der Status ‚hinterlegt‘ zeigt. Offen: apoBank-Stammnummer (nicht in Stammdaten), FK-4 Vollmachten (Wortlaut fehlt).
N-4 ✅: Scan des unterschriebenen Originals optional bei ‚Original ist eingegangen‘ (Dokument am Kunden, ID im Audit). Noch ohne Oberfläche: Berater-Antworten erfassen (N-3), Katalog-Zuordnung zu Produkten (N-2).
N-2/N-3 ✅: Verwaltung → Fragenkataloge je Beratungsangebot (zuordnen, Standardsatz); Akte zeigt Onboarding + gebuchte Produkte; Berater-Antworten (Rolle Berater) im Akte-Panel. Zum Live-Gang: Kataloge dem Angebot ‚onboarding‘ zuordnen (jetzt per UI).

2026-10-14 — Praxis-Pflicht und Eindeutigkeit entkoppelt (MED-D-712)

Was: praxisPflicht (MED-D-686) steuerte zwei unabhängige fachliche Aussagen in einem Flag — „Praxis zwingend" und „höchstens ein offenes Mandat je Praxis". Beim Aufmachen von #687 (Pflicht auch für die übrigen praxisbezogenen Produkte?) hätte das die naheliegenden Fälle blockiert: Praxisfinanzierung braucht den Praxis-Bezug, verträgt aber zwei parallele Finanzierungen je Praxis.
Jetzt: Drittes Katalog-Flag eindeutigJePraxis (+ eindeutigJePraxisFuer()); der praxis_schon_belegt-Guard hängt nur noch daran — in anlegen und in praxisZuordnen. Der Katalog beschreibt den Praxis-Bezug damit in drei unabhängigen Fragen: erlaubt (praxisbezogen, MED-D-99) · zwingend (praxisPflicht, MED-D-686) · eindeutig (eindeutigJePraxis, MED-D-712).
Abgrenzung: Reine Entkopplung — beide Flags sind weiterhin nur für dexman_controlling gesetzt, es gibt keinen Verhaltensunterschied und keine Migration. #687 bleibt offen, ist aber jetzt je Produkt in zwei getrennten Zeilen entscheidbar.
Geprüft: Server-Vitest 891/891 grün (+1), Typecheck grün, Client-Build grün, E2E 48/48 gemockt und 20/20 Full-Stack.

2026-10-14 — App-Meisterwerk-Audit v0.161.0 (MED-D-713)

Was: Das App-Audit war nach der Stale-Regel (agents.md §6.7) überfällig — Bezugspunkt v0.144.1 lag 17 Minor-Versionen zurück (Issue #713). Neue Ausgabe docs/betrieb/UX-Prozess-Review-2026-10.md, Bezugspunkt v0.161.0 · d8a4082 · 2026-10-14.
Methode: App real bedient (Full-Stack-Worker + echte D1, Testpraxis mit Planungsbausteinen), Screenshots Desktop 1366 px und Mobil 390 px, Overflow/Erreichbarkeit im Browser gemessen; dazu Code-Sweep (stille Fehler · A11y-Kanäle · ARIA der Umschalter · Token · Typografie · Touch-Ziele · MED-D-330-Begriffe) und Nachprüfung des Altbacklogs.
Ergebnis: Dexman ist die bislang beste Fläche — der Kompass stellt die Antwort als Satz vor die Daten, Status steht als Text neben der Farbe, Kennzahlen tragen ihre Einordnung; ARIA der Dexman-Reiter ist vollständiger als die der Akten-Reiter (dort fehlt role="tabpanel" weiterhin, B38). Token-Disziplin makellos, keine still geschluckten Fehler in den neuen Flächen.
Befunde: B47 (mittel, #721) — Dexman-Overlay bei 390 px: Inhalt 519 px in 340 px, „Schließen" angeschnitten, Kopfzeile und Reiterzeile beschnitten. B48–B50 (niedrig, #722) — role="tab" ohne Pfeiltasten-Roving, ein 38-px-Ziel, Achsentext fix 12 px.
Altbestand: B36–B38, B40, B42, B43, B45 nachgeprüft und unverändert offen (#435); B46 ist inzwischen eine im Code begründete Entscheidung und kein Befund mehr. M-02/M-04/M-06/M-08 der E-Runde bleiben der größte Hebel.
Offen: Das Doku-Audit (Doku-Review-2026-09.md, Bezugspunkt v0.150.0) ist seit v0.161.0 ebenfalls überfällig — eigene Runde nötig.

MED-D-690 (2026-10-06): Formular-Raster .md-form + Entitäts-Karte .md-entity + Leerzustand .md-leer sind als wiederverwendbare Bausteine in client/src/styles.css definiert und im Register „Praxen / Gesellschaften" eingelöst. Offen (bewusst nicht in diesem PR): das abgelöste Muster md-row + flex-wrap + .md-grow steht noch an ~13 weiteren Stellen (mandant-detail.component.ts ×4, mandant-dentmarking.component.ts ×2, verwaltung.component.ts ×6) — dort droht derselbe Label-Umbruch, sobald eine Zeile voll läuft. Angleichung je Fläche beim nächsten inhaltlichen Anfassen (oder als eigener PR), nicht als Blind-Refactoring.

2026-10-06 — Dexman: Regel-Katalog der Handlungsempfehlungen + Monatsbericht-Beleg (MED-D-683/684)

Ausgangsfrage: „Können wir in Dexman für den Berater Handlungsvorschläge vorschlagen? Wie arbeitet der Berater mit Dexman?" — Handlungsempfehlungen (DEX-6) waren bereits gebaut; die Durchsicht zeigte zwei Lücken, die der Auftraggeber zur Umsetzung freigegeben hat (Issues #683, #684).
Was (Regel-Katalog, MED-D-683): HEBEL_KATALOG in shared/dexman-kern/hebel.ts führt je Regel Auslöser · Schwelle · Wirkungsart (gerechnet vs. ueberschlag) · Datengrundlage · gebaut/geplant mit wartetAuf; hebelRegel(hebelId) löst eine Hebel-ID auf ihre Regel auf. Systementwurf §10.5 spiegelt den Katalog, scripts/check-doc-consistency.sh Check 10 prüft beide Richtungen (Regel ohne Doku-Zeile und Doku-Zeile ohne Regel). Drei neue Regeln aus vorhandenen Daten: anlage-spaeter, darlehen-endfaellig, kontokorrent → 8 gebaute Regeln.
Was (Monatsbericht, MED-D-684): server/src/domain/dexman-monatsbericht.ts (Blockmodell → PDF + Markdown), DexmanService.monatsberichtErstellen legt die PDF über den Ablage-Port ab und führt sie als Dokument (status=erhalten); Route POST /api/dexman/praxen/:id/monatsbericht/:monat; Knopf „Monatsbericht erstellen" in der Kopfzeile des Dexman-Fensters (Berichtsmonat = Vormonat, im Hinweistext genannt). Audit dexman.monatsbericht.erstellt mit SHA-256 des Berichtstexts.
Abgrenzung: Keine Migration, keine neue Entität (der Inhalt ist abgeleitet, G-2) · keine Attrappen für DEX-15/17/18 · die Datenpflege-Erinnerung bleibt bei den Monatsaufgaben (MED-D-652).
Offen (Dexman): Empfehlungs-Rückmeldung in die Beratungsdoku R6 samt Status übernommen/umgesetzt je Empfehlung (DEX-6-Akzeptanz, heute nur Wiedervorlage) · Cockpit-Kachel in der Akte (DEX-5) · Widerspruch Doku↔Code beim Beratungsmodus (Systementwurf §4.7 „Beträge gerundet auf 100 €" vs. dexman-daten.ts „Beträge bleiben") · unverändert: Monatsmeldung im Portal, Excel-Import (DEX-13), Bank/PVS (#373/#374), Behandler-Vergleich (OP-DEX-4), RISK-38.
Geprüft: Server tsc + npm test grün (883 Tests / 72 Dateien), Client-Build grün, gemockte E2E 48/48, Full-Stack-E2E 18/18 (Monatsbericht gegen echten Worker: Dokument in der Akte + PDF-Download aus der lokalen R2-Ablage), Doku-Konsistenz-Check ohne Hinweise (inkl. Gegenprobe des neuen Checks 10).

MED-D-672 (2026-10-06): "Nächster Schritt"-Banner oben in der Kundenakte entfernt — die Antwort auf "Was ist offen und fällig?" steht nur noch an einer Stelle (Kontext-Spalte "Anstehende Aufgaben"). Offen: nichts; falls ein hervorgehobener Einstieg später doch gewünscht ist, neu entscheiden.

MED-D-674 (2026-10-06): Portal-Login — "E-Mail erneut senden" auf der Postfach-Seite (60 s Wartezeit, enumeration-frei, kein neuer Endpunkt); Turnstile wird explizit gerendert und greift damit auch nach einem Ansichtswechsel. Offen: nichts; der Live-Versand hängt weiter am Domain-Onboarding im Cloudflare Email Service (OP-DM-8).

MED-D-677 (2026-10-06): Prüfung der Kundenanmeldung — nicht nutzbar: /portal liegt noch hinter Cloudflare Access (Magic-Link läuft gegen die Access-Wand; 4 Konten alle eingeladen, 5 Tokens, 0 Sessions), Turnstile ist nicht konfiguriert. Gebaut: Turnstile deploy-fähig (Secret-Sync + Sitekey-Platzhalter + Start-Warnung bei Halb-Konfiguration). Offen: (1) Sitekey aus dem Cloudflare-Turnstile-Widget + TURNSTILE_SECRET als GitHub-Secret setzen, (2) Access-Bypass für /portal* (Issue #677), (3) Mail-Kanal im Audit mitschreiben (Issue #678 — zustellung: ok belegt heute keinen echten Versand).

MED-D-678 (2026-10-14): Audit der Magic-Link-Seams schreibt jetzt den Mailkanal mit — zustellung: "ok" allein belegte keinen Versand (Log-Kanal wirft nie). Offen: unverändert der Access-Bypass für /portal* und der Turnstile-Sitekey (Issue #677).

MED-D-681/682 (2026-10-06): Dexman bewertet Kostendeckung über die nächsten 12 Monate und nennt einen Engpass im Kopfsatz; einmalige Ereignisse als Meilensteine mit Mouse-over. Offen: Plausibilitätshinweise in der Planung (Darlehensrate unter den Zinsen, Ist-Umsätze vor Eintritt, Behandler mit Ist aber Plan 0) — Vorschlag R-29.

2026-10-06 — Akten-Rail: mehr Platz, bessere Lesbarkeit (MED-D-675)

Was: Die linke Rail der Kundenakte (Person · Status · Zuständigkeit · Stammdaten) war mit 268px und 0.95rem Polster zu eng, seit alle Kleinschriften auf 0.875rem angehoben sind (A11y): „Zuständig: " brach mitten in der Adresse um, die Stammdaten-Paare klebten bei 6px Zeilenabstand aneinander, die E-Mail-Zeile wurde per nowrap abgeschnitten.
Jetzt: 310px Spalte (nur .mw-scope, erst ab 1101px — unter 1100px bleibt der bestehende Block-/Ein-Spalten-Kollaps unverändert), 1.35rem/1.2rem Polster, line-height: 1.5, Rail als flex-Spalte mit 1.45rem Abschnitts-Rhythmus (der md-grow-Spacer im Template wirkt endlich: die „Druckansicht" sitzt am Rail-Fuß). Zuständigkeit = Label über Wert (.mw-rail-zust), Select darunter auf voller Breite; Stammdaten als .mw-rail-stamm (Label-Spalte min. 7.5rem, 0.55rem/1rem Abstand, Werte brechen um statt abgeschnitten zu werden); Rail-Textlinks als .mw-rail-link.
Abgrenzung: Rein visuell — keine Feld-, API- oder Datenmodell-Änderung; Cockpit/Leitstand (ohne .mw-scope) bleiben unberührt.
Geprüft: npm run build (client) grün, mocked E2E-Suite 46/46 grün, Rail bei 1440px und 1000px visuell gegengeprüft.

2026-10-06 — Dexman-Mandat braucht eine Praxis (MED-D-686)

Was: dexman_controlling war wie jedes andere Produkt praxisbezogen: true — das heißt im Katalog nur „Praxis-Bezug erlaubt" (MED-D-99). Folge: Ein Dexman-Mandat ließ sich ohne Praxis anlegen und zeigte dann nur den Hinweis „Dexman braucht eine Praxis" — ein Mandat ohne Arbeitsfähigkeit.
Jetzt: Zweites Katalog-Flag praxisPflicht (nur dexman_controlling, impliziert praxisbezogen). Server: Anlegen ohne praxisId → praxis_pflicht; je Praxis höchstens ein offenes Mandat des Pflicht-Produkts → praxis_schon_belegt (abgeschlossene blockieren nicht). Client: Produkt im „+ Mandat"-Dialog gesperrt, solange der Kunde keine Praxis hat („zuerst Praxis anlegen"); Praxis-Auswahl ohne „ohne Zuordnung" und Anlegen-Knopf bis zur Wahl deaktiviert.
Bestand: Migration v69 setzt praxis_id automatisch, wenn der Kunde genau eine Praxis hat (sonst wäre die Wahl geraten) und die Zuordnung die Eindeutigkeit wahrt: abgeschlossene Mandate bekommen die Praxis immer, ein offenes nur, wenn kein anderes offenes Dexman-Mandat sie beansprucht — zwei unzugeordnete offene Mandate blockieren sich und bleiben beide leer (CodeRabbit-Befund zu v69; geprüft in server/src/db/migrate-v69.test.ts gegen echtes SQLite). Bei 0 oder >1 Praxen bleibt das Mandat ohne Praxis und verlangt die Zuordnung im Mandat-Overlay sichtbar nach — neue Aktion „Praxis zuordnen" auf POST /api/mandanten/:id/auftraege/:auftragId/praxis, mandant-scoped, PII-arm auditiert als auftrag.praxis_zugeordnet (G-4).
Abgrenzung: Die Pflicht gilt nur für Dexman-Controlling. Für die übrigen rein praxisbezogenen Produkte (Dentmarking, Praxisfinanzierung, Existenzgründung, Abrechnungsberatung, Praxisnachfolge) ist sie fachlich offen → Issue #687 (fachliche-bestätigung).
Geprüft: Server-Vitest 879/879 grün (+10), Client-Build grün, mocked E2E 46/46, Full-Stack-E2E 19/19 inkl. neuer e2e-fullstack/dexman-mandat-praxispflicht.spec.ts gegen echten Worker + D1.

MED-D-659 (2026-10-04): Kundenklärungen = Issues mit Label fachliche-bestätigung (#660–#669 aus den KB-Punkten); Kunden-Besprechungspunkte.md eingefroren. Bestand gesichtet (2026-10-06): Label zusätzlich an #374 · #375 · #404 · #413 · #414 · #417 · #424 · #425 (fachliche Entscheidung des Kunden); ohne Label bleiben #373 · #405 · #408 · #409 · #411 (Tool-/Anbieterwahl bzw. Compliance-Arbeit — weiter status: anreicherung).

MED-D-654 (2026-09-28): Kundenportal-Block ohne Erinnerungs-Schalter/Hinweis; Stand leise in den Basis-Dokumenten. Offen: falls Abschalten je Kunde doch in der Oberfläche gebraucht wird, neu entscheiden (derzeit nur API).

MED-D-630 R-13 (2026-09-27): Standard-Mandats-Unterlagen per Migration v66 eingespielt (alle Zeilen freigegeben, inkl. Annahmen). Offen: Annahme-Zeilen bei Gelegenheit fachlich gegenprüfen und in der Verwaltung anpassen.

MED-D-652 (2026-09-27): Laufende Dexman-Mandate bekommen monatlich drei Wiedervorlagen für den Vormonat (5./10./15.). Offen: Fälligkeitstage fachlich bestätigen; Zeitbasis ist UTC.

MED-D-649 (2026-09-27): Dexman-Mandate bekommen beim Buchen vier Folgeaufgaben (7/21/30/45 Tage). Offen: wiederkehrende Monatsaufgaben (z. B. monatliche Ist-Erfassung) gibt es nicht — das Playbook legt nur einmalig an.

MED-D-646 (2026-09-27): Dexman-Mandate bekommen beim Buchen vier Standard-Unterlagen (Migration v68). Offen: Standard-Folgeaufgaben für Dexman-Mandate (Playbook) sind weiterhin leer.

MED-D-643 (2026-09-27): Dexman-Controlling ist als Mandat buchbar; das Mandat öffnet Dexman für die gebuchte Praxis. Offen: Standard-Folgeaufgaben und -Unterlagen für Dexman-Mandate fachlich festlegen (derzeit leer).

MED-D-638 (2026-09-27): Automatische Kunden-Erinnerung an fehlende Unterlagen gebaut (7 Tage, max. 3 Mails, dann Wiedervorlage; je Kunde abschaltbar). Offen: wirkt erst mit onboardeter Absender-Domain im Cloudflare Email Service; Mailtext fachlich gegenlesen.

MED-D-635/637/639 (2026-09-27): "Basis-Dokumente" statt "Onboarding-Dokumente"; Erstonboarding-Einladung entsteht automatisch über das Portal (Einmal-Link-Abschnitt in der Akte entfernt); Basis-Dokumente mit 4-Stand-Schieber. Offen: automatische Kunden-Erinnerung an fehlende Unterlagen (#638, alle 7 Tage, max. 3, dann Wiedervorlage).

MED-D-337 (2026-09-26) — Unterschrift auch für erzeugte/frei geschriebene Dokumente nur über den Assistenten (MED-OP-UX-18) (0.149.0→0.150.0, MINOR; Nutzer: "MED-OP-UX-18 bauen, dann Doku-Audit aktualisieren"). Auch erzeugte (Dokumentgenerierung) und frei geschriebene Dokumente (Individualdokument) gehen jetzt nur über den Unterschriften-Assistenten zur Unterschrift: der Knopf "Zur Unterschrift →" öffnet den Assistenten mit dem erzeugten Dokument. Serverseitig führt api/signatur-quelle.ts beim Signatur-Start (POST /api/dokumente/:docId/signatur und /signatur/vor-ort) die Quelle nach — Status zur_unterschrift, signaturRef und dasselbe Audit-Event wie bisher (dokumentgenerierung.zur_unterschrift bzw. individualdokument.zur_unterschrift, G-4) —; beim Individualdokument gilt die beim Anlegen gewählte Unterschrift-Stufe als Vorgabe, solange der Assistent auf "automatisch" steht. Nur fertig abgelegte Quellen (abgelegt) werden nachgeführt; ein zweiter Start auf dasselbe Dokument bleibt 409 (kein Doppel-Vorgang). Bei einer Generierung im Zwischenzustand erzeugt bietet die Liste "Erzeugen & ablegen" an (idempotent). Die alten Direkt-Endpunkte bleiben serverseitig bestehen (Rückwärtskompatibilität), der Client nutzt sie nicht mehr.

MED-D-384 (2026-09-26) — Impressum + Datenschutzhinweise als eigene Seiten, Kundenkontakt gesetzt (version:minor, Nummer stempelt der Deploy; Nutzer: "Lege Impressum und Datenschutz-Seiten selber an und verlinke" · "Q-1 a, Q-2 ja" · "nimm die Angaben von medidentas.de"). Eigene Seiten /impressum + /datenschutz (Worker, server/src/rechtliches.ts), verlinkt über https://medidentas.com/.... Links je Seite unabhängig: eine gesetzte https://-IMPRESSUM_URL/DATENSCHUTZ_URL hat Vorrang; sonst verlinken Landing und Kundenseiten die eigene Seite nur bei vollständigem Pflichtkern (Name + Vertretung + Anschrift + E-Mail). Anbieterdaten von medidentas.de: medidentas GmbH, Kunstwerkerstr. 175, 45136 Essen, vertreten durch Geschäftsführer Holger Queckenstedt, Amtsgericht Essen HRB 24834, Vermittlerregister §34c/d/h/i GewO, Datenschutz-Aufsicht LDI NRW; Kundenkontakt 0201 959 748 84 · info@medidentas.de. Offen (#384): USt-IdNr., Datenschutzbeauftragter, Erlaubnisbehörde (ANBIETER_ERLAUBNISBEHOERDE) + Schlichtungsstellen; anwaltliche Prüfung beider Texte vor Go-Live.

MED-D-370 (2026-09-26) — Doku-Audit-Refresh v0.150.0 + B52/B54 (Doku-only, keine Versionsänderung). Doku-Meisterwerk-Audit aufgefrischt (Bezugspunkt v0.150.0, MED-OP-REVIEW-1): neue Befunde B56–B60 behoben (Testzahl-Kopien in README/MVP-Scope/Management-Summary durch Verweis auf Test-Uebersicht.md ersetzt · Portal-Doku um die Aufgabenliste MED-D-333 ergänzt · Glossar um "Vollständigkeit" und "Unterschrift-Stufe" · Doku-Landkarte mit den Meisterwerk-Audits · MED-D-321 in HANDOFF §2 nachgetragen) und die Alt-Befunde B51 (Unterschriften.md: DocuSign-Kern live verifiziert), B52 (Design-Entscheidungen-Kunde.md auf 0.150.0, Status je AD am Code nachgeprüft: AD-005/008/009/010 ✅) und B54 (Dokumentenverwaltung-NextCloud.md: Abschnitt "Ablage-Spiegel in der Oberfläche" mit Mermaid) — MED-OP-DOKU-9/10 erledigt, Doku-Backlog leer. Audit: docs/betrieb/Doku-Review-2026-09.md §0.

Nachzug zu MED-D-337/MED-D-370 (2026-09-26) — CodeRabbit-Fixes zu #370 (0.150.0→0.150.1, PATCH). Nachzug der CodeRabbit-Fixes zu #370, die der Merge-Queue nicht mehr mitgenommen hat (gemergt wurde der Stand vor dem Fix-Commit): Signatur-Quelle wiederherstellbar nachgeführt (erst Audit-Event, nur falls für den Vorgang noch nicht vorhanden, dann Status; Nachführ-Fehler kippt die 201-Antwort nicht, der Wiederholungsversuch mit 409 holt die Verknüpfung idempotent nach; +1 Vitest), Full-Stack-E2E für erzeugte und frei geschriebene Dokumente komplett durch den Assistenten, Doku-Korrekturen (OP-SIGN-1-Rest, Audit-Bezugspunkt mit Commit, §0a historisch, Reiter "4 + Mehr", Testzahl-Verweise, UX-18-Zeile, gerade Anführungszeichen).

Stufe 2 der GitHub-Arbeitsweise (2026-09-26, #361/#362/#363/#365). Offene Punkte und Features leben jetzt ausschließlich als Issues (Alt-OPs #392–#437, Features #438–#620; HANDOFF §4/Lastenheft §11 eingefroren, docs/fachlich/Feature-Liste.md = Wegweiser, Text in feature.d/). Die Version stempelt der Deploy (PR-Label version:*, Tag v<semver>; erster Deploy nach dem Merge setzt aus 0.151.2 + version:minor den ersten Tag v0.152.0). KW-Aggregat im Timesheet wird beim Bau abgeleitet. Offen: ersten Deploy-Lauf nach dem Merge prüfen (Schritte „Version stempeln“/„Version-Tag setzen“, Tag vorhanden); #364 (Repo-Einstellungen + AUTOMATION_PAT).

MED-D-364 (2026-09-26) — Pflicht-Check heißt jetzt checks (Issue #364, BP-5): Job ci-gate meldet als checks (drkv-einheitlich), CodeRabbit bleibt Pflicht. Offen: Admin stellt den Required-Check im Ruleset/der Merge Queue von CI Gate auf checks um — bis dahin kein Auto-Merge (die Queue würde auf CI Gate warten).

#365 Teil 1 (2026-09-26) — union-Dubletten-Checks entfernt. Doku-Check §2 prüft nur noch Konflikt-Marker. Offen: Teil 2 — KW-Aggregat im Timesheet ableiten.

MED-D-359 (2026-09-26) — GitHub-Arbeitsweise (drkv-Standard) übernommen (CI-Konfig/Doku, keine Versionsänderung; Issue #359). Ab jetzt je PR nur Fragmente: changelog.d/, handoff.d/, timesheet.d/ (<YYYY-MM-DD>-<branch-slug>.md) und bei Entscheidungen entscheidungen.d/<nr>-<slug>.md — CHANGELOG.md, HANDOFF.md, docs/betrieb/Timesheet.md, docs/betrieb/Decision-Log.md sind erzeugt (nie von Hand editieren; Bau nach dem Merge via dokumente-nachziehen.yml). Entscheidungs-ID = GitHub-Nummer (Issue, sonst PR), neue offene Punkte als GitHub-Issue statt §4-Zeile. CI läuft nicht mehr auf Draft-PRs. Standard: drkv-com/everything-as-code-template docs/GitHub-Arbeitsweise.md; Detail docs/konventionen/agents.md §3/§6.4. Offen (Stufe 2, eigene Issues): Altbestand OPs → Issues, Feature-Liste aus Issues, Version stempeln, BP-5-Repo-Einstellungen + Secret AUTOMATION_PAT, union-Glätt-Reste, KW-Aggregat ableiten.

MED-D-372 (2026-09-26) — Dexman-Spezifikation v2 (Doku-only, Issue #372). spezialtools/Dexman.md ist jetzt die Master-Spezifikation (DEX-1…DEX-19, Slices X1–X8, Dexman-MVP = X1–X4), inkl. MediPulse-Zusätze DEX-14…19. Offen: Prioritäten/MVP-Schnitt vom Auftraggeber bestätigen; OP-DOMAIN-1 (dental-first); Issues #373 (Bank-Anbieter), #374 (PVS-Konnektor), #375 (Ziffern dental).

MED-D-380 (2026-09-26) — Dexman-Systementwurf + Prototyp (Issue #380): spezialtools/Dexman-Systementwurf.md, design/dexman/Dexman-Prototyp.html. Offen: Entscheidungen E-A…E-F durch den Auftraggeber (Vorzimmer-Zugang, Priorität, gemeinsames Rechenkern-Modul, Tageslinie, Beratungsmodus, Benchmark-Satz).

MED-D-381 (2026-09-26) — Dexman erste Ausbaustufe gebaut (0.150.1→0.151.0, Issue #381): Rechenkern shared/dexman-kern/, Planungsbausteine (v63), Ist-Erfassung durch Medidentas, Hebel → Wiedervorlage, zwei Oberflächen Kompass und Klassisch (Reiter Praxen → „Dexman", /dexman/:praxisId). E-A…E-F bestätigt. Offen: Monatsmeldung im Kundenportal, Excel-Import (DEX-13), Bank #373 / PVS #374, Behandler-Vergleich (OP-DEX-4), Monatsbericht-PDF, dexman_controlling buchbar schalten, AV-Vertrag + Aufbewahrung für Beschäftigtendaten (RISK-38), Nutzertest Kompass vs. Klassisch (U-2/E-D).

MED-D-383 (2026-09-26) — Dexman formelle Fachsprache (0.151.0→0.151.1, Issue #383): Statusbegriffe je Bereich (Kostendeckend / Liquiditätsengpass absehbar / Über Richtwert …), Sätze, Empfehlungen, Beschriftungen; Regel für neue Texte im Systementwurf §11.

MED-D-630 (2026-09-26): Vorschlag Mandats-Unterlagen je Produkt liegt zur Prüfung vor (fachlich/Mandats-Unterlagen-Vorschlag.md; belegt nur Kapitalanlage + Dentmarking, Rest Annahme). Offen: Freigabe durch den Auftraggeber, dann Erfassung in der Verwaltung.

MED-D-630 Slice 2 (2026-09-26) — Mandats-Unterlagen je Produkt gebaut. Nächster Schritt: in der Verwaltung je Produkt die Unterlagen hinterlegen (bisher leer; bestehende Mandate erhalten keine rückwirkenden Anforderungen).

MED-D-630 Slice 1 (2026-09-26): Onboarding = Abhak-Liste der Basis-Unterlagen (ohne Mandat-Auswahl, ohne "Formular anfordern"). Offen (Slice 2, #630): Mandats-Unterlagen als eigene Checkliste je Mandat mit admin-pflegbarer Vorlage je Produkt, beim Buchen automatisch angelegt.

MED-D-629 (2026-09-26) — Teams + "Chef / Backoffice" + Filter "Nicht zugewiesen" (Issue #629). Nächste Schritte zum Einschalten des Kunden-Scopes: (1) in der Kundenliste "Nicht zugewiesen" abarbeiten, (2) in der Verwaltung Rollen/Teams setzen (Chef = Chef / Backoffice), (3) rbac_mandant_scope_aktiv = 1, Stichprobe mit Berater-Konto (eigener/Team-Kunde sichtbar, fremder 404).

MED-D-623 Nachlese (2026-09-26): Scope-Test robuster gegen Objekt-Referenzen des MemoryRepo (CodeRabbit-Befund auf #624). Keine Code-Änderung.

MED-D-623 (2026-09-26) — alle By-ID-Routen mit Kundenbezug im Kunden-Scope (Issue #623): Dokumente, Bankkonten, Onboarding-Items, Signaturen, Dokumentgenerierung, Leistungszeit. Damit ist rbac_mandant_scope_aktiv für alle kundenbezogenen Routen dicht. Offen: Einschalten der Einstellung in Produktion (Entscheidung Betrieb); Pentest vor Mehr-Mandanten-Betrieb (RISK-10).

MED-D-382 (2026-09-26) — Praxis-Routen im Kunden-Scope (0.151.1→0.151.2, Issue #382): Scope-Guard für /api/praxen/:id*, /api/gutachten/:id*, /api/befunde/:id/*. Damit ist rbac_mandant_scope_aktiv auch für Dentmarking/Dexman dicht. Offen: weitere By-ID-Routen ohne /api/mandanten/:id-Präfix (z. B. /api/dokumente/:id) systematisch prüfen (RISK-10).

MED-D-335 (2026-09-26) — Kundenseite verschlankt, ein Weg je Aufgabe, Schrift/Klickflächen global (MED-OP-UX-16 Slice B) (0.148.0→0.149.0, MINOR; Nutzer: „Q-1 ja, Q-2 ja, Q-3 global"). I-02 Kundenseite verschlankt: oben ein Block „Nächster Schritt" mit einer Handlung („Jetzt erledigen →", abgeleitet aus derselben Liste wie „Anstehende Aufgaben", G-2) · ein Status (Kopf-Pille „Status: …", „Schritt x von y" und „Phase …"-Pille entfernt; Rail-Label „Status") · vier Haupt-Reiter, übrige („Praxen", „Gesprächsprotokoll") unter „Mehr ▾" (nichts mehr abgeschnitten) · Texte der nächsten Schritte in Klartext („Unterlage(n)/Angabe(n) fehlen noch — Kunden erinnern oder Eingang abhaken" statt „Pflicht-Item(s) … Self-Service-Link"). I-04 je Aufgabe ein Weg: der Direktversand „Zur Unterschrift senden" ohne Assistent ist entfernt (Unterschrift am Dokument nur über den Unterschriften-Assistenten, kein Doppel-Einstieg im „⋯"-Menü); „Dokument anfordern" = Checkliste → der Kunde sieht es als Aufgabe im Portal (MED-D-333); Hochladen/Upload-Link nur noch als Rückfall im „⋯"-Menü („Kunde ohne Portal"). I-07 global: Mindest-Schrift 14 px für Neben-/Hinweistexte (254 Stellen angehoben; Grundschrift 16 px) · Schaltflächen, Auswahlen und Eingabefelder mindestens 44 px hoch, Symbol-Knöpfe 44 × 44 px, Häkchen 22 px. Dazu I-05-Rest: Verlaufseintrag „stammdaten_version eingesehen" → „Stammdaten-Verlauf eingesehen". Offen: MED-OP-UX-18.

MED-D-334 (2026-09-26) — Interne Oberfläche einfacher (MED-OP-UX-16 Slice A) (0.147.0→0.148.0, MINOR; Nutzer: „K-10 fixen, dann MED-OP-UX-15, danach MED-OP-UX-16"). I-05 interne IDs/Technikbegriffe aus der Oberfläche entfernt (MED-D-/MED-KB-/G-/OP-/AD-Verweise, „Ablage (R2) provisionieren" → „Ablage einrichten", „eIDAS-Niveau/Rechtsmatrix" → „Unterschrift-Stufe · automatisch (passend zum Dokument)", „Weltmodell-Attribut" → „Stammdaten-Feld", „AcroForm", „append-only/hash-verkettet", „Provider"; Cockpit „Tagestakt/Bahnen/Brennt/Taktgeber" → „Heute/Listen/Dringend"; „aktenreif" → „vollständig"). I-09 Cockpit-Kopfzeile ohne seitliches Scrollen (Leitstand-Optionen in den Seiteninhalt, Kopfzeile bricht um; gemessen 1024/1280/1366 px), toter Knopf „Suchen / Springen (bald verfügbar)" entfernt; Version/Build war bereits nur für Admins (MED-D-324/325). I-10 Fehlermeldungen nennen Ursache + nächsten Schritt: neue fehlerText(e, aktion) (Status 0/401/403/404/409/4xx/5xx → „… hat nicht geklappt: . "), 87 Stellen umgestellt, zentrales Auffangnetz ebenso. I-11 Wiedervorlage zuweisen per Personenauswahl (Anzeigename) statt freier E-Mail; E-Mail-Eingabe nur noch als Rückfall ohne Benutzerliste; Zuständige mit Namen angezeigt. Nächster Schritt: Slice B (I-02/I-04/I-07).

MED-D-333 (2026-09-26) — Kundenportal als eine To-do-Liste + Fragebogen seitenweise (MED-OP-UX-15 Slice B) (0.146.0→0.147.0, MINOR; Nutzer: „K-10 fixen, dann MED-OP-UX-15, danach MED-OP-UX-16"). K-02 Portal = eine To-do-Liste „Was Sie noch tun müssen": offene Onboarding-Einladung, Formulare (Entwurf/Korrektur, Korrektur klar benannt), Fragebogen und angeforderte Dokumente je mit einem Knopf „Jetzt ausfüllen →"/„Jetzt korrigieren →" bzw. Upload direkt in der Liste; interne Checklisten-Items nicht mehr sichtbar (nur fehlende Stammdaten im Klartext); Erledigtes unter „Bereits übermittelt"; „Angaben ändern" eingeklappt. Portal-Mails (Einladung/Anmeldung) erklären Zweck, Gültigkeit (15 Min., einmalig) und den Weg zu einem neuen Link. K-06 Fragebogen seitenweise („Teil x von n", Fortschrittspunkte, „Speichern und weiter →" speichert den Entwurf, Zusammenfassung vor dem Absenden). K-08 Portal-Sitzung bleibt bei Aktivität (Tippen/Klicken) am Leben (Ping höchstens alle 5 Min.) — kein Datenverlust nach Leerlauf-Ende beim Tippen; verständliche Meldung bei Ablauf. Nächster Schritt: MED-OP-UX-16 (interne Oberfläche).

MED-D-332 (2026-09-26) — Kundenseiten: Hilfe sichtbar, verständlich, gut lesbar (MED-OP-UX-15 Slice A) (0.145.2→0.146.0, MINOR; Nutzer: „K-10 fixen, dann MED-OP-UX-15, danach MED-OP-UX-16"). K-01 Fußzeile aller Kundenseiten mit „Fragen? Wir helfen gern." — Ansprechperson (Anzeigename der Betreuung, nie Roh-E-Mail), antippbare Telefonnummer/E-Mail, Impressum/Datenschutz; Werte als Worker-Vars KUNDEN_KONTAKT_TELEFON/_EMAIL/IMPRESSUM_URL/DATENSCHUTZ_URL (dormant ohne Wert, Deploy.md §7f) — Werte vom Betrieb offen. K-03 Klartext statt Jargon (Sicherheitsprüfung statt „Bot-Schutz", „So weit sind Sie", „Optional" statt „Nice-to-have", Vorgangsnummer statt Beleg-Nr./Prüfsumme (Prüfsumme eingeklappt), kein „technischer Status", „Ansprechperson"/„Steuerberatung"/„Ihre Betreuung" statt Gender-Doppelpunkt). K-04 gesperrte Absende-Buttons nennen, was fehlt. K-05 Handy-Tastatur je Feldart, Format-Beispiele + Hilfe unter dem Feld. K-07 Upload: beschrifteter Button „Foto machen oder Datei auswählen", Dateiwähler-Filter = Server-Whitelist, sichtbare Bestätigung, verständliche Fehler; Einmal-Link-Upload-Seite in Marken-Handschrift. K-09 Grundschrift 17 px, Hinweise ≥ 0,92 rem, Beschriftungen dunkel, Klickflächen ≥ 44 px, Schritt-Labels brechen um statt abgeschnitten. Offen (Slice B): K-02 Portal als einzige To-do-Liste + verständliche Einladungs-/Anmelde-Mail, K-06 Fragebogen seitenweise, K-08 Sitzungsende ohne Datenverlust. +4 Vitest → 793; +2 gemockte E2E → 33.

MED-D-331 (2026-09-26) — Kunden-Erinnerung zu offenen Formularen kommt jetzt an (K-10) (0.145.1→0.145.2, PATCH; Nutzer: „K-10 fixen, dann MED-OP-UX-15, danach MED-OP-UX-16"). Die weiche SLA-Erinnerung (FormularSlaService, Cron) ging mit empfaenger: null raus → der Mail-Adapter übersprang sie still, slaErinnertAm wurde trotzdem gesetzt („verbrauchte" die Erinnerung). Jetzt: Empfänger = Kontakt-E-Mail des Kunden; Klartext mit absolutem Fortsetzungs-Link je Strecke (/onboarding/, /formular/, /fragebogen/ + Token, Basis APP_URL); ohne E-Mail kein Versuch und keine Markierung (wird nachgeholt, sobald die E-Mail gepflegt ist); Zustellfehler nicht-fatal (keine Markierung, harte Eskalation läuft trotzdem). Audit bleibt PII-arm. +2 Vitest → 789.

MED-D-336 (2026-09-26) — Build-Minuten Runde 2 (CI-Konfig/Doku, keine Versionsänderung): Client-CI = ein Job client (1× Build → gemockte + Full-Stack-E2E; BM-2/BM-3), Docs-Build nur bei gerenderter Doku (docs/**, docs-site/**, HANDOFF.md, README.md; BM-6). Offen aus der Build-Minuten-Liste: BM-1 (CI_RUNNER zurück auf hot), BM-4/5/7/8/10.

MED-D-330 (2026-09-26) — Begriffe „Kunde" + „Mandat" in der Oberfläche (MED-OP-UX-17) (0.145.0→0.145.1, PATCH; Nutzer: „ready for review, dann MED-OP-UX-17"). Setzt die Begriffsentscheidung aus MED-D-326 um: alle sichtbaren Texte „Mandant/Mandanten" → „Kunde/Kunden" (Client-Templates/Toasts/Aria-Labels, labels.ts, Server-Fehlermeldungen, generierte Dokumente „Kunde"/„Kundennummer", Einstellungs-Texte, DocuSign-Fehlertexte) und „Beratungsauftrag/Beratungsmandat/Auftrag" → „Mandat" (von Hand wegen Genus/Artikel). Mechanik: TS-AST-gestützt nur in String-/Template-Literalen → keine Bezeichner/Routen/DB/API-Felder geändert. Bewusst unverändert: Ablage-Basispfad Medidentas/Mandanten (Speicherort), „Dienstleistungsauftrag" (Dokumenttyp), Signatur-Matrix „Vertrag/Auftrag". Glossar: Hauptbegriff „Kunde" (Alias „Mandant"), neu „Mandat". Fließtext-Doku wird schrittweise beim nächsten inhaltlichen Anfassen angeglichen (analog MED-Präfix-Regel), Glossar erklärt den Alias. Tests unverändert 787 Vitest / 31 gemockt / 9 Full-Stack (Texte angepasst).

MED-D-326/329/328 (2026-09-25) — Einfachheits-Audit („trivial für ältere / wenig IT-affine Nutzer") + Sofort-Fixes + Startseite „Heute fällig" (0.144.3→0.145.0, MINOR; Nutzer: „prüfe ganz kritisch die UX/UI … absolut trivial … auch ältere oder weniger IT-affine Menschen" → „b, Begriffe: Kunde und Mandat; dann c"). Audit (docs/betrieb/UX-Prozess-Review-2026-09.md §E, App lokal gestartet + Screenshots): Verdikt nicht trivial — zu viele gleichzeitige Bedienelemente/Status, mehrere Wege je Aufgabe, Jargon/interne IDs sichtbar, kleine/blasse Schrift, kein Ansprechpartner für Kunden. Begriffsentscheidung (MED-D-326): UI/Doku sprechen künftig von „Kunde" (statt Mandant) und „Mandat" (statt Beratungsauftrag/Auftrag/Beratungsmandat); Umsetzung = MED-OP-UX-17. Behoben (MED-D-329): Portal /portal zeigte Kunden die interne Staff-Kopfzeile (U-01); Formular-Korrektur-Mail kam nie an (empfaenger: null + relativer Link, U-02) → jetzt Kontakt-E-Mail + absoluter Link, nicht-fatal, Staff-Toast meldet ehrlich, ob eine Mail rausging; Primary-Buttons 2,4:1 → neues --md-cta ≈5,0:1 (U-03, WCAG AA); Kundenstrecken fest hell (U-04/B44). Gebaut (MED-D-328): Startseite zeigt oben „Heute fällig" (datierte überfällige + heute fällige Punkte, Klartext-Frist, große Klickflächen; M-03); Zeiterfassung startet nicht mehr beim Öffnen eines Mandanten, sondern per Button „Zeiterfassung starten" (M-07; durchlaufender Timer MED-D-275 bleibt, sobald gestartet); Fokus-Einzeltasten-Kürzel standardmäßig aus (Schalter „Tastenkürzel verwenden"). Offen: MED-OP-UX-15/16/17. +2 Vitest → 787; +4 gemockte E2E → 31; +1 Full-Stack-E2E → 9; tsc+787 Vitest+ng build+client/e2e 31/31+e2e-fullstack 9/9 grün.

MED-D-327 (2026-09-26) — Build-Minuten: Merge-Queue verbindlich + CI ohne push: main (CI-Konfig/Doku, keine Versionsänderung). ci.yml ohne push: main (BM-9, spart den doppelten Voll-Lauf je Merge), workflow_dispatch als Sicherheitsnetz; SBOM jetzt im App-Deploy. Merge-Queue vom Nutzer am 2026-09-26 in GitHub aktiviert (Pflicht; Required-Check CI Gate) — ohne aktive Queue landet Code ungetestet auf main. Weitere Einspar-Optionen BM-1…BM-10 (u. a. BM-1 CI_RUNNER zurück auf hot, BM-2/3 E2E-Jobs zusammenlegen, BM-6 Docs-Pfadfilter enger) als Vorschlag im Chat, nicht umgesetzt.

MED-D-325 (2026-09-26) — Betriebsinfo im Footer nur für Admins (0.144.2→0.144.3, PATCH; Nutzer: „Ja" auf die Rückfrage admin-only?). Die in MED-D-324 in den Fuß verschobene technische Betriebsinfo (Version/Build + Deploy) ist jetzt an istAdmin() statt ich() gebunden — sie erscheint nur noch für die Rolle admin, nicht mehr für backoffice/berater. Beide Stellen: App-Shell (app.component, neuer istAdmin()-Helfer) und Cockpit (cockpit.component, bestehendes istAdmin()). +1 gemockte E2E (smoke.spec.ts: Berater → kein footer.mw-footer) → 27 gemockt / 35 E2E. ng build+client/e2e 27/27+tsc+Doku grün. PATCH.

MED-D-324 (2026-09-25) — Version/Build + Deploy dezent in den Footer (nur Mitarbeiter) (0.144.1→0.144.2, PATCH; Nutzer: „versionsinfo und deploy-button nur bei internen mitarbeitern anzeigen (und dann nur klein im Footer)"). Die technische Betriebsinfo stand prominent im Kopf — an zwei Stellen: der App-Shell-Kopf (app.component, Version + Deploy-Badge) und der Cockpit-Kopf (cockpit.component, Version). Beide zeigen sie jetzt klein im Fuß und nur für eine aufgelöste Staff-Identität (@if (ich())): App-Shell → footer.md-footer; Cockpit → neue footer.mw-footer (Grid-Zeile auto ergänzt), inkl. Deploy-Badge (Deploy-Signal + Helfer in den Cockpit portiert). Öffentliche/Portal-Strecken zeigen die Betriebsinfo weiterhin nie. +2 gemockte E2E (smoke.spec.ts: Cockpit & /verwaltung — Info im Fuß, nicht im Kopf) → 26 gemockt / 34 E2E. ng build+client/e2e 26/26+tsc+Doku grün. PATCH.

MED-D-323 (2026-09-25) — Auto-Migration restart-sicher (MED-OP-MIGRATE-1 ✅) (0.144.0→0.144.1, PATCH; Nutzer: „MED-OP-MIGRATE-1 beheben"). migrate.ts setzte die schema_version-Marke bisher einmal am Ende der ganzen SCHRITTE-Schleife → ein Absturz mitten in der Migration (z. B. nach einem ALTER TABLE … ADD COLUMN, vor dem finalen Update) ließ den nächsten Start dieselbe, nicht-idempotente DDL erneut ausführen → duplicate column blockiert den Worker-Start. Fix: jeder Schritt wird jetzt atomar angewandt — die DDL des Schritts und der Versions-Bump auf schritt.version laufen in einem db.batch(...) (D1 klammert einen Batch in eine Transaktion). Absturz mitten im Schritt → Transaktion nicht committet → nichts angewandt, schema_version bleibt beim Vorgänger → Neustart wiederholt nur diesen Schritt sauber. Behebt den systemischen Fehler für alle Versionen (nicht nur v42). +3 Vitest (neues db/migrate.test.ts mit minimalem Fake-D1 inkl. atomarer batch() + Absturz-Simulation; erste Bausteine Richtung MED-OP-TEST-1) → 785. tsc+785 Vitest+Doku-Check grün. PATCH.

MED-D-322 (2026-09-25) — OP-DM-8 Mail-Selbsttest (Diagnose-Button) (0.143.0→0.144.0, MINOR; Nutzer: „OP-DM-8 ist eingerichtet, bitte testen"). Da ein echter Live-Versand von außerhalb der Prod-Umgebung (hinter Cloudflare Access) nicht auslösbar ist und bewusst kein unauthentifizierter Test-Endpoint existiert, ist die verlässliche Verifikation ein admin-gesicherter Selbsttest: POST /api/diag/test-mail (Guard benutzer_verwalten) sendet eine echte Test-Mail an die eigene eingeloggte Adresse über den konfigurierten Kanal. Die Antwort meldet ehrlich kanal + zugestellt — cloudflare-email/zugestellt=true = echte Mail raus, log/zugestellt=false = kein send_email-Binding → NICHTS zugestellt, 502 = Provider-Fehler (z. B. Domain noch nicht verifiziert). PII-arm auditiert (nur Kanal/Erfolg, nicht die Adresse; G-4/G-6). Client: Verwaltung → „Betrieb & Diagnose" → „Test-Mail an mich senden" (nur Admin). +4 Vitest → 782, +3 Client-E2E (verwaltung.spec.ts) → 24; tsc+782+client/e2e+ng build+Doku grün. MINOR. Live-Verifikation: der Nutzer löst zusätzlich den No-Code-Seam (Portal-Zugang an die eigene Adresse) aus.

MED-D-321 (2026-09-25) — Doku-/Kommentar-Konsistenz: stale OP-DM-8-Referenzen aufgeräumt (Doku/Kommentar-only, keine Versionsänderung). Der E-Mail-Versand ist gebaut (Cloudflare Email Service, MED-D-314); Kommentare/Docs, die ihn noch als „offen" führten, auf „gebaut, Live-Gate = Domain-Onboarding" angeglichen. (Nachtrag im Doku-Audit-Refresh v0.150.0, B60 — fehlte in §2.)

MED-D-320 (2026-09-25) — MED-OP-PORTAL-2 Teil 2: mehrere Kontakt-Logins je Mandant (0.142.2→0.143.0, MINOR; Nutzer: „MED-OP-UX-14, danach MED-OP-PORTAL-2"; löst MED-KB-13 (3)). Ein Mandant kann mehrere Kontaktpersonen mit je eigenem Portal-Login haben. Datenmodell war nie 1/Mandant-beschränkt (email global eindeutig) → Gap war die Verwaltungs-Fläche. Server: Repo listePortalKontenFuerMandant+setzePortalKontoStatus; PortalService.kontenFuerMandant/kontoSperren/kontoReaktivieren (Scope-Guard, PII-armes Audit; Sperre beendet laufende Sessions). Staff-Routen GET …/portal-konten + POST …/portal-konto/:kontoId/{sperren,reaktivieren}. Client: mandant-einladungen zeigt die Kontakt-Liste + Sperren/Reaktivieren. Sperren statt Hard-Delete; Staff-gated (Zero-Trust); DSGVO-Autorisierung je Kontakt beim Staff (RISK-36). +3 Vitest → 778; Client ng build-verifiziert; tsc+778+client/e2e 21/21+ng build+Doku grün. MINOR.

MED-D-319 (2026-09-25) — MED-OP-UX-14 aufgelöst: Primary-CTA-Farbe + Verlassen-Modal → md-overlay + Command-Palette abgesichert (0.142.1→0.142.2, PATCH; Nutzer: „MED-OP-UX-14, danach MED-OP-PORTAL-2"). Part A: die zwei Primary-Grüns vereinheitlicht → .mw-btn.primary/.mw-scope button.primary nutzen das Markengrün --md-green (wie global button.primary); --accent bleibt für Fokus/Füllung/Spine/Links. Part B: Verlassen-Modal auf die geteilte md-overlay-Shell umgestellt (role=dialog/Fokus-Falle/-Rückgabe/Esc/Backdrop) → hand-gerollte Mechanik (window:keydown-HostListener + ViewChild + manuelle Fokusverwaltung) entfernt. Command-Palette bleibt bewusst KEINE md-overlay (Spotlight-Muster) → per Interaktions-E2E abgesichert. Bewusst nicht: Pixel-Visual-Regression-Infra + Merge der 3 (absichtlich gelayerten) Button-Basen. +3 gemockte E2E (cockpit-overlays.spec.ts); 775 Vitest unverändert; ng build+client/e2e 21/21+tsc+Doku grün. PATCH.

MED-D-318 (2026-09-25) — UI/UX-Konsistenz- & Rough-Edges-Pass (Audit) (0.142.0→0.142.1, PATCH; Nutzer: „Prüfe gründlich auf inkonsistente ui/ux/rough edges" → „Alles inkl. Refactorings"). Zwei-Achsen-Audit (Terminologie/Labels + Interaktion/a11y) + Token-Analyse. Behoben: Landing-Markenfarbe blau→Markengrün; undefinierte CSS-Tokens --md-text/--md-chip (Dark-Theme); gegenderte Pille „wartet auf Kundin"→zentrales Label; „Fake-"→„Demo-Provider"; „Magic-"→„Anmelde-Link"; konkrete Server-Fehlermeldung + gemeldet-Guard in 2 Overlays; Ladeindikatoren in 4 Register-Panels; Wizard-/Popover-Fokus; klickbares <li> + aria-label; In-Flight-Guards (5 Cockpit-Aktionen + Timer); labels.ts-Nachbauten zurückgeführt (behob entfällt→„offen"). Getrackt statt blind refaktoriert: Button-System-Vereinheitlichung + Overlay-Migration (Command-Palette/Verlassen-Modal → md-overlay) = MED-OP-UX-14 (§4) — visuelle/Interaktions-Refactors ohne Testdeckung, im Code als Konvention dokumentiert. Tests unverändert 775 Vitest / 18 E2E; tsc+775+client/e2e 18/18+ng build+Doku grün. PATCH.

MED-D-317 (2026-09-25) — Öffentliche WIP-Landing auf medidentas.com + robots.txt/KI-Trainings-Hinweise + CodeRabbit-Nachlese #343 (0.141.0→0.142.0, MINOR; Nutzer: „erstelle eine Landing-Page unter medidentas.com … Ist portal.medidentas.com vielleicht besser für alle? … robots.txt und ai-training notes ergänzen"). Domain-Entscheidung: app.medidentas.com bleibt der kanonische Login für Mitarbeiter UND Kunden (kein Umzug auf portal. — app. ist live an Access/DocuSign/APP_URL/Magic-Link/R2/Cookies verdrahtet; portal. optional später als 301 → app.). Neuer server/src/oeffentlich-site.ts (pure): statische WIP-Landing (noindex, „Zur Anmeldung" → app.medidentas.com) auf Apex/www + robots.txt (host-abhängig) + /ai.txt + /.well-known/tdmrep.json (W3C TDMRep) auf allen Hosts, Antworten mit X-Robots-Tag: noai, noimageai/tdm-reservation:1. In index.ts ganz vorne verdrahtet (Marketing-Seite ohne D1/Access/Assets); wrangler.toml Apex+www als custom_domain-Routes. Golden Rule: Apex/www = dokumentierte Public-Ausnahme. KI-/TDM-Opt-out (DSM-RL Art. 4/§44b UrhG) + Impressumspflicht (§5 DDG/ECG) proaktiv geflaggt (Deploy.md §10, Risikoregister). Nachlese #343: dokFarbe-Tokens --warn/--muted→--amber/--mut; uploadLaeuft→Set<docId>; Decision-Log-Backtick. Backlog: magic-byte-Content-Prüfung. +11 Vitest → 775. tsc · 775 Vitest · client/e2e 18/18 · ng build · Doku-Check grün. Deploy-Restschritt: Apex/www gehen beim nächsten Deploy öffentlich live (DNS+Cert via wrangler); Impressum/Datenschutz ergänzen. MINOR.

MED-D-316 (2026-09-25) — Portal-Dokument-Upload (MED-OP-PORTAL-2 Teil 1) (0.140.0→0.141.0, MINOR; Nutzer: „Upload zuerst"). Der eingeloggte Kunde lädt seine im Portal-Dashboard gelisteten angeforderten Dokumente selbst hoch, statt über den anonymen Einmal-Link. Neuer domain/upload-pruefung.ts (pruefeUpload: ≤15 MB, Endungs-Whitelist, Doppel-Endung foo.pdf.js→abgelehnt) + Route POST /oeffentlich/portal/dokumente/:docId/upload (flag-gated→404 dormant · Session→401 · eigener Mandant →404 kein Existenz-Leak · nur angefordert/erhalten→sonst 409 · Multipart datei→pruefeUpload→ bestehende DokumentService.hochladen = R2-Put + Status erhalten + Item-Propagation + Audit, G-1/G-4; PII-armes Zusatz-Audit portal.dokument_hochgeladen). Token-Upload-Weg (…/ablage/upload/:token) mit derselben Prüfung gehärtet. PortalService.dashboard liefert nun dokumente:[{id,bezeichnung,status}] (kein Pfad/PII). Client: /portal-„Ihre Dokumente" mit Datei-Upload je offenem Dokument. +9 Vitest → 764 (neue upload-pruefung.test.ts) + 1 gemockte E2E → 18 gemockt / 26 E2E. tsc · 764 Vitest · client/e2e 18/18 · ng build · Doku-Check grün. Offen (MED-OP-PORTAL-2 Teil 2): mehrere Kontakt-Logins je Mandant. MINOR.

MED-D-315 (2026-09-25) — Portal-Zugang automatisch beim Kunden-Anlegen (0.139.0→0.140.0, MINOR; Nutzer: „Wenn ein Kunde angelegt ist, soll das Portal direkt für ihn verfügbar sein. email sollte schon bekannt sein"). Neue PortalService.zugangSicherstellen(mandantId, email, basisUrl, config): legt bei bekannter Kontakt-E-Mail (nur wenn Portal aktiv) ein Portal-Konto an + sendet genau einmal den Einladungs-Magic-Link — idempotent (email_vergeben → kein zweites Konto/Invite), nicht-fatal. Verdrahtet an POST /api/mandanten (Anlage mit E-Mail) + PATCH /api/mandanten/:id (E-Mail gesetzt/geändert); beide Hooks brechen die Mandant-Operation bei Portal-/Mail-Fehler nie. Manueller Staff-Weg bleibt Fallback (abweichende E-Mail). Design-Wahl (AskUserQuestion): Invite sofort senden; Auslöser = Anlage + späteres Bekanntwerden. Edge: geänderte E-Mail → Konto für die neue Adresse (Dedup/Mehr-Kontakt = MED-OP-PORTAL-2). +4 Vitest → 755. tsc · 755 Vitest · ng build · Doku-Check grün. MINOR.

MED-D-314 (2026-09-25) — Cloudflare Email Service als einziger Mail-Provider (MailChannels raus) (0.138.1→0.139.0, MINOR; Nutzer: „wieso nutzen wir nicht cloudflare send mail?" → „Cloudflare, MailChannels ganz raus" → „MED-D-314 starten"). Neuer benachrichtigung/cloudflare-email.ts über das plattform-native send_email-Binding (env.EMAIL.send({to,from,subject,text}) → {messageId}); DKIM/SPF signiert Cloudflare über die onboarded Absender-Domain → kein DKIM-Key im Repo, kein externer Vendor (G-1), ein Sub-Prozessor weniger (vereinfacht das MED-KB-13-Residenz-Gate). Selector in index.ts: EMAIL-Binding → CF-Email, sonst dormant → Log-Kanal; pruefePortalKonfig prüft jetzt das Binding. wrangler.toml: [[send_email]] name="EMAIL" (per wrangler deploy --dry-run als „Send Email: EMAIL: unrestricted" verifiziert), MailChannels-/DKIM-Vars raus. Entfernt: mailchannels.{ts,test.ts}; neu: cloudflare-email.test.ts. Nicht-fatal (Portal/Staff-Login) bleibt gewahrt (Send vor Domain-Onboarding wirft, ohne den Login zu 500en). −6/+5 Vitest → 751. Deploy-Restschritt (Deploy.md §7e): Absender-Domain medidentas.com im Cloudflare Email Service onboarden (statt MAILCHANNELS_API_KEY+DKIM-DNS). Verifikation: tsc · 751 Vitest · ng build · Doku-Check grün. MINOR. — Merge-Queue (MED-D-313): Bootstrap live bewiesen (merge_group-CI lief im Queue-Ref für #340), danach vom Nutzer wieder deaktiviert („merge queue aus"); merge_group-Trigger bleibt auf main bereit.

MED-D-312 (2026-09-23) — CodeRabbit-Nachlese zu #339: Login-Härtung + Mailversand-Robustheit + Rate-Limit-Retention + Doku-Sync (0.138.0→0.138.1, PATCH; Nutzer: „ja"). CodeRabbits Review landete zur Merge-Minute von #339 (nach dem Auto-Merge) → echte Befunde als frische Änderung auf main nachgezogen. Server: (1) Sicherheit (Major, G-4): die /api/*-Identitäts-Middleware nutzt eine Staff-Session nur, wenn sie zur verifizierten Access-Identität passt oder keine vorliegt — A's 12h-Session überschreibt auf geteiltem Gerät nicht B's spätere Access-Anmeldung (sonst falscher Audit-Akteur); latent, da Staff-Login dormant. (2) Stabilität (Major): 8s-AbortController-Timeout am MailChannels-fetch; Mailversand in portal/staff-anmeldenAnfordern nicht-fatal (kein 500/kein Enumeration-Leak); erinnerungenVersenden je Erinnerung isoliert (kein Cron-Abbruch). (3) Datenschutz (Minor, G-6): repo.bereinigeRateLimits(vor) (D1+Memory) räumt abgelaufene rate_limit-Fenster im Cron (30-Min-Kappe) → keine unbegrenzte pseudonyme-PII-Retention. (4) Guard (trivial): Startup-Warnung bei PORTAL_AKTIV="true" ohne MAILCHANNELS_API_KEY/TURNSTILE_SECRET. Client: Turnstile-Token nach jedem Login-Versuch geleert + Widget zurückgesetzt (Einmal-Token). Round-2 (CodeRabbit nach „ready", tiefer, 4 Befunde): (a) MailChannels-8s-Timer bleibt bis nach dem Fehler-Body-res.text() aktiv; (b) erinnerungenVersenden trennt Zustellung+Markierung (retrybar) vom Audit danach (Audit-Fehler ≠ „unversendet", kein Doppelversand, G-4); (c) Portal-/Staff-anmeldenAnfordern schreiben zustellung-Status PII-arm ins Audit statt still zu schlucken; (d) Rate-Limit-Cleanup läuft im Cron zuerst. Doku-Sync: Portal-Go-Live-Stand in Management-Summary/MVP-Scope/Feature-Liste/Lastenheft/Kunden-Self-Service-Portal/Kunden-Besprechungspunkte/Doku-Review nachgezogen — EU-/CH-Residenz-/AVV-Nachweis bleibt explizit als Go-Live-Gate (Kundenfreigabe belegt nicht die Residenz). Übersprungen (MED-D-144): Straight-Quote-Nits + Docstring-Coverage-Warnung. Tests: +6 Vitest (staff-login/portal/wiedervorlage) → 752. Gefaltet: MED-D-313 (immer Auto-Merge + Merge-Queue): ci.yml merge_group-Trigger + Job-Gates != 'pull_request' + paths-filter nur auf PR → CI Gate läuft im Queue-Ref; agents.md §6.5/§7 aktualisiert. Verifikation: tsc · 752 Vitest · client/e2e 17/17 · ng build · Doku-Check grün. PATCH.

MED-D-311 (2026-09-23) — Portal-Login-Härtung: Turnstile + Rate-Limiting am öffentlichen anmelden (löst MED-OP-PORTAL-3) (0.137.0→0.138.0, MINOR; Nutzer: „bau die Härtung (MED-OP-PORTAL-3)"). Schließt die in MED-D-310/RISK-33 als VOR dem Cloudflare-Access-Bypass zwingend geflaggte Lücke: der mit PORTAL_AKTIV="true" öffentlich erreichbare POST /oeffentlich/portal/anmelden war ohne Bot-/Missbrauchsschutz ein Bot-/Mail-Flut-Vektor. Gebaut (Server): fensterbasiertes Rate-Limiting — repo.pruefeRateLimit(schluessel, limit, fensterMs, jetzt) (Tabelle rate_limit, Migration v62, additiv; D1 atomarer ON CONFLICT-Upsert mit RETURNING, Memory-Repo als Map). Am anmelden: je IP 20 / je E-Mail 5 pro gleitendem 10-Min-Fenster → 429 rate_limit; Schlüssel gehasht (hasheBearer/SHA-256 → PII-arm, G-6); 429 kontounabhängig (kein Enumeration-Leak). Turnstile am anmelden (reuse verifyTurnstile, G-1; dormant ohne TURNSTILE_SECRET → Rate-Limit bleibt die zweite, immer aktive Verteidigung) + neuer flag-gated GET /oeffentlich/portal/config (nur turnstileSitekey, kein Secret). Client: die Portal-Login-Seite rendert das Turnstile-Widget (reuse ladeTurnstileScript/bindeTurnstileCallback), lädt den Sitekey aus /portal/config, sendet das Token mit; 429/bot_check verständlich gemeldet. Reihenfolge: Turnstile → Rate-Limit → anmeldenAnfordern. Tests: +3 Vitest (portal.test.ts) → 746; portal-E2E-Login-Mock um /portal/config ergänzt. Verifikation: tsc · 746 Vitest · client/e2e 17/17 · ng build · Doku-Check grün. Restschritt vor öffentlichem Betrieb (Deploy.md §7e): TURNSTILE_SITEKEY/TURNSTILE_SECRET setzen (sonst nur Rate-Limit aktiv), dann Cloudflare-Access-Bypass für /portal. MINOR.

MED-D-310 (2026-09-23) — Portal-Go-Live: echter Mailversand (MailChannels, OP-DM-8) + Kundenportal scharfgeschaltet (0.136.0→0.137.0, MINOR; Nutzer zeigte auf die „Aktualisierung anfordern"-Links in der Akte: „es soll doch das self-service-portal für kunden geben - dann brauchen wir diese aktualisierungslinks nicht" → per AskUserQuestion „Portal jetzt scharf schalten"; MED-KB-13 = „liegt vor", Provider = MailChannels). Zwei harte Gates geflaggt + geklärt: OP-DM-8 (es gab keinen echten Mailversand → Magic-Link-Login funktional unmöglich) und MED-KB-13 (DSGVO/AVV-Kundenfreigabe für die persistente öffentliche Kundenfläche, Golden Rule — vom Nutzer bestätigt). Gebaut (Server): MailChannels-Adapter benachrichtigung/mailchannels.ts (HTTP-fetch, X-Api-Key, optionale DKIM-Signatur, Körper inkl. Magic-Link nie geloggt G-5/G-6), dormant/deploy-sicher ohne MAILCHANNELS_API_KEY → Log-Kanal; in index.ts als ein Kanal für App + Cron verdrahtet (Portal-/Staff-Magic-Link · Formular-Feedback · Wiedervorlage/SLA, G-2). Portal-Magic-Link-Bug behoben: Link zeigte auf den API-Endpunkt /oeffentlich/portal/login?token= (rohes JSON für den Kunden) → korrigiert auf die Client-Route /portal?token=. Aktiviert: PORTAL_AKTIV="true" (PORTAL_TEST_MODE bleibt aus). Client: neuer „Kundenportal"-Abschnitt in der Akte (mandant-einladungen.component.ts) — Staff richtet den Portal-Zugang für die Kontakt-E-Mail ein (POST /api/mandanten/:id/portal-konto, 409 idempotent) + Portal-Link kopieren; die bisherigen Einmal-Links laufen unter „Dokumente & Onboarding anfordern" weiter (Portal deckt Stammdaten-Self-Service ab, nicht Dokument-Upload → volle Ablösung als MED-OP-PORTAL-2 notiert). +6 Vitest (743); portal.test.ts an die neue Link-Form angepasst. Verifikation: tsc · 743 Vitest · client/e2e 17/17 · ng build · Doku-Check grün. Deploy-Restschritte (nicht Code, Deploy.md §8): wrangler secret put MAILCHANNELS_API_KEY (+DKIM-DNS auf medidentas.com) und Cloudflare-Access-Bypass für /portal + /oeffentlich/portal/* (dokumentierte Public-Ausnahme zur Golden Rule) — bis dahin ist das Portal erreichbar, aber Login-Mail stumm. MINOR.

MED-D-309 (2026-09-22) — Staff-Magic-Link-Login „hinter Access" (dormant) (0.135.0→0.136.0, MINOR; „login per email magic link; bekannte email ist m.kirchhof@drkv.com, in der Verwaltung können weitere mitarbeiter-accounts mit eMail angelegt werden" → per AskUserQuestion „Magic-Link hinter Access"). Sicherheits-Weggabelung geflaggt (Golden Rule/G-1/D-8): ein Mitarbeiter-Login könnte Cloudflare Access ersetzen (neues öffentliches Tor) → Widerspruch zur Golden Rule + D-8 (kein Eigenbau-Login). Nutzerwahl: Access bleibt das äußere Tor, der Magic-Link ist eine additive App-Session-Schicht darauf (kein neues öffentliches Tor). Zwei Nutzeranforderungen, beide erfüllt: (1) passwortloser Magic-Link-Login je E-Mail; (2) „weitere Mitarbeiter-Accounts in der Verwaltung anlegen" — kein neues Account-Modell (G-1/G-2): Account-Store = die in der Verwaltung gepflegten Benutzer (Benutzer & Rollen, R7, benutzer) + Bootstrap-Admin (m.kirchhof@drkv.com); die Rollen-Auflösung bleibt bei aufloeseAkteur. Gebaut (dormant hinter STAFF_LOGIN_AKTIV): eigener Realm auf denselben gehärteten Magic-Link-Primitiven wie das Kunden-Portal (domain/portal-auth.ts, realm-agnostisch), strikt getrennte Tabellen staff_anmelde_token/staff_session (Migration v61, additiv). StaffLoginService: No-Enumeration · atomarer Einmal-Token-Claim (kein Replay) · Session-zuerst · Idle+Absolut-TTL · Bearer nur als SHA-256-Hash at rest (MED-D-280-Muster). 3 Routen unter /api/* (bleiben hinter Access) + flag-gated → 404 dormant: POST /api/staff-login/anmelden · GET …/login?token= · POST …/abmelden; Cookie staff_session HttpOnly/Secure/SameSite=Lax/Path=/. Das /api/*-Middleware bevorzugt eine gültige Staff-Session, fällt sonst auf Access zurück (additiv/non-breaking: Flag aus = exakt bisheriges Verhalten). Audit PII-arm (staff.anmeldung_angefordert/staff.eingeloggt, mandantId:null, keine E-Mail im Detail). Client: staff-login.component.ts (md-staff-login) an der chrome-losen Route /anmelden (eigene .md-pub-Karte, istAnmeldung); Zustände login→link_gesendet(+Test-Link im STAFF_LOGIN_TEST_MODE)→eingeloggt(→Reload /) / dormant (404) / link_ungueltig (401); 3 API-Methoden (withCredentials). +7 Vitest (staff-login.test.ts) → 737; +3 gemockte E2E (client/e2e/staff-login.spec.ts) → 17 gemockt/25 gesamt. Verifikation: tsc · 737 Vitest · client/e2e 17/17 · ng build · Doku-Check grün. Go-Live (STAFF_LOGIN_AKTIV=true) bleibt offen — braucht echten Mailversand (OP-DM-8) + explizite Freigabe (Golden Rule). MINOR.

MED-D-308 (2026-09-14) — S5-UI: Kunden-Self-Service-Portal Client-UI (dormant) (0.134.0→0.135.0, MINOR; „s5/n3" → per AskUserQuestion „Full dormant Portal UI"). Bis dato hatte das Portal (S1–S4, MED-D-282/283/304) nur Server-Endpunkte, keine Kundenoberfläche. Golden-Rule-Flag (verbindlich): der eigentliche Go-Live (S5/N3, „Portal als einziger Zugang") ist außenwirksam und bleibt am Gate MED-KB-13 (DSGVO/AVV) + OP-DM-8 (echter Mailversand) → PORTAL_AKTIV nicht gesetzt; die Client-UI ist genauso dormant (alle Endpunkte → 404, bis freigeschaltet). Gebaut (Client-only, reuse): portal-public.component.ts (md-portal-public) an /portal, gleiche .md-pub-Handschrift; Zustände dormant→login (Magic-Link, Test-Link im PORTAL_TEST_MODE)→dashboard. Dashboard (S3): eigener Onboarding-Fortschritt + offene Items + Formular-/Selbstauskunft-Status (rein abgeleitet, G-2). Proaktive Einreichung (S4): 11 whitelisted Felder → stammdaten-vorschlag (kein Stammdatum geschrieben, 4-Augen bleibt). Login via ?token=. Server unverändert; +6 Portal-API-Methoden/DTOs. +3 gemockte E2E (portal.spec.ts) → 14 gemockt/22 gesamt. Verifikation: ng build · client/e2e 14/14 · 730 Vitest unverändert · Doku-Check grün. Go-Live (PORTAL_AKTIV=true) bleibt offen (MED-KB-13/OP-DM-8). MINOR.

MED-D-307 (2026-09-14) — N5: Onboarding-Einwilligung über DocuSign statt SES-Attrappe (OP-SIGN-1), flag-gated/dormant (0.133.1→0.134.0, MINOR; Nutzer: „dann n5"). Setzt MED-D-291 Q3 um. Compliance-Flag (verbindlich): Spannung D-30 (Einwilligung = SES-Häkchen, DocuSign an Verträgen) vs. MED-D-291 Q3 (DocuSign-Consent) — per Flag aufgelöst, live-Default bleibt SES. Gebaut (Server-only, G-1): die Onboarding-Einreichung kann die Einwilligung über den echten SignaturService/DocuSign-Pfad führen — Einwilligungs-PDF erzeugen (reuse pdf-dokument.ts) → ablegen (R2) → Dokument angefordert → SignaturService.anfordern(dok,'SES',{Kunden-Mail}) (emailter Envelope) → Abschluss via bestehenden Connect-Webhook → abgleich. eIDAS SES (Matrix). Flag EINWILLIGUNG_PROVIDER=docusign, dormant (greift nur mit Provider+Ablage; sonst SES-Attrappe, deploy-/secret-sicher); Provider-Fehler → consent_provider_fehler (502, kein stiller Fallback); Audit wahrheitsgemäß (einwilligung.angefordert bis Signatur, dann signatur.signiert). Client unverändert. Geteilter SignaturService für Signatur-Routen + Consent. +3 Vitest (730). Verifikation: tsc · 730 Vitest · Full-Stack-E2E 8/8 · Doku-Check grün. Go-Live (Flag in Prod) bleibt am OP-SIGN-1-Gate (echte Rechtswirkung + AVV, RISK-4). MINOR.

MED-D-306 (2026-09-14) — Kollisionssicheres Hash-Schema 3 + Ablehnung unbekannter Schema-Marker (G-4), CodeRabbit-Nachlese zu #332 (0.133.0→0.133.1, PATCH). Zwei Major-Review-Befunde auf dem gemergten MED-D-305-Code aufgegriffen (echte Tamper-Evidenz-Lücken): (1) Schema 2 feld=wert-Join mit ungeschützten =/|-Trennern → Freitext-Kollision zweier verschiedener Snapshots auf denselben Hash; (2) stiller Fallback + nicht gebundener Marker → Umschreiben eines gespeicherten hashSchema (2→3) unentdeckt. Gebaut (Server-only): Schema 3 = JSON.stringify der sortierten [key, wert|null]-Paare (feldset-tolerant und eindeutig) als neuer AKTUELLES_HASH_SCHEMA; Schema 1 & 2 byte-stabil belassen (nur neue Versionen schreiben 3). kanonischerSnapshot wirft bei unbekanntem Schema; pruefeVersionsKette meldet hashSchema ∉ {1,2,3} als Kettenbruch (UNTERSTUETZTE_HASH_SCHEMATA). Nebenbei stale Test-Zähler 692→727 korrigiert; Quote-Nits übersprungen (MED-D-144). +4 Vitest (727). Verifikation: tsc · 727 Vitest · Full-Stack-E2E 8/8 (schema-3-Schreibpfad) · Doku-Check grün. Keine neue Migration (hash_schema seit v60). PATCH.

MED-D-305 (2026-09-14) — Feldset-tolerante Stammdaten-Hash-Kette (G-4); die 6 Onboarding-Grunddaten jetzt versioniert (0.132.0→0.133.0, MINOR; „n4" → per AskUserQuestion „Kette feldset-tolerant machen"). Löst den in MED-D-284 explizit als Folge-OP notierten Kettenbruch: die per-Mandant Stammdaten-Hash-Kette (MED-D-179) re-hashte gegen die fixe VERSIONIERTE_FELDER-Reihenfolge → jedes neue versionierte Feld hätte alle Bestands-Ketten in Produktion gebrochen. Gebaut (rückwärtskompatibel, Tamper-Evidenz bleibt intakt): je Version ein hashSchema-Marker (Spalte stammdaten_version.hash_schema, Migration v60 ADD COLUMN … NOT NULL DEFAULT 1, additiv/idempotent). Schema 1 (Bestand): eingefrorene 12-Feld-Reihenfolge VERSIONIERTE_FELDER_V1 → byte-identische Hash-Eingabe, Alt-Zeilen verifizieren unverändert. Schema 2 (neu, feldset-tolerant): kanonischerSnapshot serialisiert über die eigenen Keys des gespeicherten Snapshots (sortiert) — ein späteres weiteres Feld ändert keine bereits geschriebene Zeile. versionHash/pruefeVersionsKette/baueNaechsteVersion schema-bewusst; neue Versionen schreiben immer Schema 2 (AKTUELLES_HASH_SCHEMA). Payoff: die 6 MED-D-284-Grunddaten (handynummer·steuernummer·steuerberater{Name,Kanzlei,Email,Telefon}) sind jetzt in VERSIONIERTE_FELDER/StammdatenSnapshot → tamper-evidente Versionen (GoBD/§147 AO) + Feld-Historie im Detail-Overlay (VersionedField). Client: Typen ergänzt (6 Felder + hashSchema) + 6 md-versioned-field-Zeilen. +6 Vitest (723). Verifikation: Server tsc + 723 Vitest · client/e2e 11/11 · Full-Stack-E2E 8/8 (v60 bootet sauber) · ng build · Doku-Check grün. MINOR.

MED-D-304 (2026-09-14) — Kunden-Self-Service-Portal S3 (Dashboard) + S4 (proaktive Einreichung), dormant (0.131.0→0.132.0, MINOR; neuer PR nach dem Merge von #330). Nutzer: „n3" → per AskUserQuestion „S3 + S4 Einreichung" (N3-Go-Live selbst bleibt am Gate MED-KB-13). Golden-Rule-Flag: N3 („Portal als einziger Zugang") = Portal-Go-Live (S5) und ist an die offene DSGVO/AVV-Kundenfreigabe (MED-KB-13) + echten Mailversand (OP-DM-8) gebunden — nicht ohne Freigabe scharf zu schalten. Deshalb die unblockierten, dormanten Portal-Slices gebaut. S3 (Dashboard): PortalService.dashboard(rohSessionId) → kompakte, kundensichere Statusübersicht des EIGENEN Mandanten (Onboarding-Fortschritt + offene Items + Formulare offen/eingereicht/freigegeben + Self-Service-Status), rein abgeleitet (G-2), Route GET /oeffentlich/portal/dashboard (flag-gated, session-authed). S4 (proaktive Einreichung): POST /oeffentlich/portal/stammdaten-vorschlag — der Kunde schlägt Stammdaten-Updates vor (whitelisted auf ONBOARDING_STAMM_REGELN-Felder); es wird kein Stammdatum geschrieben — die Einreichung landet als self_service-FormularVorgang (status eingereicht) und läuft durch dieselbe 4-Augen-Feld-Sichtung/Übernahme (MED-D-89/84, Quelle self_service); uebernahmeVorschlag/uebernehmen typ-bewusst (self_service → Onboarding-Regelset). Berater-Sicht: GET /api/mandanten/:id/selbstauskuenfte + Sektion „Kunden-Vorschläge (Self-Service)" in mandant-formulare (reuse md-mandant-stammuebernahme). Dormant (PORTAL_AKTIV=false → 404); keine Live-PII, kein Go-Live. +5 Vitest (717). Verifikation: Server tsc + 717 Vitest · client/e2e 11/11 · Full-Stack-E2E 8/8 · ng build · Doku-Check grün. MINOR.

MED-D-303 (2026-09-13) — Item↔Mandat-Zuordnung (interaktiv) (0.130.0→0.131.0, MINOR; neuer PR nach dem Merge von #329). Nutzer: „Item↔Mandat". Löst den in MED-D-301 als Folgeschritt notierten Punkt (interaktive Zuordnung mit Persistenz) ein. Gebaut: OnboardingItem.auftragRef (R2-F17, neue Spalte onboarding_item.auftrag_ref, Migration v59 additiv/idempotent) — ein Onboarding-Checklisten-Item kann einem gebuchten Beratungsmandat zugeordnet werden. Repo-Setter updateItemAuftrag (memory+d1), Service service.itemAuftragSetzen(mandantId, itemId, auftragRef) mandant-scoped validiert (Item gehört zum Onboarding dieses Mandanten, Auftrag gehört diesem Mandanten — kein Cross-Mandant-Verweis, MED-OP-AUTH-2), PII-arm auditiert (onboarding_item.auftrag_zugeordnet/_geloest, nur IDs). Route POST /api/mandanten/:id/onboarding-items/:itemId/auftrag ({auftragRef: string|null}; 400 ungültig · 404 fremdes Item/Auftrag). Client: je erforderlichem Checklisten-Item ein „Mandat"-Select (mandant-detail); die „Jetzt gebraucht"-Sicht zeigt jetzt pro aktivem Mandat die tatsächlich zugeordneten Items (mit Status), Fallback = abgeleiteter Produkt-Playbook-Bedarf (MED-D-301 Part B). Wirkung: True North #1/#2 — „was fehlt / was ist fällig" wird pro Mandat steuerbar. +3 Vitest (712) + 1 Full-Stack-E2E (onboarding-item-mandat.spec.ts, 8). Verifikation: Server tsc + 712 Vitest · client/e2e 11/11 · Full-Stack-E2E 8/8 (v59 bootet sauber + Roundtrip + Guard) · ng build · Doku-Check grün. MINOR.

MED-D-302 (2026-09-13) — Onboarding-Greenfield Slice G5: Alt-Code entfernt (dormante ausfuellformular-Tabelle + Repo-Methoden) (0.130.0, kein Bump — selber Branch/PR). Nutzer: „g5". Entfernt (seit G3E2 toter Code): AusfuellformularPatch + die 4 *Ausfuellformular*-Repo-Methoden (repo.ts), ausfuellformulare-Map + Methoden (memory-repo.ts), zuAusfuellformular/AusfuellformularRow + Methoden (d1-repo.ts), Drizzle-Tabelle ausfuellformular (schema.ts); Migration v58 DROP TABLE IF EXISTS ausfuellformular (risikolos: greenfield, seit MED-D-298 nicht mehr beschrieben). Behalten: historische Migrations-Schritte (append-only) + Ausfuellformular-Interface (externe alsFormular-Sicht des FormularVorgang). Kein Verhalten geändert. Verifikation: 709 Vitest + Full-Stack-E2E 7/7 (v58-DROP bootet sauber) + client/e2e 11/11 + tsc + Doku-Check grün. Damit Greenfield-Programm G1–G5 abgeschlossen.

MED-D-301 (2026-09-13) — Onboarding-Greenfield Slice G4: Item↔Vorgang-Link real + „aus Item anfordern" + Bedarf je Mandat (0.130.0, kein Bump — selber Branch/PR). Nutzer: „g4". Part A: FormularVorgang.onboardingItemId (seit G2 vorhanden, nie gesetzt) real verdrahtet — erstellen(…, onboardingItemId?) setzt den Link, je Item idempotent (ein offener Vorgang je Item; item-gebundene zählen nicht im generischen Parallel-Limit), alsFormular gibt ihn additiv nach außen, Route liest ihn. Client: die Onboarding-Checkliste (mandant-detail) zeigt je Dokument-Item den verknüpften Vorgang (Status + „Öffnen"/„Link kopieren") oder „Formular anfordern" (Vorlagen-Select) → Vorgang mit Item-Link → Checkliste treibt die Vorgänge (True North #1). Part B (MED-OP-ONB-1, Q4-Zusatz): abgeleiteter Onboarding-Bedarf gruppiert je gebuchtem Mandat („Jetzt gebraucht — aus den Beratungsmandaten") via AuftragMitLabel.benoetigt = Produkt-Playbook (G-1/G-2, nichts persistiert). Offen: interaktive Item↔Mandat-Zuordnung (neue Persistenz) → Folgeschritt; G5. Verifikation: 709 Vitest + client/e2e 11/11 + Full-Stack-E2E 7/7 + ng build + Doku-Check grün.

MED-D-294…300 (2026-09-13) — Onboarding voller Greenfield-Neubau (Option A), Slices G1–G3 gebaut (0.130.0, kein Bump — selber Branch/PR). Nutzer: „voller Greenfield-Neubau — keine Echtdaten, frei neu aufbauen" → „g1 / go / g3 / Etappe 2 (voller Rewrite) / Etappe 3 jetzt bauen". Design (MED-D-294): docs/architektur/Onboarding-Neubau.md — vier Einsen (ein Feld/G-8 + Feld-Engine · ein FormularVorgang statt 3 Services · ein Fluss · echter Item↔Vorgang-Link), Slice-Plan G1–G5. G1 ✅ (MED-D-295): kanonisches Feld + FormularSchema (feld.ts + formular-schema.ts-Adapter der 3 Alt-Kataloge), 3 Wichtigkeits-Achsen → eine Skala, Weltmodell §3.4, +9 Vitest. G2 ✅ (MED-D-296): eine FormularVorgang-Entität + Persistenz (Tabelle formular_vorgang, Migration v57) + schema-getriebener FormularVorgangService, +8 Vitest. G3 Etappe 1 ✅ (MED-D-297): geteilte PubFeldEngineComponent (Client) + Adoption im Ausfüll-Formular. G3 Etappe 2 ✅ (MED-D-298, voller Rewrite): Ausfüll-Flow komplett über den einen FormularVorgangService/formular_vorgang-Store (gesamte Logik portiert — Festwerte/KI/PDF-Beleg/WV/Rückübernahme/N2/SLA), AusfuellformularService gelöscht, HTTP-Vertrag erhalten. G3 Etappe 3a ✅ (MED-D-299): Onboarding-Strecke rendert über dieselbe Feld-Engine. G3 abgeschlossen ✅ (MED-D-300): Fork aufgelöst — eine Feld-Engine für die strukturell gleichen Wege (Ausfüll + Onboarding), Fragebogen bleibt bewusst purpose-built (reiche Domänen-UX = Feature, G-3), Store-Vereinheitlichung auf den Ausfüll-Flow begrenzt (keine Wide-Table, G-8). Offen: G4 (Item↔Vorgang-Link + „was jetzt dringend gebraucht wird", MED-OP-ONB-1) · G5 (dormante ausfuellformular-Tabelle entfernen) · N3–N5. Verifikation je Slice grün: Server tsc + 706 Vitest · client/e2e 11/11 · Full-Stack-E2E 5/5 · Doku-Check. Gesamt: 706 Vitest + 16 Playwright (11 gemockt + 5 full-stack).

MED-D-291/292 (2026-09-13) — Onboarding-Vereinfachung: 4 Richtungsentscheidungen + Slice N2 „Abschnitts-Freigabe" (0.129.0→0.130.0, MINOR). Nutzer: „klären die 4 Fragen, dann N1 und N2." Richtung (MED-D-291, §7 der Neubaustudie): Zugang = Portal-Konto + Token als Einmal-Login (→N3, nach DSGVO/AVV-Gate MED-KB-13); Prüfung = Abschnitts-Freigabe als Standard (→N2, jetzt); Einwilligung = SES vorerst (→DocuSign erst N5); Pflichtdaten = minimal + progressiv (G-6) plus Nutzer-Zusatz: der Betreuer muss angeben können, was jetzt dringend gebraucht wird, gruppiert aus den gebuchten Beratungsmandaten (neuer Punkt MED-OP-ONB-1, Teil von N1). Gebaut (MED-D-292, N2): die Feld-Sichtung (MED-D-89) bekommt einen 1-Klick-Standard „alles i. O." — alleAkzeptieren akzeptiert alle noch offenen Felder eines eingereichten Formulars in einem atomaren Server-Aufruf (statt N concatMap-Einzelrequests → kein Lost-Update, ein PII-armes Audit-Event formular.abschnitt_freigegeben); reine Domäne-Funktion akzeptiereOffene() lässt bestehende Entscheidungen (v. a. Ablehnung mit Grund) unangetastet → Feld-für-Feld-Ablehnung bleibt Ausnahmepfad. Route POST …/ausfuellformulare/:token/alle-akzeptieren; Client-Button „Abschnitt freigeben — alles i. O.". Wirkung: deutlich weniger Backoffice-Klicks (True North #2/#3), gleiche Auditierbarkeit (G-4). N1 1. Schritt gebaut (MED-D-293, „gebündelt/sicher" per AskUserQuestion): die wortgleich in allen 4 Public-Komponenten kopierte Lade-Fehler-Auswertung + Turnstile-Callback-Bindung sind jetzt geteilte Bausteine in pub-bausteine.ts (ladeFehlerAuswerten + bindeTurnstileCallback, verhaltensneutral, e2e-abgesichert) — H1-Anzahlung „ein Kontext/Turnstile". Bewusst deferiert: die volle Feld-Engine-Verschmelzung und der sichtbare Item↔Token-Vorgang-Link (heute kein Datenmodell-Link → braucht ausfuellformular.onboardingItemId via „aus Item erzeugen"; nächstes N1-Inkrement, MED-OP-ONB-1). Verifikation: 696 Vitest + e2e 9/9 + 1 neue Full-Stack-E2E + ng build grün lokal · Doku-Check grün. Gesamt: 696 Vitest + 14 Playwright.

MED-D-290 (2026-09-12) — Full-Stack-E2E gegen den echten Worker + DocuSign-Flow; Test-Pflege verbindlich (0.128.0→0.129.0, MINOR; löst MED-OP-E2E-1). Nutzer: „full-stack e2e gegen echten Worker+D1; ergänze auch den docusign-flow und halte alle automatischen tests immer aktuell." Gebaut: neue Playwright-Suite client/e2e-fullstack/ (4 Tests) gegen den echten Worker — start-worker.mjs bootet wrangler dev (workerd) mit lokaler D1 + R2 und Test-Overrides (AUTH_ENFORCED=false, SIGNATUR_PROVIDER=fake, ABLAGE_BACKEND=r2); ein Origin = UI + /api (kein Mock). Deckt Smoke+Health, Mandant anlegen→persistiert→Reload und den DocuSign-Flow end-to-end (Onboarding→provisionieren→Datei ins echte R2→senden→Vor-Ort-/Demo-Abschluss→Dokument „erhalten" + signierte Rückablage). Prüft den echten Datenpfad (Migration/D1-SQL/R2-Write-back/Provider-Lebenszyklus). CI-Job client-e2e-fullstack (gated bei client- oder server-Änderung, braucht server-Deps für wrangler) ist Teil des CI Gate. Test-Pflege dauerhaft: verbindliche Regel in agents.md/CLAUDE.md/Test-Uebersicht.md — jeder PR hält Server-Vitest + beide Playwright-Suiten (gemockt + full-stack) aktuell. Verifikation: e2e-fullstack 4/4 + e2e 9/9 grün lokal · ng build · 692 Vitest · Doku-Check grün. Gesamt: 692 Vitest + 13 Playwright.

MED-D-289 (2026-09-12) — E2E-/UI-Tests (Playwright) + Meisterwerk-Audits aufgefrischt (0.127.1→0.128.0, MINOR). Nutzer: „Audits auffrischen; haben wir automatische UI/UX-/E2E-Tests? Wenn nein, bauen und immer laufen lassen." Befund: es gab keine automatischen UI-/E2E-Tests — Client war nur ng build-abgesichert. Gebaut: erste Client-Test-Infrastruktur — Playwright-E2E-Suite in client/e2e/ (9 Tests: App-Shell-Smoke, Cockpit-Liste + Leerzustand, Onboarding-3-Schritte-Flow inkl. Lücken-Report/Happy-Path/ungültiger Token, Lead, ungültige Fragebogen-Einladung), gegen den fertigen Build mit gemockter API (deterministisch, ohne Worker/D1/Secrets). Neuer CI-Job client-e2e (gated wie client-build) ist Teil des CI Gate → läuft auf jedem Client-PR/main-Push. @playwright/test auf 1.56.0 gepinnt (Chromium 1194). Volllast-E2E (echter Worker+D1) = Folge-OP MED-OP-E2E-1. Audits (MED-OP-REVIEW-1): neue docs/betrieb/UX-Prozess-Review-2026-09.md + Doku-Review-2026-09.md (v0.128.0) lösen die v0.116.1-Runde ab; neue Backlogs MED-OP-UX-13 (B44–B45) + MED-OP-DOKU-10 (B53–B54), Alt-Backlog ehrlich weitergetragen. Verifikation: 9/9 E2E grün · ng build grün · Server 692 Vitest unverändert · Doku-Check grün.

MED-D-287/288 (2026-08-27) — Mandant-Detailsicht: Gutachten-Block & Ablage-Spiegel (0.127.0→0.127.1, PATCH). Zwei Screenshot-Anstöße des Nutzers: (1) MED-D-287 — der eigenständige Dentmarking-Gutachten-Block im Reiter „Mandate" wird nur noch angezeigt, wenn Praxen vorhanden sind ([hidden]-Gate um praxen().length === 0 erweitert), damit kein leeres Gutachten frei im Mandate-Reiter steht. (2) MED-D-288 — „Ablage soll nur der Spiegel der NextCloud-Dokumente sein": der Ablage-Reiter (R2) listet in der Hauptliste nur noch tatsächlich abgelegte Dokumente (Referenzen mit gesetztem nextcloudPfad). Provisionierte, aber noch nicht abgelegte erwartete Dokumente wandern in eine ausklappbare Unterliste darunter — mit erhaltenen Intake-Aktionen (Datei hochladen · Upload-Link · zur Unterschrift), bis eine Datei/Unterschrift eingeht und sie in den Spiegel wandern. Visuelle Option A (Filter über nextcloudPfad); die echte NextCloud-Live-Spiegelung bleibt MED-OP-FILES-1. Beide reine Client-Änderungen in mandant-detail.component.ts (+ .md-erwartet-Style in styles.css); ng build grün, kein Server-/Datenmodell-/Migrations-Belang.

MED-D-286 (2026-08-27) — Cockpit-Aufräumen (Mandant-Detailsicht) (im 0.127.0-Branch). Nutzer (2 Screenshot-Anstöße): (1) Beratungsmandate-Kurzkarten aus dem Reiter „Basis-Informationen" entfernt (Mandate haben den eigenen „Mandate"-Reiter; Basis = nur noch Onboarding-Dokumente); (2) Sidebar-Block „Beratungsmandate · nach Phase" entfernt. Dead-Code mitbereinigt (auftragBuckets/AUFTRAG_STATUS_ORDER/AUFTRAG_STATUS_FARBE/praxisName). Reine Client-Entfernung in mandant-detail.component.ts; ng build grün, kein Server-Belang.

MED-D-285 (2026-08-27) — Onboarding-Kundenstrecke als klarer 3-Schritte-Flow (Slice B) (0.126.0→0.127.0, MINOR). Nutzer: „klarer Flow … wo fehlt was?". Die öffentliche Onboarding-Seite (onboarding-public.component.ts) ist von einer flachen Seite auf einen 3-Schritte-Stepper umgebaut: ① Grunddaten erfassen → ② Übersicht „wo fehlt was?" → ③ Einwilligung & Absenden. Schritt ② ist der abgeleitete Lücken-Report (G-2, kein neuer State): fehlende Pflichtangaben (blockierend) getrennt von noch offenen optionalen Angaben (empfohlen) + aufklappbare Liste der erfassten Angaben. Schritt-Anzeige mit aria-current; Navigation Weiter/Zurück; Zwischenspeichern bleibt auf Schritt 1; Absenden erst auf Schritt 3 (Gate absendbar() unverändert). Reine Client-Umstrukturierung — kein Server-/Datenmodell-/Migrations-Belang, nutzt die bestehenden Endpunkte (kontext/entwurf/einreichen). handynummer→tel-Autocomplete ergänzt. Client ng build grün · Server unverändert (692 Vitest) · Doku-Check grün. Offen: Slice B-Rest (interne Steuerberater-Erfassung mit Art.-14-Info); Slice C = DocuSign-Einverständnis statt SES.

MED-D-284 (2026-08-27) — Onboarding-Grunddaten-Katalog erweitert (Handynummer · Steuernummer · Steuerberater-Fundament), datensparsam (0.125.0→0.126.0, MINOR). Nutzer: „Onboarding verbessern, klarer Flow … Grunddaten … wo fehlt was? … Daten erfassen, dann Einverständnis per DocuSign plus weitere Formulare." Entschieden: reguliertes PII → datensparsam (KEINE Steuer-ID §139b/KEINE Ausweisnummer §20 PAuswG; Personalausweis bleibt Upload-Nachweis); erster Slice → Kundenstrecke. Slice A (gebaut, Fundament): 6 neue plain mandant-Spalten (Migration v56) — handynummer · steuernummer · steuerberater{Name,Kanzlei,Email,Telefon} (Wertobjekte Kontakt/Steuer/Steuerberater). NICHT hash-versioniert (Anhängen an die fixe VERSIONIERTE_FELDER-Kette bräche bestehende per-Mandant-Ketten in Prod → plain wie betreuungsmodell). Öffentlich erhoben nur die eigenen Kundendaten Handynummer + Steuernummer (STAMMDATEN_FELDER); Steuerberater-Felder NICHT öffentlich (PII dritter Person → Art.-14-DSGVO-Gate, RISK-34) — Spalten + ONBOARDING_STAMM_REGELN als Fundament, Erhebung folgt Slice B. Einwilligungs-Fassung 2026-08-v2. PII-Begründung G-6/RISK-34; RISK-30 (Steuernummer-Teil) erledigt. +1 Vitest → 692 (ausfuellgrad 75→67 durch die neuen optionalen Felder). Nächste Slices: B = Mehrschritt-Strecke (① Grunddaten → ② „wo fehlt was?" → ③ Einverständnis) + Steuerberater/Art.-14; C = DocuSign-Einverständnis (embedded) statt SES. Server tsc+Vitest 692 · Client ng build · Doku-Check grün. CodeRabbit #321: Steuerberater-Public-Deferral, Konsens-Version-Bump, telefon-Label neutral, Weltmodell-Mermaid + Lastenheft-Feldrows ergänzt; bewusst offen (raise): der pre-existing Last-Writer-Wins in updateMandant (Voll-Zeilen-Write, betrifft ALLE Felder) → eigener OP (Optimistic Concurrency), nicht in diesem Slice.

MED-D-283 (2026-08-27) — Kunden-Self-Service-Portal: Slice S2 (passwortlose Auth-Routen, flag-gated) (0.124.0→0.125.0, MINOR). Nutzer: „passwortlos zum Testen, los" (MED-KB-13(a) beantwortet). Server: api/portal-service.ts + Routen POST /oeffentlich/portal/anmelden (No-Enumeration), GET …/login?token= (atomarer Einmal-Claim → HttpOnly-Cookie, at rest nur Session-Hash), GET …/ich (Idle+Absolut, Scope eigener Mandant), POST …/abmelden, Staff POST /api/mandanten/:id/portal-konto. Golden Rule: flag-gated (PORTAL_AKTIV dormant-Default; PORTAL_TEST_MODE gibt den Link zurück — nur Test). CodeRabbit-#320-Härtung: Login-Atomarität (Session zuerst, Token-Claim zuletzt → kein verbrannter Link bei Schreibfehler), Sperr-Check in sessionKonto (gesperrtes Konto → Session 401), istEmail an beiden Eingängen. +9 Vitest → 691. Testen: PORTAL_AKTIV=true+PORTAL_TEST_MODE=true in der Umgebung setzen → Staff legt Konto an (POST /api/mandanten/:id/portal-konto {email}) → POST /oeffentlich/portal/anmelden {email} liefert testLink → Link öffnen (setzt Cookie) → GET /oeffentlich/portal/ich. Offen (Go-Live-Gate S5): DSGVO/AVV + Rate-Limiting/Turnstile + echter Mailversand (OP-DM-8) + Client-Portal-UI (S3). Nächster Schritt: S3 (Dashboard-UI) oder S5-Gate.

MED-D-282 (2026-08-27) — Kunden-Self-Service-Portal: Slice S1 (Fundament, DORMANT) (0.123.1→0.124.0, MINOR; MED-OP-PORTAL-1). Das gehärtete Datenmodell + Auth-Domänen-Kern aus dem MED-D-279-Plan — keine öffentliche Route (S2/S5 folgen nach MED-KB-13 + OP-DM-8). Server: Migration v53–v55 (portal_konto/portal_anmelde_token/portal_session) + Drizzle-Schema, Bearer-Werte nur als Hash; domain/portal-auth.ts (SHA-256/WebCrypto, TTL+Einmalgebrauch, Idle+Absolut-Session-TTL); Repo mit atomarem Token-Claim (kein Replay). Kein Passwort-Hash (G-5/G-6). +16 Vitest → 681. Alle MED-D-280-Härtungen umgesetzt. Nebenbei #317-Review-Nachlese: Risiko-Zähler 33, Lastenheft-Timer vereinheitlicht (Segment-Modell), AD-001 „Beratungsauftrag"; Historie (MED-D-278/280) nicht re-editiert (G-4). Nächster Schritt: S2 (Auth-Routen, flag-gated) nach Kundenfreigabe.

MED-D-281 (2026-08-27) — Gesprächsprotokoll aus der Sidebar in eigenen Reiter (0.123.0→0.123.1, PATCH). Nutzer: „Gesprächsprotokoll aus der Sidebar entfernen und als eigenen Tab neben Praxen erstellen." Das Meeting-Doku-Panel (md-mandant-meetings, R11) ist aus der linken Rail (dort seit MED-D-273) in einen eigenen Reiter „Gesprächsprotokoll" neben „Praxen" gewandert — mehr Platz fürs Protokoll + Aufgaben- Ableitung. Reine Client-Umstrukturierung (Register + Panel, Sidebar-Block entfernt), ng build grün.

MED-D-280 (2026-08-27) — CodeRabbit-Nachlese #315+#316 (Doku-only). Reale Findings forward-gefixt (Quote-Nits übersprungen, MED-D-144). Portal-Design-Härtung (prägt S1): Token/Session nur als Hash at rest · atomarer Claim (CAS) · Idle+Absolut-TTL getrennt · Residenz konditional · quelle = bestehendes self_service (nicht portal). Sweep: Lastenheft-Timer als pre-MED-D-275 markiert · H1 „Mandant-Struktur" · je-Beratungsauftrag · Grammatik-Fragmente · „ganzer Mandant". Doku-Check grün.

MED-D-279 (2026-08-27) — Kunden-Self-Service-Portal: Design (S0) (Doku-only, App bleibt 0.123.0; MED-OP-PORTAL-1). Nutzer: „Self-Service-Portal für Kunden — Info-Updates direkt dort, submitted ≠ tatsächlicher Datenstand, 4-Augen-Freigabe durch Berater." Wahl (AskUserQuestion): echtes Kunden-Login (persistente Accounts) → design-first. Kern (G-1/G-2): submitted-vs-actual + 4-Augen + versionierte Übernahme existieren schon (feld-sichtung.ts, …/uebernahme-vorschlag→…/uebernehmen, VersionedField), heute nur einladungsbasiert; Portal = persistente Identitäts-/Übersichts-Schicht darüber. Auth-Default passwortlos/Magic-Link (kein Passwort-Hash at rest). Neu: portal_konto/portal_anmelde_token/ portal_session. Compliance: Zero-Trust-Ausnahme (RISK-33), DSGVO/AVV (MED-KB-13), Mail (OP-DM-8). Design: docs/architektur/Kunden-Self-Service-Portal.md. Slices: S0(Design, hier)→S1(Fundament,dormant) →S2(Auth,gated)→S3(Dashboard)→S4(Einreichung)→S5(Go-Live, Gate Kundenfreigabe). Nächster Schritt: S1.

MED-D-277 (2026-08-23) — Umbenennung „Akte“ → „Mandant“ (Sprache + Komponenten-Rename, Tier A+B) (0.122.0→0.123.0, MINOR). Nutzer: „Entferne den Begriff Akte und ersetze diesen durch Mandant.“ Die App dreht sich um Mandanten (0..n Beratungs-Mandate je Mandant) — die separate „Akte“ für die Detailsicht war redundant. Tier A: alle user-sichtbaren „Akte“/„Mandantenakte“ → „Mandant“ (inkl. Audit-Label; der persistierte Code mandant.eingesehen bleibt, G-4). Tier B: 14 Client-Dateien umbenannt (akte-*→ mandant-*/overlay-shell/status-slider/versioned-field/vorgang; mandant-akte→mandant-druckansicht), Selektoren md-akte-*→md-mandant-*, Route /mandant/:id/akte→/mandant/:id/druck, Server-Enum andere_akte→ anderer_mandant. Behalten: Aktenreife, Akteur, Programmname „Akten-Cockpit-Redesign“, Design-Artefakte, append-only Log-Historie. Client tsc+ng build · Server tsc+Vitest 666 · Doku-Check grün. Nachlese erledigt (MED-D-278, 2026-08-23): die tiefere Doku-Prosa (MED-OP-DOCS-2) ist gesweept — „Akte"→„Mandant" grammatik-korrekt in 20 lebenden Referenz-Docs + Glossar-Quelle + 2 stale Code-Refs in Test-Uebersicht; Historie/Design-Handoff/Eigennamen/Dateinamen bewusst unangetastet (G-4).

MED-D-275 (2026-08-23) — Durchlaufender Timer: Vordergrund-Segmente + Buchungs-Overlay + Live-Push (0.121.0→0.122.0, MINOR). Der Timer folgt jetzt der Akte (statt zu blockieren) und protokolliert je Akte die Vordergrund-Zeit (neue Tabelle timer_segment); ein Zeitbuchungs-Overlay (Cockpit-Chip „⏱ Zeit buchen" / Push-Klick ?zeitbuchung=1) zeigt die Aufschlüsselung je Akte, editierbar/zuweisbar (auch an nie geöffnete Mandanten), mit geräteübergreifendem „Buchen & stoppen". Web-Push als daten-loses Push mit VAPID-JWT (WebCrypto, kein Node-web-push, PII-frei über die Gateways; schlanker /sw.js + PWA-Manifest; dormant ohne VAPID-Secret). Server tsc + Vitest 654 (+6) · Client ng build grün. Design/DSGVO: docs/architektur/Zeiterfassung-Segmente-und-Push.md. Offen: VAPID-Secrets in Prod setzen (dann Push live) + In-App-Test der geräteübergreifenden Buchung (MED-OP-TIME-4).

MED-D-276 (2026-08-23) — CodeRabbit-#313-Härtung (in-PR vor Merge, bleibt 0.122.0): 13 Findings am frischen Timer/Push-Feature, die realen vor dem Merge behoben. (a) Segment-Konsistenz aller Timer-Aktionen (starten öffnet ein Segment; buchen/verwerfen räumen sie; korrigieren schließt das offene) → keine verlorene/doppelt gezählte Zeit. (b) Direkt-buchen verweigert Fehlzuordnung über mehrere Mandanten (verteilen_noetig → 409 {verteilen:true}; Client leitet ins verteilte Overlay). (c) Push härter & datensparsamer (G-6): kein user_agent, Endpoint-Allowlist (HTTPS + FCM/Mozilla/Apple/WNS), unsubscribe user-scoped, Zustellung non-blocking (waitUntil) + 5-s-Timeout. (d) vordergrund weist malformte mandantId mit 400 ab. (e) partieller UNIQUE-Index (v52) = ein offenes Segment je Benutzer. (f) Stopp-Übergänge pushen → SW schließt die Benachrichtigung. (g) Doc-Korrekturen. Server tsc + Vitest 666 (+12) · Client ng build grün. Runde 2–4 (Re-Review): 🔴 atomare Buchung (claim-first, keine Doppelbuchung), Verlassen-Guard-Einmal-Bypass für den Overlay-Redirect, SW schließt nur bei gesichert gelesenem Stopp-Stand; Buchung räumt nur die gelesenen Segmente + Timer-Neuanlage nur wenn absent → kein Verlust bei nebenläufigem Vordergrund-Wechsel; Crash-nach-Ledger-Write verhindert (verwaistes Segment vor Neuanlage geschlossen); korrigieren gleicht Segment-Historie an (MED-OP-TIME-5). Bewusst offen: Rest-Zeit-Guard + volle Transitions-Atomarität (CAS/Durable Object) + Push-Secret-at-rest (vor Live) — Feature-Zeile 🟡; dauerMinuten-Deckelung bewusst NICHT (freie Zuweisung ist Kern-Feature).

MED-D-274 (2026-08-23) — CodeRabbit-#312-Nachlese (Teil 0.121.0): (a) Major — Cockpit-laden() bekam einen monotonen mandantenSeq-Guard (spät eintreffende Vor-Anlage-cockpit()-Antwort überschreibt die neue Mandantenliste nicht mehr); (b) a11y — Neuer-Mandant-Overlay aus der Command-Palette gibt den Fokus jetzt korrekt zurück (neuerMandantSchliessen, WCAG 2.4.3); (c) 0.121.0-Datum in MVP-Scope/Sanity auf 2026-08-23 angeglichen. Quote-Nits bewusst nicht übernommen. tsc+ng build grün.

MED-D-273 (2026-08-23) — Akte „Mandate"-Reiter aufgeräumt (Teil 0.121.0). Drei Nutzer-Meldungen aus dem Live-Durchklick: (1) Mandat anlegen läuft jetzt über einen „+ Mandat"-Button oben rechts + Overlay (akte-auftraege.component.ts, geteilte md-overlay-Hülle) statt über ein inline-Formular unter der Liste; (2) „Formulare zum Ausfüllen" (md-akte-formulare) ist vom Mandate- in den „Alle Dokumente"-Reiter verschoben (fachlich Dokumente); (3) Gesprächsnotizen/Meeting-Doku (md-akte-meetings) sind in die linke Rail gewandert und lösen dort die Self-Service-Kurzfassung ab (volles Self-Service-Panel bleibt im Basis-Reiter). Verwaiste Rail-Helfer + ungenutzte Importe entfernt. tsc+ng build grün.

MED-D-271/272 (2026-08-23) — Neuer Mandant als Overlay + Overflow-Fix Akte/Overlay (0.120.1→0.121.0, MINOR). Nutzer: „Neuer Mandant anlegen soll nicht in der Verwaltung sein, sondern als Overlay aufgehen" + „Die UI sieht krumm aus — Text läuft über" (Akte/Overlay). MED-D-271: die Anlege-Form ist aus verwaltung.component.ts in eine neue neuer-mandant-overlay.component.ts gewandert (nutzt die geteilte md-overlay-Hülle: Scrim + Dialog- Semantik + Fokus-Falle, G-3); die Cockpit-Buttons „+ Neuer Mandant"/Command-Palette öffnen jetzt das Overlay statt nach /verwaltung zu navigieren; nach dem Anlegen lädt die Mandanten-Liste neu. Server-Endpunkt (POST /api/mandanten) unverändert (G-1/G-2). MED-D-272: horizontaler Textüberlauf in Akte/Overlay behoben — Wurzel war ein fehlendes min-width:0/overflow-wrap an .md-grow (Flexbox-Default) + ungeschützte Wertzellen; Fixes in styles.css (.md-grow, .md-akte-grid-Zellen, .mw-overlay-panel) + die CRM-Zelle der Detail-Rail, sodass lange Strings (E-Mail/IBAN/URL/CRM-Link/Nextcloud-Pfad) umbrechen statt den Container zu sprengen. Nachschärfung aus Nutzer-Screenshot (Detail-Rail ~230 px): Zuständigkeits-<select> auf volle Rail-Breite, Stammdaten-/Self-Service-Kopf flex-wrap:wrap, Self-Service-Label white-space:nowrap (statt 3-Zeilen-Bindestrich-Bruch). tsc(Client)+ng build(prod) grün.

MED-D-270 (2026-08-23) — CodeRabbit-Nachlese #310: Statistik-Retry-Race + Endpunkt-Doc (0.120.0→0.120.1, PATCH). CodeRabbit fand auf dem gemergten #310 zwei reale Minor-Punkte: (1) der „Erneut versuchen"-Retry (nochmalLaden()) konnte bei Mehrfachklick Requests überholen — ein spät scheiternder älterer fragebogenStatistik()-Call setzte statistikFehler=true trotz bereits geladener Daten → mit monotonem statistikSeq-Guard behoben (nur die jüngste Antwort setzt den Zustand, gleiche Machart wie MED-D-263). (2) Docs nannten den Endpunkt fragebogen-statistik, echte Route ist GET /api/fragebogen/statistik → in CHANGELOG/HANDOFF/Timesheet/Feature-Liste/Decision-Log korrigiert (OP-DOCS-1). Bewusst übersprungen: Client-Component-Tests beider Zugriffspfade — der sicherheitsrelevante Gate ist serverseitig und bereits getestet (rbac.test.ts, 403/403/200), der Client hat per Konvention keine Component-Unit-Test-Infra (build-only); als Backlog vermerkt. tsc(Client)+ng build(prod) grün.

MED-D-269 (2026-08-16) — Statistiken als eigener Cockpit-Bereich (0.119.1→0.120.0, MINOR). Nutzer: „Fragebogen-Statistik gehört in einen separaten Bereich „Statistiken" neben dem Leitstand." Gebaut: vierter Cockpit-Modus „Statistiken"; das Fragebögen-Statistik-Widget (DM-9) aus der Verwaltung dorthin verschoben (G-2), Admin-Gate beibehalten (G-5, praxisbezogene Daten; Nicht-Admins sehen einen Hinweis). Client-only, nutzt den vorhandenen GET /api/fragebogen/statistik-Endpunkt. ng build grün.

MED-D-268 (2026-08-16) — A11y-Fix: Mandanten-Zeilen bleiben echte Buttons (0.119.0→0.119.1, PATCH). CodeRabbit-Nachlese #307: role="listitem" auf dem <button> überschrieb die Button-Rolle (Screenreader kündigt die Zeile nicht als Button an). Fix: aufgesetzte role="list"/role="listitem" entfernt → native Buttons, konsistent mit den bestehenden Cockpit-Listen. ng build grün; Quote-Nits bewusst nicht übernommen.

MED-D-267 (2026-08-16) — Mandanten-Liste als aufgeräumter Einstieg (0.118.1→0.119.0, MINOR). Nutzer: „Einstieg aufräumen / Mandanten-Liste mit Filtern?" → per AskUserQuestion: Liste wird die Landing, Filter Lifecycle-Status · Betreuungsmodell · offene Fakturierung. Gebaut: dritter Cockpit-Modus „Mandanten" (Default-Ansicht, Segment vor Fokus/Leitstand) — Namenssuche + Lifecycle-/Betreuungs-Chips + „Zu fakturieren" + Reset, alphabetische Liste, Klick öffnet die Akte. Rein abgeleitet (G-2, GET /api/mandanten + labels.ts), kein Backend, keine neue Route. Beantwortet True North #1 direkter. tsc+ng build grün; client-only, keine neuen Vitest.

MED-D-266 (2026-08-02) — Runbook-Präzisierung: Rücklauf + „vorbefüllt" (keine Versionsänderung, reine Doku). CodeRabbit-Nachlese #305: §8-Aussage korrigiert (der form_data-Rücklauf liest generisch alle Tab-Typen — nur das Prefill ist text-only); §9 „alle vorbefüllten Datenfelder". Stand/offener Punkt (MED-OP-FORM-7): heute befüllt das Prefill (baueTabWerte→anfordernAusTemplate) nur textTabs; die Unterstützung weiterer Tab-Typen (Date/Checkbox) im Prefill ist zurückgestellt (der Rücklauf ist bereits tab-typ-generisch). Quote-Nits bewusst nicht übernommen.

MED-D-265 (2026-08-02) — Runbook-Korrektur: Datumsfelder auf Text-Tabs (keine Versionsänderung, reine Doku). CodeRabbit-Nachlese #304: der Prefill sendet nur textTabs — ein Date-Tab für person.geburtsdatum bliebe leer. §9 Teil A korrigiert (alle vorbefüllten Felder auf Text-Tabs); neuer offener Punkt MED-OP-FORM-7 (Prefill auf weitere Tab-Typen ausdehnen, zurückgestellt). Quote-Style-Nits bewusst nicht übernommen (Korpus nutzt „…").

MED-D-264 (2026-08-02) — Runbook Fremdformular-Template + Doku-Welle-7-Teil (B49) (keine Versionsänderung, reine Doku). Neu: Fremdformulare.md §9 Runbook (Template Klick-für-Klick anlegen + kanonische tabLabel-Referenz) und §8 korrigiert (MED-OP-FORM-6 „teilweise gebaut", Hausformular-Auto-Routing via dokumenttyp ist live) → B49 teilweise erledigt (MED-OP-DOKU-9). Mitgezogen: die im #300-Merge verlorene cad8c82-Politur (Test-Uebersicht „bis zu 100 Seiten" + True-North-Satz; Decision-Log-Quote-Rationale). Kein Version-Bump (Zeitdokument-Analogie).

MED-D-263 (2026-08-02) — CodeRabbit-Nachlese #299: stale-Attribut-Fix + Template-Paginierung (0.118.0→0.118.1, PATCH). Nachlese der CodeRabbit-Review auf dem gemergten MED-D-262-PR #299. Major-Fix (Funktionskorrektheit): templateGewaehlt (Verwaltung) akkumulierte die auto-erkannten Attribute über Templatewechsel → falsche FremdformularVorlage.attribute. Jetzt in dsAutoErkannt verfolgt + bei jedem Wechsel (Dropdown und manuelle GUID via templateIdManuellGesetzt) zurückgesetzt, plus Out-of-order-Guard gegen veraltete templateFelder-Antworten. Minor: listeTemplates() paginiert jetzt über nextUri (>2000 Templates). Nitpick: Fehler-Body im Wurf. +2 Vitest (646→648). Nicht übernommen: Markdown-Quote-Nits + CHANGELOG-PR-Link (repo-Konvention, MED-D-144). Details: CHANGELOG / Decision-Log MED-D-263.

MED-D-262 (2026-07-26) — DocuSign-Templates ziehen + Felder anzeigen (0.117.1→0.118.0, MINOR). Nutzer: „Templates automatisch ziehen (Refresh-Kreisel) + Felder zeigen" + Options-Frage zum „Felder in DocuSign zeigen" → gewählt A (Konvention + App-Anzeige), kein Plugin. Gebaut: zwei Provider-Lese- methoden listeTemplates()/templateFelder(id) (DocuSign-Adapter + Fake-Stub) + Admin-Routen; Verwaltung- UI: Template-Dropdown + Refresh-Kreisel (Freitext-GUID als Fallback) + echte Template-Felder angezeigt und gegen die Weltmodell-Attribute gematcht (✓ erkannt/⚠ unbekannt), erkannte auto-vorgemerkt. Reine Lese- Aufrufe. +2 Vitest (644→646). Optionen A/B/C (Konvention · In-App-Authoring · Extension-App-Plugin) dem Nutzer erklärt; C (echtes Plugin) als Großprojekt zurückgestellt. Grenze: live gegen den echten DocuSign- Account erst beim Testen (Fake = Stubs). Mitgezogen: Management-Summary-DocuSign-Status korrigiert (CodeRabbit #298).

MED-D-261 (2026-07-26) — B41 Feld-Editor-Token-Fix (0.117.0→0.117.1, PATCH; MED-OP-UX-12). Vorzieh- Fix des höchsten App-Audit-Punkts (v0.116.1): der akte-feld-editor nutzte undefinierte CSS-Tokens --fg/--fg-faint/--gruen → Feldname-Text im Light-Theme nahezu unsichtbar. Auf var(--text)/var(--mut)/ var(--green) (theme-fähig) umgestellt. Reine CSS, ng build grün, 644 Tests unverändert. B41 in MED-OP-UX-12 erledigt; B42 (Rücklauf-Falsch-Leere) + B43 (<24px) bleiben offen.

MED-D-260 (2026-07-26) — Selbst-Rollenwahl in der UI (interim Admin-Bootstrap) (0.116.1→0.117.0, MINOR; RISK-31). Nutzer: „Die Benutzer-Rolle soll zunächst in der UI auswählbar sein." Anlass: die Fremd-Formular-Verwaltung + die ganze Admin-Sektion waren live unerreichbar, weil die Produktions-benutzer- Tabelle leer ist (0 Admins, per D1 bestätigt) und AUTH_BOOTSTRAP_ADMIN nicht greift → jeder ist Default-berater. Gebaut: POST /api/ich/rolle (setzt die eigene Rolle, ohne benutzer_verwalten- Guard, auditiert) + Verwaltung-Karte „Meine Rolle" (für alle sichtbar, oberhalb des Admin-Gates). Sicherheits- Weiche mit dem Nutzer geklärt → freie Selbst-Wahl; nur hinter Cloudflare Access vertretbar (Zero Trust), als RISK-31 geflaggt mit Rückbau-Bedingung (später auf benutzer_verwalten gaten / verriegeln / entfernen

AUTH_BOOTSTRAP_ADMIN korrekt setzen). +2 Vitest (642→644). ⚠️ Betrieb: solange RISK-31 offen ist, kann sich jeder Access-Nutzer selbst zum Admin machen — nach dem Setzen der echten Rollen zurückbauen.

MED-D-258 (2026-07-26) — CodeRabbit-Nachlese zu MED-D-257 (#292) (0.116.0→0.116.1, PATCH). Drei reale Befunde am eben gebauten Auto-Routing: (A) eIDAS-Untergrenze — das Template-Routing signiert jetzt mit dem stärkeren aus Template-Niveau und geforderter Rechtswirkung (staerkeresNiveau), damit eine als SES registrierte Fassung keinen QES-pflichtigen Dokumenttyp abschwächt (RISK-2). (B) Eindeutiges Routing — anlegen lehnt eine zweite aktive Vorlage je Hausformular-Dokumenttyp ab (sonst mehrdeutiger Match). (C) G-8 — Verwaltung-Dropdown aus DOKUMENTTYP_LABEL abgeleitet + Client-Typ Dokumenttyp | null. +2 Vitest (640→642). Bewusst NICHT: Straight-Quote-/MD038-Nitpicks + CLAUDE.md-Umbau (Repo-Konvention).

MED-D-257 (2026-07-26) — Hausformular auf ausfüllbare DocuSign-Fassung routen (0.115.0→0.116.0, MINOR; MED-OP-FORM-6 Baustein 2 — löst das MED-D-256-OFFEN). Nutzer wählte „Rücklauf-Weg 1: Kunde füllt in DocuSign → AD-009". Gebaut: eine Weg-B-Vorlage (ausfüllbares DocuSign-Template, MED-D-248) ist jetzt optional an einen Hausformular-Dokumenttyp verknüpfbar (FremdformularVorlage.dokumenttyp, Migration v49). Ist verknüpft, routet SignaturService.anfordern beim Versenden eines Hausformulars ohne Datei automatisch auf dieses Template (Helper versuchAusfuellbaresTemplate: Prefill aus Stammdaten → anfordernAusTemplate → Identitäts-Mapping am bestehenden Dokument → AD-009-Rücklauf greift; Template-Niveau) — der Kunde füllt die offenen Felder selbst in DocuSign, die Angaben 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 (Kunde): das echte Makler-Alleinauftrag- DocuSign-Template muss angelegt (Tabs tabLabel=Weltmodell-Attribut) + in der Verwaltung verknüpft werden — erst dann greift das Routing live (Kern-Loop verifiziert MED-D-238/247/248).

MED-D-256 (2026-07-26) — Eigenformular beim Versenden erzeugen + vorbefüllen (0.114.2→0.115.0, MINOR). Nutzer (Live, Makler-Alleinauftrag): „das Formular sollte erstellt und vorausgefüllt werden — die Eingaben vom Kunden sollen dann zurückfließen." Der R12-Generator kannte die Makler-Vorlage, aber der Unterschriften-Assistent rief ihn nie auf → 422 kein_inhalt. Baustein 1 (gebaut): SignaturService erzeugt ein bekanntes Hausformular ohne Datei jetzt beim Versenden (vorlageFuerBezeichnung → befuelleVorlage → erzeugePdf → Ablage + nextcloudPfad), dann Signatur; Fremdformulare ohne Vorlage bleiben kein_inhalt. +2 Vitest (635→637). OFFEN — Baustein 2 (MED-OP-FORM-6): die PDF ist eine flache Stammdaten-Tabelle ohne ausfüllbare Felder → echter Kunden-Rücklauf (Anschrift/Geburtsdatum → AD-009) braucht die ausfüllbare Weg-B-Fassung (Makler-Alleinauftrag als DocuSign-Template) — Empfehlung, wartet auf Kunden-Steuerung.

MED-D-255 (2026-07-26) — Härtung nach dem DocuSign-Live-Vorfall (0.114.1→0.114.2, PATCH). (A) Push-Guardrail: #288 mergte ein Duplikat, der DocuSign-Fix erreichte nie main/Prod — Ursache: Commit auf detached HEAD, Push schob die stale Branch-Ref hoch. Jetzt: eingecheckter .githooks/pre-push (bricht detached-HEAD-Push ab), Auto-Aktivierung via core.hooksPath im Session-Start-Hook, 4-Schritt-Push-Disziplin in agents.md §7 (checkout -B · Remote==Local nach Push · PR-Diff sichten · Deploy verifizieren). (B) Signatur-Härtung (CodeRabbit #289): providerFehlerText redigiert E-Mail-Adressen ([email]) vor 502/Log (G-6, keine Empfänger-PII); Ablage-Read + Empfänger-Auflösung laufen mit im try/catch (R2-Read-Fehler → provider_fehler statt opaker 500), symmetrisch in anfordern/vorOrtVorbereiten. +2 Vitest (633→635).

MED-D-254 (2026-07-26) — DocuSign-Fehler im Live-System sprechend machen (0.114.0→0.114.1, PATCH, Bugfix): Nutzer meldete im Live-Betrieb beim „Versenden" die generischen Toasts „Verbindung zum Server fehlgeschlagen" + „Anfrage fehlgeschlagen" — der echte DocuSign-Grund war verborgen, weil die Signatur- Anfrage-Routen jeden Provider-Wurf als unbehandelten 500 durchreichten. Jetzt prüfen SignaturService.anfordern/vorOrtVorbereiten beim echten Provider vorab (PDF-Bytes/Empfänger) und fangen Provider-Würfe ab → 422 (fehlende Datei/Empfänger, mit Handlungshinweis) bzw. 502 (sanitisierter DocuSign-Grund, PII-arm geloggt) statt 500; der Client-Interceptor bevorzugt bei 5xx die Server-Klartextmeldung, der Assistent zeigt den konkreten Grund. Prod-Diagnose (D1): DocuSign läuft grundsätzlich (2 signiert/1 gesendet); alle Erfolge hatten eine abgelegte Datei → ein fileless Dokument ist der wahrscheinlichste Auslöser. +5 Vitest (628→633). Offen (OP-SIGN-1): der exakte Live-Grund wird beim nächsten Versand mit der neuen Meldung sichtbar.

MED-D-252 (2026-07-26) — Cockpit-Fokus entschlackt + Mandant-Filter/-Suche + „Zu fakturieren" (0.113.1→0.114.0, MINOR): Nutzer „Wie können wir diese Seite entschlacken? … einfacher Weg, um einen bestimmten Mandaten zu öffnen oder zu filtern, zB wo rechnungen offen sind" → gewählt „a+1+2+3". (A) „Als Nächstes" nach Mandant gruppiert (restGruppen), „Brennt"-Rail je Mandant eine Zeile (dedupliziert + Punkte-Zähler), Kontext-Liste „Offen bei diesem Mandanten" auf 6 gekappt. (1+2) sichtbare Filterleiste: Mandant-Suche + Kategorie-Chips (Ring bleibt ungefiltert), löst die Cmd-Palette-only-Filterung ab. (3) „Zu fakturieren"-Filter: neuer abgeleiteter MandantCockpit.offeneFakturierungMinuten (Summe dauerMinuten je Mandant mit abrechenbar && !abgerechnet, G-2, nicht persistiert); Chip listet Mandanten mit offener abrechenbarer Zeit (Absprung in die Akte). Echte Rechnung bleibt extern (SevDesk, OP-INVOICE-1; Definition zu bestätigen: MED-KB-12). +1 Vitest (627→628). Server+tsc+vitest+ng build+Doku-Check grün; Client-Strecke im Browser noch nicht interaktiv durchgeklickt.

MED-D-251 (2026-07-26) — CodeRabbit-Nachlese zu Weg B (#284) (0.113.0→0.113.1, PATCH): Härtungen ohne Verhaltensänderung. Unique je Template: eine Katalog-Zeile je DocuSign-Template — Migration v48 (Dedup + CREATE UNIQUE INDEX idx_ff_vorlage_template), schema.templateId.unique(), Service-Vorabprüfung (klarer Grund statt DB-Constraint-Fehler) + Memory-Repo-Guard (Test-DB verhält sich wie D1). Kein verwaistes Dokument: FremdformularVorlageService.starten ruft den Provider (anfordernAusTemplate) vor dem Anlegen des Dokuments — wirft er, entsteht keine Waise. Fake: markiereSigniert erhält die formularWerte (Rücklauf nach Signatur nicht mehr leer). Client: weltmodellAttribute-/fremdformularVorlagen- Ladefehler surfacen jetzt (kein stiller Swallow); Wording „Tab-Name" → „Tab-Label (tabLabel)". +2 Vitest (625→627). tsc/vitest/ng build/Doku-Check grün.

MED-D-250 (2026-07-26) — Weg B gebaut: Fremd-Formular-Vorlagen über DocuSign-Templates/Tabs, live gegen DocuSign Demo verifiziert (0.112.0→0.113.0, MINOR): Nutzer „B implementieren" (setzt MED-D-248 um). Neue Fremd-Formulare (auch flache Bank-PDFs) binden über ein DocuSign-Template ein, tabLabel = Weltmodell-Attribut-Schlüssel. Neue Entität FremdformularVorlage {name, templateId, attribute[], niveau} (v47, kein PDF-Blob/PII); Provider anfordernAusTemplate (DocuSign compositeTemplates); Domäne baueTabWerte + identitaetsMapping (macht AD-009-Rücklauf unverändert nutzbar); FremdformularVorlageService (Katalog-CRUD + starten = Dokument+Vorgang+vorbefüllter Envelope). Routen: /api/weltmodell-attribute, /api/fremdformular-vorlagen (Admin), /api/mandanten/:id/fremdformular-vorlagen/:id/starten. Client: Verwaltung (Vorlagen registrieren) + Akte („vorbefüllt starten"). Live verifiziert (Session-Demo, temp. Skript): JWT → Template → Envelope aus Template → form_data {anschrift.plz:"40210"} (Prefill landet) → gevoidet. +8 Vitest (617→625). Konvention (KB-11): Template-Rolle Unterzeichner. Grenze: Client im Browser noch nicht durchgeklickt; der Template-Kern ist live belegt. Offen bleibt MED-OP-FORM-6 (Eigen- Formulare auch als Templates).

MED-D-247 (2026-07-26) — Formular-Rücklauf-Prüfung, AD-009 (DocuSign form_data → Review-and-apply), live gegen DocuSign Demo verifiziert (0.111.0→0.112.0, MINOR): Nutzer „AD-009, nutze für die Verifikation die env-Angaben hier in der Session." Schließt den Fremdformular-Loop (Prefill = Slice 1 MED-D-235; Wert-Rücklauf = jetzt, löst die MED-OP-FORM-5-Slice-2-Deferral): die vom Kunden ausgefüllten/korrigierten Feldwerte fließen geprüft zurück, nie still (Vier-Augen, G-4). Provider formularRuecklauf(externalId) (DocuSign form_data); Domäne ATTRIBUT_ZU_STAMMZIEL + ruecklaufRegeln speisen die bestehende Review-and-apply-Maschine (baueVorschlaege/bauePatch, G-1/G-2). SignaturService.formularRuecklauf (Diff, on-demand, nichts persistiert, G-6) + ruecklaufUebernehmen (nur gewählt+gültig → versionierter updateMandant, Quelle formular) + Audit. Routen mit Dokument-Scope-Guard. Client: „Rücklauf prüfen"-Overlay (Diff-Liste, Checkbox je gültigem Feld → Übernehmen). Live gegen DocuSign Demo verifiziert (Session-Credentials, temp. Skript, danach entfernt): JWT → Envelope mit Text-Feld → form_data {f_plz:"40210"} zurückgelesen → gevoidet. +7 Vitest (610→617). Grenze: Client-Overlay gebaut+build/unit-geprüft, im Browser noch nicht durchgeklickt (der reale form_data-Pfad ist gegen DocuSign verifiziert). Damit ist AD-009 gebaut; offen bleiben AD-010 Feld-Editor

Sammel-Umschlag (OP-SIGN-1-Rest).

MED-D-246 (2026-07-26) — Abgelaufene Dokumente als abgeleitete Aufgabe (nicht persistiert), AD-005 (0.110.0→0.111.0, MINOR): Nutzer-Entscheidung „Aufgaben zu abgelaufenen Dokumenten u.ä. nicht persistieren, sondern ableiten — hält das Backlog sauber." Ein R3-Dokument mit überschrittenem gueltigBis war bisher in beiden Ableitungs-Sichten unsichtbar (blieb geprüft → nicht dokumenteOffen; kein Auto-Setter auf abgelaufen). Neuer reiner Helfer dokumentAbgelaufen(d, jetzt); AktenreifeInput um dokumenteAbgelaufen erweitert → eigener Reifepunkt (dokument/Stufe aktiv/wichtig = fällig, kein Abschluss-Blocker) + naechsteSchritte-Schritt dokumente-erneuern + offenePunkte()-Eintrag (überfällig, faelligAm = das Gültigkeitsdatum). Nichts persistiert — keine Wiedervorlage/Aufgabe geschrieben (G-2, Backlog sauber). Client: „erneuern"-TaskCard in Akte + Cockpit; roter „abgelaufen"-Chip jetzt auch abgeleitet aus gueltigBis. +7 Vitest (603→610); tsc+vitest(610)+ng build+Doku-Check grün.

MED-D-245 (2026-07-26) — Build-Version dauerhaft in der UI (inkl. Build-Zeitpunkt) (0.109.1→0.110.0, MINOR): Nutzerwunsch „immer die Build-Version inkl. Zeitpunkt anzeigen". Die App-Shell-Kopfzeile zeigte v… · build … · {Zeitpunkt} schon — aber die zwei Vollbild-Hauptsichten rendern mit eigener Chrome ohne diese Shell: das Cockpit (/) zeigte gar keine Version, die Akte (/mandant/:id) nur die SemVer ohne Build-Nummer/-Zeitpunkt. Jetzt tragen beide den vollen Stempel v{SemVer} · Build {Nr.} · {Zeitpunkt} (Cockpit: Header-Chip vor dem Benutzer-Chip; Akte: „Stand:"-Zeile unter dem Lifecycle-Stepper). Reine Client-Anzeige über den bestehenden health-Endpunkt (version/build/buildZeit), kein Server-/Persistenz-Change; BUILD_NUMBER/BUILD_ZEIT kommen weiterhin aus gen-build-number.mjs (Git-Commit-Count). Öffentliche Kundenstrecken bleiben bewusst außen vor (keine Shell, kein /api). Nebenbei: die überholte „Stammdaten-Overlay read-only"-Notiz in Kunden-Cockpit-Redesign.md §4 auf den MED-D-241-Stand (direkt editierbar) korrigiert. ng build grün, Tests unverändert.

MED-D-244 (2026-07-25) — AD-006-Nachlese: Dokument-Scope-Guard auf den Signatur-Routen (Sicherheit) (0.109.0→0.109.1, PATCH): CodeRabbit-Review zum bereits gemergten #279 (MED-D-243) fand einen realen, sicherheitsrelevanten Befund — die Routen POST /api/dokumente/:docId/signatur und /signatur/vor-ort trugen keinen Sichtbarkeits-Guard (der /api/mandanten/:id-Chokepoint greift bei :docId-Routen nicht). Zusammen mit dem neuen Empfänger-Override (AD-006) hätte ein authentifizierter Berater mit einer fremden docId ein fremdes Dokument an eine beliebige E-Mail senden können (Daten-Exfiltration). Fix: ladeDokScope (bisher nur in der Fremdformular-Strecke) auf gemeinsamen Scope hochgezogen und vor leseEmpfaenger/sig.anfordern/vorOrtVorbereiten in beide Signatur-Routen gesetzt → Fremd-Mandant 404 (kein Existenz-Leak), Schreiben verlangt mandant_bearbeiten. Zwei weitere valide Befunde: vor Ort wird keine Empfänger-E-Mail mehr mitgeschickt (In-Person signiert eingebettet), und der irreführende Hinweis "… geht an diese Person" → "Empfänger bei Bedarf auf diese Person ändern". +1 Vitest (602→603, HTTP-Guard-Test: fremd→404 ohne Provider-Aufruf, eigen→201). tsc+vitest(603)+ng build+Doku-Check grün. #279 war beim Review bereits per Auto-Merge gemergt → Forward-Fix als frische Änderung (Nachlese-Muster wie MED-D-240).

MED-D-243 (2026-07-25) — AD-006 editierbarer Empfänger im Unterschriften-Assistenten (0.108.0→0.109.0, MINOR): löst die AD-006-Deferral aus MED-D-241 auf. 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 „… geht an diese Person", gespeist aus Bankkonto.zeichnungsberechtigt/inhaber). Für den E-Mail-Versand ist eine gültige E-Mail Pflicht (Client-Disable + Server-400), vor Ort optional. Server: SignaturService.anfordern/ vorOrtVorbereiten + beide Routen nehmen einen optionalen empfaenger-Override (Default = Mandant), der Provider-Vertrag (unterzeichner) trug ihn schon. Kein neues PII persistiert (nur Versand, G-5/G-6). +2 Vitest (600→602). tsc+vitest(602)+ng build+Doku-Check grün.

MED-D-242 (2026-07-25) — AD-014 "Über den Link hochgeladen"-Statusliste (0.107.0→0.108.0, MINOR): löst die AD-014-Deferral aus MED-D-241 auf. Der Handoff-Prototyp meint mit "Über den Link hochgeladen" nicht je-Token getrackte Uploads, sondern die angeforderten Dokumente + ihren Upload-Status — das sind echte, bereits gespeicherte Daten. Das Self-Service-Panel (akte-einladungen) zeigt jetzt mandantweit die Dokumente der Self-Service-Pipeline: angefordert ("noch kein Upload", amber) bzw. erhalten ("hochgeladen, zu prüfen", grün) mit Prüfen-Aktion (→ geprüft, Item-/Ring-Propagation). Reine Client-Sicht über die bestehenden Endpunkte api.dokumente + api.dokumentStatusSetzen — keine neue Persistenz, kein neues Public-Upload-Feld, keine Migration (G-1/G-2). ng build + 600 Vitest grün.

MED-D-241 (2026-07-25) — Akten-Cockpit-Design-System exakt übernommen (0.106.2→0.107.0): präzise Rekonziliation des bereits gebauten Akten-Cockpits (MED-D-188) gegen den finalen Handoff-Prototyp "Akten-Cockpit 1a (Detail)". Vier Nutzer-Entscheidungen (AskUserQuestion): Stammdaten jetzt direkt editierbar (versioniert+auditiert, löst MED-D-147 ab), Lifecycle-Rail-Wording "Lebenszyklus des Kunden" statt "Mandats-Status" (AD-001, Edit behalten), Unterschriften-Assistent ergänzt (DocuSign/Multi-Doc behalten), Onboarding-Doks angeglichen (Datenquellen getrennt). LifecycleRing als 5 SVG-Bögen, "Anstehende Aufgaben"-TaskCards in der Kontext-Spalte, volles Rail-Stammdaten-Grid, Design-Wording überall. Compliance-Flag: Steuernummer/Steuer-ID bewusst zurückgestellt (§139b AO/DSGVO → RISK-30/MED-KB-10). Deferiert: AD-014-Upload-Liste (in MED-D-242 aufgelöst) + AD-006-Empfänger-Feld (in MED-D-243 aufgelöst). 600 Vitest grün.

Die App ist live auf app.medidentas.com (Cloudflare Worker + D1 EU, hinter Cloudflare Access, Auto-Deploy bei Push auf main). Slices 1–13 + Dentmarking T1–T7 sind feature-complete: Mandant · Onboarding · Dokumente (Ablage produktiv auf R2, MED-D-61) · Unterschriften (Fake-Adapter bis MED-KB-5) · Wiedervorlagen/Delegation · Beratungsdoku + Regel-Check · Identität/RBAC · Audit-Log · Dokumenten-Automatisierung · Leistungszeit — plus die vier öffentlichen Kundenstrecken (Onboarding · Dentmarking-Fragebogen · Ausfüll-Formular mit Feld-Sichtung/Korrektur-Schleife MED-D-89 · Lead) und die UX-Wellen 1–5 (MED-D-90…94; MED-OP-UX-1..4 ✅). Neu: Beratungsaufträge Slices A+B (MED-D-95, 3-Ebenen-Modell Person · Auftrag · Artefakte — je Mandant 0..n Aufträge mit Produkt-Katalog + eigenem Status; Dentmarking = Produkt-Typ im neuen Register; 9-Produkt-Katalog MED-D-99; Slice B MED-D-101: Artefakte je Auftrag binden + Auftrags-Reife + Retro-Ableitung). Slice C teils gebaut (C1 Produkt-Playbooks ✅ MED-D-104; C2a Lead-Auto-Anlage ✅ MED-D-106: Lead-Formular erfasst Produkt-Interesse → je buchbarem Produkt Auftrag + Playbook automatisch; C2b+ offen: Cockpit-Kontext/Dexman) (MED-OP-AUFTRAG-1); CodeRabbit-Reviews nachgehärtet (0.71.1). App-UX-Audit aufgefrischt auf v0.72.0 (MED-D-107); UX-Welle 6 abgeschlossen (MED-OP-UX-5: Akte mobil responsiv, stille Ladefehler sichtbar, A11y-Basis; 0.72.1→0.72.5 inkl. zweier CodeRabbit-Nachlesen MED-D-116/117). UX-Welle 7 abgeschlossen (MED-OP-UX-6: interne IDs/rohe Enums aus sichtbaren Texten raus, Consent-Text "Geldanlage" → "Kapitalanlage", Lead-Picker-A11y, Fragebogen-Handschrift-Ausreißer; 0.73.0→0.73.1, MED-D-118/119). UX-Welle 8 Teil 1 (MED-OP-UX-7, B5: natives confirm() durch gestalteten ConfirmService-Dialog ersetzt inkl. eines dabei gefundenen Signal-Reset-Bugs; datum()/datumZeit()/kopiereText() überall durchgesetzt; Verlassen-Modal-Buttons getrennt; 0.73.1→0.74.0, MED-D-120), Teil 2 (Cockpit-Fokus-Kontext mobil als Bottom-Sheet statt display:none, analog Leitstand-Detail, MED-OP-UX-3; 0.74.0→0.75.0, MED-D-121) und Teil 3 (Inline-Styles Runde 1: 49 exakte Duplikate in cockpit.component.ts als Utility-Klassen konsolidiert, 215→166, per Long-Tail-Analyse als bewusst bounded Erstschritt; 0.75.0→0.75.1, MED-D-122) und Teil 4 (Inline-Styles Runde 2, atomar: 36 neue Deklarations-Atome für ≥4×-wiederkehrende Einzeleigenschaften, Werte unverändert, 145 weitere Stellen konsolidiert, 166→132; 0.75.1→0.75.2, MED-D-126). World-2-Rollout (Token-Welten-Vereinheitlichung: Schritt 1 Verwaltung + App-Shell, 0.75.2→0.76.0, MED-D-128; Schritt 2 Akte/Mandant-Detail — mandant-detail.component.ts + mandant-akte.component.ts auf .mw-scope umgestellt, die 6 Register-Unterkomponenten ziehen automatisch per CSS-Cascade mit, ohne eigenen Wrapper; 0.76.0→0.77.0, MED-D-129; Schritt 3 die 4 öffentlichen Kundenstrecken — Onboarding/Ausfüll-Formular/Dentmarking-Fragebogen/Lead + pub-bausteine.ts auf .mw-scope umgestellt; da diese Seiten keine App-Shell haben, bekommt .md-pub selbst direkt background: var(--bg); 0.77.0→0.78.0, MED-D-130) — kein zweifarbiger Übergangszustand mehr in der gesamten App; CodeRabbit-Nachlese (MED-D-131, 0.78.0→0.78.1): Doku-Wortlaut präzisiert (Wrapper-Beschreibung, "EU-konform betrieben" → "live in der EU mit Compliance-by-Design-Kontrollen" + Compliance-Verweis); CLAUDE.md-Restrukturierungsvorschlag bewusst dem Nutzer zur Entscheidung vorgelegt statt einseitig umgesetzt. Doku-Review aufgefrischt auf v0.78.1 (MED-D-132, keine Versionsänderung): Doku-Wellen 1–3 hielten größtenteils, aber Wurzelursache B18 kehrte zurück — Lastenheft.md nie für Beratungsaufträge nachgezogen + eigener Phantom-"Ablage"-Rückfall, README/MVP-Scope erneut veraltet, Deploy.md widersprach der Live-Realität, Check hatte blinden Fleck; Backlog B20–B32 → MED-OP-DOKU-5. Doku-Welle 4a+4b umgesetzt (MED-D-133, 0.78.1→0.78.2): Wahrheit wiederhergestellt (README/MVP-Scope/Lastenheft/CLAUDE.md/Deploy.md/Management-Summary korrigiert, Phantom-"Ablage" an der Quelle behoben, Beratungsaufträge-Abschnitt in Lastenheft ergänzt) + Check-Lücke geschlossen (check-doc-consistency.sh §8-Regex erkennt jetzt auch "Status" statt nur "Stand", Lastenheft.md in der Prüfliste). Doku-Welle 4c+4d umgesetzt (MED-D-134, 0.78.2→0.78.3): Compliance.md/Risikoregister.md echt neu geprüft (28 Risiko-Zeilen + Compliance-Tracker-Stempel); Weltmodell-Data-Dictionary um Beratungsauftrag-Entität ergänzt; agents.md §3 um D-n/RISK-n/KB-n ergänzt + toter "Letztes Update"-Stempel repariert; docs/README.md-Index (+Architektur-Uebersicht.md, "Geldanlage"→"Kapitalanlage") + Lesepfade.md-Routing für IT-Architektur/Customer-Service; Dexman.md pyramidal umsortiert (Zweck vor Wettbewerbsanalyse); Unterschriften.md/Dokumentenverwaltung-NextCloud.md-Sequenzdiagramme auf "Ablage (R2/NextCloud)" korrigiert; OP-DEX-Nummerierung vereinheitlicht; Entwicklungsansatz.md verweist jetzt explizit auf agents.md §7 als kanonische Draft-PR-Quelle. CLAUDE.md-§Versionierung restrukturiert (MED-D-140, keine Versionsänderung): der laufend wachsende Absatz (jede PR hängte einen weiteren Satz an) auf 1–2 Sätze Ist-Stand gekürzt, volle Historie lebt jetzt ausschließlich in CHANGELOG.md/Feature-Liste.md/HANDOFF.md §2 — löst die seit MED-D-131 offene CodeRabbit-Frage. MED-OP-AUTH-2 + MED-OP-WV-2 gehärtet (MED-D-142, 0.78.3→0.78.4, PATCH): geteilter By-ID-Mandant-Scope-Guard für Meetings/Beratungsdoku/Individualdokumente (schlossen bislang den /api/mandanten/:id*-Chokepoint nicht ein, CodeRabbit-#108) + Unique-Index auf wiedervorlage.quelle_ref (Migration v39) inkl. Duplicate-Key-Handling in createWiedervorlage (D1 + Memory-Repo deckungsgleich); +4 Vitest, alle vorab gegen den ungefixten Stand verifiziert (schlagen ohne Fix fehl). CodeRabbit-Nachlese zu MED-D-142 (MED-D-143, 0.78.4→0.78.5, PATCH): PR #181 mergte, bevor die Review-Kommentare eintrafen (Draft-Skip-Timing) — 5 von 9 Befunden waren echt und wurden nachgezogen: app.ts-Guard schloss bei orphaned Mandant fail-open statt fail-closed (jetzt konsistent zu Chokepoint B); d1-repo.ts/memory-repo.ts prüften quelleRef auf Truthy statt Nullish (leerer String hätte die Dublettenprüfung umgangen); memory-repo.tss Check-dann-Insert war durch das await auf getWiedervorlageByQuelle theoretisch racy — auf synchronen Inline-Lookup umgestellt (echte Atomizität im Single-Thread-Sinn), per Promise.all-Test bewiesen; Migration v39 hätte bei bereits vorhandenen Alt-Dubletten mit Fehler abgebrochen (Index-Aufbau validiert Bestand) — Reconciliation-UPDATE davor ergänzt (behält je Dublette die älteste Zeile, kein Datenverlust, G-4-sicher), gegen echtes node:sqlite verifiziert (Dedup + Idempotenz + Index-Durchsetzung bestätigt); Management-Summary hatte einen übersehenen 442-Rest. Bewusst nicht übernommen (4 Befunde, mit Begründung): CLAUDE.md-Kürzung noch weiter (widerspräche der gerade erst getroffenen MED-D-140-Entscheidung), Decision-Log strikt ans Dateiende anhängen (Log ist laut eigener Kopfzeile "analog CHANGELOG.md" = neueste zuerst, nicht neueste zuletzt), Feature-Liste um Detail-Zeilen erweitern (bestehende RBAC-Zeile stattdessen minimal ergänzt statt neue granulare Zeilen), Migrationstest-Infrastruktur neu aufbauen (kein D1/SQLite-Testharness im Repo — eigene Design-Entscheidung, nicht Teil dieses Fixes). CodeRabbit-Nachlese zu MED-D-143 (MED-D-144, keine Versionsänderung): 2 von 4 Restpunkten echt — Feature-Liste.md fehlte in jedem Lesepfade.md-Lesepfad (jetzt im "Business/Management"-Pfad ergänzt) + benannter Folgepunkt MED-OP-TEST-1 für die D1-/SQLite-Testharness-Lücke in HANDOFF §4 angelegt; 2 Punkte bewusst nicht übernommen (CHANGELOG-Format ist etablierte Repo-Konvention, Test-Uebersicht.md bereits über Lesepfade.md geroutet). Anführungszeichen vereinheitlicht (MED-D-145, keine Versionsänderung): Nutzeranstoß gegen wiederkehrende CodeRabbit-Nitpicks — die Doku mischte durchgängig „…" (öffnend typografisch, schließend gerade) mit vereinzelt korrektem „…"; auf Rückfrage Scope auf Doku begrenzt (App-Code/Tests bewusst außen vor, andere Risikoklasse). Alle 43 .md-Dateien auf gerade Anführungszeichen ("/') normalisiert (reine Zeichenersetzung, ‹Variable›-Platzhalter in Dentmarking-Excel-Logik.md ausgenommen); dabei einen vorbestehenden, unabhängigen Mermaid-Syntaxfehler in Dentmarking.md gefunden und behoben (unescapetes Anführungszeichen in einem Flowchart-Knoten, gegen den echten Validator verifiziert). Konvention in agents.md §2 verankert, .coderabbit.yaml per path_instructions angewiesen, gerade Anführungszeichen nicht mehr zu bemängeln. MED-OP-VALID-1 Slice 1 gebaut (MED-D-146, 0.78.5→0.79.0, MINOR): kanonischer Feld-Typ (domain/feld-typ.ts, G-8) aus stammdaten-uebernahme.ts extrahiert + um plz/tel/zahl/betrag erweitert (ValidierungsArt/pruefeWert/normalisiereWert dort re-exportiert, kein Bruch); immer weich (Nutzerentscheidung: Freitext-Fallback, nie blockierend) — ausfuellformular.tss FeldArt ist jetzt ein Alias des kanonischen Typs, neue reine Funktion pruefeAlleWerte(). Neuer Fake-first KI-Vorschlag-Seam (ki/vorschlag.ts + ki/regel-vorschlag.ts, analog KiPruefer/GespraechsAuswerter): deterministischer Formatvorschlag (DE-Datum→ISO, IBAN-Normalform, Ziffern-Bereinigung PLZ/Tel), RISK-14-Hinweis, dormant-tauglich für ein echtes LLM. Erste Anwendung: AusfuellformularService.kontext() liefert neu hinweise/vorschlaege je Feld — nie automatisch übernommen, Client-UI-Anbindung ist der nächste Slice (Onboarding/Dentmarking-Fragebogen folgen danach). Als Produkt-USP festgehalten (Produkt-und-Marketing.md, Management-Summary.md §5). +18 Vitest (feld-typ.test.ts, regel-vorschlag.test.ts, erweiterte ausfuellformular.test.ts), alle gegen die neue Logik verifiziert. MED-OP-VALID-1 Slice 2 (MED-D-147, 0.79.0→0.80.0, MINOR): Nutzer "Die smarte Eingabe-Unterstützung (LLM + RAG?) auch für die Eingabe-Felder in der App verwenden" — geklärt, dass RAG hier nicht zutrifft (OP-ASSIST-1s RAG ist strikt auf Doku-Retrieval beschränkt, PII/Bestandsdaten explizit ausgeschlossen; Feld-Formatvorschlag ist der bereits gebaute, einfachere KiFeldVorschlag-Mechanismus). Recherche zeigte: Mandant-Stammdaten (Telefon/Geburtsdatum/Anschrift) sind heute gar nicht Berater-editierbar (nur über den Formular-Rückübernahme-Pfad); einzig Praxis strasse/plz/ort sind bereits editierbar und ungeprüft (kein Format-Constraint). Scope nach Rückfrage bestätigt: nur die risikofreie additive Erweiterung (Praxis-PLZ) umsetzen, bestehende harte Felder (Mandant email/ibanPrivat, Praxis iban/geschaeftsjahrBeginnMonat) bleiben hart, Mandant-Stammdaten-Editierbarkeit bewusst nicht neu eingeführt (Audit-Trail-Design der Formular-Rückübernahme nicht umgehen). Neuer weicheHinweise()-Helfer in app.ts (nutzt denselben kiFeldVorschlag) an den Praxis-Anlege- (POST) und PATCH-Routen; Antwort um hinweise/vorschlaege erweitert (additiv, kein Bruch der bestehenden Praxis-Antwortform). Client: mandant-detail.component.ts#praxisAnlegen() zeigt bei einem PLZ-Vorschlag einen Undo-Toast ("PLZ übernehmen", ToastService.mitAktion) — nie automatisch übernommen. Gegen echten Browser verifiziert (wrangler dev + Playwright, nicht nur Tests): malformte PLZ "40 210" → Toast "meintest du '40210'?" → Klick → PLZ tatsächlich auf 40210 aktualisiert (Screenshot bestätigt). +2 Vitest (praxis.test.ts). Rest: nur noch 132 verbleibende Einzelwert-Inline-Styles in Cockpit, Absende-Button-Texte bewusst divergent — siehe §4. MED-OP-VALID-1 Slice 3 — Adressvalidierung (b) (MED-D-149, 0.80.0→0.81.0, MINOR): Nutzerentscheidung "g-1: use OpenPLZ" (G-1 Standardwerkzeug-Bevorzugen) — OpenPLZ (openplzapi.org, öffentliches DACH-Postleitzahlverzeichnis, kein API-Key) als Provider hinter neuer PlzOrtProvider-Abstraktion (adressen/provider.ts), OpenPlzClient sucht DE→AT→CH (Zielmärkte-Reihenfolge) mit 3s-Timeout, fällt bei jedem Fehler neutral auf "nicht prüfbar" zurück (nie blockierend, analog feld-typ.ts). Test-sicherer Fake-Default (FakePlzOrt) lebt in createApp(), der echte netzwerkrufende Client wird ausschließlich im Worker-Entrypoint (index.ts) verdrahtet — ein erster Entwurf hatte den echten Client versehentlich als createApp-Default gesetzt, ein 936ms-Testausreißer deckte den daraus resultierenden echten Netzwerkaufruf in einem Unit-Test auf (selbst gefunden und korrigiert, vor jeder Nutzer-Sichtbarkeit). Wired in Praxis-Anlege-/PATCH-Route (analog PLZ-Formatvorschlag aus Slice 2), Client zeigt bei Ort-Vorschlag einen zweiten Undo-Toast. Gegen echten Browser + echte OpenPLZ-API verifiziert (wrangler dev + Playwright): PLZ "40210"/Ort "Köln" → Toast "meintest du „Düsseldorf"?" → Klick → Praxis tatsächlich auf ort: "Düsseldorf" aktualisiert. Damit ist MED-OP-VALID-1 (a)+(b) für Praxis-Felder vollständig gebaut; Onboarding/Dentmarking-Angleichung + Mandant-Stammdaten-Editierbarkeit bleiben Folge-Slices (§4). +13 Vitest (openplz.test.ts 6, fake.test.ts 3, praxis.test.ts +4; 466→479, 46 Dateien). MED-OP-VALID-1 Slice 4 — Onboarding-Formular (MED-D-150, 0.81.0→0.82.0, MINOR): nach einer Erklärungsrunde der drei Slice-2-Folgepunkte wählte der Nutzer "1" (Onboarding/Dentmarking-Angleichung). Recherche (2 parallele Explore-Agenten) zeigte: beide Ziele sind fachlich nicht gleich groß — Onboarding passt direkt (einwilligung.tss StammdatenFeld.typ ist heute nur ein Render-Hinweis, Intake prüft nur Pflichtfelder, nie Format; erst die spätere Rückübernahme nutzt pruefeWert); Dentmarking nutzt dagegen ein eigenes, semantisch andersartiges Konzept (Wertebereich/bereichsHinweis() — Zahlen-Plausibilität mit min/max/Einheit statt Format-Typen wie E-Mail/IBAN/PLZ, bereichsHinweis() existiert zudem nur client-seitig als manuell synchron gehaltenes Duplikat des Server-Parsers). Nutzer entschied per Rückfrage: nur Onboarding jetzt, Dentmarking separat (keine erzwungene Vereinheitlichung eines andersartigen Konzepts). Umsetzung: ONBOARDING_STAMM_REGELN (stammdaten-uebernahme.ts) hebt telefon/plz von generischem 'text' auf die kanonischen 'tel'/'plz'-Arten (bewusst nur hier, AUSFUELL_STAMM_REGELN unverändert — out of scope); neue reine Funktion pruefeRegelWerte() (analog pruefeAlleWerte, aber über UebernahmeRegel[]). OnboardingFormularService bekommt den KiFeldVorschlag-Seam injiziert (Default RegelVorschlag, wie bei AusfuellformularService); kontext() und entwurfSpeichern() liefern jetzt hinweise/vorschlaege (aus dem aktuellen Entwurf berechnet). Client (onboarding-public.component.ts): je Feld ein Inline-Hinweis (.md-ob-warn, analog Dentmarkings .md-fb-warn) + ein klick-übernehmbarer Formatvorschlag (.md-ob-vorschlag + "übernehmen"-Button, füllt nur das Feld, kein automatisches Zwischenspeichern) — Hinweis/Vorschlag werden beim nächsten Editieren des Feldes verworfen (serverseitig neu berechnet, kein Client-Duplikat der Prüf-Logik, anders als bei Dentmarking). Bewusst nicht geändert: AUSFUELL_STAMM_REGELNs dieselbe telefon/plz-'text'-Untertypisierung (Inkonsistenz jetzt benannt, nicht behoben — eigener Folgepunkt); Dentmarking-Fragebogen (s. o.). Gegen echten Browser verifiziert (wrangler dev + Playwright): E-Mail "kaputt" → Hinweis "E-Mail-Format ungültig"; Telefon "0211 / 12-34-56" → Vorschlag "0211123456" → Klick auf "übernehmen" → Feld tatsächlich auf den bereinigten Wert gesetzt (Screenshots bestätigt, keine Konsolenfehler). +5 Vitest (onboarding-formular.test.ts +3, stammdaten-uebernahme.test.ts +2; 479→484, 46 Dateien). tsc + ng build grün, Doku-Konsistenz-Check grün. PROZESS_PHASE retiriert (MED-D-151, 0.82.0→0.83.0, MINOR): Nutzervorgabe löste die strukturelle Redundanz zwischen Mandant.prozessphase (erstkontakt·onboarding·beratung·unterschrift·betreuung·archiviert) und Beratungsauftrag.status (anbahnung·beratung·unterschrift·laufend·abgeschlossen) auf — Mapping erstkontakt→lead, onboarding/beratung/unterschrift→onboarding, betreuung→aktiv in LIFECYCLE_STATUS (unverändert, 5 Werte, jetzt die EINE grobe Achse) auf, die feine Granularität lebt bereits in AUFTRAG_STATUS je Beratungsauftrag (kein neues DB-Feld nötig) — löst zugleich MED-D-95s Mehrfach-Auftrag-Problem (eine Person kann jetzt mehrere Aufträge in unterschiedlichen Stadien zeigen, was eine einzelne Prozessphase nie konnte). Neue domain/lifecycle.ts (ersetzt phasen.ts): LIFECYCLE_SPINE=['lead','onboarding','aktiv'] (Ruhend/Archiviert bleiben frei erreichbare, ungeordnete Verwaltungszustände), erstmals ein Guard auf lifecycleStatus-Wechsel (pruefeLifecycleUebergang: Eintritt in aktiv verlangt vollständiges Onboarding + keine offenen Unterschriften — fasst die zwei alten Phasen-Engine-Guards zusammen; PATCH kann jetzt 409 liefern, ein reales Verhaltens-Update). Mandanten-Playbook auf 2 Einträge reduziert (nachfassen@onboarding, jahrescheck@aktiv, ehem. betreuung); die beiden verwaisten termin/ruecklauf-Einträge leben jetzt als Code-Katalog am Beratungsauftrag (domain/auftrag-playbook.ts §AUFTRAG_STATUS_PLAYBOOK, feuert neu auf Auftrags-Statuswechsel, nicht nur -Anlage; Nutzerentscheidung: Code-Katalog statt admin-editierbar). kunden-vollstaendigkeit.ts/naechste-schritte.ts von phase/jePhase auf stufe/jeStufe umgestellt, laufen nur noch über die 3-wertige Spine. DB: db/migrate.ts v40 (Mandant-Reconcile per Mapping + DROP COLUMN prozessphase, monoton vorwärts, regressiert nie einen bereits fortgeschritteneren/administrativ gesetzten Status) + v41 (Playbook-Remap, termin/ruecklauf-Zeilen deaktiviert statt gelöscht, G-4). Client: MandantCockpit.prozessphase → auftragStatusZusammenfassung (Nutzerentscheidung: sofort mit Auftrag-Status-Chips je Cockpit-Karte statt nur grober Lane-Reduktion); Cockpit-Board-Lanes jetzt Lead·Onboarding·Aktiv·Ruhend (Archiviert ausgeblendet), löst zugleich die alte Doppel-Achsen-Mischung in phaseOf() auf; mandant-detail/mandant-akte verlieren das zweite Prozessphase-Select (EINE Kontroll-Stelle), die vormals eigenen Register „Beratung"/„Unterschrift" falten in „Beratungsaufträge", „Betreuung"→„Wiedervorlagen" (stufe aktiv). Migrationssicherheit doppelt verifiziert: manuelles node:sqlite-Skript (Drift-Matrix inkl. ruhend-Nicht-Regression) und wrangler dev gegen die reale, aus vielen Vorsessions gewachsene lokale D1 — alle 4 Browser-Szenarien (Solo-Mandant→aktiv inkl. jahrescheck-WV, Guard bei unvollständigem Onboarding, Guard bei offener Unterschrift, Mehrfach-Auftrag mit unabhängigen Status+Chips) per Playwright/Screenshot bestätigt. +2 Vitest (Status-Playbook-Idempotenz + Fehler-Isolation; 488→490, 46 Dateien), tsc + ng build + Doku-Konsistenz-Check grün. CodeRabbit-Nachlese zu MED-D-151 (MED-D-152, keine Versionsänderung, PR #192 hatte bereits gemergt bevor das Review eintraf): 12 von 14 Befunden echt — Major: service.ts#aktualisieren()s Lifecycle-Playbook-Erzeugung lief ungeschützt vor den Audit-Aufrufen (ein Fehler hätte den bereits persistierten Wechsel unauditiert gelassen, 500 statt 200) — mit try/catch isoliert (analog beratungsauftrag-service.ts), neues mandant.playbook_fehler-Event, Regressionstest vorab gegen den ungefixten Stand verifiziert. 11 Doku-Funde (Achsen-Terminologie CLAUDE.md/Beratungsauftraege.md, MD028/Anführungszeichen/Klammer-Tippfehler, Wiedervorlagen-als-Lifecycle-Stufe-Ungenauigkeit, veraltete Test-/Versions-Zahlen in Management-Summary/MVP-Scope-Fließtext) behoben; zusätzlich im eigenen Nachlese-Audit Lastenheft.md §5.1/§5.1a/§5.2 (trug noch den vollständigen alten prozessphase-Diskurs) sowie Sanity-Checkliste.md auf das neue Modell umgeschrieben. +1 Vitest (490→491, 46 Dateien), tsc + ng build + Doku-Konsistenz-Check grün. App-UX-Audit aufgefrischt auf v0.83.0 (MED-D-153, keine Versionsänderung; Bezugspunkt war seit v0.72.0/MED-D-107 11 Minor-Versionen alt, über der Stale-Schwelle, MED-OP-REVIEW-1): fünf parallele Dimensions-Reviews (Feedback-Verlässlichkeit · Sprache G-3/G-8 · Kundenstrecken · Design/Mobile/A11y · neu: Eine Handschrift/Konsistenz, eigene Dimension diese Runde wegen des Umfangs der Welle-8/World-2-Konsolidierung) plus Live-Begehung (wrangler dev + Playwright, Desktop 1440px + Mobil 390px, Testakten "Mustermann Dr. Max" [16 Beratungsaufträge] und "MED-D-1xx Test C (Multi-Auftrag)"). Ergebnis: alle carry-over Befunde B1–B4/B6/B7 aus v0.72.0 verifizieren als weiterhin behoben oder unverändert bestehend — keine Regression durch den MED-D-151-Umbau. Zwei neue, genuine Befunde direkt aus dem Umbau: Cockpit- Chip-Overflow (die neue Auftrags-Status-Zusammenfassung je Lane-Kopf hat keine Ellipsis/Truncation, live per DOM-Messung bestätigt an "Mustermann Dr. Max", rowScrollWidth=190px > rowClientWidth=180px) und PHASE_LABEL-Dopplung (cockpit.component.ts reimplementiert LIFECYCLE_LABEL lokal und weicht dabei ab — aktiv:'Aktiv' vs. kanonisch 'Aktiv (betreut)', ein echter G-8-Verstoß). Dazu: der neue Lifecycle-Guard-Undo-Pfad (lifecycleZuruecksetzen()) hat keinen error:-Handler (True-North-#2-Risiko, Schwesterstelle zum korrekt gehärteten Hauptpfad) und Playbook-Fehlschläge (*.playbook_fehler, seit MED-D-152 korrekt auditiert) haben weiterhin kein UI-Signal. Neuer Backlog B8–B13 → MED-OP-UX-8 (Welle 9). Detail: docs/betrieb/UX-Prozess-Review-2026-07.md. Welle 9, Punkt 1 — PHASE_LABEL-Dopplung behoben (MED-D-154, 0.83.0→0.83.1, PATCH): cockpit.component.tss lokale PHASE_LABEL-Konstante (B9, G-8-Verstoß) war vom kanonischen LIFECYCLE_LABEL (labels.ts) abgedriftet — aktiv:'Aktiv' statt 'Aktiv (betreut)'. Jetzt const PHASE_LABEL = LIFECYCLE_LABEL (Alias, keine eigene Kopie mehr); PHASE_STRIP/PIPELINE_PHASEN/PHASE_VAR (die intern per Label-String statt Enum-Wert indizieren/ vergleichen) auf die Werte von PHASE_LABEL umgestellt, damit kein zweiter manueller Abgleichspunkt entsteht. Beim Durchsuchen des Codes für denselben Fehler-Typ eine zweite, bislang unentdeckte Dopplung gefunden: mandant-detail.component.ts#lifecycleLabel() hatte einen eigenen (zufällig noch wertgleichen) Hardcode-Fallback statt LIFECYCLE_LABEL zu importieren — ebenfalls auf den kanonischen Import umgestellt. Live verifiziert (wrangler dev + Playwright): Cockpit-Pipeline-Leiste und KPI-Kachel zeigen jetzt korrekt "Aktiv (betreut)" statt "Aktiv", kein Layout-Bruch, keine Konsolenfehler. 491 Vitest unverändert grün (reiner Anzeige-/Struktur-Fix, keine neue Testfläche), tsc + ng build grün, Doku-Konsistenz-Check grün. CodeRabbit-Nachlese zu MED-D-154 (MED-D-155, keine Versionsänderung): der Versions-Stempel-Sync hatte nur die vom Konsistenz-Check geprüfte erste "Stand"-Zeile je Datei getroffen — Test-Uebersicht.md/MVP-Scope.md/Management-Summary.md trugen je weitere Stellen mit 0.83.0/490 Tests, jetzt auf 0.83.1/491 korrigiert. Akten-Cockpit-Redesign (MED-D-156, 0.83.1→0.84.0, MINOR): per claude.ai/design-Mockup ("Akten-Cockpit 1a (Detail)") beauftragte Vereinheitlichung der Akte (mandant-detail.component.ts, die meistgenutzte interne Arbeitsfläche) mit dem bereits bestehenden dunklen Cockpit-Design (.mw-*/World-2) statt der bisherigen separaten hellen Brand-Optik — Vollbild-3-Spalten-Layout (Person-Sidebar · Arbeitsbereich mit neuem Übersicht-Standard-Tab + 7 weiteren Registern · Zeit/Kontext-Sidebar). Vier Nutzerentscheidungen (Rückfrage): (1) Lifecycle-Pill in der linken Sidebar bleibt klickbar und öffnet den bestehenden Status-Wechsel voll funktional (Guard/409/Undo-Toast unverändert) statt nur anzeigend wie im Mockup; (2) der globale App-Header wird für /mandant/:id durch den Cockpit-eigenen Header ersetzt (analog app.component.tss bestehendem istVollbild-Bypass, jetzt um diese Route erweitert); (3) Mandate-Tab voll verschmolzen — akte-auftraege.component.ts übernimmt die komplette Beratungsdoku-Bearbeitung inline pro Auftrag (bisher eigenständiger Block in mandant-detail.component.ts), inkl. neuer "Anlegen & verknüpfen"-Direktbindung für den Fall ohne gebundene Beratungsdoku; (4) ein großer PR statt gestufter Rollout. .mw-scopes bestehender CSS-Var-Remap (.md-*→World-2-Tokens) erlaubte, alle unangetasteten Tabs (Dokumente/Onboarding/Wiedervorlagen/Zeiterfassung/Verlauf/Stammdaten) unverändert zu lassen — nur Header/beide Sidebars/Übersicht-Tab/verschmolzenes Mandate-Register brauchten echte .mw-*-Markup; Timer zieht in die rechte Sidebar um (Logik unangetastet), Aktenreife-Ring vergrößert, "Letzte Aktivität" neu aus dem bereits eager geladenen Verlauf gespeist. Dabei mitgeliefert: der seit MED-OP-UX-8 Punkt 3 bekannte fehlende error:-Handler an lifecycleZuruecksetzen() (Trigger wechselte ohnehin von <select> auf klickbaren Pill, selbe Änderungsstelle). Zwei genuine Bugs erst in der Live-Browser-Verifikation gefunden (nicht durch tsc/vitest/ng build abgedeckt): die alte Lifecycle-basierte Erst-Tab-Heuristik in laden() überlebte den Umbau versehentlich und überschrieb den neuen Standard-Tab "Übersicht" bei jedem ersten Laden auf die Lifecycle-Stufe des Mandanten (an "Mustermann Dr. Max" [Status Onboarding] reproduziert: Seite öffnete auf "Onboarding" statt "Übersicht") — Heuristik komplett entfernt, aktiv bleibt beim Default; und die geteilte .mw-rail-CSS-Klasse trug eine für Cockpit spezifische Mobil-Transformation (@media max-width:1100px: Rail wird horizontale Chip-Leiste mit overflow-x:auto), die Cockpit-eigene Unterklassen (.mw-rail-ring/-buckets/-brennt) voraussetzt, welche die Akte nicht hat — führte bei 390px zu einer intern horizontal scrollenden, optisch abgeschnittenen Sidebar (scrollWidth=977px vs. clientWidth=390px, live per DOM-Messung bestätigt). Fix: .mw-scope .mw-fokus > .mw-rail überschreibt die Transformation zurück auf normalen Blockfluss (nur für die Akte, Cockpit unverändert). Bewusst nicht gebaut: die im Mockup gezeigte Zeiterfassungs-"Mandat"-Zuordnung — ApiService.leistungszeitErfassen() hat keinen Auftrags-/Beratungs-Bindungsparameter, obwohl Leistungszeit.beratungRef das Feld bereits trägt; ein neuer Backend-Endpunkt hätte den reinen-Client-Umbau-Rahmen dieses PRs gesprengt (offener Punkt, s. §4). Verifiziert: tsc + ng build (Client) + 491 Vitest (Server, unverändert — reiner Client-Umbau) grün; wrangler dev + Playwright gegen zwei reale Testakten ("MED-D-1xx Test C" [2 Aufträge, Merge-Flow inkl. "Anlegen & verknüpfen" + Speichern] und "Mustermann Dr. Max" [16 Aufträge, Bucket-Widget-Stresstest]) bestätigt Übersicht-Links, verschmolzenes Mandate-Register, Lifecycle-Pill-Klick inkl. Abbrechen-Pfad, Timer/Aktenreife-Ring/Letzte-Aktivität in der rechten Sidebar, keine Konsolenfehler, 390px ohne Seiten-Overflow (nach den beiden o. g. Fixes). CodeRabbit-Review vor Merge (4 Befunde, alle real, vor Merge im selben PR gefixt): bdSpeichern() löschte den lokalen Entwurf nach Erfolg nicht (falscher Dirty-Zustand am Verlassen-Guard, jetzt analog bdRahmendatenSpeichern()); rwDatum()/setRwDatum() mischten lokale Mitternacht mit UTC-toISOString() (verschob terminAm für DACH-Nutzer um einen Tag, jetzt beidseitig lokale Datumskomponenten); ringUmfang rechnete mit r=31 statt dem gerenderten r="27" (falscher Aktenreife-Ring-Füllgrad); Klammer-Tippfehler in der Feature-Liste. Zeiterfassungs- "Mandat"-Zuordnung nachgeliefert (MED-D-157, 0.84.0→0.85.0, MINOR): der in MED-D-156 bewusst zurückgestellte Punkt — ein Auftrags-Bindungsparameter am Timer — ist jetzt gebaut. Neues Feld Leistungszeit.auftragRef (R13-F11, eigenständige Ref → Beratungsauftrag; bewusst nicht beratungRef wiederverwendet, das referenziert R6 Beratungsdoku über zwei Hops und ist nur für den Auto-Seed gedacht). Server: erfassen() validiert einen optionalen auftragRef gegen repo.getBeratungsauftrag() (existiert + gehört zum Mandanten, sonst 400); migrate.ts v42 (ALTER TABLE ... ADD COLUMN auftrag_ref + Index). Client: neues Mandat-<select> am Live-Timer, an der "Verlassen & buchen"-Modal (geteiltes Signal) und im retroaktiven Erfassen-Formular — Optionen aus dem bereits eager geladenen auftraege()-Signal (kein neuer Fetch); die Historie zeigt "· Mandat: X" analog "· aus Beratung". Gegen echten Browser verifiziert (wrangler dev + Playwright, "Mustermann Dr. Max"): Auswahl → Buchen → Historie zeigt die korrekte Zuordnung, retroaktives Formular ebenso, 390px ohne Overflow, keine Konsolenfehler. +2 Vitest (491→493, 46 Dateien), tsc + ng build + Doku-Konsistenz-Check grün. Register-Tableiste/Timer-Überlauf behoben (MED-D-159, 0.85.0→0.85.1, PATCH): Nutzerfund per Screenshot ("Die Schrift überlappt … kam mit der Übernahme des neuen Designs") — Root-Cause war .mw-seg, ein für 2–3-Optionen-Umschalter im Cockpit gebautes flex: none-Segment ohne Wrap/Scroll, das der Akten-Cockpit-Redesign (MED-D-156) für die jetzt 8-teilige Register-Leiste weiterverwendete — sie überlief die schmale Mittelspalte und verschwand sichtbar hinter dem opaken Hintergrund der rechten Kontext-Spalte (kein DOM-Overlap, sondern Überlauf + Verdeckung durch spätere Paint-Reihenfolge). Neue, eng gescopte .mw-seg-scroll-Modifier-Klasse (overflow-x: auto, Register bleiben per Scroll erreichbar, per Playwright bestätigt) — die Basis-Regel für Cockpits echte 2–3-Optionen-Umschalter bleibt unverändert. Zweiter, verwandter Fund im selben Screenshot: .md-timer-head (Live-Timer-Kopf) war ebenso flex: none/kein Wrap — die immer 8-stellige HH:MM:SS-Uhr lief über die Timer-Karte hinaus, sobald das Label ("Zeiterfassung läuft/pausiert") auf zwei Zeilen umbrach; flex-wrap: wrap ergänzt, Uhr fällt jetzt sauber in eine eigene Zeile statt zu überlaufen. Gegen echten Browser verifiziert (wrangler dev + Playwright, Bounding-Box-Überlauf vorher/nachher gemessen). Kein Server-/Schema-Change; 494 Vitest unverändert grün, tsc + ng build + Doku-Konsistenz-Check grün. Akten-Cockpit auf strikte Mockup-Konformität nachgezogen (MED-D-162, 0.85.1→0.86.0, MINOR): Nutzerauftrag, das Original-Mockup erneut per DesignSync-MCP zu importieren und Zeile für Zeile gegenzuprüfen — ein systematischer Diff deckte 26 echte Abweichungen auf (Tab-Anzahl 8 statt 6, fehlende Badges auf den meisten Tabs, ein abweichendes Mandats-Status-Widget, mehrere Wortlaut- Abweichungen, ein fehlender Bestätigungshinweis nach Zeitbuchung u. a.); alle behoben bis auf zwei bewusst beibehaltene, bereits in MED-D-156 begründete Abweichungen (Dentmarking bleibt eigenständige Karte, Freies Dokument bleibt eigene Sektion). Detail: docs/fachlich/Feature-Liste.md, MED-D-162. Drei weitere Nutzeranstöße umgesetzt (MED-D-164, 0.86.0→0.87.0, MINOR): Aktenreife-Ring aus der Akte-Sidebar entfernt (explizit als MED-OP-REIFE-1 auf später vertagt, Tab-Badges/"Jetzt dran" bleiben); NextCloud-Rolle final entschieden (R2 bleibt einziger Schreibpfad, NextCloud künftig ausschließlich Read-Only-Sicht — löst MED-KB-4 Punkt 0 endgültig ab); Marke auf "Medidentas Digital" umbenannt (Identität + UI-Wortmarke, technische Identifier/Domain/"medidentas GmbH" bewusst unverändert). CodeRabbit-Nachlese zu MED-D-164 (MED-D-165, keine Versionsänderung): PR #203 mergte per Auto-Merge vor vollständiger Review-Prüfung — 11 von 13 Befunden echt und behoben, 2 bewusst nicht übernommen (.md-wordmark-suffix-CSS-Fix, restliche "Medidentas"-Erwähnungen in den bereits umbenannten Identitäts-Dateien, Feature-Liste.md/Management-Summary.md-Widersprüche zur R2-Produktivsetzung korrigiert, Dokumentenverwaltung-NextCloud.md präzisiert — final ist nur die NextCloud-Rolle, das Zugriffskonzept der Read-Only-Sicht bleibt ein eigener offener Punkt, Kunden-Besprechungspunkte.md MED-KB-4 als überholt annotiert statt gelöscht). CodeRabbit-Nachlese zu MED-D-165 (MED-D-166, keine Versionsänderung): PR #204 mergte ebenfalls per Auto-Merge vor vollständiger Review-Prüfung — 6 von 7 Befunden echt, darunter ein selbst begangener append-only-Verstoß im Decision-Log (bestehende MED-D-164-Zeile war editiert statt nur ergänzt worden — zurückgenommen) und eine falsche "12 von 13"-Bilanz (korrekt: 11+2); zusätzlich Kunden-Besprechungspunkte.md MED-KB-4 auf ✅ geklärt gesetzt + "Read-Only-Notfall-Backup"→"-Sicht" präzisiert, Feature-Liste.md-NextCloud-Zeilen als seit R2 ungenutzt annotiert, Management-Summary.md redundante Dokumentenablage-Zeile gestrichen, README.md Rolle-vs-Bau präzisiert. CodeRabbit-Nachlese zu MED-D-166 (MED-D-167, keine Versionsänderung): PR #205 mergte erneut per Auto-Merge vor vollständiger Review-Prüfung (dritte Runde in Folge) — 2 von 3 Befunden echt: README.mds "künftig read-only" widersprach der eigenen, bereits im Präsens finalen Kopfzeile — gestrichen; Kunden-Besprechungspunkte.md MED-KB-4 hatte einen Präsens-Satz zum Mac-Sync außerhalb des Überholt-Blocks stehen, der der eigenen Endaussage "kein Finder-Sync" widersprach — in den Überholt-Block verschoben. CHANGELOG-PR-Links weiterhin bewusst nicht nachgetragen (etablierte Konvention). CodeRabbit-Review zu MED-D-167 (PR #206, MED-D-168, keine Versionsänderung): Review traf zwar erstmals ein, während der PR noch offen war, doch mergte auch #206 per Auto-Merge, bevor der Fix gepusht war (vierte Runde in Folge) — Branch erneut frisch aufgesetzt. 2 von 4 Befunden echt: README.mds "Sicht noch offen" auf "fachlich entschieden, Umsetzung offen" präzisiert; CHANGELOG.mds Formatzeile dokumentiert jetzt explizit die seit MED-D-144 etablierte Branch-Name-Ausnahme (löst den wiederkehrenden Doku↔Praxis-Widerspruch, den CodeRabbit bei jeder Runde erneut anmahnte). Bewusst nicht übernommen (1): historische #203/#204-CHANGELOG-Einträge nachträglich um PR-Links ergänzen (der gleiche append-only-Verstoß, den MED-D-166 bereits korrigiert hat). Ein Nitpick (MED-KB-4-Umstrukturierung, von CodeRabbit selbst als Heavy-Lift eingestuft) zurückgestellt. Detail: docs/betrieb/Decision-Log.md, MED-D-165/MED-D-166/MED-D-167/MED-D-168. Akten-Cockpit-Detail: Self-Service-Link-Kurzfassung + Onboarding-4-Tasten-Umschalter (MED-D-170, 0.87.0→0.88.0, MINOR): zwei Elemente aus dem Design-Mockup "Akten-Cockpit 1a (Detail)" (Projekt "Mandanten-Akte verbessern", via claude_design-MCP) umgesetzt — linke Rail bekommt eine Self-Service-Link-Kurzfassung (liest das bestehende <md-akte-einladungen>-Signal per viewChild, kein Zweit-Fetch, G-8); Onboarding-Items bekommen einen 4-Tasten-Umschalter (Geprüft/Da/Nötig/Später) statt des 5-wertigen Dropdowns, frontend-only über dem bestehenden ItemStatus. Bewusst nicht übernommen: Tab-Split "Basis-Informationen"/"Praxen" (würde eine frühere Merge-Entscheidung revidieren), Mandate-Modal statt Inline, der im Mockup selbst display:none gesetzte Aktenreife-Ring (bereits MED-D-164 descoped) — die übrigen Register bleiben unverändert, da ihre md-*-Klassen bereits über .mw-scope auf dieselben Tokens gemappt sind wie die neuen mw-*-Klassen. Gegen echte Seed-Daten via wrangler dev + Playwright verifiziert (Klick → Status

Fortschritt ändern sich server-seitig, danach zurückgesetzt). CodeRabbit-Review zu MED-D-170/MED-D-169 (PR #208, bereits gemergt; MED-D-171, keine Versionsänderung): 4 von 6 Befunden echt — CLAUDE.md präzisiert (nur die Self-Service-Karte sitzt in der Rail, der Onboarding-Umschalter in der Item-Liste); 4-Tasten- Umschalter bekam aria-pressed + einen No-op-Guard gegen unnötige API-Requests (offen→angefordert bleibt möglich); Feature-Liste-Zeile in den richtigen True-North-Abschnitt verschoben. Ein erster Versuch, die Anführungszeichen in den bestehenden MED-D-170-Zeilen von CHANGELOG/Decision-Log zu korrigieren, verletzte selbst das append-only-Prinzip (derselbe Fehlertyp wie MED-D-166) — zurückgesetzt. Bewusst nicht übernommen: die zwei CHANGELOG-Zeilen zusammenführen, MED-D-171 vor MED-D-170 einsortieren (widerspricht der MED-D-143-Anhänge-Konvention). Aktiver Timer — ein Timer je Benutzer statt je Browser-Tab (MED-D-172, 0.88.0→0.89.0, MINOR, OP-TIME-3): Nutzer-Bugreport "mehrere Akten gleichzeitig offen, dann Zeiterfassung nur auf dem aktiven Kunden, der vorne ist — verlassen und schließen nicht möglich". Code-Recherche zeigte: im canDeactivate/beforeUnload-Guard selbst kein echter Deadlock (jeder Pfad löst korrekt auf) — die eigentliche Ursache war architektonisch: der Live-Timer lebte rein lokal je Komponenteninstanz, also je geöffnetem Browser-Tab unabhängig (mehrere Tabs = mehrere sich gegenseitig ignorierende Uhren). Auf expliziten Nutzerwunsch "ich will nur einen Timer pro eingeloggtem Nutzer" umgebaut: neue serverseitige Entität AktiverTimer (Erweiterung von R13 Leistungszeit, R13-F12..F17, Tabelle aktiver_timer, Migration v43) — eine Zeile je Benutzer (G-2), ephemer bis zum Buchen. Neuer AktiverTimerService (start/pause/fortsetzen/korrigieren/buchen/verwerfen) + Routen GET/PATCH /api/timer, POST /api/timer/{start,pause,fortsetzen,buchen,verwerfen}; starten() überschreibt NIE einen bereits für einen anderen Mandanten laufenden Timer (Datenverlust-Schutz) — liefert stattdessen konflikt:true mit dem bestehenden Timer. Client (mandant-detail.component.ts): lokale Timer-Signale durch aktiverTimer() (Server-State) ersetzt; timerHierAktiv()/timerAnderswo() steuern, ob die Akte die Bedienelemente zeigt oder nur einen Hinweis "Zeiterfassung läuft in einer anderen Akte" mit Link + Live-Uhr; visibilitychange synct beim Zurückkehren in einen Tab sofort den echten Server-Stand (behebt zugleich die Browser-Drossel- Symptomatik in Hintergrund-Tabs). Bewusstes Verhaltens-Update: beforeUnload warnt jetzt NICHT mehr wegen des Timers (er lebt serverseitig fort, geht durchs Schließen/Neuladen nicht mehr verloren) — nur noch bei ungespeicherten Beratungsdoku-Texten; das Verlassen-Modal bleibt als Buchungs-Erinnerung erhalten (Guard pausiert weiterhin serverseitig beim Verlassen). Gegen echten Browser verifiziert (wrangler dev
Playwright, zwei Tabs auf zwei verschiedenen Mandanten): Öffnen von Akte A startet automatisch; Öffnen von Akte B zeigt korrekt den Timer von A als "läuft anderswo" statt eigenen Timer zu starten; Pause/Fortsetzen/Buchen in A wirken sofort server-seitig; eigener erster Entwurf hatte einen kosmetischen Bug (die "läuft anderswo"-Anzeige zeigte immer den grünen/pulsierenden Punkt, auch wenn der Timer dort pausiert war) — selbst per Screenshot entdeckt und auf timerLaeuft()-Zustand korrigiert. +25 Vitest (timer.test.ts, 519 Server-Tests gesamt), tsc + ng build grün, Doku-Konsistenz-Check grün. CodeRabbit-Nachlese zu MED-D-172 (MED-D-173+174, PR #210 bereits gemergt, 0.89.0→0.89.1 PATCH): zuerst ein separater append-only-Verstoß entdeckt und korrigiert (die MED-D-171-Zeile war in Decision-Log/ CHANGELOG/Timesheet versehentlich überschrieben statt ergänzt worden — auf Original-Wortlaut zurückgesetzt, eigene MED-D-173-Zeile für die Korrekturrunde). Danach 4 echte Befunde: canDeactivate() pausierte den Timer vor statt nach der Schwellen-Prüfung (blieb bei schnellem, folgenlosem Verlassen still pausiert stehen, ohne dass verlassenAbbrechen() ihn je fortsetzt) — Reihenfolge korrigiert; /api/timer/start/ /api/timer/buchen hatten keine darfSehen/mandant_bearbeiten-Prüfung (echter RBAC-Sicherheitsfund, analog dem früheren MED-OP-AUTH-2-Fund für Meeting/Beratungsdoku/Individualdokument) — nachgezogen, +3 RBAC-Tests; Lastenheft-Anführungszeichen korrigiert; Konflikt-Test-Assertion + fehlendes konflikt:true- Feld in der /api/timer/start-Antwort ergänzt. Bewusst nicht übernommen: CLAUDE.md-Statusabsatz kürzen (mehrfach bestätigte Konvention), Test-Uebersicht-Zielgruppe (bereits über Lesepfade geroutet, identisch zu einem bereits abgelehnten MED-D-144-Vorschlag), HANDOFF-Zielgruppen-Vorspann (kein Präzedenzfall in ~170 vorherigen Einträgen). +3 Vitest (522 gesamt), gegen echten Browser verifiziert (schnelles Verlassen lässt den Timer nachweislich weiterlaufen). CodeRabbit-Nachlese zu MED-D-174 (MED-D-175, keine Versionsänderung): MVP-Scope.mds Status-Absatz behauptete pauschal "Slices 1–13 sind feature-complete", widersprach aber der eigenen Backlog-Tabelle (Slice 9 = 🟡 "Kern gebaut", echte Transkription offen) — präzisiert. Ein zweiter vorgeschlagener Test für die mandant_bearbeiten-403-Verzweigung bewusst nicht übernommen (kein Pfad erreichbar, da alle drei Rollen diese Fähigkeit besitzen — dieselbe bereits heute unabgedeckte Lücke wie bei den bestehenden Scope-Guards). Akten-Cockpit 1a (Detail): Mockup-Re-Sync per DesignSync-MCP (MED-D-176, 0.89.1→0.90.0, MINOR): auf Nutzerauftrag das aktuelle Akten-Cockpit 1a (Detail).dc.html erneut aus claude.ai/design ("Mandanten-Akte verbessern") gezogen und Zeile für Zeile gegen die Implementierung geprüft — dieses Mockup war bereits mehrfach umgesetzt/ nachgezogen worden (MED-D-156/159/162/164/170). Die meisten scheinbaren Abweichungen erwiesen sich als bereits bewusst getroffene, dokumentierte Entscheidungen statt Drift: Beratungsdoku bleibt inline im Mandate-Tab statt im Mockup-Modal-Overlay (MED-D-156, "volle Verschmelzung"); das "Jetzt dran" liegt konsolidiert im Übersicht-Tab statt zusätzlich in der Sidebar dupliziert. Der Aktenreife-Ring in der rechten Sidebar wurde bewusst nicht nachgebaut — das Mockup selbst hat diesen Abschnitt hart auf display:none gesetzt, auch der aktuelle Referenzentwurf zeigt ihn also nicht. Zwei echte, risikoarme Lücken behoben: das "Fristen & Aufgaben"-Anlage-Formular ist jetzt per + Aufgabe-Button ein-/ausklappbar statt dauerhaft sichtbar (wvFormOffen, wvFormToggle()); erledigte Wiedervorlagen lassen sich per neuem "Wieder öffnen"-Button (wvOeffnen(), nutzt die bereits bestehende wiedervorlageStatus(id,'offen')-API) reaktivieren statt endgültig erledigt zu bleiben. Reine Client-Änderung. tsc + ng build grün, vitest (522 Tests, unverändert) grün, Playwright-Verifikation der Toggle-/Reopen-Interaktion erfolgreich. CodeRabbit-Nachlese zu MED-D-176 (MED-D-177, keine Versionsänderung): 1 von 7 gemeldeten Befunden echt — die übrigen 6 waren Artefakte eines falschen Diff-Vergleichspunkts (der Feature-Branch war seit PR #210 commit-different, aber inhaltlich identisch zu origin/main divergiert, wodurch GitHub den Merge-Base fälschlich vor PR #210 statt auf den echten main-Kopf berechnete — app.ts/timer.test.ts erschienen dadurch als "geändert", zwei längst korrekt behobene historische Zeilen als "in diesem PR überschrieben"; Branch per git checkout -B … origin/main + Cherry-Pick sauber neu aufgesetzt, löst alle sechs an der Wurzel). Echt, behoben: PATCH /api/wiedervorlagen/:id + Nachbarrouten (…/kommentare, …/zuweisen) hatten keinen darfSehen/mandant_bearbeiten-Scope-Guard — derselbe Lückentyp wie MED-OP-AUTH-2/MED-D-174, hier aber schon vor MED-D-176 bestehend (der neue "Wieder öffnen"-Button macht sie nur über eine zweite Zustandsrichtung erreichbar). Neuer geteilter wiedervorlageScopeGuard (analog den drei bestehenden By-ID-Guards) auf /api/wiedervorlagen/:id*; +1 RBAC-Test, vorab gegen den ungefixten Stand verifiziert (schlägt ohne Fix nachweislich fehl). Grammatikfehler in der MED-D-176-Zeile korrigiert. Bewusst nicht übernommen: CHANGELOG.md-Eintrag um einen PR-Link ergänzen (etablierte MED-D-144-Konvention). +1 Vitest (523 gesamt), tsc + ng build grün, Doku-Konsistenz-Check grün. Zweiter CodeRabbit-Lauf gegen PR #212 (MED-D-178, keine Versionsänderung; PR #212 mergte per Auto-Merge, bevor dieser Fix gepusht war — Branch erneut frisch von origin/main aufgesetzt, landet als eigene Folge-PR): 8 gemeldete Befunde — 4 behoben, 2 aus Konventionsgründen abgelehnt, 1 durch die Merge-Race unanwendbar geworden, 1 nicht reproduzierbar. Echt, behoben: wvErledigen/wvOeffnen setzten nie das arbeitet()-Signal — der [disabled]="arbeitet()"-Doppelklick-Schutz griff dadurch nie; Busy-Flag ergänzt (analog wvAnlegen()). Veraltete 522-Testzahlen in Test-Uebersicht.md/Management-Summary.md/MVP-Scope.md auf 523 nachgezogen. Durch die Merge-Race unanwendbar geworden: die vorgeschlagene Zusammenführung der zwei CHANGELOG-Einträge von PR #212 zu einem — ein erster Versuch, dies rückwirkend in der bereits gemergten MED-D-177-Zeile selbst zu korrigieren, war ein eigener append-only-Fehler dieser Runde (selbst erkannt, vor dem Push zurückgesetzt). Aus Konventionsgründen abgelehnt: CLAUDE.md-Kürzung (mehrfach bestätigte Konvention); dieser Absatz um einen Link auf die aktuelle Folge-PR ergänzen (MED-D-144-Ausnahme). Nicht reproduzierbar: Lastenheft.md-Testzahl (Datei nennt keine, Fund nicht reproduzierbar). +0 Vitest (523 unverändert), tsc + ng build grün, Doku-Konsistenz-Check grün.

Stammdaten-Versionierung — Slice 1 (MED-D-179, 0.90.0→0.91.0, MINOR): Nutzer-Vorgabe aus der Durchsicht des überarbeiteten Design-Mockups "Akten-Cockpit 1a (Detail)" — "Alle Stammdaten sollen immer versioniert sein, z. B. alte Anschriften; jede Aktualisierung erzeugt eine neue Version" (erst Mandant, Praxis + Steuernummer/Steuer-ID als Folge-Slice). Neue append-only, per-Mandant hash-verkettete Entität StammdatenVersion (voller Snapshot je Version + quelle/actor, eigene Hash-Kette wie domain/audit.ts). Bewusst PII-tragend — der eine sanktionierte Ausnahmefall zur PII-armen Audit-Regel; die alten Feldwerte, die das Audit-Log weglässt, leben hier (Verschlüsselung/Retention = MED-KB-6). Versioniert im Repo-Chokepoint updateMandant/createMandant → lückenlos über alle 5 Schreibpfade (Berater, Self-Service, Onboarding); reine lifecycleStatus/verantwortlich-Änderung erzeugt keine Version. Migration v44 + idempotenter App-Level-Backfill (repo.backfillStammdatenV1, in index.ts — Hash-Kette braucht SHA-256). Route GET /api/mandanten/:id/stammdaten-versionen; Client: "Stand: vN"-Pille + Verlauf-Expander im Stammdaten-Rail. Live gegen echtes D1 verifiziert (Migration v44, Backfill 20 Mandanten, PATCH→v2 mit intakter Kette). Entschieden: dedizierte Struktur statt Audit-Tabelle (PII-Trennung); Repo-Chokepoint statt Service-Ebene (Lückenlosigkeit); IA des Mockups (5 Tabs, "Basis-Informationen" default) wird übernommen (kehrt MED-D-156-Übersicht-Konsolidierung um) — IA-Umbau + Modal + Bankkonten-1:n als Folge-Slices. +12 Vitest (523→535). Doku: Decision-Log MED-D-179, CHANGELOG, Feature-Liste, Test-Übersicht, Lastenheft §4.1.

DocuSign-HTTP-Adapter gebaut (2026-07-24, MED-D-220, 0.99.13→0.100.0, MINOR): erster echter Provider hinter der SignaturProvider-Abstraktion (server/src/signatur/docusign.ts) — Auth via JWT Grant (RS256 in-Worker über WebCrypto, PKCS#8-Key), Envelope-Flow (Dokument-Bytes aus der Ablage base64→Envelope mit Signer=Mandant + signHere-Tab), Status/Download der signierten Fassung (/documents/combined), Connect-Webhook POST /oeffentlich/signatur/docusign-webhook (HMAC-SHA256 konstant-zeit verifiziert, fail-closed ohne Key → 401; Pull-abgleich bleibt Fallback, RISK-6). QES→AES mit sichtbarem Hinweis (Dev-Account-Grenze, echte QES erst mit CSP, RISK-2). Sicherheitsriegel bleibt: kein abschliessenDemo → vorOrtAbschluss 409 (echte Vorgänge nie fälschbar, MED-D-198). Dormant ohne Secret (docuSignKonfigAusEnv→null → Fallback fake / 503; deploy-sicher, G-5). +10 Vitest gegen gemocktes fetch (553→563/51 Dateien). Bewusst nicht live verifiziert (kein Dev-Secret + kein Netz-Egress in der Build-Sandbox) — Scharfschalt-Runbook: docs/architektur/Deploy.md §7d. tsc+vitest grün. Doku: Unterschriften.md (DocuSign-Adapter-Abschnitt + OP-SIGN-1-Rest), Compliance/Risikoregister (US-Transfer/QES-AES), Deploy §7d, Decision-Log MED-D-220, CHANGELOG, Feature-Liste, Test-Übersicht.

Akten-Cockpit Slice A + B (In-Person-Signatur, 2026-07-25): Slice A (MED-D-223, →0.101.0) baute die DocumentRow-Zustandsmaschine (AD-008) + zwei Server-Seams (erinnern, signiert-hochladen→erhalten). Slice B (MED-D-227, 0.101.0→0.103.0, MINOR) schließt den MED-D-192-Rest (akte-patterns §2.5): (1) der Demo-/Vor-Ort-Abschluss (vorOrtAbschluss) landet nicht mehr über abgleich auf unterschrieben/ geprüft (Falsch-Nachweis, da Attrappe), sondern — wie Sign-on-Paper über den gemeinsamen erhaltenAblegen- Helfer — auf erhalten (Prüfung offen), Vorgang signiert, Audit signatur.vor_ort_abgeschlossen, Onboarding-Item unangetastet, idempotent; der echte DocuSign-Webhook-abgleich bleibt auf unterschrieben/geprüft. (2) geführte In-Person-Strecke im Assistenten (Übergabe → Kunden- Signaturansicht → Danke/Rückgabe → Schritt 3, Vollflächen-Takeover) statt einklickigem Abschluss. (3) Write-back-Automatik: bei Abschluss automatisch SEPA-Konto→gültig (ersetzt manuellen Button) + auslösende Aufgabe→erledigt (neuer aufgabeId-Input), best-effort + idempotent, Ergebniskarte. Server-Vitest 571→572; tsc+vitest+ng build grün. Verifikation: Server-Unit-Tests (State-Transitions/Idempotenz/Audit) + ng build (validiert die Template-Kontrollfluss-Blöcke) — kein seedbarer e2e-Harness im Repo, daher kein Playwright-Klickdurchlauf in dieser Session. Rest C/D (MED-D-192-Delta) bleibt offen (§4).

Akten-Cockpit Delta C — Prüfen-Schritt ausgebaut (2026-07-25, MED-D-229, 0.102.0→0.103.0, MINOR): Der Nutzer wählte aus den (im Repo nie ausbuchstabierten) Delta-Kandidaten „Prüfen-Schritt ausbauen". Assistent-Schritt 1 (§2.5) zeigt bei ausgewähltem Dokument jetzt (1) eine Pflichtdaten-Checkliste (Name/E-Mail/Anschrift/Geburtsdatum, ✓ „aus Stammdaten"/● „fehlt", abgeleitet read-only), (2) SEPA-Konto-Auswahlkarten (nur SEPA-Kontext) + Inline „Neues Konto erfassen" via die berater-editierbare Bankkonto-Route; das gewählte Konto (effektivKontoId) steuert den SEPA-Write-back, (3) eine Formular-Vorschau (read-only). mandant-Input neu; der Assistent lädt seine Bankkonten selbst. Bewusste Scope-Grenze: kein Inline-Schreiben fehlender Mandant-Stammdaten (kreuzt die editierbar-Grenze/Audit- Design MED-D-147) → fehlende Felder werden markiert + auf Self-Service/Formular verwiesen. Rein Client, kein Server-/Enum-Change (Tests unverändert 572); tsc+ng build grün.

Akten-Cockpit Delta D — Fremdformular-Markierung + Feld-Editor-Hinweisbox (2026-07-25, MED-D-230, 0.103.0→0.104.0, MINOR): der an OP-SIGN-1 gekoppelte, aber jetzt schon baubare Teil von Delta D. (1) Fremdformular-Klassifikation rein abgeleitet: ein Dokument ist ein Eigenformular, wenn seine Bezeichnung eine bekannte Vorlage trägt (DOKUMENTTYP_LABEL als einzige Quelle, G-2), sonst Fremdformular (kunden-/drittseitiges Formular ohne hinterlegte Vorlage) — keine neue Persistenz/Enum-Flags. (2) amber „Fremdformular"-Pill an der Schritt-1-Dokumentzeile. (3) bei gewählten Fremdformularen 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) — die echte Feld-/Template-Bindung gehört an DocuSign (OP-SIGN-1); der Button meldet ehrlich „folgt mit der DocuSign-Anbindung" (MED-KB-5). Rein Client, kein Server-/Enum-Change (Tests unverändert 572); tsc+ng build grün. Weiterhin offen (§4): der echte Feld-Editor (an OP-SIGN-1) + die persistierten versendet/nicht_erforderlich-Enum-Flags (bewusst deferiert).

Fremdformular-Feldmapping & Prefill — AD-010 Weg A, Slice 1 (2026-07-25, MED-D-235, 0.105.0, MINOR). Löst AD-010 ein und ersetzt den MED-D-230-Platzhalter-Toast: fremde ausfüllbare PDFs (Bank-/Partner-Formulare wie die apoBank-EDÜ) → AcroForm-Felder auslesen, je Feld ein Weltmodell-Attribut zuordnen (G-8), aus den Stammdaten vorbefüllen (verlustfreie R2-Rückablage). Weg A (Nutzerwahl „A" + echtes apoBank-PDF): nur das Mapping ist Eigenbau — Füllen via pdf-lib, Signieren via DocuSign (G-1). Neu: pdf/pdf-formular.ts, domain/fremdformular.ts (Katalog WELTMODELL_ATTRIBUTE), api/fremdformular-service.ts, Feld-Editor-Overlay client/akte-feld-editor.component.ts; Mapping als JSON-Spalte dokument.fremdformular_mapping (Migration v46); Routen /api/dokumente/:docId/fremdformular (GET/PUT/POST). +17 Vitest (591), Adapter gegen echtes apoBank-PDF verifiziert. Rücklauf = Slice 2 (MED-OP-FORM-5, §4); interaktive UI-Begehung steht aus. Design: docs/architektur/Fremdformulare.md.

Echte Vor-Ort-/In-Person-Signatur (DocuSign embedded) + irreführender 409 entfernt (2026-07-25, MED-D-236, 0.106.0, MINOR). Nutzerfund: bei echtem DocuSign warf „Vor Ort abschließen" einen 409 — der Vor-Ort-Weg lief bisher nur über die Attrappe (abschliessenDemo, die echte Provider bewusst nicht bieten). Jetzt echte In-Person-Signatur: SignaturProvider um vorOrtVorbereiten (captive/embedded recipient → kein E-Mail-Versand) + vorOrtSignaturUrl (recipient view) erweitert; DocuSign-Adapter implementiert beide (Host = Berater via DOCUSIGN_HOST_NAME/_EMAIL). Client lädt bei echtem Provider die Signatur-URL in einen iFrame (sequenziell bei mehreren Dok.), erkennt signing_complete same-origin → abgleich+Write-back → Dokument erhalten (Prüfung offen, wie Sign-on-Paper). Demo-Banner/-Schnellabschluss nur noch beim Fake (istEcht). Sicherheitsriegel unverändert (echter Adapter ohne abschliessenDemo → Attrappe weiter 409). +5 Vitest (597). Host = eingeloggter Berater (MED-D-237, 0.106.1, PATCH): der In-Person-Host wird aus der eingeloggten Identität (akteurVon(c).email + benutzer.anzeigename) abgeleitet statt aus einem globalen Secret — für einen korrekten DocuSign-Audit-Trail (G-4); DOCUSIGN_HOST_* bleiben Fallback. Voraussetzung: Berater-E-Mail muss DocuSign-Account-Nutzer sein. +1 Vitest (598). Live gegen DocuSign noch nicht verifiziert (keine Secrets/Netz in der Session, wie MED-D-220) → OP-SIGN-1 offen; Runbook Deploy.md §7d. Design: docs/architektur/Unterschriften.md.

Historie je Version: CHANGELOG.md · was gebaut ist: docs/fachlich/Feature-Liste.md (dieser Abschnitt hält bewusst nur den aktuellen Stand — ein Absatz, keine Log-Kopien; MED-OP-DOKU-1). 1.0.0 wartet auf: Live-Betrieb der Integrations-Adapter (DocuSign-Adapter gebaut, aber Secret/AVV/Live-Verifikation offen → OP-SIGN-1; PandaDoc/QES-CSP · E-Mail-Versand → OP-DM-8 · CRM) + HQ-Eigentümer-Zuordnung der Domain.

3. Letzte Entscheidungen (mit IDs)

MED-D-221 DocuSign-Credentials via GitHub-Secrets (keine Versionsänderung, CI/Config + Doku): die 5 DOCUSIGN_*-Credentials liegen als GitHub-Repo-Secrets und werden beim main-Deploy in den Worker gesynct (app-deploy.yml, dasselbe Muster wie NextCloud). Geheim/nicht-geheim getrennt: Credentials → GitHub-Secrets (RISK-8/G-5); Go-Live-Schalter SIGNATUR_PROVIDER=docusign bleibt als nicht-geheimer, auskommentierter Toggle in wrangler.toml [vars] (Everything-as-Code, G-2 — Go-Live = sichtbarer Commit). Credentials allein schalten nichts scharf (Compliance-Gate RISK-4). Runbook Deploy §7d.
MED-D-220 DocuSign-HTTP-Adapter gebaut (0.100.0, MINOR): erster echter E-Signatur-Provider hinter der Abstraktion — JWT-Grant (WebCrypto/PKCS#8, kein Node-SDK auf Workers) + Envelope + Connect-Webhook (HMAC, fail-closed). Zwei Nutzer-Weggabelungen (bereits final): QES-Behandlung = "Als AES senden + sichtbarer Hinweis" (Dev-Account-Grenze, echte QES erst mit CSP); Slice-Zuschnitt = "Adapter + Connect-Webhook". Dormant ohne Secret (deploy-sicher). Nicht live verifiziert (kein Secret/Netz in der Sandbox); Scharfschalten via Deploy.md §7d. Aktiviert RISK-2 (QES-AES) + RISK-4 (US-Transfer) konkret.
MED-D-108 Kundenmeeting 12.07.2026 eingearbeitet (Doku, keine Versionsänderung): bereinigtes Protokoll docs/fachlich/Anforderungen-Meeting-2026-07-12.md. Bestätigt: "Kunden-Detail" = CRM (Daylite) + Ablage + Beratungsmandate + Orchestrierung (MED-D-95); Betreuungsintensität Intensiv/Standard/Basis (nicht A/B/C — deckt sich mit gebautem betreuungsmodell R1-F11/D-35, schärft OP-ABC-1); Lifecycle Lead→…→Ruhend→Archiviert; Weltmodell (G-8); 3 Signaturstufen (OP-SIGN-1); Audit-Lese-Log (D-50); NextCloud entbehrlich → nur Read-Only-Notfall-Backup (MED-KB-4). Neu: Flat-Fee-Automatik (nicht abrechnen, Zeit läuft weiter für Rentabilität → OP-TIME-1); Dexman-Portal ohne Passwort (E-Mail-Code/Magic-Link → Dexman.md); Leistungsstatistik pflegt der Kunde selbst (PVS-Anbindung = späterer Ausbau, OP-DEX-1); Mahnstufen-Banner (OP-INVOICE-1). Action-Items für den Folgetermin (~2 Wochen, Taktano per Video): Kundendatenbogen ins Onboarding, Sutor-Bankformulare (MED-KB-8), Dexman-Produkt anlegen, Dokumenten-Baumstruktur, 2–3 Beispielkunden + Onboarding durchklickbar.
MED-D-60 Draft-PR-Workflow für alle Agenten (Prozess, keine Versionsänderung; ergänzt MED-D-59): Rate-Limit-Schutz auf der Demand-Seite — Feature-PRs als Draft öffnen, im Draft frei pushen (CodeRabbit reviewt Drafts nicht → 0 Reviews im WIP), erst bei "ready for review" reviewt CodeRabbit einmal + Auto-Merge scharf → ~1 Review/PR statt je Push. Gate implizit (nur Draft-Status, kein Label). Bewusst keine ignore_usernames-Bot-Ausnahme (CodeRabbit-Finding PR #86): ein ausgenommener dependabot[bot]-PR bekäme nie den CodeRabbit-Status → bliebe als Required Check am Gate hängen; Bot-PRs werden mitreviewt. Konvention in agents.md §7, gilt für alle Sessions (SessionStart-Hook liest agents.md/CLAUDE.md).
MED-D-59 CodeRabbit auto-merge-tauglich & rate-limit-sicher (Tooling, keine Versionsänderung; schärft MED-D-52): .coderabbit.yaml setzt commit_status: true (Status-Context CodeRabbit = als Required Check hinterlegbar), fail_commit_status: false (Rate-Limit bleibt pending statt failure → kein Auto-Merge-Deadlock), auto_incremental_review (damals true; später auf false gesetzt, MED-D-100 — EIN Review je PR beim "ready for review", keine inkrementellen Re-Reviews), collapse_walkthrough: true + erweiterte path_filters (kompakter, Doku bleibt), drafts: false + "nur bei offenem PR". Offen (Admin/gh api, agents.md §6.5): Status-Context CodeRabbit in der Branch-Protection von main neben checks als Required Check aufnehmen.
G-1 Standardwerkzeuge bevorzugen als zentrales Leitprinzip (Nutzer-Vorgabe: "nach Möglichkeit auf Standardwerkzeuge zurückgreifen").
A-1 Dokumente → NextCloud (kein Eigenbau-DMS).
A-2 Unterschriften → DocuSign oder PandaDoc über Provider-Abstraktion (Anbieterwahl offen).
A-3 Kundenstamm → CRM extern; Medidentas referenziert (S-1).
OP-PM-1 union-Merge für CHANGELOG/HANDOFF/Timesheet; branch-abgeleitete Session-IDs.
A-6 / R10 Plattform um Spezial-Tools erweiterbar (Tool-Host + Manifest-Vertrag, Isolation je Tool).
Dexman als erstes Spezial-Tool spezifiziert (Mitbewerber medipulse.de analysiert). Sharpt OP-DOMAIN-1: Mandanten = Zahnarzt-/Arztpraxen / MVZ, Anwender = Praxisberatungs-Kontext (final bestätigen).
A-4 Stack = Cloudflare (06-27, Nutzer-Entscheidung): Workers + D1 + Queues + Cron, wie Taktano. Schließt OP-STACK-1; eröffnet Folge-OPs OP-AUDIT-1 (D1+R2-Retention), OP-OBS-1, OP-DATA-1, OP-AUTH-1.
Deploy-Architektur (28.06., OP-DEPLOY-1): eine Subdomain app.medidentas.com — ein Worker bedient UI + /api über Static Assets (wrangler [assets] + SPA-Fallback in index.ts). Begründung: ein Origin → Cloudflare Access schützt UI und API in einer Policy, kein CORS. Domain medidentas.com gekauft, Transfer an HQ ausstehend. Repo ist deploy-fertig (manueller app-deploy.yml-Workflow); sofort testbar über *.workers.dev. Runbook: docs/architektur/Deploy.md.
MVP-Plan: erster vertikaler Slice = Mandant + Onboarding (R1/R2), dann Dokumente → Wiedervorlagen → Unterschriften → Beratungsdoku; Audit-Log quer ab Slice 1.
Workshop 20.01.2026 (Anwender-Betrieb): Domäne bestätigt (Finanz-/Versicherungs- & Praxisberatung für (Zahn-)Arztpraxen) → schließt OP-DOMAIN-1. Neu: R11 (Meeting-Doku & Aufgaben, Prio 1 des Kunden), R12 (Dokumenten-Automatisierung), UC-7/8, OPs OP-MEET-1/OP-DOCGEN-1/OP-AI-1, FR-4 (MyID). CRM: Ist=Daylite, Zielrichtung HubSpot — aber Build-vs-Buy offen (Medidentas hält zunehmend "eine Wahrheit"; OP-CRM-1 geschärft). Neue Risiken RISK-14 (KI-Beratungsdoku-Haftung), RISK-15 (PII in US-/Cloud-KI-Diensten).

4. Offene Punkte (Kurzform — Detail im Lastenheft §11)

Eingefroren (MED-D-361, #361): alle offenen Alt-Punkte sind als GitHub-Issue migriert — die Quelle ist das Issue (→ #n in der ID-Spalte; Übersicht: Issues mit Label offener-punkt). Diese Tabelle wird nicht mehr fortgeschrieben; erledigte Zeilen bleiben als Archiv.

ID	Kurz	Nächster Schritt
MED-OP-UX-15 → #392	✅ Slice A ✅ (MED-D-332: K-01/03/04/05/07/09), K-10 ✅ (MED-D-331), Slice B ✅ (MED-D-333: K-02/K-06/K-08); Rest: Formular-/Fragebogen-Einladungen versenden weiter die Mitarbeitenden; Go-Live-Gate Kontaktwerte (Deploy.md §7f) — Einfachheit Kundenseite (Audit §E.3, K-01…K-10): Ansprechpartner (Name/Telefon) + Impressum/Datenschutz auf allen Kundenseiten; Portal als einzige To-do-Liste (Formulare öffenbar, keine internen Items, Dokumente nicht doppelt); App versendet Einladungen selbst; deaktivierte Buttons mit Begründung + Fehler am Feld; Datums-/IBAN-/PLZ-Eingaben mit Format/Zifferntastatur; Fragebogen seitenweise; Upload mit Kamera + gestaltetem Button; Portal-Sitzung ohne Datenverlust; Schrift ≥14 px; SLA-Erinnerung mit echtem Empfänger (K-10) ✅ MED-D-331.	Priorisieren mit dem Nutzer; zuerst M-02 (ein Einstieg für Kunden) + K-01. Nutzertest (M-08).
MED-OP-UX-16	✅ Slice A ✅ (MED-D-334: I-05/I-09/I-10/I-11), Slice B ✅ (MED-D-335: I-02/I-04/I-07); Rest → MED-OP-UX-18 — Einfachheit interne Seite (Audit §E.4, I-02/I-04…I-11): Mandanten-/Kundenseite verschlanken (ein „Nächster Schritt", ein Status, Rest per „Mehr"); je Aufgabe ein Weg (Dokument anfordern, Unterschrift); interne IDs/Technikbegriffe aus der UI; Schrift ≥16 px Grundgröße, Klickflächen ≥44 px; Cockpit-Kopfzeile ohne Überlauf/Build-Infos, toter „Suchen/Springen"-Knopf; Fehlermeldungen mit Ursache + nächstem Schritt; Zuweisen per Personenauswahl. I-01/I-03/I-08 ✅ MED-D-328.	M-04 als eigenes Programm planen; Nutzertest (M-08).
MED-OP-UX-18	✅ MED-D-337 — Unterschrift auch bei erzeugten/frei geschriebenen Dokumenten nur über den Assistenten (Rest aus I-04, MED-D-335)	Umgesetzt: "Zur Unterschrift →" bei Dokumentgenerierung/Individualdokument öffnet für Quellen im Status `abgelegt` den Assistenten mit `erzeugtesDokumentRef`; der Server führt die Quelle beim Signatur-Start nach (Status `zur_unterschrift`, `signaturRef`, Audit-Event, beim Individualdokument dessen Stufe als Vorgabe), wiederherstellbar über den 409-Wiederholungsweg; ein zweiter Start liefert 409. Abgeschlossen per MED-D-337.
MED-OP-UX-17 → #393	🟡 UI ✅ (MED-D-330), Fließtext-Doku schrittweise — Begriffs-Umstellung „Kunde" + „Mandat" (MED-D-326): sichtbare UI-Texte, `labels.ts`, Glossar und Doku von „Mandant" → „Kunde" und von Beratungsauftrag/Auftrag/Beratungsmandat → „Mandat"; technische Identifier/Routen/DB bleiben (kein Daten-Refactor).	Eigener PR: UI-Texte + Glossar + Doku; E2E-Selektoren mitziehen.
MED-OP-UX-14	✅ aufgelöst (MED-D-319): Primary-CTA überall Markengrün `--md-green` (die 2 nahen Grüns vereinheitlicht; `--accent` bleibt Fokus/Füllung/Spine/Links); Verlassen-Modal nutzt die geteilte `md-overlay`-Shell (hand-gerollte Mechanik entfernt); Command-Palette bewusst als eigenständiges Spotlight-Muster belassen + per Interaktions-E2E (`cockpit-overlays.spec.ts`) abgesichert. Bewusst nicht: Pixel-Visual-Regression-Harness + Merge der drei (absichtlich gelayerten, dokumentierten) Button-Basen — die substanzielle Inkonsistenz ist gelöst.	— (optionale Zukunft: Pixel-Visual-Regression-Harness, falls je nötig).
MED-OP-PORTAL-2	✅ abgeschlossen. Teil 1 Dokument-Upload im Portal (MED-D-316): der eingeloggte Kunde lädt angeforderte Dokumente direkt im `/portal` hoch (der anonyme Einmal-Link bleibt als Fallback). Teil 2 mehrere Kontakt-Logins je Mandant (MED-D-320, löst MED-KB-13 (3)): Staff verwaltet je Mandant mehrere Portal-Kontakte (anlegen/auflisten/sperren/reaktivieren), jeder mit eigenem Magic-Link-Login, alle auf denselben Mandanten scoped.	— (erledigt).
MED-OP-PORTAL-3	✅ erledigt (MED-D-311): Portal-Login-Härtung — Turnstile + fensterbasiertes Rate-Limiting (je IP 20 / je E-Mail 5 pro 10 min → 429; Schlüssel gehasht, PII-arm) am öffentlichen `POST /oeffentlich/portal/anmelden`; `GET /oeffentlich/portal/config` liefert den Sitekey; Client rendert das Widget. Voraussetzung vor dem öffentlichen Cloudflare-Access-Bypass für `/portal`.	Nur noch Infra (Deploy.md §7e): `TURNSTILE_SITEKEY`/`TURNSTILE_SECRET` setzen (ohne Secret nur Rate-Limit) + Access-Bypass.
MED-OP-ONB-1 → #394	🟡 Onboarding-Vereinfachung (Neubaustudie, Richtung MED-D-291) — Slice-Fahrplan N1–N5. N2 (Abschnitts-Freigabe) ✅ gebaut (MED-D-292). N1 1. Schritt ✅ gebaut (MED-D-293): geteilte Bausteine (Lade-Fehler-Auswertung + Turnstile-Bindung) in `pub-bausteine.ts` konsolidiert (verhaltensneutral). Offen (N1 Rest): (a) sichtbarer Item↔Token-Vorgang-Link — heute kein Datenmodell-Link (nur `Dokument.onboardingItemId`; die 3 Vorgang-Flächen liegen in getrennten Reitern, `mandant-detail` lädt die Formulare nicht) → braucht `ausfuellformular.onboardingItemId` (+ Migration) gesetzt über einen „aus Item erzeugen"-Fluss, statt eines brüchigen Titel-Matches; (b) volle Feld-Engine-Verschmelzung der 3 unterschiedlichen Feld-Modelle. Dann: N3 (Portal als einziger Zugang, Token = Einmal-Login — hängt am DSGVO/AVV-Go-Live-Gate MED-KB-13); N4 (1 Snapshot je Einreichung statt Feld-Hash-Kette im Onboarding); N5 (Consent → DocuSign, an OP-SIGN-1). Nutzer-Zusatz zu Q4 (H5): der Betreuer muss angeben können, was jetzt dringend gebraucht wird, und das soll gruppiert aus den gebuchten Beratungsmandaten hervorgehen.	Richtung geschärft (MED-D-294): Nutzer wählte vollen Greenfield-Neubau (Option A) — keine Echtdaten → Datenmodell frei neu (ein `Feld`/G-8 · ein `FormularVorgang` · ein Fluss · echter Item↔Vorgang-Link). Design-Dokument + Slice-Plan G1–G5: `docs/architektur/Onboarding-Neubau.md`. G1 ✅ (MED-D-295): kanonisches `Feld` + `FormularSchema` (`feld.ts`) + Adapter der 3 Alt-Kataloge (`formular-schema.ts`), Weltmodell §3.4. G2 ✅ (MED-D-296): die eine `FormularVorgang`-Entität + Persistenz (Tabelle `formular_vorgang`, Migration v57) + `FormularVorgangService` (schema-getrieben) — noch von keiner Route geschrieben. G3 Etappe 1 ✅ (MED-D-297): geteilte Feld-Engine `PubFeldEngineComponent` (Client) + Adoption im Ausfüll-Formular. G3 Etappe 2 ✅ (MED-D-298, voller Rewrite): der Ausfüll-Flow läuft komplett über den einen `FormularVorgangService` auf dem `formular_vorgang`-Store (gesamte Logik portiert: Festwerte/KI/PDF-Beleg/WV/Rückübernahme/N2/SLA), `AusfuellformularService` gelöscht, HTTP-Vertrag erhalten, 706 Vitest + Full-Stack-E2E 5/5 grün. G3 Etappe 3a ✅ (MED-D-299): Onboarding-Strecke rendert über die geteilte `PubFeldEngineComponent` (Ausfüll + Onboarding aus einer Engine). G3 abgeschlossen ✅ (MED-D-300): Fork aufgelöst — die eine Feld-Engine gilt für die strukturell gleichen Wege (Ausfüll + Onboarding ✅); der Fragebogen bleibt bewusst purpose-built (reiche Domänen-UX — Klasse-Badges/Einheit/Plausibilität/Block-Akkordeon/Öffnungszeiten-`strukturTyp`/gewichteter Score — ist ein Feature; ihn in die generische Engine zwingen würde die UX regressieren oder die Engine aufblähen, G-3), die Store-Vereinheitlichung bleibt bewusst auf den Ausfüll-Flow begrenzt (Onboarding/Fragebogen anders geformt → keine Wide-Table mit Nullable-Spalten, G-8); `fragebogenSchema()` bleibt als Adapter für Analyse/Konsistenz. G4 ✅ (MED-D-301): der Item↔Vorgang-Link ist real (`onboardingItemId` verdrahtet, „Formular aus Item anfordern" je Item idempotent, Status/Öffnen/Link an der Checklisten-Zeile → Checkliste treibt die Vorgänge, True North #1); Q4-Zusatz als abgeleitete Bedarfs-Sicht gruppiert je gebuchtem Mandat („Jetzt gebraucht", `benoetigt` = Produkt-Playbook, G-2). G5 ✅ (MED-D-302): dormante `ausfuellformular`-Tabelle + Repo-Methoden entfernt (Migration v58 `DROP TABLE`), historische Migrations-Schritte + `Ausfuellformular`-Interface bleiben. Greenfield-Programm G1–G5 abgeschlossen. Interaktive Item↔Mandat-Zuordnung ✅ (MED-D-303): `OnboardingItem.auftragRef` + mandant-scoped Bind-Route/Service + per-Item „Mandat"-Select; die „Jetzt gebraucht"-Sicht zeigt die zugeordneten Items je Mandat (Fallback = Playbook). Offen: N3 (Portal als einziger Zugang, an MED-KB-13), N4 (1 Snapshot je Einreichung), N5 (Consent → DocuSign, OP-SIGN-1).
MED-OP-AKTE-2	🟡 Kunden-Cockpit-Redesign v2 (Design "Kunde verbessern") — mehrteilig; voller Slice-Plan S1–S6 festgelegt (MED-D-188); S1–S6 vollständig gebaut — MED-OP-AKTE-2 ✅ geschlossen. Das überarbeitete Mockup "Kunden-Cockpit 1a (Detail)" bündelt vier Bausteine: (1) Stammdaten-Versionierung ✅ gebaut (MED-D-179, Mandant) — der einzige bereits gebaute Baustein; (2) Praxis-Stammdaten + neue Felder Steuernummer/Steuer-ID versionieren; (3) IA-Umbau auf die 5 Mockup-Tabs (Basis-Informationen default, "Übersicht" raus — kehrt MED-D-156 bewusst um) + Stammdaten-Bearbeitung als Modal-Overlay mit inline Feld-Historie; (4) Self-Service-Portal (FR-1) — die zwei heute getrennten Links (Stammdaten-Einladung + Dokument-Upload) zu einem Portal verschmelzen, Dokument-Status + Kunden-Upload, Dokument-Versionierung mit Prüf-Zyklus (Reupload → Status "zu prüfen", analog Feld-Sichtung MED-D-89). Bankverbindungen als eigene 1:n-Entität (mehrere Konten, SEPA-Mandat je Konto, versioniert, swipe-to-archive): frühere Zurückstellung aufgehoben — jetzt Plan-Slice S3 (MED-D-188, Nutzerentscheidung 2026-07-23). Externe Formulare:** dünne Referenz `vorlageRef` → DocuSign/PandaDoc-Template-ID (kein Eigenbau-Editor, G-1) + Admin-Anleitung + Feldnamen-Test-Lauf beim Integrieren.	Voller Slice-Plan festgelegt (2026-07-23, MED-D-188): `docs/architektur/Kunden-Cockpit-Redesign.md` — Ziel-IA (5 Reiter + 4 Overlays, Basis-Informationen default) + 10 Komponenten, Slices S1 IA-Fundament/Overlay-Shell · S2 Dokument-Zustandsmaschine · S3 1:n-Bankkonten+SEPA · S4 VersionedField/Self-Service · S5 Unterschriften-Assistent · S6 Feinschliff (je PR). Drei Nutzer-Entscheidungen eingebaut: Plan-first · Assistent jetzt gegen die Fakes (MED-KB-5/OP-DM-8) · 1:n-Bankkonten jetzt (kehrt die frühere Zurückstellung um). S1 löst MED-OP-AKTE-2 ein. ✅ S1 gebaut (2026-07-23, MED-D-191, `0.92.0`): 5-Reiter-IA (Basis-Informationen Default · Mandate · Alle Dokumente · Fristen & Aufgaben · Praxen), generische Overlay-Shell (Scrim/ESC) mit Stammdaten- & Zeiten-Overlay, LifecycleRing-Avatar (Client-only). Mandat-Overlay (Mandate-Rework) + Assistent-Overlay (S5) bewusst zurückgestellt; Mandate bleibt vorerst ein Reiter. ✅ S2 gebaut (2026-07-23, MED-D-192, `0.93.0`): StatusSlider (Fehlt·Erhalten·Geprüft, neue Komponente `md-status-slider`) an Onboarding-Items + Ablage-Dokumenten, RequirementCheckbox + "vorerst nicht erforderlich"-Trenner, Ablauf-Chip — reines UI-Mapping, kein Server-/Enum-Change (Design-Konflikt so entschieden). Assistent-abhängige DocumentRow-Zustände (versendet/"Zur Unterschrift"/Fremdformular) zu S5 verschoben. ✅ S3a gebaut (2026-07-23, MED-D-195, `0.94.0`): 1:n-`Bankkonto`-Entitaet (Inhaber · IBAN · Zeichnungsberechtigung · Pruefstatus `neu/geprüft/archiviert` · `sepaGueltig`) — Domain/Schema/Migration v45/Repo/Service/Routen + verlustfreier, crash-/nebenlaeufigkeitssicherer Backfill aus den Alt-Feldern `mandant.ibanPrivat`/`praxis.iban` (stabiler `quellSchluessel` + UNIQUE-Index + `ON CONFLICT DO NOTHING`; Alt-Felder zwei-phasig lesbar erhalten, kein DROP). Live gegen `wrangler dev`/miniflare verifiziert (Migration + Backfill `angelegt:2`, idempotent bei Zweit-Boot, manuelle CRUD-Routen + 400-Validierung). +12 Vitest (CRUD + Idempotenz/Concurrency/Crash-Backfill). ✅ S3b gebaut (2026-07-23, MED-D-196, `0.95.0`): BankRow-UI im Stammdaten-Overlay — 1:n-Bankverbindungen als Zeilen (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 als Sicherheitsnetz) plus dezenter Desktop-/Tastatur-Archivieren-Button, Peek-Teach der Geste (einmalig beim Overlay-Öffnen), archivierte Konten schreibgeschützt unter Trenner. Reine Client-Anbindung an die S3a-Routen (neue `KundeBankrowComponent` + ApiService-Methoden). Live gegen `wrangler dev` + Playwright verifiziert (11/11 grün: Render, Slider, SEPA, Anlegen, Desktop-Archiv, Swipe-Geste, append-only kein DELETE, 0 Konsolenfehler). Damit ist S3 vollständig. ✅ S4 gebaut (2026-07-23, MED-D-197, `0.96.0`): VersionedField (§2.7) — neue `KundeVersionedFieldComponent` (`md-versioned-field`) im Stammdaten-Overlay: je versioniertes Feld (Anzeigename · E-Mail · Telefon · Geburtsdatum · Straße/PLZ/Ort · CRM) aktueller Wert + `vN`-Pille (Version der letzten Änderung) → aufklappbare Feld-Historie genau dieses Feldes, client-seitig aus den bereits geladenen MED-D-179-Snapshots abgeleitet (kein Zweit-Fetch, G-2); Versions-Pille jetzt auch im Overlay-Kopf (`Stand: vN`); `stammVersionen` wird eager geladen. Reine Client-Anbindung, kein Server-Change. Live gegen `wrangler dev` + Playwright verifiziert (9/9: Kopf-Pille v4, 8 VersionedFields, E-Mail-Feldhistorie v3/v2, CRM v4, unveränderte Felder ohne Pille, 0 Konsolenfehler). §2.8 Self-Service-Karte: die Link-Verwaltung (kopieren/übernehmen/neu) ist bereits gebaut (MED-D-170, linke Rail + `md-kunde-einladungen`); customer-hochgeladene Dokumente erscheinen im Reiter "Alle Dokumente" (S2) — keine Duplizierung nötig, als erfüllt bewertet. ✅ S5 gebaut (2026-07-23, MED-D-198, `0.97.0`): Unterschriften-Assistent (§2.5) — neue `KundeUnterschriftenAssistentComponent` (`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 (MED-KB-5, kein Echt-Eindruck). Einstiege: DocumentRow (⋯ "Im Unterschriften-Assistenten"), Dokumente-Tab ("Assistent öffnen"), BankRow "SEPA einholen" (setzt bei Abschluss das SEPA-Mandat gültig). Server: neuer Vor-Ort-/Demo-Abschluss-Seam — `SignaturProvider.abschliessenDemo?` (nur der Fake implementiert es → echte Vorgänge können nie gefälscht werden), `SignaturService.vorOrtAbschluss` + Route `POST /api/signaturen/:id/vor-ort-abschluss` (409 bei echtem Provider), Niveau-Override an der Anfordern-Route. Write-back läuft in den bestehenden `abgleich`-Pfad (Dokument → unterschrieben, Item → geprüft, signierte Ablage, Audit). +5 Vitest (552 gesamt). Live gegen `wrangler dev` + Playwright verifiziert (9/9: Banner, 3 Schritte, Sammel-Auswahl, Vor-Ort-Abschluss, Write-back Dokument→unterschrieben, SEPA-Einstieg). Bewusst deferiert (dokumentiert): die Enum-Flags `versendet`/`nicht_erforderlich` (S2-Entscheidung — "wartet auf Signatur" wird aus dem Signatur-Status abgeleitet, kein Enum-Change); automatische SEPA-/Wiedervorlage-Verknüpfung ans Dokument (manueller Bestätigungs-Schritt statt neuem Modell). Echte DocuSign/PandaDoc-Adapter + E-Mail-Versand (MED-KB-5/OP-DM-8) bleiben der spätere reale Einbau. ✅ S6 gebaut (2026-07-23, MED-D-199, `0.98.0`): TaskCard-Feinschliff (§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 einen "Im Unterschriften-Assistenten →"-Einstieg (schließt die letzte offene TaskCard→Assistent-Kante aus dem §2-Diagramm). Bewusst kein eigener Sub-Komponent (die bestehende Zeile trägt viel inline-State — Edit/Zuweisen/Kommentare; Extraktion wäre Churn ohne Wiederverwendung, analog der S1-Sidebar-Entscheidung) — reiner Präsentations-Feinschliff, alle Bedienelemente erhalten. Live gegen `wrangler dev` + Playwright verifiziert (9/9). Damit sind alle 10 kunden-patterns-Komponenten gebaut → MED-OP-AKTE-2 (Kunden-Cockpit-Redesign, MED-D-188) ✅ vollständig. ✅ Mandat-Overlay nachgezogen (2026-07-23, MED-D-200, `0.99.0`): der in S1 zurückgestellte 4. Design-Overlay — Mandate-Reiter jetzt kompakte Liste (eine Zeile je Auftrag) + Klick öffnet die vollständige Mandat-Detail im Scrim-Overlay (`kunde-auftraege.component.ts`, reine Client-Restrukturierung, In-Place-Reload hält das Overlay flacker-frei offen); Live 9/9 verifiziert. Damit sind alle 4 Design-Overlays gebaut. Bewusst weiterhin offen: der reale Signatur-/E-Mail-Adapter (MED-KB-5/OP-DM-8/OP-SIGN-1); MED-KB-6 (Bank-PII-Verschlüsselung/Retention).
~~MED-OP-UX-1~~	✅ erledigt (`0.63.0`, MED-D-90): UX-Welle 1 — Verlässlichkeit & Rechtssicherheit (aus `docs/betrieb/UX-Prozess-Review-2026-07.md` §3): `/formular/` als öffentliche Route (rendert heute in interner App-Shell) + DSGVO-Consent/Fehlerdifferenzierung im Ausfüll-Formular; HTTP-Fehler-Auffangnetz + "Toast erst nach Erfolg"; Schein-Aktionen (Cockpit "Erinnern"/lokales "Erledigt"/`prompt()`-Zuweisen) beseitigen; Google Fonts self-hosten ⚠DSGVO	✅ alles umgesetzt; Rest-Idee: `offene-punkte` um Wiedervorlagen-IDs erweitern, damit auch unzugewiesene WVs im Cockpit erledigt werden können (→ Welle 2/3)
~~MED-OP-UX-2~~	✅ erledigt (`0.64.0`, MED-D-91): UX-Welle 2 — eine Sprache (G-3/G-8-Pass): zentrale `labels.ts` (+ Datums-Utility + eine Vollständigkeits-Stufen-Ableitung), Kunden-Detail/Arbeitssicht/Cockpit/Verwaltung ohne rohe Enums/Audit-Codes/Doku-IDs; Feld-Sichtung mit Feld-Labels, Fortschritt, Sammel-Akzeptieren, markierten Feldern, 0-Felder-Fall; Korrektur-Marker als Ausweg (Server)	Rest-Ideen → Welle 3 (MED-OP-UX-3)
~~MED-OP-UX-3~~	✅ Kern erledigt (`0.65.0`, MED-D-92): UX-Welle 3 — eine Handschrift: `pub-bausteine.ts` (Kopf/Fortschritt/Legende/Marker-Chips/Fußzeile/`autocomplete`) über alle 4 Kundenstrecken, Ausfüll-Formular mit Fortschritt+Zwischenspeichern, Turnstile-Gating überall; EIN Toast-System + `--md-error`; sichtbare Navigation + "Strg K"; Cockpit-Mobile (Chip-Leiste · Bottom-Sheet · kein Quer-Overflow); Arbeitssicht: Experten-Import, Stepper anzeigend, Timer-Guard nur bei Interaktion + Dirty-Check	Rest → MED-OP-UX-4
~~MED-OP-UX-4~~	✅ abgeschlossen (`0.67.0`, MED-D-94) — Rest umgesetzt: Register-Sub-Komponenten (`kunde-meetings`/`kunde-einladungen`/`kunde-formulare`/`kunde-stammuebernahme` + `kunde-vorgang.ts`; `mandant-detail` 3.190 → 2.662 Zeilen; weitere Panels opportunistisch beim nächsten Anfassen) + Utility-Klassen `.md-hint`/`.md-m0`/`.md-w100` (1:1-Ersetzung der häufigsten Muster). Davor Kern (`0.66.0`, MED-D-93): Theme hell/dunkel/system über ALLE internen Sichten (Umschalter in Shell + Cockpit, Druck hell) · EINE Primäraktion je Dokument-Zeile + "…"-Menü · Komma-tolerante Zahleneingaben (Client-Spiegel von `alsZahl`, G-2) · Command-Palette `role=dialog`/Fokus-Falle/Fokus-Rückgabe · Kontrast-Pass (`--faint`, Mini-Texte ≥0.7rem). Rest: `mandant-detail` (3.1k Zeilen) in Register-Sub-Komponenten · Inline-Styles → Utility-Klassen flächig	Rest = reines Code-Refactoring ohne UI-Änderung; bei Bedarf eigener PR
~~OP-DOMAIN-1~~	✅ Bestätigt: Finanz-/Versicherungs- & Praxisberatung für (Zahn-)Arztpraxen	Restpunkt: R6-Pflichtfelder je Themenbereich aus Regulatorik (§34d/f/i, VVG §61–62, FinVermV §18) ableiten.
OP-ONBOARD-1 → #395	Self-Service-Onboarding (Slice 9)	✅ Einladungslink + öffentl. Formular + SES-Einwilligung (auditiert) gebaut. Manuell offen (Cloudflare-Dashboard, kein Code): Access-Bypass-Policy muss alle drei öffentlichen Präfixe abdecken — `/onboarding` + `/fragebogen` (Seiten) *und `/oeffentlich` (die Daten-Route, die beide Seiten aufrufen). Bestätigter Vorfall 2026-07-04 (Ursache verifiziert): öffentliche Links (Onboarding und Fragebogen) liefern für anonyme Besucher "Einladung nicht gefunden". Ein eingeloggter Aufruf der Daten-Route `/oeffentlich/onboarding/<token>` gibt valides JSON (`praxisName`/`gueltig`) zurück → Token/Daten/Code sind korrekt (Token = `crypto.randomUUID()`, Exact-Match-Lookup). Ursache ist damit eindeutig der fehlende `/oeffentlich`-Eintrag in der Access-Bypass-Policy: die Seite lädt via bypasstem `/onboarding`/`/fragebogen`, der anonyme Daten-Abruf an `/oeffentlich` läuft aber in die Access-Loginwand (HTML statt JSON). *Fix = `/oeffentlich` zur Bypass-Policy hinzufügen (Dashboard, kein Code, kein Deploy).** Diagnose-Fix #54 weist den Zugriffsschutz jetzt explizit als eigenen Zustand aus. Weiter offen: Turnstile-Keys, Einwilligungstext juristisch prüfen (RISK-18), echte NextCloud/Signatur statt `DEMO_MODE`.
OP-DEPLOY-1 → #396	Deploy-Reife & Domain (`architektur/Deploy.md`)	✅ Wired (28.06.): D1 EU (`c58623e3…`) in `wrangler.toml`, Custom-Domain-Route `app.medidentas.com`, `AUTH_ENFORCED=true`; Cloudflare Access (Zero Trust) aktiv (Policy "HQ + MK"); GitHub-Secrets gesetzt. Offen: `AUTH_BOOTSTRAP_ADMIN` als Worker-Secret (Admin-Erstzugang), NextCloud-/Signatur-Secrets (sonst 503), erster Deploy-Run + Smoke-Test. HQ-Eigentümer-Zuordnung = org. Folgepunkt. EU-Residenz Pflicht (G-5/RISK-17).
OP-MEET-1 → #397	🟡 Kern gebaut (`0.58.0`, MED-D-82): Meeting-Entität + Protokoll → Aufgaben → Wiedervorlagen (R5, delegiert); echte Transkription offen	✅ Kern (MED-D-82): `Meeting` (manuelles Protokoll) → `GespraechsAuswerter`-Seam (Fake, Mensch-im-Prozess RISK-14) → Aufgaben als Wiedervorlagen `quelle='aufgabe'` (G-2, delegiert an R7). Offen: Tool wählen (Notion/Plaud/Krisp), EU-Residenz + AVV (RISK-15, DSGVO Art. 9), Einwilligungs-/Hinweis-Flow, Aufgaben-Sync ins CRM (OP-CRM-1); dann Fake-Auswerter → echtes Tool, `quelle=transkription`. Design: `architektur/Prozessmodell.md` §8 P5, `architektur/Meeting-Doku-und-Aufgaben.md`.
~~MED-OP-AUTH-2~~	✅ erledigt (2026-07-15, MED-D-142): By-ID-Mandant-Scope-Guard (systemisch) — `PATCH /api/meetings/:id` + `…/aufgaben*`, `beratungsdoku/:id`, `individualdokumente/:id`	CodeRabbit-#108-Befund (Major) behoben: geteilter `byIdMandantScopeGuard` (Entität→`mandantId`→`service.darfSehen`, an `rbac_mandant_scope_aktiv` gebunden) auf alle drei Entitäten angewandt — fremder Mandant → 404 (kein Existenz-Leak), Mutation ohne `mandant_bearbeiten` → 403. 3 neue RBAC-Tests, vorab gegen den ungefixten Stand verifiziert (schlagen ohne den Guard fehl).
~~MED-OP-WV-2~~	✅ erledigt (2026-07-15, MED-D-142): Unique-Index + Duplicate-Key-Handling — Idempotenz der Wiedervorlagen jetzt auch DB-seitig gehärtet	CodeRabbit-#108-Befund (Major) behoben: `CREATE UNIQUE INDEX … ON wiedervorlage (quelle_ref)` (Migration v39 — SQLite erlaubt mehrere `NULL`, `quelle: 'manuell'` bleibt unberührt); `createWiedervorlage` fängt die Constraint-Verletzung ab und liefert die bereits vorhandene Zeile statt zu werfen (D1 + Memory-Repo deckungsgleich). Bewusst `quelle_ref` allein statt Composite `(quelle, quelle_ref)` — der App-Level-Lookup (`getWiedervorlageByQuelle`) filtert ebenfalls nur auf `quelle_ref`, ein Composite-Index wäre schwächer als der tatsächliche Dedup-Schlüssel gewesen. 1 neuer Idempotenz-Test, vorab gegen den ungefixten Stand verifiziert.
MED-OP-TEST-1 → #398	Kein D1-/SQLite-Testharness im Repo — alle 466 Vitest laufen nur gegen `MemoryRepo`, `d1-repo.ts` ist seit Projektbeginn ungetestet	Bei MED-D-143 (Migration v39, `CREATE UNIQUE INDEX` gegen Alt-Dubletten) bewusst nicht mitgelöst — stattdessen einmalig manuell gegen echtes `node:sqlite` (`DatabaseSync`) verifiziert, deckt aber nur den einen Fall ab. Naheliegende Lösung: `node:sqlite` (Node-built-in, kein neuer Dep) als zweiter Vitest-Testkreis für `d1-repo.ts` + künftige Migrationen; eigene, größere Infrastruktur-Entscheidung, daher als OP statt Teil eines Bugfixes umgesetzt.
MED-OP-MIGRATE-1	✅ behoben (MED-D-323, `0.144.1`): jeder Migrations-Schritt wird jetzt atomar angewandt — DDL + Versions-Bump auf `schritt.version` in einem `db.batch(...)` (D1 = Transaktion je Batch). Absturz mitten im Schritt → nichts committet, `schema_version` bleibt beim Vorgänger → Neustart wiederholt nur diesen Schritt sauber, kein `duplicate column` mehr. Behebt den seit v1 systemischen Fehler für alle Schritte. +3 Vitest (`db/migrate.test.ts`, Fake-D1 mit atomarer `batch()` + Absturz-Simulation).	— (erledigt). Die frühere Analyse (Marke erst am Ende der Schleife → nicht-idempotente `ALTER TABLE … ADD COLUMN` bei Neustart) ist damit adressiert; gewählt wurde die `db.batch()`-Variante (DDL+Version je Schritt atomar) statt bloßem Per-Schritt-Upsert, weil sie auch einen Absturz innerhalb eines mehrteiligen Schritts abdeckt.
~~OP-DOCGEN-1~~	✅ MVP gebaut (Slice 8): Mapping-Engine + Benennung + NextCloud-Ablage + R4-Übergabe	Rest: PDF-/Binär-Formularerzeugung, erweiterter Kundendatenbogen, native Provider-Vorausfüllung. Ergänzung (08.07., Nutzerfrage "automatisches Ausfüllen aus Stammdaten im Onboarding"): die R12-Mapping-Engine (Vorlage aus Stammsatz befüllen) existiert bereits — aber die Onboarding-Pflichtdokumente SEPA-Lastschriftmandat/Dienstleistungsauftrag (`onboarding-vorlagen.ts`, MED-D-70) sind heute reine manuelle Upload-Items (`kategorie: 'dokument'`), noch nicht an R12 angebunden. Naheliegende kleine Weiterentwicklung: diese zwei Items per R12-Vorlage aus dem Stammsatz vorausfüllen statt Kunden-Upload zu verlangen (kein neuer OP nötig, Rest von OP-DOCGEN-1/OP-DOCGEN-2).
OP-DOCGEN-2 → #399	🟡 Freitext-Autoren-Strecke gebaut (`0.57.0`, MED-D-81); manuelle Detail-Ausformulierung template-basierter Individualverträge (Dienstleistungsauftrag, Makler-Allein-Auftrag) offen	✅ Freitext (MED-D-81): neue Entität `Individualdokument` — frei geschriebener Text → Hauslayout (`pdf/pdf-dokument.ts#erzeugePdf`) → R3-Dokument (landet im Ledger, auto-auditiert) → Signatur (R4) mit explizit gewähltem Niveau; Workflow Entwurf→freigegeben→erzeugt→abgelegt→zur_unterschrift→signiert (Freigabe = Mensch-im-Prozess, RISK-14). Rest offen: die template-basierten Individualverträge (Feld-Mapping reicht nicht: Leistung/Vergütung/Sonderabreden ausformulieren) als eigener "Entwurf im Template → freigeben"-Schritt vor R4; echte E-Signatur (Fake → DocuSign AES/QES, MED-KB-5); eIDAS-Niveau je Rechtswirkung (OP-SIGN-1). Design: `architektur/Prozessmodell.md` §6 P4. Bezug OP-DOCGEN-1/OP-SIGN-1.
~~MED-OP-DOC-2~~	✅ gebaut (`0.56.0`, MED-D-80): Dokumente & Unterschriften als quer-liegende Achse (Dokument-Ledger)	Neues Register "Dokumente & Unterschriften" (`phase: null`) in Arbeitssicht + Kunden-Detail bündelt R3-`Dokument` + R12-`Dokumentgenerierung` + R4-`Signatur` an einem Ort, "an jeder Stelle" erzeugbar; Sprungziele via `SPRUNGZIEL_REGISTER`. Client-only (Sektionen um-geeltert, keine Dedup), Phasen-Reife-Gates bleiben phasengenau (`kunden-vollstaendigkeit.ts` unverändert). G-3/G-4, "nie löschen" MED-D-56. Rest offen: zusammengeführter, dedup'ter Einzel-Ledger (über `erzeugtesDokumentRef`/`signaturRef`) als Feinschliff. Design: `architektur/Prozessmodell.md` §6 P2.
~~MED-OP-REG-1~~	✅ gebaut (`0.56.0`, MED-D-80): Wiedervorlagen am Betreuung-Register sichtbar	`PhaseReife` um Feld `hinweis` erweitert (Summe der `anzahl` nicht-blockierender Punkte je Phase) → Betreuung-Tab zeigt die WV-Anzahl als neutralen Badge (vorhandene `.md-cnt`-CSS). `reif`-Semantik unverändert (D-41: WV = `hinweis`, kein Blocker). Server-Vitest + e2e (`hinweis=2` verifiziert). Rest offen (optional): "überfällige zuerst" hervorheben (bräuchte einen Überfälligkeits-Zähler im `KundenVollstaendigkeitInput`). Design: `architektur/Prozessmodell.md` §8 P3.
~~MED-OP-FORM-3~~	✅ abgeschlossen: Formular → Stammdaten (Review-and-apply) für beide Quellen	✅ Ausfüll-Formular (MED-D-84, `0.59.0`): `AusfuellformularService.uebernahmeVorschlag`/`uebernehmen` → Mandant-PII `telefon`/`geburtsdatum`/`strasse`/`plz`/`ort` (v33). ✅ Onboarding-Fragebogen (MED-D-88, `0.61.0`): `OnboardingFormularService.uebernahmeVorschlag`/`uebernehmen` aus `eingereichteDaten` → `email`/`telefon`/`strasse`/`plz`/`ort` (`ONBOARDING_STAMM_REGELN`, gemeinsame regel-getriebene Domäne `domain/stammdaten-uebernahme.ts`). Beide: nur ausgewählte + gültige Felder, Audit `stammdaten.uebernommen` PII-arm, idempotent, mandant-scoped; Client-Panel geteilt (`stammQuelle`). `praxisName`/`typ`/`ansprechpartner` ohne 1:1-Mandant-Heimat → nicht im Diff. Compliance-Rest: MED-KB-6 — Feld-Verschlüsselung-at-rest + Retention/Löschkonzept für die sensiblen PII (Geburtsdatum/Adresse/IBAN) bleibt offen (RISK-28, Risikoregister).
MED-OP-AUFTRAG-1 → #400	🟡 Beratungsaufträge — Slice C2b+ (MED-D-95; Slices A `0.68.0` · B `0.70.0` · C1 `0.71.0` · C2a `0.72.0` gebaut)	✅ Slice A: Entität (v36) + 9-Produkt-Katalog + Register "Beratungsaufträge" (Dentmarking umgezogen). ✅ Slice B (`0.70.0`, MED-D-101): `auftragRef` (nullable, Migration v38) an Beratungsdoku/Dokumente/Wiedervorlagen/Gutachten + binden/lösen im Panel + Auftrags-Reife (schlanke Checkliste je Status/Produkt) + idempotente Retro-Ableitung (bestehende Gutachten → je Praxis ein `dentmarking_gutachten`-Auftrag, Status `abgeschlossen`). ✅ Slice C1 (`0.71.0`, MED-D-104): Produkt-Playbooks — beim Anlegen entstehen je Produkt Standard-Folgeaufgaben als Wiedervorlagen (idempotent, an den Auftrag gebunden). ✅ Slice C2a (`0.72.0`, MED-D-106): Lead-Auto-Anlage — das öffentliche Lead-Formular erfasst optionales Produkt-Interesse (nur buchbare Produkte); bei Einreichung entsteht je gewähltem Produkt direkt ein Beratungsauftrag (Status `anbahnung`, an die Lead-Praxis gebunden) samt Produkt-Playbook (Slice C1) → Kreis Lead → Auftrag → Folgeaufgaben geschlossen. Offen — Slice C2b+: Auftrags-Kontext im Cockpit (Aufträge/Reife in der Leitstand-Sicht), Dexman scharf (R10, eigener Tool-Host-Track). KB: ✅ Produkt-Katalog vom Kunden bestätigt (MED-KB-7, MED-D-99, `0.69.0`) — 9 Produkte, Slice B kann die Artefakte binden. Bewusst offen gelassen (`0.68.1`, CodeRabbit-Review): (a) Zugriffs-Log auf der Auftrags-Liste — Listen sind laut `domain/zugriff.ts` bewusst ausgenommen (Datenminimierung G-6; nur Art-9-/Datei-Inhalte werden geloggt, wie die `/dokumente`-Liste); (b) Freitext-`notiz` bleibt (kurzer interner Vermerk, konsistent mit `wiedervorlage.betreff`/`meeting.titel`, Audit PII-arm) — Strukturierung erst falls PII-Bedarf auftaucht; (c) optimistisches Locking / atomare Bindung = querschnittliche Entscheidung (der ganze Code nutzt Read-modify-write), nicht auftrags-lokal → eigener OP, wenn nebenläufige Schreibkonflikte real werden. Restrisiko (CodeRabbit #135/#136, `0.70.2` bewusst akzeptiert): die Artefakt-Bindung prüft den Besitz vor dem Schreiben (kein Compare-and-Set) — bei gleichzeitigem Doppel-Submit (zwei Tabs/Retry auf demselben Artefakt) kann ein verlorener Race ein leicht ungenaues Audit-Event erzeugen; für den heutigen Einzeloperator-Betrieb tragbar, bei echtem Mehrbenutzer-/Parallel-Editing nachzuziehen (atomare CAS-Updates je Artefakt-Repo). Design: `docs/architektur/Beratungsauftraege.md`.
MED-OP-FORM-4 → #401	🟡 Feld-Sichtung approve/deny + Kunden-Feedback per Mail + Korrektur-Schleife als verbindliches Formular-Muster (MED-D-89, `0.62.0`) — gebaut am Ausfüll-Formular, Rollout auf Onboarding/Dentmarking offen	✅ Ausfüll-Formular (MED-D-89): generisch/rein `domain/feld-sichtung.ts`; Mitarbeiter entscheidet jedes eingereichte Feld (`…/feld-sichten`) → Sichtung abschließen (`…/sichtung-abschliessen`) = Kunden-Feedback über den Benachrichtigungs-Seam (Log PII-arm; realer Mail-Adapter OP-DM-8) + Korrektur-Schleife (Status `korrektur`, nur abgelehnte Felder offen, akzeptierte server-gesperrt, Re-Einreichung setzt nur diese zurück + reaktiviert die Sichtungs-WV). Migration v35 (`ausfuellformular.sichtung`). Offen: (1) Rollout desselben Musters auf Onboarding-Einladung + Dentmarking-Fragebogen (dieselbe `feld-sichtung.ts`, je Strecke `sichtung`-Spalte + Service-Verdrahtung); (2) realer Mail-Versand (OP-DM-8, DSGVO/AVV-Providerwahl = Kundenpunkt); (3) sprechende Feld-Labels im internen Sichtungs-Panel (heute Feldschlüssel).
MED-OP-FORM-5 → #402	🟡 Fremdformular-Feldmapping & Prefill (AD-010) — Slice 1 (Weg A) gebaut (MED-D-235); Wert-Rücklauf (Slice 2, AD-009) gebaut + live verifiziert (MED-D-247); Einbindung neuer Formulare (Weg B, DocuSign-Templates) gebaut + live verifiziert (MED-D-248/250/251). Rest-offen: interaktive UI-Begehung + MED-OP-FORM-6 (Eigen-Formulare als Templates)	✅ Slice 1 (MED-D-235): fremde ausfüllbare PDFs → AcroForm-Felder auslesen, je Feld ein Weltmodell-Attribut zuordnen, aus Stammdaten vorbefüllen (pdf-lib); Mapping als JSON-Spalte `dokument.fremdformular_mapping` (v46); Routen `/api/dokumente/:docId/fremdformular`. ✅ Slice 2 Wert-Rücklauf (MED-D-247, AD-009): DocuSign `form_data` → Review-and-apply (`baueVorschlaege`/`bauePatch`, on-demand, nichts persistiert bis zur Übernahme, versioniert Quelle `formular`); Routen `/api/dokumente/:docId/ruecklauf[/uebernehmen]`; live gegen DocuSign Demo verifiziert. ✅ Weg B gebaut (MED-D-250, `0.113.0`, live verifiziert): Vorlagen-Katalog `FremdformularVorlage` (v47) + Provider `anfordernAusTemplate` (`compositeTemplates`) + Prefill `baueTabWerte` + `identitaetsMapping` (Rücklauf via AD-009 unverändert) + `FremdformularVorlageService.starten`; Routen `/api/weltmodell-attribute` · `/api/fremdformular-vorlagen` (Admin) · `.../starten`; Client Verwaltung-Registrierung + Kunden-Detail-„vorbefüllt starten". Offen: (1) interaktive Playwright-Begehung der Weg-B-/Rücklauf-Client-Strecken (Server+Adapter+Build+Unit verifiziert, DocuSign-Template-Kern live belegt, UI-Flow noch nicht durchgeklickt); (2) MED-OP-FORM-6 (Eigen-Formulare ebenfalls als Templates).
MED-OP-FORM-6 → #403	💡 *Eigen-Formulare ebenfalls als DocuSign-Templates — Eigen- & Fremd-Formulare an einer* Stelle** (Nutzer 26.07., MED-D-248: „ggf. später, jetzt nur festhalten")	Die R12-Dokumentautomatisierung (eigene generierte Standarddokumente) und die Fremd-Formulare (Weg B, DocuSign-Templates) würden denselben Vorlagen-Katalog + Füll-/Signier-/Rücklauf-Pfad teilen: ein Ort für „alle Formulare/Vorlagen", ein Mechanismus (Template → Envelope → Prefill → Signatur → `form_data`-Rücklauf), statt zweier Wege (eigene: R12/pdf-generate; fremde: DocuSign-Template). Bewusst zurückgestellt — erst Weg B für Fremd-Formulare bauen (MED-D-248), dann prüfen, ob die Eigen-Dokumente sinnvoll auf denselben Template-Katalog wandern (Abwägung: DocuSign-Bindung/Kosten je Envelope vs. Vereinheitlichung). Bezug: MED-D-248 · R12/OP-DOCGEN-2 · `Fremdformulare.md` §8. ⚙️ Update 26.07. (MED-D-256): Konkret geworden am Makler-Alleinauftrag — Baustein 1 (Eigenformular beim Versenden erzeugen+vorbefüllen, flache PDF) ist gebaut; Baustein 2 = genau dieser OP: damit die Kundeneingaben (Anschrift/Geburtsdatum) zurückfließen, muss die Eigen-Vorlage eine ausfüllbare Weg-B-Fassung (DocuSign-Template mit Tabs) sein → dann greifen Prefill + AD-009-Rücklauf unverändert. Nächster Schritt: Makler-Alleinauftrag als DocuSign-Template anlegen + über `FremdformularVorlageService` registrieren + im Assistenten „vorbefüllt starten" auch für Eigenformulare anbieten (wartet auf Kunden-Steuerung zum Rücklauf-Weg).
~~MED-OP-DATA-1~~	✅ abgeschlossen (`0.60.0`, MED-D-87): alle bekannten Einzeilen-Adressen an das Wertobjekt `Anschrift` angeglichen (G-8, MED-D-85)	✅ MED-D-86 (`0.59.1`): `kundendatenbogen_v1` → `strasse`/`plz`/`ort` (verlustfreie Rückübernahme). ✅ MED-D-87 (`0.60.0`): `dienstleistungsauftrag_….rechnungsanschrift` → `rechnung_strasse`/`rechnung_plz`/`rechnung_ort`; `Praxis` → strukturierte Anschrift `strasse`/`plz`/`ort` (Migration v34, Legacy-`standort` als Anzeige-Fallback). Bereits strukturiert: Mandant-Adresse (v33), Name (D-31), IBAN (MED-D-71). Rest (Governance, kein offener Bau): neue Adressfelder kommen laut G-8 immer strukturiert; der Legacy-`Praxis.standort` bleibt als Read-Fallback (kein Parser). Katalog: `architektur/Weltmodell-Data-Dictionary.md`.
OP-GWG-1 → #404	GwG: Verpflichteten-Status & Ident-Prozess (D-30)	Klären, ob LV-/Anlagevermittlung → GwG-Pflicht (§ 2 Abs. 1 Nr. 8). Falls ja: Berater-Ident im Termin als Standard (Kunden-Detail+Audit), VideoIdent nur Fallback; QES enthält Ident. Bezug RISK-25, OP-SIGN-1.
~~OP-AI-1~~	✅ Abstraktion + Regel-Check + Haftungsgrenze gebaut (Slice 5)	Rest: echtes Medidentas-GPT (Modell/Anbieter, EU-Residenz).
~~OP-BERATDOK-1~~	✅ Gebaut (Slices 10–11, `0.11.0`/`0.12.0`): Beratungsprotokoll-Pflichtangaben R6-F11..F20 (Modell/Migration v10/Service/API/Client) + Dokumentationsverzicht-Workflow (F19) + Audit je Feldänderung	Slice 11: `POST /beratungsdoku/:id/verzicht` erzeugt die Verzichtserklärung (R3-Dokument + SES-Signatur R4), setzt `dokumentationsverzicht`+`freigegeben`, blendet die Protokoll-Pflichtinhalte im Client aus, gilt als vollständig (G-2); `aktualisieren` schreibt `beratungsdoku.aktualisiert` (PII-arm: nur Feldnamen). Rest offen: juristische Endabnahme der Einwilligungs-/Verzichts-/Schlusserklärungs-Texte (RISK-18/20).
~~OP-WV-1~~	✅ Gebaut (Slice 12, `0.13.0`): Wiedervorlagen an Mitarbeiter delegieren/zuweisen (R5↔R7)	`POST /api/wiedervorlagen/:id/zuweisen` (validierte Benutzer-Referenz R7 statt Freitext; `null` = entziehen) + Benachrichtigung bei (Neu-)Zuweisung + Audit der Delegation (`wiedervorlage.zugewiesen`, wer→wem, G-4). "Meine Wiedervorlagen" (`GET /api/wiedervorlagen/meine`, nach aktueller Identität) im Cockpit; Zuweisen-Steuerung im Mandant-Detail. Speist UC-4/UC-6.
OP-CRM-1 → #405	CRM: Daylite→HubSpot oder Eigenlösung	Build-vs-Buy entscheiden; Daylite-Migration inkl. Wiedervorlagen.
OP-SIGN-1 → #406	✅ Abstraktion + Niveau-Matrix (Slice 4) · ✅ DocuSign-HTTP-Adapter gebaut (MED-D-220, `0.100.0`): JWT-Grant/WebCrypto + Envelope + `/documents/combined`-Download + Connect-Webhook (HMAC, fail-closed) + QES→AES-mit-Hinweis, dormant ohne Secret · ✅ Credential-Weg gewählt (MED-D-221): 5 `DOCUSIGN_` als GitHub-Secrets → beim Deploy in den Worker gesynct (`app-deploy.yml`), Go-Live-Toggle `SIGNATUR_PROVIDER` in `wrangler.toml` · ✅ Live verifiziert (2026-07-25):* Demo-E2E MED-D-238 (`0.106.2`) — echter Adapter gegen `demo.docusign.net`: JWT/Consent/Envelope/Status/Reminder/Webhook-HMAC/void ✅; dabei `pkcs8PemToBuffer` delimiter-gehärtet (Session-Demo-Key hatte kaputten Footer). Und Webhook-Write-back in Produktion MED-D-239: die produktive D1 hält 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` (der `/oeffentlich`-Webhook nutzt den Default-Actor; on-demand `/api` schriebe die Nutzer-Mail, Cron macht keinen Signatur-`abgleich`) + 54-s-Push-Timing; Endpoint fail-closed (401 ohne HMAC). Der deployte Private-Key ist wohlgeformt.	Rest (🟡): (1) Prod-Umschaltung für echte Rechtswirkung (Consent in Prod, `DOCUSIGN_AUTH_BASE`/`_REST_BASE` auf Prod-Hosts, `DEMO_MODE=false`) · (2) die embedded/captive In-Person-Strecke (MED-D-236) ist noch nicht durchgeklickt (der verifizierte Kern deckt den E-Mail-Envelope- + Webhook-Weg ab, nicht die iFrame-Signieransicht) — vor Go-live gegen echtes DocuSign begehen · US-Transfer-Absicherung vor erstem Prod-Envelope (RISK-4, DPF/SCC) · QES-CSP statt AES-mit-Hinweis (RISK-2) · PandaDoc als Alternative/Fallback.
~~OP-STACK-1~~	✅ Erledigt: Cloudflare	— (Folge-OPs: OP-AUDIT-1, OP-OBS-1, OP-DATA-1, OP-AUTH-1).
~~OP-DOC-1~~	✅ MVP gebaut (Slice 2): WebDAV + App-Passwort + Ordner + Abgleich	Rest: OAuth2 (RISK-16), OCS-Group-Folders, Webhooks.
~~MED-OP-FILES-1~~	✅ Analyse dokumentiert (06.07.), NextCloud-Rolle final entschieden (20.07.): Datei-Werkzeug-Alternativen + lokaler Mac-Sync	A-1 bleibt — Mac-Sync via offiziellem NextCloud-Desktop-Client (klassischer Sync; VFS-Client meiden, 2026 fehleranfällig); kDrive = Plan B (WebDAV-kompatibel, CH); M365/Dropbox ⚠️ Art.-9-Flag; Tresorit/E2EE bricht R12-Automatisierung. ✅ Final entschieden (20.07., löst MED-D-54/MED-KB-4 Punkt 0 ab): Verzicht auf NextCloud als Storage — geschlossene Ablage V2 "R2 + App-UI" (EU-Jurisdiction, Bucket Locks/WORM) ist die einzige schreibende Ablage; NextCloud ist ausschließlich eine Read-Only-Sicht auf dieselben Dokumente (Notfall-/Katastrophenfall-Zugriff, kein zweiter Schreibpfad — Ordner-Referenzen dürfen nicht durch manuelles Verschieben/Umbenennen zerstört werden). V2 ist gebaut (`0.50.0`, MED-D-58) — R2-Treiber hinter dem `NextCloudClient`-Vertrag, umschaltbar (`ABLAGE_BACKEND=r2`); ⚙️ scharfgeschaltet (MED-D-61): Bucket `medidentas-ablage` (EU) angelegt, `ABLAGE_BACKEND=r2` + `[[r2_buckets]]` in `wrangler.toml` einkommentiert → Datei-Ablage läuft ab Deploy über R2 (kein NextCloud). Sandbox-Wurzel `medidentas-digital-test` bleibt vorerst; vor echtem Produktiv-Go auf `Medidentas/Mandanten` umstellen. Offen bleibt ausschließlich der Bau der Read-Only-Sicht selbst (Action-Item A8, Kontakt zum bisherigen NextCloud-Betreiber — kein Code heute). Kunden-Detail-Kartentitel "Ablage (NextCloud)" → "Ablage (R2)" korrigiert (CodeRabbit-Fund an MED-D-162, jetzt behoben statt nur vermerkt). Detail: `Dokumentenverwaltung-NextCloud.md` §Nachtrag + `Deploy.md` §7a-2, `Kunden-Besprechungspunkte.md` MED-KB-4.
MED-OP-OFFLINE-1 → #407	Offline-fähiger Kunden-Upload (geschlossene Ablage, V2)	Der öffentliche Upload (`/oeffentlich/ablage/upload/:token`) soll auch bei fehlender/instabiler Verbindung funktionieren: Kunde wählt die Datei offline, sie wird lokal gepuffert und bei Wiederverbindung übertragen. Ansatz: PWA/Service-Worker (App-Shell + Upload-Seite cachen) + IndexedDB-Warteschlange + Background Sync API; der Server-Upload ist bereits idempotent (Status-Hub `angefordert→erhalten`, Mehrfach-POST unschädlich) → passt. Browser-Support/Fallback: Background Sync ist Chromium-only → Fallback = erneuter Sende-Versuch beim nächsten Öffnen des Links (Retry aus der Queue). ⚠️ Compliance-Flag (proaktiv, G-5/G-6, DE/AT/CH): gepufferte Dateien enthalten ggf. Art.-9-Gesundheitsdaten (Gesundheitsbogen R6-F18, Verträge R4) → im Browser-Storage so kurz wie nötig, nach erfolgreichem Upload löschen, Verschlüsselung/Retention klären; kein PII in Service-Worker-Caches. Umfang offen: nur Kunden-Upload oder auch interne Datei-Ablage. Bezug: MED-D-58, `Dokumentenverwaltung-NextCloud.md`.
~~OP-AUTH-1~~	✅ MVP gebaut (Slice 7): Cloudflare Access + Rollen (`benutzer`-Tabelle) + RBAC + echter Audit-Actor	Rest: Access-Application/Policies (Deploy), RBAC je Mandant, SCIM/Gruppen-Sync.
~~OP-AUDIT-1~~	✅ Gebaut (Slice 6): append-only + Hash-Chain + Verify	Rest: Cold-Storage-Archiv (R2), Restore, Concurrency-Härtung.
~~OP-TIME-1~~	✅ Gebaut (Slice 13, `0.14.0`): Leistungszeit/Zeiterfassung je Mandant (R13)	Ansatz A (dünnes Ledger + Export): R13-Entity (Benutzer×Mandant×Beratung×Dauer×`abrechenbar`/`abgerechnet`), Migration v11, Service/API/Client. Auto-Seed aus R6-F13 (`POST /beratungsdoku/:id/leistungszeit`, idempotent), Abrechnungsvorschau (offene abrechenbare Stunden) als SevDesk-Export-Vorstufe (OP-INVOICE-1), append-only Audit (G-4). Rest: konkreter SevDesk-Push (OP-INVOICE-1). Neu (Meeting 12.07., MED-D-108): Flat-Fee-Automatik — hat ein Mandant eine monatliche Flat-Fee (am Vertrag erkennbar), soll das System automatisch erkennen "Beratungszeit wird nicht gesondert abgerechnet", die Zeit aber weiter erfassen (Rentabilitätsauswertung). Umsetzung: Flat-Fee-Kennzeichen am Mandant/Vertrag → Leistungszeit `abrechenbar=false` per Default vorbelegen (überschreibbar), Abrechnungsvorschau blendet sie aus, Rentabilitäts-Sicht zählt sie mit.
OP-TIME-2 → #408	Gesetzliche Arbeitszeiterfassung der Mitarbeiter (ArbZG)	Getrennt von OP-TIME-1 (das = abrechenbare Leistung). Beginn/Ende/Pausen je Mitarbeiter, BAG 2022/EuGH-Pflicht, Mitarbeiter-PII + BetrVG-Mitbestimmung (RISK-21). Tool-/Umfangswahl offen.
OP-INVOICE-1 → #409	Rechnungsstellung & Mahnwesen	SevDesk als Standard-Werkzeug prüfen (Rechnung + Mahnwesen + DATEV, GoBD/§147 AO, EU/DE) — anbinden statt nachbauen (G-1); Medidentas liefert Leistungs-/Zeitdaten (OP-TIME-1) + Mandanten-Referenz (A-3), SevDesk = Single Source der Belege. API/Sync, AVV/Residenz klären. Neu (Meeting 12.07., MED-D-108): (1) Abschlagsrechnungen als gängige Praxis abbilden (mindern das Streitrisiko großer Endrechnungen); (2) Mahnstufen-Banner — ist ein Mandant in einer Mahnstufe (z. B. 3), oben im Kunden-Detail ein Banner anzeigen (nicht weiterarbeiten / Rücksprache / nur mit expliziter Freigabe / Vorkasse), damit es nicht in Vergessenheit gerät (abgeleitet aus dem SevDesk-Status, G-2).
MED-OP-COST-1	✅ Guidance G-7 festgezurrt (06.07., MED-D-62): Betriebskosten automatisch je Provider-API ziehen (cost-pull-at-source) — Design `docs/architektur/Kosten.md`	Übernommen aus Taktano `OP-COST-2`. Abgrenzung: eingehende Betriebskosten (Cloudflare/LLM/Domain/Signatur/Ablage), ≠ SevDesk (OP-INVOICE-1 = ausgehende Rechnung). Datenmodell (Posten je Dienst×Monat, Cent, `quelle=api/manuell`+Idempotenz-`quelleRef`), Rollen-Gate (Admin/Owner/D-48), Secrets/CI-Sync (G-5), Pull=Audit (G-4).
MED-OP-COST-2 → #410	Bau: Betriebskosten-Auto-Pull (Slices, geparkt)	Slice 1 = D1-Datenmodell + manuelle Erfassung (Bootstrap) + abgeleitete Auswertung + Admin/Owner-Gate; Slice 2 = erster dormant-sicherer Provider-Pull (LLM/Cloudflare, Idempotenz-Upsert, "zuletzt gezogen"-Stempel); Slice 3 = weitere Provider + Cron-Automatik; später FX/Report/Export. Referenz-Code: Taktano `server/src/kosten/*-billing.ts`. Design: `docs/architektur/Kosten.md`.
OP-DSGVO-1 → #411	Datenschutz-Konzept	AVV, Residenz, Löschkonzept.
OP-EXT-1 → #412	Tool-Vertrag (Erweiterbarkeit)	Manifest-Schema, Scopes/Events, Isolation, Lizenz.
OP-MANDGRP-1 → #413	Mandanten-Gruppierung ("Klammer", D-32)	Gruppen (z. B. "Eheleute Müller"), einzeln betreut + Querverweise; Ablage-Variante A (flach + gemeinsamer Ordner, Kundenbestätigung offen); Entität `mandant_gruppe` (referenzielle Klammer über Personen — ändert `Mandant`/`Praxis` aus D-45 nicht). Offene Feinheit (D-45): gemeinsam gehaltene Gesellschaft (BAG/MVZ-GmbH) evtl. auf Gruppen-Ebene bzw. m:n-Beteiligung statt an einer Einzelperson (`Praxis.mandantId`). Eigener Slice. Vor dem Bau mit dem Kunden zu klären → `docs/betrieb/Kunden-Besprechungspunkte.md` KB-1 (Ablage-Variante) / KB-2 (Miteigentum).
OP-IMPORT-1 → #414	Datenübernahme bestehende Ablage	Import Fremdbestand → neue Struktur (D-31): Namens-Parsing, Mapping, Dedup, idempotent, DSGVO (RISK-22/23). Quelle/Format offen.
OP-SKILL-1 → #415	Mitarbeiter-Skills & Lernziele	Skill-Katalog + Mitarbeiter-/Aufgaben-Skills → Aufgaben-Matching (R5/OP-WV-1) + Lernziel-Mentoring (Zweit-Zuweisung). Compliance RISK-26 (BetrVG/PII).
OP-RUHEND-1 → #416	Ruhende Mandate — Workflow	Status `ruhend` existiert (R1-F05); offen: Grund + Reaktivierungsdatum, Wiedervorlage-Pause solange ruhend, auditierte Reaktivierung (≠ archiviert), Reporting.
OP-ABC-1 → #417	ABC-Klassifizierung + Codenamen	Mandant-Feld A/B/C (Priorität, ≠ Lifecycle/Phase) + admin-konfigurierbare, diskrete Codenamen fürs Kundengespräch; nur berechtigte Rollen sehen die Roh-Stufe; PII-nah. Meeting 12.07. (MED-D-108): der Kunde will bewusst keine A/B/C- oder Gold/Silber/Bronze-Anzeige (brüskiert beim Screensharing) — das bereits gebaute `betreuungsmodell` Intensiv/Standard/Basis (R1-F11/D-35) erfüllt genau diesen "diskret im Kundengespräch"-Bedarf. Ein separates A/B/C-Prioritätsfeld bleibt damit optional (nur falls eine reine Wertigkeits-/Takt-Steuerung zusätzlich zur Betreuungsintensität gebraucht wird); primär reicht das Betreuungsmodell.
OP-DUP-1 → #418	Dubletten-Check bei Mandanten-Anlage	Beim Anlegen (und Import, OP-IMPORT-1) vor Dublette warnen — Kandidat-Schlüssel E-Mail (R1-F12) + Name (nachname+vorname, normalisiert) + ggf. CRM-Link; weich (Hinweis "ähnlicher Mandant existiert bereits: …", nicht hart blockieren, da Namensgleichheit legitim). Server-Endpoint `POST /api/mandanten/aehnlich` (Kandidaten im Request-Body, nicht in der URL → keine PII in Logs/History/Caches, G-5), rein abgeleitet (G-2). Kein neues Feld nötig.
OP-NEXTSTEP-1 → #419	"Meaningful actions" — nächste sinnvolle Schritte ableiten & anzeigen	✅ Erst-Slice gebaut (`0.44.0`, D-46): abgeleitete "Nächste Schritte"-Leiste im Kunden-Detail (`domain/naechste-schritte.ts` → `MandantDetail.naechsteSchritte`, rein aus dem `KundenVollstaendigkeitInput`, G-2); Buttons mit Handlungsempfehlung je Zustand, blockierend zuerst, Klick springt zum Ausführungsort (Register/Anker). Rest: (1) ausführbare Ein-Klick-Aktionen (Self-Service-Link direkt senden, Dokument anfordern, Protokoll starten — Wiederverwendung bestehender Endpunkte statt nur Navigation); (2) dieselben Schritte an der Fokus-Karte (Cockpit) statt nur im Kunden-Detail; (3) ggf. Playbook-getriebene Zusatz-Empfehlungen.
OP-ASSIST-1 ✅ Design vorhanden (MED-D-74) → #420	KI-Assistent (LLM + RAG) auf Live-Daten & Doku — drkv-Standard-Baustein (In-App-Chatbot)	✅ Architektur dokumentiert: `docs/architektur/In-App-Assistent.md` (MED-D-74) — ein Chat-Assistent über App und Doku (drei Säulen: Doku-Q&A via RAG · Insights aus D1 abgeleitet · Feedback), vorschlagend nicht ausführend, RBAC (D-48) + Zugriffslog (D-50), PII-frei indexiert (nur Doku im Vektor-Store, G-6), EU-LLM/-Embeddings, dormant ohne Secret; löst "Medidentas-GPT" ein. Feedback wird git-nah als Issue abgelegt und angezeigt (Standard-Eigenschaft 4). Integrate-before-build (G-1). Compliance kritisch (proaktiv, DE/AT/CH): PII-Scrubbing im Kontextfenster, EU-/CH-Residenz, AVV mit dem LLM-Anbieter, Vectorize-Residenz als Risiko führen (analog Taktano C-19/RISK-17). Verwandt: R6-KI-Check (`ki/`), OP-NEXTSTEP-1. Offen: Bau (Slices s. Design-Doc §9). Klarstellung (08.07., Nutzerfrage "Kommentarfunktion in `docs.medidentas.com`"): ist kein neuer OP — das Design-Doc §7 deckt eine Doku-Kommentarfunktion bereits ab: element-verankertes Feedback (Anker + optional Screenshot) wird git-nah als Issue abgelegt und als Overlay/Marker "wo, offen/erledigt?" in der Doku selbst angezeigt (Standard-Eigenschaft 4, Doku-Feedback ≠ App-Feedback nur in der Anzeige-Fläche, derselbe Mechanismus). Kein separates Kommentarsystem für `docs.medidentas.com` nötig — offen bleibt nur der Bau (s. o.).
~~OP-AKTE-1~~	✅ Gebaut (`0.40.0`, D-43): Leitstand-Band auf echtes Vollständigkeits-Aggregat	`GET /api/vollstaendigkeit` (`service.kundenVollstaendigkeitUebersicht()`, `{ reif, score, blockierend }` je Mandant, geteilter Helper mit `detail()`); Cockpit `leitReifeStufe` nutzt das autoritative Aggregat statt des Client-Proxys. Rest: die per-Mandant-Queries laufen nebenläufig, könnten aber später mit `offenePunkte()` in einem Pass zusammengelegt werden (Perf-Feinschliff, kein Blocker).
OP-DENTMARK-1 → #421	Dentmarking (Spezial-Tool, Vorstufe Dexman)	✅ Tool-Spec erstellt: `spezialtools/Dentmarking.md` (DM-1..DM-8) + extrahierte Alt-Excel-Logik `spezialtools/Dentmarking-Excel-Logik.md` (Feldkatalog, 18 Kennzahl-Formeln, Benchmarks, Potential, VBA, Befunde B-1..B-11). ✅ Umsetzungspfad entschieden (D-27): Modul im Kern-Worker/D1, Kern-Entität `praxis` + GJ-Faktentabelle `praxis_jahreswert` (Dexman-Basis), Slices T1–T7 ✅ gebaut (`0.27.0`–`0.36.0`; T6 = Feld-Datenmodell/Score/Wiederaufnahme DM-9/D-33, T7 = Entwurf-TTL/Ablauf-Hook/Statistik DM-9/D-34) + PDF-Fassung ✅ (`0.32.0`, OP-DOCGEN-1/D-28); manuell offen: Access-Bypass `/fragebogen`. Rest:* OP-DM-1..8 (Formel-Korrekturen bestätigen, Benchmark-Quellen, Dexman-Übergabe, Alt-Daten/DSGVO → RISK-23, Marke/Hosting, Lizenz, GJ-/Benchmark-Jahresbezug, OP-DM-8 Ablauf-Mail des Zwischenstands) + Umsetzung.
OP-TOOLSPEC-1 → #422	Verfeinerung / Detail-Lastenheft Dexman & Dentmarking	Dentmarking ✅ erledigt (siehe OP-DENTMARK-1). Offen: Dexman vertiefen (OP-DEX-1..10: Kennzahlen, Prognose, PVS/Bank/DATEV, BetrVG, Lizenz, Umsatzbeteiligung, Ein-/Austritte, Darlehen-Klassifikation, Steuer-/SV-Parameter, VEM/DAM-Abbildung). Manifest/Scopes/Isolation je Tool (OP-EXT-1).
MED-OP-NG22-1 → #423	Angular 22 evaluieren, wenn nächstes Formular-Feature ansteht (MED-D-66)	Client liegt bewusst auf Angular 21 (MED-D-53). Inhaltlicher Treiber für 22 = Signal Forms (in 22 stable) — passt zum formularlastigen Client (Onboarding/Fragebogen/Verwaltung/Zeit-Kommentar, DM-9-Score) + `@angular/aria` (GA) für den A11y-Track (D-22/WCAG); ferner `httpResource` (stabile Signal-Datenschicht), Sicherheits-Release (Sanitization; SSRF v. a. `platform-server` → für die SPA irrelevant). Kosten/Blocker: TypeScript 6 Pflicht (5.9 raus), CLI verlangt Node ≥ 22.22.3 → CI/Umgebung (22.22.2) muss zuerst angehoben werden; Webpack-Builder deprecated (egal, App nutzt `@angular/build:application`/esbuild). Nächster Schritt: beim nächsten größeren Formular-/Fragebogen-Increment als bewusst geplanten PR "Node-Bump + Angular 22 + erstes Signal-Form" fahren, nicht als reinen Versionssprung. `@boundary` (Error Boundaries) erst Q3/2026 Preview → abwarten.
OP-DEX-1..10 → #424	Dexman-Detailfragen	PVS/Bank/DATEV-Integration, Prognose-Methodik, Benchmarks, Behandler-Sichtbarkeit (BetrVG), Lizenzmodell; neu (03.07., `Dexman-Fachmodell.md`): Umsatzbeteiligung Mitarbeiter (OP-DEX-6), dynamische Ein-/Austritte (OP-DEX-7), Darlehen-Klassifikation/Praxis-Zuordnung (OP-DEX-8), Steuer-/SV-Parameter-Pflege (OP-DEX-9). Meeting 12.07. (MED-D-108): (i) Kundenportal ohne Passwort — Kunde gibt E-Mail ein → Einmal-Code/Magic-Link per Mail → Zugang zur Leistungsstatistik-Pflege; Backoffice kann den Link auch selbst erzeugen/verschicken (kurz gültig, an das Vorzimmer weiterleitbar). (ii) Leistungsstatistik pflegt der Kunde selbst (monatlich/quartalsweise) — bewusst gewollt (Datenherkunft/Verantwortung beim Kunden); PVS-Direktanbindung (Dampsoft/Charly/Evident/Computer konkret) ist Stufe 2, nicht Phase 1 (OP-DEX-1). Neu (20.07.): viertes Zuliefer-Tool VEM (Vermögensmanagement) benannt, noch nicht analysiert + Frage nach einer eigenständigen DAM-Darlehensübersicht (OP-DEX-10). Design: `Dexman.md`.
OP-DM-9 ✅ erledigt (`0.51.1`, MED-D-64)	Fragebogen-Statistik-Endpoint admin-gaten (Security/Privacy, DM-9/G-5)	`GET /api/fragebogen/statistik` liefert `aktiveEntwuerfe[]` inkl. Einladungs-`token` (= Zugang zum auth-losen Fragebogen-Entwurf) — war nur in der Anzeige (seit `0.37.0`, `verwaltung.component.ts`) admin-beschränkt, der Endpoint selbst nicht (Defense-in-Depth-Lücke). Fix: neue admin-exklusive Fähigkeit `fragebogen_statistik_sehen` (`domain/rechte.ts`), Route via `guard(c, 'fragebogen_statistik_sehen') → 403` gegated (RBAC-Matrix statt inline-`istAdmin`, MED-D-48-konform). Regressionstests: `rbac.test.ts` (Berater/Backoffice → 403, Admin → 200) + `rechte.test.ts`. Ursprung: Review PR #65 (CodeRabbit).
MED-OP-CROSS-1 → #426	Cross-Repo-Best-Practices in TKT/GRM übernehmen (Repo-übergreifend, MED-D-57-Registry)	Konventionen, die nicht medidentas-spezifisch sind, sind Kandidaten für `taktano` (TKT) & `gh-runner-manager` (GRM) — hier nur editierbar, dort beim nächsten Anfassen mitziehen. Aktuell offen: Stacked/Child-Branches + Squash-Rebase (MED-D-65, `agents.md` §7), Draft-PR-Workflow (MED-D-60), CodeRabbit auto-merge-/rate-limit-Config (MED-D-58/59). Sammelpunkt, damit gute Muster nicht repo-lokal versanden.
MED-OP-FORM-1 → #425	"Warum?" je Fragebogen-Feld + auswertungsgetriebener Ausfüllgrad (⚠️ dedizierte Diskussion nötig, Nutzer 07.07.)	Zwei zusammenhängende Ideen, bewusst nicht ad hoc gebaut: (a) Feld-Zweck ("Warum?") — jedes Fragebogen-/Formularfeld trägt eine kurze, sprechende Begründung, wozu die Angabe gebraucht wird (welche Auswertung/Handlung sie ermöglicht). Nutzen: höhere Ausfüllbereitschaft + Datenqualität (G-3 Selbsterklärbarkeit) und zugleich die je-Feld-Zweckbindung/Rechtsgrundlage (G-5/G-6 — "warum speichern wir das?"). (b) Auswertungsgetriebener Ausfüllgrad — der Fortschritt wird nicht (nur) an Feld-Gewichten gemessen, sondern daran, welche Auswertung dadurch möglich wird (z. B. "Kennzahl X berechenbar", "Gutachten erstellbar") → outcome-orientierte Vollständigkeit statt reiner Feldzählung; ergänzt/ersetzt den heutigen dreistufigen `ausfuellgrad` (MED-D-67). Zu klären in der Diskussion: Datenmodell (Feld-`zweck` + Auswertungs-/Abhängigkeits-Graph "welche Kennzahl braucht welche Felder"), Verhältnis zu Wichtigkeits-Stufen, UX (Tooltip/Inline-Hinweis am Feld, Fortschritt "X von Y Auswertungen freigeschaltet"), Pflege (wer definiert Zweck/Abhängigkeiten je Katalog). Bezug: Dentmarking-Katalog (`domain/dentmarking-katalog.ts`, Klassen/Gewichte), MED-D-67 (`ausfuellgrad`), True North #3 (vollständige, verwertbare Doku).
MED-OP-VALID-1 → #427	🟡 Slice 1–4 gebaut (18.–19.07., MED-D-146/147/149/150): kanonischer Feld-Typ + weiche Prüfung + KI-Formatvorschlag + PLZ↔Ort-Plausibilität (OpenPLZ), jetzt im App-internen Praxis-Formular UND im öffentlichen Onboarding-Formular sichtbar. Dentmarking-Fragebogen bewusst nicht vereinheitlicht (eigenes, andersartiges Zahlen-Bereichs-Konzept). (b) Adressvalidierung erledigt.	Slice 4 (MED-D-150, `0.82.0`): Nutzerwahl "1" (Onboarding/Dentmarking-Angleichung) nach Erklärung der Slice-2-Folgepunkte. Recherche zeigte Onboarding/Dentmarking sind nicht gleich groß: Dentmarkings `Wertebereich`/`bereichsHinweis()` ist Zahlen-Bereichs-Plausibilität (min/max/Einheit), nicht Format-Validierung — passt semantisch nicht zu `ValidierungsArt`; zudem existiert `bereichsHinweis()` heute nur client-seitig (manuell synchron gehaltenes Duplikat). Nutzerentscheidung: nur Onboarding jetzt, Dentmarking separat. `ONBOARDING_STAMM_REGELN` hebt `telefon`/`plz` auf die kanonischen `'tel'`/`'plz'`-Arten (bewusst nur hier, `AUSFUELL_STAMM_REGELN` unverändert); neue `pruefeRegelWerte()`. `OnboardingFormularService.kontext()`/`entwurfSpeichern()` liefern jetzt `hinweise`/`vorschlaege` (KiFeldVorschlag-Seam injiziert). Client (`onboarding-public.component.ts`): Inline-Hinweis + klick-übernehmbarer Formatvorschlag je Feld. Gegen echten Browser verifiziert (`wrangler dev` + Playwright): E-Mail "kaputt" → Hinweis; Telefon "0211 / 12-34-56" → Vorschlag "0211123456" → übernommen. +5 Vitest (479→484, 46 Dateien). Bewusst nicht behoben: `AUSFUELL_STAMM_REGELN`s dieselbe `telefon`/`plz`-`'text'`-Untertypisierung (jetzt benannt, eigener Folgepunkt); Dentmarking-Client-Duplikation (s. u.). Slice 3 (MED-D-149, `0.81.0`): Nutzerentscheidung "g-1: use OpenPLZ" — neue `PlzOrtProvider`-Abstraktion (`adressen/provider.ts`) + `OpenPlzClient` (DE→AT→CH-Fallback, öffentliches, kostenloses DACH-Postleitzahlverzeichnis `openplzapi.org`, kein API-Key, 3s-Timeout, fehlerresilient auf "nicht prüfbar" statt Blocker) + test-sicherer `FakePlzOrt`-Default (Netzwerkaufruf nur im echten Worker-Entrypoint `index.ts` verdrahtet, nicht in `createApp()` — ein früher Entwurf hatte das vertauscht, ein 936ms-Testausreißer deckte den Fehler auf, selbst korrigiert). Wired an Praxis-Anlege-/PATCH-Route, zweiter Undo-Toast bei Ort-Vorschlag. Gegen echten Browser und echte OpenPLZ-API verifiziert (`wrangler dev` + Playwright): PLZ "40210"/Ort "Köln" → Vorschlag "Düsseldorf" → Klick → Praxis tatsächlich korrigiert. Anmerkung (Nutzer): ein Wechsel auf einen umfassenderen/bezahlten Online-Geocoding-Dienst (HERE/Google/Post) bleibt eine mögliche spätere Verbesserung. +13 Vitest (466→479, 46 Dateien). Slice 1 (MED-D-146): `domain/feld-typ.ts` (G-8) — `ValidierungsArt` (`text/email/tel/select/zahl/datum/iban/plz/betrag`) + `pruefeWert()`/`normalisiereWert()`/`formatVorschlag()`, aus `stammdaten-uebernahme.ts` extrahiert (dort re-exportiert) + um `plz`/`tel`/`zahl`/`betrag` erweitert; `ausfuellformular.ts`s `FeldArt` ist jetzt Alias des kanonischen Typs. Ausschließlich weich (Scope-Entscheidung Nutzer 18.07.): Freitext wird immer als Fallback akzeptiert, die Prüfung erzeugt höchstens einen Hinweis, nie eine Ablehnung (analog `bereichsHinweis()` im Dentmarking-Fragebogen). KI-Vorschlag-Seam (`ki/vorschlag.ts` + `ki/regel-vorschlag.ts`, Fake-first analog `ki/pruefer.ts`/`ki/gespraechs-auswerter.ts`): deterministischer Formatvorschlag (DE-Datum→ISO, IBAN-Normalform, PLZ/Tel-Ziffernbereinigung), RISK-14-Hinweis, nie automatisch übernommen; wired in `AusfuellformularService.kontext()` → `hinweise`/`vorschlaege` je Feld (API-seitig, noch ohne Client-UI). Slice 2 (MED-D-147): Nutzerfrage "Die smarte Eingabe-Unterstützung (LLM + RAG?) auch für die Eingabe-Felder in der App verwenden" — geklärt, dass RAG hier nicht zutrifft (OP-ASSIST-1s RAG ist strikt auf Doku-Retrieval beschränkt); Recherche zeigte Mandant-Stammdaten sind heute gar nicht Berater-editierbar, nur Praxis `strasse`/`plz`/`ort` sind editierbar und bislang ungeprüft — Scope nach Rückfrage auf diese risikofreie additive Erweiterung begrenzt (bestehende harte Felder Mandant `email`/`ibanPrivat`/Praxis `iban`/`geschaeftsjahrBeginnMonat` bleiben hart, Mandant-Stammdaten-Editierbarkeit bewusst nicht neu eingeführt). Neuer `weicheHinweise()`-Helfer in `app.ts` an Praxis-Anlege-/PATCH-Route, Antwort additiv um `hinweise`/`vorschlaege` erweitert; `mandant-detail.component.ts` zeigt bei PLZ-Vorschlag einen Undo-Toast ("PLZ übernehmen"). Gegen echten Browser verifiziert (`wrangler dev` + Playwright): malformte PLZ → Toast-Vorschlag → Klick → PLZ tatsächlich korrigiert. Als Produkt-USP festgehalten: `docs/produkt/Produkt-und-Marketing.md` (Nutzenversprechen-Tabelle) + `docs/produkt/Management-Summary.md` §5. ✅ Onboarding-Stammdaten erledigt (MED-D-150): siehe Slice 4 oben. Bewusst NICHT vereinheitlicht: Dentmarking-Fragebogen (eigenes Zahlen-Bereichs-Konzept, semantisch andersartig — Client-Duplikation von `bereichsHinweis()` bleibt eigener Folgepunkt); Mandant-Stammdaten-Editierbarkeit (eigene Prozess-Entscheidung, umgeht sonst die auditierte Formular-Rückübernahme). ✅ (b) Adressvalidierung erledigt (MED-D-149): OpenPLZ (öffentliches, kostenloses DACH-Postleitzahlverzeichnis, kein AVV/Drittdaten-Risiko, da keine Anmeldung/Kontobindung — nur die eingegebene PLZ/Ort werden anonym abgefragt) statt eines bezahlten Online-Geocoding-Dienstes gewählt; Compliance-Flag damit entschärft (kein AVV-pflichtiger Vertragsdienst). Bezug: `domain/dentmarking-katalog.ts` (Wertebereich/Klassen), MED-D-67/MED-OP-FORM-1.
MED-OP-VALID-2 → #428	Typische Struktur je Textfeld -> KI-Neuformulierung fuer einheitliche Strukturen (Nutzeranstoss "OP: ...", 25.07.)	Fuer alle (Freitext-)Textfelder in den Stammdaten eine hinterlegbare typische Struktur/Vorlage ermoeglichen; die KI nutzt diese Vorlage, um Freitext-Eingaben neu zu formulieren, sodass gleichartige Felder eine einheitliche Struktur bekommen. Baut auf MED-OP-VALID-1 auf: dort ist der KI-Vorschlag heute feld-wert-bezogen (Datum/IBAN/PLZ via `ki/vorschlag.ts`/`RegelVorschlag`); dies erweitert auf Struktur/Prosa je Freitextfeld. Regeln: vorschlagend, nie automatisch (RISK-14, Mensch-im-Prozess), weiche Validierung (Freitext geht immer durch, G-3), PII-arm (G-6); Struktur-Vorlagen als pflegbarer Katalog (Verwaltung). Vor Bau klaeren: welche Felder, wo die Vorlage gepflegt wird, LLM-Anbindung (Fake-first-Seam analog `KiFeldVorschlag`).
MED-OP-FORM-2 → #429	Zwischenspeichern-Hinweistext im Ausfüll-Formular (`formular-public.component.ts`) fehlt — bei Onboarding/Fragebogen längst da	Inkonsistenz der drei öffentlichen Token-Strecken (MED-D-67): Onboarding (`onboarding-public.component.ts`) und Fragebogen (`fragebogen-public.component.ts`) haben je einen "Zwischenspeichern"-Button + sichtbaren Hinweis "Zwischengespeichert um … — Sie können später über denselben Link fortsetzen." Das Ausfüll-Formular (`formular-public.component.ts#zurVorschau()`) speichert den Entwurf nur still im Hintergrund (`api.formularSpeichern(...)`, `error: () => {}`) — kein Button, kein Hinweistext, keine Fehlerrückmeldung; Nutzer sehen nicht, dass/ob ihr Stand gesichert wurde. Fix (klein, Client-only): dasselbe `gespeichertHinweis`-Muster übernehmen (Button optional, da Speichern hier implizit beim Vorschau-Klick passiert — mindestens der Hinweistext + Fehlerfall gehören ergänzt). Bezug: MED-D-67/MED-D-68, MED-OP-FORM-1.
MED-OP-BAUSTEIN-1 → #430	Textbaustein-Bibliothek für Beratungsdoku (FR-2) nicht gebaut — nur Themenbereich-Defaults vorhanden	Nutzeranstoß "OP: Textbausteine für Beratungsdoku" (20.07.) — vor dem Eintrag recherchiert: `bausteine[]` (R6-F05) existiert bereits, aber nur als vier hartcodierte Default-Sets je Themenbereich (`domain/beratung-themen.ts`, je 4–6 kurze Themen-Überschriften wie "Anlass des Gesprächs", keine ausformulierten Textbausteine) — verwendet für (a) den Vollständigkeits-Check (Keyword-Matching gegen `inhalt`+`bausteine`) und (b) einen reinen Platzhalter-Hinweis im Protokolltext-Feld (`kunde-auftraege.component.ts`: "Protokolltext … (Bausteine: X · Y · Z)"). Was FR-2 ("Vorlagen-/Textbaustein-Bibliothek für Beratungsprotokolle") und R6-F03s eigener Kommentar ("admin-editierbarer Katalog") vorsehen, existiert nicht: keine Oberfläche zum Verwalten/Erweitern einer wiederverwendbaren Bausteine-Bibliothek, kein Ein-Klick-Einfügen eines Bausteins in den Protokolltext, keine Admin-Editierbarkeit — der Code-Kommentar in `beratung-themen.ts` markiert das selbst bewusst als Platzhalter ("Admin-editierbar gedacht; hier als Code-Default"). Naheliegender Ausbau: (1) `bausteine[]` von Themen-Überschriften zu echten, einfügbaren Textschnipseln erweitern; (2) Einfügen-Aktion im Protokolltext-Editor; (3) admin-editierbarer Katalog analog `verwaltung.component.ts`s Playbook-Admin-UI. Kein Kundenklärungsbedarf (FR-2/R6-F04/F05 sind bereits spezifiziert) — reiner Bau-Rückstand, daher hier statt in `Kunden-Besprechungspunkte.md`. Bezug: `Lastenheft.md` §4.6/FR-2, `Glossar.md#textbaustein`.
MED-OP-REIFE-1 → #431	Vollständigkeits-Ring (rechte Sidebar des Kunden-Details) bewusst entfernt (20.07.), Wiedereinführung explizit auf später vertagt	Nutzeranstoß "Nimm die Vollständigkeit erstmal raus - halte das als OP für später (explizit descoped auf später)" — auf Rückfrage bestätigter Umfang: nur der 62px-Ring + Score-Prozentzahl + klickbare Punkte-Liste in `mandant-detail.component.ts`s rechter Sidebar raus (samt der dadurch verwaisten Methoden `zuPunkt`/`offenGesamt`/`reifeLabel`/`ringOffset`/`ringUmfang`). Bewusst erhalten (nutzen dieselbe `KundenVollstaendigkeitInput`-Berechnung, gelten aber nicht als "der Ring"): die Tab-Badges (`tabBadge()`), die "Jetzt dran"-Karte im Übersicht-Tab (inkl. "… blockieren die Vollständigkeit"-Zähler) und alles auf dem Cockpit (andere Seite, out of scope). Serverseitige `domain/kunden-vollstaendigkeit.ts`-Berechnung unangetastet — nur diese eine Client-Anzeige entfernt. Offen für später: ob/wie die Ring-Visualisierung (oder ein Ersatz) zurückkehrt, ist bewusst nicht spezifiziert — kein Platzhalter hinterlassen, reine Entfernung.
MED-OP-UI-1 → #432	UI-Aufräumarbeiten: Groß-/Kleinschreibung uneinheitlich + Dentmarking-Sektion falsch platziert	(a) Dentmarking/"Praxen"-Sektion: liegt im Kunden-Detail unter `[hidden]="aktiv() !== 'erstkontakt'"` (`mandant-detail.component.ts`, Register "Erstkontakt") — widerspricht MED-D-70 ("Dentmarking ist eine Beratungsleistung"); gehört fachlich eher ins Register "Beratung" oder als eigenes quer-liegendes Register (`phase: null`, analog "Dokumente & Unterschriften" MED-D-80). (b) Groß-/Kleinschreibung: UI-Labels/Überschriften im Client sind stellenweise uneinheitlich großgeschrieben (noch kein systematischer Durchgang über `client/src/app/*.component.ts`-Templates gegen G-3 Selbsterklärbarkeit) — konkrete Fundstellen beim nächsten Anfassen der jeweiligen Komponente mitziehen, kein isolierter Groß-Refactor. Beide Punkte klein/kosmetisch, kein Blocker.
OP-LEAD-1 ✅ realisiert (`0.55.0`, MED-D-72 — öffentliches Lead-Formular)	Lead-Auto-Anlage beim Einstieg (Prozess-Einstieg, MED-D-70)	✅ Gebaut: öffentliches Self-Service-Lead-Formular (`/lead` + `GET/POST /oeffentlich/lead`, ohne Token, Turnstile) legt den Mandanten direkt als `lead` an (+ Entität, Sichtungs-Wiedervorlage). Rest offen: die in Dentmarking integrierte Auto-Anlage (ein öffentlicher Dentmarking-Einstieg, der bei fehlendem Mandanten selbst einen Lead anlegt) + Dublettencheck (OP-DUP-1). Ursprünglicher Kontext unten.
~~OP-LEAD-1 (Original)~~	Lead-Auto-Anlage beim Dentmarking-Einstieg (Prozess-Einstieg, MED-D-70)	Der Mandanten-Prozess beginnt mit dem Onboarding; Dentmarking ist eine Beratungsleistung und dient als niedrigschwelliger Lead-Einstieg. Heute setzt ein Dentmarking-Fragebogen einen bestehenden Mandanten + Praxis voraus (erst Mandant als `lead` anlegen, dann Praxis, dann Fragebogen). Ausbau: ein Entry-Point, der beim Dentmarking-Start einen fehlenden Mandanten automatisch als `lead` anlegt (+ minimale Praxis), damit Beratung/Erhebung möglich ist, bevor die formale Onboarding-Strecke läuft; Onboarding wird später als eigene Phase nachgeholt. Zu klären: Entry-Point (öffentlicher Dentmarking-Einstieg? interner Schnellanlage-Flow?), Dublettencheck (OP-DUP-1), welche Minimaldaten für die Lead-Anlage nötig sind (Name/Praxis/GJ), Verantwortlich=null (Lead-Pool, D-48). Bezug: MED-D-70, `api/dentmarking-service.ts` (`fragebogenEinladungErstellen`), R1/R2, OP-DUP-1.
~~MED-OP-DOKU-1~~	✅ erledigt (2026-07-12, MED-D-98): Doku-Welle 1 — "eine Wahrheit wiederherstellen" (aus dem Doku-Audit `docs/betrieb/Doku-Review-2026-07.md`, B1–B6/B9/B10)	Umgesetzt — Status-Sync aller Stand-Stempel auf den echten Stand: README (`0.9.1`→aktuell), Sanity-Checkliste (steht komplett auf ⛔ "noch kein Code" — ehrliche ✅/🟡-Neubewertung), MVP-Scope (`0.9.0`, Backlog endet bei Slice 9), Management-Summary (`0.58.0`), Test-Übersicht-Kopf, Lastenheft §3 (endet bei G-5) + §4-Kopf (R1–R12 mit R13-Tabelle); G-8 überall nachziehen (Entwicklungsansatz, Management-Summary, README, CLAUDE.md-Querverweis); R2-Aktivierung MED-D-61 in die vier Ablage-Docs (Dokumentenverwaltung-NextCloud, System-Charakter, Unterschriften, Dentmarking); HANDOFF glätten (§2 → EIN Absatz, §4-Dubletten OP-DEX/OP-DENTMARK-1/OP-TOOLSPEC-1/OP-LEAD-1 mergen); CLAUDE.md-Standabsatz (29,5k-Zeichen-Zeile) auf 3–5 Zeilen + CHANGELOG-Verweis kürzen. Zuerst umsetzen — solange Einstiegs-Docs einen falschen Stand erzählen, multipliziert jede Session den Schaden.
~~MED-OP-DOKU-2~~	✅ erledigt (2026-07-12, MED-D-110): Doku-Welle 2 — "eine Definition, ein Ort" (Doku-Audit B7/B16–B18)	Umgesetzt: Phantom-Phase "Ablage" aus Prozessmodell §3 + System-Charakter §1 raus → Diagramm auf die 6 echten `prozessphase`-Enum-Werte, Ablage als quer-liegende Achse (§6). Kanonische-Quellen-Tabelle neu in `agents.md` §5.4 (welche Regel wohnt wo) + Pflege-Pflichtsatz je PR einmal definiert (bedingt "nur Betroffene", mit Last-Kritik — nicht jeder PR fasst ~10 Docs an). ID-Vergabe-Regel bei parallelen Sessions (`agents.md` §3, First-merge-wins) gegen die heute zweimalige Kollision. README `R1–R12`→`R1–R13`. Session-Start-Reihenfolge war inzwischen bereits konsistent.
~~MED-OP-UX-5~~	✅ erledigt (2026-07-13): UX-Welle 6 — Zugang & Verlässlichkeit (App-Audit `v0.72.0`, B1/B3/B4)	✅ (1) Kunden-Detail mobil (B1, `0.72.1`, MED-D-111): behoben — die Shell-Kopfzeile (`.md-header`) war eine einzeilige Flex-Zeile und zwang das Kunden-Detail auf Desktop-Breite (390px → 944px Overflow); `@media (max-width:640px)` lässt sie umbrechen → Kunden-Detail reflowt (live: 390px; Cockpit/Lead unverändert). ✅ (2) Stille 4xx sichtbar (B3, `0.72.2`, MED-D-114): die beiden höchsten Schweregrade behoben — Audit-Verlauf (rechtssicherheitsrelevanter Nachweis, G-4) zeigt einen Ladefehler jetzt explizit "konnte nicht geladen werden" + Retry statt wie "keine Historie" auszusehen (interaktive Kunden-Detail `verlaufFehler`/`verlaufLaden()` + Druckansicht `auditFehler`, Kopfzeile zeigt "(?)" statt "(0)"); die 2 Abrechnungs-Mutationen (`lzAbrechenbarToggle`/`lzAbrechnen`) melden Fehler jetzt per Toast. Bewusst zurückgestellt (kleinerer Rest, außerhalb B3): die übrigen Sub-Ressourcen-Listen (Meetings/Aufträge/Einladungen/Formulare, `dokumentgenerierungen`/`individualdokumente`/`praxen`) mappen Ladefehler weiterhin auf "leere Liste" — niedrigere Priorität, offen für eine spätere Politur-Runde. ✅ (3) A11y-Basis (B4, `0.72.3`, MED-D-115): `--faint`-Kontrast im hellen Theme war ≈2,8:1 (unter AA) — auf `#5c665f` verdunkelt (≈5,3–6,0:1); "Verlassen"-Modal hatte keine Fokus-Falle — jetzt echte Dialog-Semantik (Fokus rein/raus, Tab/Shift+Tab gefangen, Escape = Abbrechen) analog der Command-Palette (MED-D-93).
~~MED-OP-DOKU-3~~	✅ Kern erledigt (2026-07-12, MED-D-113): Doku-Welle 3 — "Check schärfen + Zielgruppen komplettieren" (Doku-Audit B8/B11–B15/B19)	Umgesetzt: `check-doc-consistency.sh` +4 semantische Checks (doppelte `##`-Überschriften · aktive OP-Zeilen-Dubletten · veraltete G-/R-Spannen · Stand-Stempel↔APP_VERSION; high-signal, 0 False-Positives) → deckte reale Drift auf (Sanity/Management-Summary auf `0.72.0`/442 gefixt); Lesepfade 7 Zielgruppen + Matrix; Glossar-Generator (4→7 Zielgruppen, R1–R13, +3 Begriffe = 41); B12 (OP-DOMAIN-1 bestätigt · Feature-Listen-Waisenzeile weg · "erstes gebautes Tool = Dentmarking" · Meeting-§3 = MED-D-82 · Stack "bewertet"). Aufgeschobener Rest → neu MED-OP-DOKU-4 (P4-Politur): Pyramidal-BLUF (Produkt-Marketing/Dexman/Dokumentenverwaltung-NextCloud) + fehlende Diagramme (Feld-Sichtungs-Loop MED-D-89 im Prozessmodell, Dexman-Liquidität).
~~MED-OP-DOKU-4~~	✅ erledigt (2026-07-12, MED-D-113): Doku-Politur (P4, Rest aus Welle 3)	`Produkt-und-Marketing.md` Kernaussage/BLUF nach vorn. `Dexman.md` (Zweck stand bereits oben) + `Dokumentenverwaltung-NextCloud.md` (R2-Kernaussage stand bereits im ⚠️-Kasten oben) = schon pyramidal, kein Fix nötig. Zwei tragende Diagramme ergänzt + Mermaid-validiert: Feld-Sichtungs-/Korrektur-Loop (MED-D-89, stateDiagram) im Prozessmodell §5, Liquiditäts-/Ergebnisvorschau-Datenfluss (flowchart) in `Dexman-Fachmodell.md` §4.
~~MED-OP-DOKU-5~~	✅ Kern erledigt (2026-07-14, MED-D-133): Doku-Welle 4a+4b — "Wahrheit wiederherstellen" + "Check-Lücke schließen" (Doku-Audit `v0.78.1`, B20–B23/B29/B30, MED-D-132)	Umgesetzt: README/MVP-Scope/Lastenheft/CLAUDE.md/Feature-Liste/Test-Übersicht/Sanity-Checkliste/Management-Summary auf `0.78.2`/442-Tests synchronisiert + Beratungsaufträge/World-2/UX 6-8 nachgetragen; `Lastenheft.md` um §5.1a Beratungsaufträge-Abschnitt ergänzt + Phantom-"Ablage"-Fehler an der Quelle behoben (B20/B29, dort UND in `CLAUDE.md`s Standard-Prozess-Zeile — Fix erreichte zuvor nur die abgeleiteten Docs); `Deploy.md` auf "live in Produktion" korrigiert (B22); Management-Summary Ablage-Zeile (R2 produktiv statt Platzhalter) + Standard-Bausteine-Absatz ergänzt (B24/B30); `check-doc-consistency.sh` §8-Regex erkennt jetzt `Stand`/`Status`, `Lastenheft.md` in die Prüfliste aufgenommen (B23) — Check bestätigt getestet: erkennt die alte Stale-Formulierung, meldet nach dem Fix grün. Aufgeschobener Rest → neu MED-OP-DOKU-6 (4c/4d).
~~MED-OP-DOKU-6~~	✅ erledigt (2026-07-14, MED-D-134): Doku-Welle 4c+4d — Governance-Aktualität + Handwerk (Doku-Audit B24–B28/B31/B32/B12f/B14/B15/B17)	Umgesetzt: Compliance.md/Risikoregister.md echt neu geprüft (28 Risiko-Zeilen einzeln gegen den aktuellen Stand gegengelesen, nicht nur Datum gestempelt — B31/B32); Weltmodell-Data-Dictionary um `Beratungsauftrag`-Entität ergänzt (B25); agents.md §3 (kanonische ID-System-Quelle) um `D-n`/`RISK-n`/`KB-n` ergänzt — waren live im Einsatz, aber in der Quelle nicht gelistet (B26); `docs/README.md`-Index um `Architektur-Uebersicht.md` ergänzt + "Geldanlage"→"Kapitalanlage" korrigiert, `Lesepfade.md` verlinkt jetzt `Beratungsauftraege.md` (IT-Architektur + Customer Service) und `Architektur-Uebersicht.md` (IT-Architektur) (B27/B28); agents.md-"Letztes Update"-Stempel repariert (B12f); `Dexman.md` pyramidal umsortiert — §1 Zweck & Leitfragen vor §2 Wettbewerbsanalyse (B14); `Unterschriften.md`/`Dokumentenverwaltung-NextCloud.md`-Sequenzdiagramme von "NextCloud" auf "Ablage (R2/NextCloud)" korrigiert, konsistent mit den bereits gefixten Prosa-Stellen in denselben Docs (B15); OP-DEX-Nummerierung in HANDOFF vereinheitlicht (1..5→1..9); `Entwicklungsansatz.md` verweist jetzt explizit auf `agents.md` §7 als kanonische Draft-PR-Quelle (B17). Bewusst nicht umgesetzt: CLAUDE.md-§Versionierung-Restrukturierung (hing an derselben offenen Nutzer-Entscheidung wie MED-D-131/B5, nicht Teil dieser Doku-Welle) — separat entschieden + umgesetzt als MED-D-140.
~~MED-OP-DOKU-7~~	✅ erledigt (2026-07-23, MED-D-186): Doku-Welle 5 — Rest-Drift + Check-Loch + Feature-Nachzieharbeit (Doku-Audit `v0.91.0`, B33–B41, MED-D-180)	Backlog aus dem Doku-Audit-Refresh (`docs/betrieb/Doku-Review-2026-07.md`, Stand `v0.91.0`): 5a (P1, zusammen) — `README.md` auf `0.91.0` / 535 Tests / 49 Dateien + aktuelle Frontier-Features (MED-D-156/172/176/179) + korrekte Prozessmodell-Achsen-Beschreibung (statt der stillgelegten "Prozessphase"-Achse) und im selben Zug `check-doc-consistency.sh` §8 um die Überschriften-Stempel-Form (`## Status` + SemVer in N Zeilen) + einen Testzahl-Abgleich erweitern (B33/B34 — README rutscht heute durch den Zeilen-lokalen Regex). ✅ erledigt (2026-07-22, MED-D-181): README-Status auf `0.91.0` + Frontier MED-D-156/157/172/176/179 + Testzahl `535`/`49`; `docs/README.md`-Prozessmodell-Landkartenzeile auf die aktuelle Achsen-Beschreibung (Auftrag-Status statt Prozessphase, MED-D-151); `check-doc-consistency.sh` §8 um Prong B (Überschriften-Stempel `## Status` + SemVer auf Folgezeile) und einen Testzahl-Abgleich (lebende Übersichten ↔ kanonische Zahl aus `Test-Uebersicht.md`) erweitert — Regressionstest bestätigt: der Check fängt jetzt genau die stale README ab, die er zuvor durchrutschen ließ. 5b (P2) — `Weltmodell-Data-Dictionary.md` um `StammdatenVersion`-Entität ergänzen (G-8: neue Entität zuerst ins Dictionary, B35); `docs/README.md`-Index um `Kosten.md` ergänzen + gegen CLAUDE-Tiefenquellen abgleichen (B36). ✅ erledigt (2026-07-22, MED-D-182): `StammdatenVersion` als Entität in der Weltmodell-§2-Tabelle (append-only, per-Mandant hash-verkettet, MED-D-179); `Kosten.md` in die `docs/README.md`-Architektur-Landkarte aufgenommen (war als CLAUDE-Tiefenquelle geführt, fehlte im Index — B36). 5c (P3) — ER-Feld `nextcloud_ref`→`nextcloud_pfad`/R2 in `Dokumentenverwaltung-NextCloud.md` + NextCloud-"Fallback"→"read-only-Sicht" in `Architektur-Uebersicht.md` (B37, doc↔code-Drift); BLUF-Zeile vor `Compliance.md`/`Risikoregister.md` + Prüf-Stempel mitziehen (B38); `Entwicklungsansatz.md` §4.2 um `<TOOL>-n`-Präfix (B39); optional Hash-Ketten-Diagramm für MED-D-179 analog `Audit-Log.md` (B40). ✅ erledigt (2026-07-22, MED-D-183): B37 ER-Feld `nextcloud_ref`→`nextcloud_pfad` (Code-Feldname, R3-F06) + R2-Bezug, `Architektur-Uebersicht.md`-Kante "Fallback"→"read-only-Sicht" (MED-D-58/61); B38 BLUF vor `Compliance.md` (DSGVO/eIDAS/GoBD + offene MED-KB-6/KB-3) und `Risikoregister.md` (28 Risiken, 18 ≥6, Höchst-Score RISK-15); B39 `<TOOL>-n`-Präfix in `Entwicklungsansatz.md` §4.2; B40 Hash-Ketten-Diagramm (Mermaid, validiert) in `Lastenheft.md` §4.4. Mitgezogen: Timesheet-Zeile 24 (5a/5b in einer 7-Spalten-Zeile gemerged) forward-repariert in zwei saubere 6-Spalten-Zeilen. Rest von MED-OP-DOKU-7: nur noch B41 (`Kunden-Struktur.md` Vor-Cockpit-Currency-Pass) — eigener Slice. Lehre (rückblickend, 5a/5b/5c erledigt): 5a wurde zuerst und als Einheit umgesetzt — ohne den Check-Fix wäre die README-Drift wiedergekehrt; offen bleibt nur B41. B41 (neu, aus CodeRabbit-Review PR #216): `docs/architektur/Kunden-Struktur.md` beschreibt noch die prozessgegliederte Vor-Cockpit-Kunden-Detail (§3 "Register = Prozessphasen", Phasen-Zeitstrahl) — überholt durch MED-D-151 (Prozessphase-Achse abgelöst) + MED-D-156 (Kunden-Cockpit-Redesign, Tab-basiert); braucht einen Currency-Pass (Register = die 5 Cockpit-Tabs statt Prozessphasen). In 5a nur die Landkartenzeile in `docs/README.md` mit Hinweis entschärft; die Doc-Überarbeitung selbst ist eigener Slice. ✅ erledigt (2026-07-23, MED-D-186): `Kunden-Struktur.md` komplett neu gefasst auf das aktuelle Vollbild-3-Spalten-Cockpit (Person-Rail · 6 arbeits-gegliederte Register [Übersicht (Standard) · Mandate · Dokumente · Fristen & Aufgaben · Stammdaten & Onboarding · Zeiterfassung] · Kontext-Rail; Verlauf/Audit nur über den Sidebar-Link, kein Nav-Reiter) — aus `mandant-detail.component.ts` abgelesen (die live-IA sind 6 Tabs mit `uebersicht`-Default, nicht die 5-Tab-"Basis"-Default-IA aus MED-D-179 — diese ist entschieden, aber nicht gebaut, MED-OP-AKTE-2). §2-Kunden-Detail/§3 "Register = Prozessphasen"/Phasen-Zeitstrahl retired; Vollständigkeits-Datenmodell (§4) auf `stufe: LifecycleStatus`/`jeStufe`/`StufeReife` nachgezogen (war `phase: ProzessPhase`/`jePhase`); Reife-Ring-Wegfall als Anzeige-Hinweis vermerkt (MED-OP-REIFE-1, Datenmodell unberührt); auf MED-D-151/156/95/172/80 querverlinkt. Danach den "Vor-Cockpit"-Hinweis in der `docs/README.md`-Kunden-Struktur-Zeile entfernt. MED-OP-DOKU-7 damit vollständig geschlossen.
MED-OP-REVIEW-1 → #433	Regelmäßige Meisterwerk-Audits (App + Doku) — Prozess verankert (MED-D-97)	Beide Quality-Audits ("Ist die App ein Meisterwerk?" = `UX-Prozess-Review-.md` · "Ist die Doku* ein Meisterwerk?" = `Doku-Review-.md`) laufen regelmäßig: Kadenz ~alle 10 Minor-Versionen oder 3 Monate + nach Meilensteinen/Wellen-Abschluss. Bezugspunkt-Pflicht* (Version · Commit · Datum in der Titelzeile); Stale-Regel: Bezugspunkt ≥10 Minor oder >90 Tage alt → Audit gilt als veraltet, Agent regt aktiv die Aktualisierung an (Session-Start), mechanische Warnung im Konsistenz-Check. Kanonische Definition: `agents.md` §6.7. App-Audit aufgefrischt auf `v0.72.0` (2026-07-12, Commit `7a13ce5`): die vier v0.62.0-Kernrisiken (Feedback · Sprache · Kundenstrecken · Cockpit-Mobile) sind adressiert (UX-Wellen 1–5); neuer Backlog B1–B7 → `MED-OP-UX-5/6/7`. Doku-Wellen MED-OP-DOKU-1..4 abgeschlossen (MED-D-98/110/113); Doku-Audit aufgefrischt auf `v0.78.1` (2026-07-14, Commit `eb94787`, MED-D-132): 10 von 19 Alt-Befunden vollständig gelöst, aber dieselbe Wurzelursache (B18: schnelle Logs aktuell, langsame Rahmen-Docs veralten) binnen 13 Minor-Versionen zurückgekehrt — README/MVP-Scope erneut veraltet, `Lastenheft.md` nie für Beratungsaufträge nachgezogen + eigener Phantom-"Ablage"-Rückfall, `Deploy.md` widerspricht der Live-Realität, Check hat blinden Fleck (Regex "Stand" statt "Status", Lastenheft fehlt in Dateiliste); Backlog B20–B32 → Doku-Welle 4 komplett umgesetzt (4a+4b als MED-OP-DOKU-5/MED-D-133 `0.78.2`, 4c+4d als MED-OP-DOKU-6/MED-D-134 `0.78.3`) — alle 32 Befunde B1–B32 aus beiden Doku-Reviews bearbeitet, inklusive der zuletzt offenen CLAUDE.md-§Versionierung-Frage (User-Entscheidung "Trim to current-state only", umgesetzt als MED-D-140). App-Audit aufgefrischt auf `v0.83.0` (2026-07-19, Commit `8df0626`, MED-D-153): fünf Dimensions-Reviews (neu: Eine Handschrift/Konsistenz) + Live-Begehung bestätigen alle carry-over Befunde B1–B4/B6/B7 als behoben/unverändert — kein Rückfall durch den MED-D-151-Umbau; zwei neue umbau-eigene Befunde (Cockpit-Chip-Overflow, `PHASE_LABEL`/G-8-Dopplung) + drei weitere (Lifecycle-Undo ohne Fehlerbehandlung, Playbook-Fehler ohne UI-Signal, Kleinbefunde) → neuer Backlog B8–B13, Sammel-OP MED-OP-UX-8. App-Audit aufgefrischt auf `v0.99.0` (2026-07-23, Commit `81c0b71`, MED-D-201): bewertet das abgeschlossene Kunden-Cockpit-Redesign (S1–S6 + Mandat-Overlay); fünf Dimensions-Reviews + Live-Begehung bestätigen B9/B10 als behoben (MED-D-154/156), 5-Reiter-IA + 4 Overlays stehen, 0 Konsolenfehler, kein 390px-Body-Overflow; neuer Backlog B14–B26 → MED-OP-UX-9 (Welle 10, absorbiert die offenen MED-OP-UX-8-Reste): hoch = Overlays keine echten Dialoge (B14) + Playbook-Teilfehlschlag als Erfolg gemeldet (B15), mittel = Touch-Ziele <24px/Mandat-Overlay-Mobile-Overflow/Ladefehler/aria (B16–B19), niedrig = Shell-Duplikation/Pillen/Enums/Drift/Kundenstrecken/Kommentare (B20–B25). Der frisch gebaute Mandat-Overlay wurde selbstkritisch mitgeprüft (B17/B20). Nächster App-Audit ~`1.09` oder >90 Tage. Doku-Audit aufgefrischt auf `v0.91.0` (2026-07-22, Commit `bcd0eec`, MED-D-180): Wirksamkeits-Kontrolle von Doku-Welle 4 — 15/17 offene Alt-Befunde gelöst, keiner regressiv; die Wurzelursache (B18) schrumpfte von 5 gleichzeitig veralteten Einstiegs-Docs auf genau 1 (`README.md`), alle 6 großen Features seit v0.78.1 dokumentiert; neuer Backlog B33–B40 → MED-OP-DOKU-7 (Doku-Welle 5). App- + Doku-Audit gemeinsam aufgefrischt auf `v0.99.8` (2026-07-24, Commit `caa33d0`, MED-D-211): Wirksamkeits-Kontrolle nach dem Kunden-Cockpit-Programm + Welle 10 + B26 + Nachlese. App: alle 12 Befunde B14–B26 behoben, kein Regress — Mobile 6→8, A11y 6→8 (echte Overlay-Dialog-Semantik + Fokus-Falle live bestätigt, 0 Konsolenfehler, 0 Overflow 1440/390); neuer, kleiner Backlog B27–B34 → MED-OP-UX-10 (Peripherie-Ehrlichkeit + A11y-Restmeile + Konsistenz-Vereinheitlichung). Doku: alle 8 Alt-Befunde B33–B40 geschlossen, Stempel/Testzahl deckungsgleich `0.99.8`/`553`; neuer Backlog B41–B48 → MED-OP-DOKU-8 (Doku-Welle 6: Governance einholen — Compliance/Risiko stale + 1:n-Bankkonto-PII + Vor-Ort-eSignatur nicht abgedeckt, Bankkonto fehlt in der Lastenheft-Feldspec). App- + Doku-Audit gemeinsam aufgefrischt auf `v0.99.12` (2026-07-24, Commit `4a3a018`, MED-D-217): Wirksamkeits-Kontrolle nach Welle 11 (S1–S3) + Design-System-Abnahme. App: alle 8 Befunde B27–B34 im Code behoben, kein Regress (B14–B26 stichprobenweise intakt); Sprache/G-8 8→9, Feedback/Kundenstrecken/A11y je →8,5; Design-System vollständig übernommen — 10/10 kunden-patterns-Komponenten (Fidelity "voll"), 5 Reiter, 4 Overlays, World-2-Tokens ausschließlich, Zustandsmodelle erfüllt, live 0 Overflow/0 Konsolenfehler; Abnahme-Grenze: Design-Rohartefakte (`kunden-patterns.md`/`.dc.html`/Screenshots 01–17) liegen nur im claude.ai/design-Projekt (DesignSync getrennt) → strukturell/funktional bestanden, kein Pixel-Diff möglich. Neuer kleiner Backlog B36–B40 → MED-OP-UX-11 (Badge-Kontrast <AA · 16-px-Touch-Ziel · Tabs-`aria-controls` · 2 role=alert-Restlücken · Cockpit-Falsch-Leere). Doku: alle 8 B41–B48 geschlossen, Test-Tabelle rekonziliert `553/50`, Stempel deckungsgleich `0.99.12`; kein neuer Doku-Backlog (nur 2 Bagatellen: A-1 Strikethrough hier mitgezogen, A-2 by-design). App- + Doku-Audit gemeinsam aufgefrischt auf `v0.116.1` (2026-07-26, Commit `5031530`, MED-D-259): Wirksamkeits-Kontrolle über 17 Minor (v0.99.12→v0.116.1) nach DocuSign-HTTP-Adapter/Fremdformulare Weg A/B/AD-009/Hausformular-Auto-Routing/Cockpit-Fokus/Mandate-Overlay, via 2 parallele Evidenz-Läufe (App-Code-Sweep + Doku-Sweep). App: Design-System-Kern (Overlay-Shell, Roving-`tabindex`) hält ohne Regress; die großen neuen Flächen überwiegend sauber; aber die zwei jüngsten Komponenten tragen neue Defekte → Feedback 8,5→8, Konsistenz 8→7,5, A11y 8,5→8; neuer Backlog B41–B43 → MED-OP-UX-12 (B41 hoch: Feld-Editor undefinierte Tokens → unsichtbarer Text im Light-Theme; B42 Rücklauf-Falsch-Leere; B43 <24px); B36–B40 (MED-OP-UX-11) unverändert offen. Doku: mechanische Achse makellos (alle Einstiegs-Stempel `0.116.1`, Testzahl `642/55` an allen 5 Pflichtstellen, IDs MED-D-218…258 geloggt); aber Doku↔Code 9→8 (Architektur-Docs hinter dem Feature-Churn): neuer Backlog B49–B52 → MED-OP-DOKU-9 (B49 hoch: `Fremdformulare.md` beschreibt das gebaute MED-OP-FORM-6 als „nicht bauen" + `FremdformularVorlage` ohne `dokumenttyp`; B50 HANDOFF §4↔§2-Widerspruch; B51 `Unterschriften.md` „nicht live verifiziert" trotz MED-D-238/239; B52 stale AD-Stempel). Nächster App-/Doku-Audit gemäß Stale-Regel.
~~MED-OP-UX-8~~	✅ abgelöst durch MED-OP-UX-9 (App-Audit-Refresh `v0.99.0`, MED-D-201): (1)+(3) erledigt (MED-D-154/156), die offenen Reste (2)/(4)/(5) sind in Welle 10 gefaltet	UX-Welle 9 — Zwei-Achsen-Umbau nachschärfen (App-Audit `v0.83.0`, MED-D-153): (1) `PHASE_LABEL`-Dopplung ✅ erledigt (MED-D-154, `0.83.1`); (2) Cockpit-Chip-Overflow (offen → B8/MED-OP-UX-9); (3) `error:`-Handler an `lifecycleZuruecksetzen()` ✅ erledigt (MED-D-156, `0.84.0`); (4) Playbook-Fehler-UI-Signal (offen → B11/B15/MED-OP-UX-9); (5) Kleinbefunde `beratungsdoku.geprüft`-Label/`aria-describedby`/Fragebogen-Legende (offen → B23/B24/MED-OP-UX-9).
~~MED-OP-UX-9~~	✅ UX-Welle 10 — Kunden-Cockpit-Abnahme nachschärfen abgeschlossen (App-Audit `v0.99.0`, B14–B25 erledigt; B26 bewusst zurückgestellt) — Slices 1–5 gebaut (MED-D-202/204/205/206/207, `0.99.5`)	Backlog aus dem App-Audit-Refresh (MED-D-201, `docs/betrieb/UX-Prozess-Review-2026-07.md`), absorbiert die offenen MED-OP-UX-8-Reste. ✅ Slice 2 (MED-D-204, `0.99.2`): B15 Playbook-Teilfehlschlag ehrlich melden — die PATCH-Antwort trägt jetzt ein transientes `playbookFehler`-Flag; der Client warnt bei `true` (⚠-Toast, „Rückgängig" bleibt), Verlaufs-Labels `.playbook_fehler` mit ⚠-Präfix. ✅ Slice 1 (MED-D-202): geteilte Overlay-Shell + Dialog-A11y* — (B14) die 4 Overlays sind keine echten Dialoge ✅ erledigt (neue `KundeOverlayComponent`: `role="dialog"`/`aria-modal`/`aria-label` + Initial-Fokus + Fokus-Falle + Fokus-Rückgabe, alle 4 Overlays migriert); (B20) Overlay-Shell dupliziert ✅ erledigt (ein Bauteil statt 4× Markup); (B2) Mandat-Kopf-Divergenz + (B3) zwei ESC-Mechaniken/Shell-ESC-Bypass ✅ mit der Shell gelöst (ESC → `schliesseOverlay()`, räumt `bankPeek`); (B17) Mandat-Overlay Mobile-Reflow ✅ erledigt (Titel-Ellipsis + `flex-wrap`, Schließen-Knopf auf 390px erreichbar, live 528→371). (B15) Playbook-Teilfehlschlag ehrlich melden ✅ erledigt (Slice 2, MED-D-204). Offen — Mittel: (B16) Touch-Ziele ≥24px ✅ erledigt (Slice 4, MED-D-206) — `.mw-slider-seg`/`.mw-sepa`/`.mw-bankrow-archbtn`/`.mw-vfield-pill` mit `min-height:24px` (WCAG 2.5.8, live = 24px); (B18) `set([])`-Ladefehler sichtbar machen ✅ erledigt (Slice 3, MED-D-205) für die 4 self-contained Kunden-Detail-Panels (einladungen/meetings/formulare/auftraege) — barrierefreies Banner (`role="alert"`) + „Erneut versuchen"; Rest-Folgepunkt: die mit `detail()` verzahnten `mandant-detail`-Sub-Loader (~1483-1490) bleiben vorerst still. (B19) `aria-describedby`+`role="alert"` an `md-error` ✅ erledigt (Slice 4, MED-D-206) — Lifecycle-Select↔Fehler verknüpft + alle 14 dynamischen `md-error` als `role="alert"`. ~~Niedrig (B21–B25)~~ ✅ erledigt (Slice 5, MED-D-207, `0.99.5`): B21 `md-status-erhalten`/`-fehlt`-Farbregel (blau/rot statt farblos-grau); B22 `ONBOARDING_KATEGORIE_LABEL` + `DOKUMENT_STATUS_LABEL` (Klartext statt roher Enums); B23 `beratungsdoku.geprüft`-Audit-Label + `MODELL_LABEL`=`BETREUUNG_LABEL`-Alias; B24 Fragebogen-``→`(Pflicht)` + Turnstile-`ngOnDestroy`-Cleanup (onboarding/fragebogen), `formular-public` bewusst ohne Turnstile (begründete Ausnahme); B25* stale Overlay-Key-/S5-Kommentare nachgezogen. Damit ist B14–B25 vollständig. B26-Teilmenge ✅ erledigt (MED-D-208, `0.99.6`): ~~Cockpit-Chip-Overflow (B8)~~ (Phase+Chips-Ellipsis im Lane-Kopf, live: 392px-Chip → 0 Overflow), ~~B18-Rest-Falle~~ (Bankkonten/Praxen-Ladefehler → `nebendatenFehler`-Banner + Retry im Stammdaten-Overlay), ~~`bdAnlegenUndBinden`-Waisen-Schutz~~ (Binde-Fehler → Reload + Nachbind-Hinweis). B26-Restschuld (substanziell) ✅ erledigt (MED-D-209, `0.99.7`): ~~Sub-0,7rem-Lesetext~~ (6 Regeln auf 0,7rem-Floor; Glyphen-Boxen + Brand-Micro-Type bewusst kompakt), ~~übrige `mandant-detail`-Sub-Loader~~ (generierungen/individualdokumente/lzUeb/auftraege → geteiltes `nebendatenFehler`-Signal + tab-übergreifendes `role="alert"`-Banner). B26 weiter zurückgestellt (Nutzer-Wahl, bekannt/akzeptiert, kein Regress): die ~134 Cockpit-Einzelwert-Inline-Styles (B5-Rest, reiner Churn ohne sichtbaren Effekt) + `.mw-fs-68`/`.mw-badge` (0,68rem ≈ Floor, Rename-Churn vermieden).
~~MED-OP-UX-10~~	✅ UX-Welle 11 — die letzte Meile zum Meisterwerk abgeschlossen (App-Audit-Refresh `v0.99.8`, MED-D-211, B27–B34) — 3 Slices (MED-D-213 `0.99.9` · MED-D-215 `0.99.11` · MED-D-216 `0.99.12`)	Backlog aus `docs/betrieb/UX-Prozess-Review-2026-07.md` (v0.99.8). Band A Ehrlichkeit an der Peripherie (Slice 1, MED-D-213): B27 Signatur-Teilfehlschlag als Totalausfall ✅ · B28 stille Ladefehler Verwaltung/Dentmarking/Druckansicht ✅. Band B A11y-Restmeile (Slice 2, MED-D-215): B29 Reiter-ARIA ✅ (`role="tablist"` + roving `tabindex` + Pfeil-/Pos1-/Ende-Tastatur; `role="tabpanel"` bewusst ausgelassen — verstreute `[hidden]`-Sektionen, kein 1-Panel-je-Reiter) · B30 `role="alert"` außerhalb des Kerns ✅ · B31 `--mut`-Kontrast <AA ✅ (`#5f6d62`, 5,45:1). Band C/D Vereinheitlichung (Slice 3, MED-D-216): B33 G-8 Enum-Label-Maps ✅ (StammdatenQuelle/ArtefaktTyp/OffenKategorie/KontoPruefstatus nach `labels.ts`; `AuftragStatus`-Doppelvokabel → `AUFTRAG_STATUS_LABEL` Langform + `AUFTRAG_STATUS_KURZ_LABEL` Kurzsicht, EINE Quelle, live verifiziert) · B34 Kundenstrecken-Politur ✅ (Consent-Checkboxen `.md-consent-check` 24×24px live bestätigt; `formular-public` Fehler amber→`md-error`-rot + onboarding/fragebogen-Speicherfehlschlag in den roten `fehler`-Kanal; `ladeTurnstile` 3× → `ladeTurnstileScript()` in `pub-bausteine.ts`; Turnstile-Ausnahme als MED-D-216-Entscheidung + Code-Kommentar festgehalten) · B32(a) `.md-status-`-Regelsatz-Drift ✅ (`erhalten` im Basis-Satz ergänzt, gleiche Status-Abdeckung wie der mw-scope-Satz). Bewusst zurückgestellt → B35/Carry-over (kein Regress, dokumentiert):* B32(b) 3-Modal-Fokus-Falle-Konsolidierung (die 3 Fokus-Fallen funktionieren, pure DRY) + Pill-Render-Vereinheitlichung + ~~300 Inline-Styles (Governance "keine ungefragten Refactorings"). Nächster App-Audit gemäß Stale-Regel (~~`1.09` oder >90 Tage).
~~MED-OP-DOKU-8~~	✅ Doku-Welle 6 abgeschlossen (MED-D-212, `v0.99.8`): B41–B48 erledigt — B41 Compliance/Risiko-Stand `2026-07-24` + Gesamtsichtungs-Note, B42 RISK-28 um 1:n-Bankkonto-PII, B43 Unterschriften.md Vor-Ort-Assistent-§+Sequence-Diagramm+Route, B44 Bankkonto-Feldtabelle R1-F33..F43+State-Diagramm im Lastenheft, B45 R1–R13, B46 Test-Uebersicht auf 553/50 rekonziliert, B47 Weltmodell-classDiagram um Bankkonto, B48 nextcloud_ref-Rest. Alle 3 neuen Mermaid validiert. Optional offen: B49.3 (Dokument-Zustandsmaschine-Diagramm).	Backlog aus `docs/betrieb/Doku-Review-2026-07.md` (v0.99.8). Band A Governance-Coverage (mittel): B41 Compliance.md + Risikoregister stehen auf `2026-07-14`, decken MED-D-188…210 nicht ab; B42 1:n-Bankkonto-PII (MED-D-195) ohne Risiko-Eintrag (RISK-28 erweitern); B43 Vor-Ort-/Demo-eSignatur (MED-D-198) fehlt im kanonischen `Unterschriften.md` (Status + §-Abschnitt + Diagramm). Band B Doku↔Code (mittel-hoch): B44 Kern-Entität `Bankkonto` (R1-F33) fehlt in der Lastenheft-Master-Feldspec (Dictionary verweist dorthin). Band C mechanische Drifts (mittel/niedrig): B45 Modul-Range "R1–R12" → R1–R13; B46 Test-Uebersicht-Tabelle summiert 513 statt Header 553/50; B47 Weltmodell-Mermaid zeigt `Bankkonto`-Entität nicht; B48 `nextcloud_ref`-Prosa-Rest. B49 (optional): 3 State-/Sequence-Diagramm-Chancen.
MED-OP-UX-12 → #434	🟡 UX-Welle 13 — Frontier-Defekte der neuesten Flächen (App-Audit-Refresh `v0.116.1`, MED-D-259, B41–B43) — B41 erledigt (MED-D-261, `0.117.1`), B42/B43 offen	Backlog aus `docs/betrieb/UX-Prozess-Review-2026-07.md` (v0.116.1). B41 (hoch, Vorzieh-Fix): `kunde-feld-editor` nutzt undefinierte Tokens `--fg`/`--fg-faint`/`--gruen` (existieren nicht; echt: `--text`/`--mut`/`--green`) → hartkodierte Dark-Hex-Fallbacks greifen immer → Feldname-Text im Default-/Light-Theme nahezu unsichtbar (`kunde-feld-editor.component.ts:111/112/114/120`); Fix = echte Tokens. ✅ erledigt (MED-D-261, `0.117.1`): die drei Farb-Deklarationen auf `var(--text)`/`var(--mut)`/`var(--green)` umgestellt (theme-fähig, hell + dunkel lesbar), Hex-Fallbacks entfernt; `ng build` grün. B42 (mittel-hoch): Rücklauf-Prüfung zeigt bei Load-Fehler die Falsch-Leere „Keine übernehmbaren Rückläufe" statt eines Fehlers (der Banner sitzt hinter dem Scrim) — `mandant-detail.component.ts:1102-1103` vs. Fehler-Render nur im `@else` `:1123`; Fix = eigenes `ruecklaufFehler` im Overlay. B43 (niedrig): „Rücklauf prüfen"-Button ≈21px < 24px (`mandant-detail:722`). Kleinbefunde: Rahmendaten-/Auftrag-Grid ohne responsive Collapse ≤390px (`kunde-auftraege:146`).
MED-OP-DOKU-9	✅ erledigt 2026-09-26 (Doku-Audit-Refresh v0.150.0, MED-D-370): B51 + B52 behoben, B49/B50 zuvor — Doku-Welle 7 — Architektur-Doku hinter den Log-Docs nachziehen (Doku-Audit-Refresh `v0.116.1`, MED-D-259, B49–B52) — B49 teilweise erledigt (§8-Status + Runbook §9, MED-D-264); B50–B52 offen	Backlog aus `docs/betrieb/Doku-Review-2026-07.md` (v0.116.1). B49 (hoch) — teilweise erledigt (MED-D-264): §8 korrigiert (MED-OP-FORM-6 von "nicht bauen" auf "teilweise gebaut" + `dokumenttyp`-Hausformular-Auto-Routing/MED-D-257 beschrieben) und neues Runbook §9 (Template-Anlegen Klick-für-Klick + `tabLabel`-Referenz). Rest offen: §6/§7 (`:97`) + die `FremdformularVorlage`-Feldspec (`dokumenttyp`, v48/v49) noch nicht durchgängig nachgezogen. B50 (mittel-hoch): HANDOFF §4 MED-OP-FORM-5/6-Punkt (`:636/:637`) widerspricht §2 + Feature-Liste (Baustein 1/2 ✅ gebaut); rekonzilieren. B51 (mittel): `Unterschriften.md:194-200` nennt den DocuSign-Adapter "gebaut, aber nicht live verifiziert" — MED-D-238/239 belegt den Kern live; OP-SIGN-1-Rest auf Prod-QES/AVV/PandaDoc verengen. B52 (niedrig-mittel): `Design-Entscheidungen-Kunde.md:6` Stand-Stempel `0.99.12` stale → nach Inhalts-Stichprobe re-stempeln.
MED-OP-DOKU-10	✅ erledigt 2026-09-26 (MED-D-370) — Doku-Welle 8 (Doku-Audit v0.128.0, B53–B54): B53 e2e-Test-Spur in `Test-Uebersicht.md` (MED-D-289) · B54 Ablage-Spiegel (MED-D-288) in `Dokumentenverwaltung-NextCloud.md` beschrieben (Abschnitt "Ablage-Spiegel in der Oberfläche" inkl. Mermaid). (Zeile nachregistriert — stand bisher nur in §2.)	—
MED-OP-UX-11 → #435	🟡 UX-Welle 12 — die A11y-/Ehrlichkeits-Restmeile (App-Audit-Refresh `v0.99.12`, MED-D-217, B36–B40) — noch nicht begonnen; v0.116.1-Audit (MED-D-259) bestätigt: alle fünf unverändert offen	Backlog aus `docs/betrieb/UX-Prozess-Review-2026-07.md` (v0.99.12), abgeleitet nach der Design-System-Abnahme. B36 Fragebogen-`.md-fb-badge` weiß-auf-Farbe unter WCAG-AA (v. a. Dark-Mode, `fragebogen-public:191-195`) — höchster Rest-Punkt; B37 16-px-Touch-Ziel "Vorschlag übernehmen" auf der Onboarding-Strecke (`onboarding-public:113`, <24px/WCAG 2.5.8); B38 Reiter `aria-controls`/`tabpanel` fehlt + tabpanel-Auslassung im Code unkommentiert (`mandant-detail:302`); B39 2 `role="alert"`-Restlücken (`mandant-kunde:335` primärer Fehler + `kunde-meetings:30` `mtgFehler`); B40 `cockpit#meineWiedervorlagen()` scheitert still → Falsch-Leere auf Primär-Content (`cockpit:705`, True North #2). Kleinbefunde (gebündelt): `aria-required` am Onboarding-`<select>` inkonsistent · Auftrag-Karten-Grid ohne responsive Collapse (`mandant-detail:354`) · Turnstile-Callback-Name onboarding/fragebogen geteilt · amber-Inline statt geteilter Klasse (`formular-public:74,125`). B35/Carry-over (B32(b) 3 Modals außerhalb der Shell + Pill-Render + ~300 Inline-Styles) bleibt bewusst offen.
~~MED-OP-UX-6~~	✅ erledigt (2026-07-13): UX-Welle 7 — Eine Sprache, zu Ende (G-3) (App-Audit `v0.72.0`, B2/B6)	✅ B2 (`0.73.0`, MED-D-118): interne IDs aus sichtbaren Texten raus (Druckansicht zuerst) — `R3/R4/R5/R6/R12/R13`, `(G-1)/(G-4)`, `MED-D-56`, `OP-INVOICE-1`, `R7`, `§5.1`, Feld-IDs `(F12)…(F20)` an den Beratungsdoku-Rahmendaten (Gesetzeszitate `§19 VVG`/`§6 Abs. 3/§61 Abs. 2 VVG` bewusst behalten); zwei rohe-Enum-Stellen geschlossen (Rollen-Dropdown → `ROLLE_LABEL`, gebundener-Artefakt-Status → typ-abhängige `artefaktStatusLabel()`); rohe Prozessphase im Playbook-Löschen-`confirm()` → `PHASE_LABEL`. ✅ B6 (`0.73.1`, MED-D-119): Consent-Text "Geldanlage" → "Kapitalanlage"; Lead-Interesse-Picker jetzt `fieldset/legend` + 24×24px-Checkboxen + differenzierte Ladefehler (`zugriffsschutz`/generisch, wie die drei anderen Kundenstrecken); Fragebogen-Handschrift-Ausreißer auf den geteilten `md-pub-fortschritt`-Baustein gehoben + neue Badge-Legende für `ESSENZIELL/WICHTIG/OPTIONAL`; tote CSS-Reste (`mwToast`-Keyframes + `--toastBg/--toastBd/--toastInk`, `.md-fb-marker-actions`/`.md-linkbtn`, `.md-fb-score`/`.md-fb-bar*`) entfernt, gezielte `cursor: default` am rein anzeigenden Stepper der interaktiven Kunden-Detail.
MED-OP-UX-7 → #436	🟡 UX-Welle 8 — Eine Handschrift, Teil 1–4 + World-2-Rollout Schritt 1–3 erledigt (`0.78.0`, MED-D-120/121/122/126/128/129/130; App-Audit `v0.72.0`, B5/B6)	✅ natives `confirm()` (7×) → gestalteter `ConfirmService`-Dialog (inkl. Fokus-Falle) — dabei einen bereits bestehenden Signal-Reset-Bug beim Archivierungs-Abbruch gefunden und mitbehoben; ✅ `datum()`/`datumZeit()` überall durchgesetzt (4 Rohformate + 1 tote Dopplung entfernt); ✅ `kopiereText()`-Helfer vereinheitlicht (4 Stellen, dabei einen `?.`-Bug in `kunde-dentmarking` behoben); ✅ "Verwerfen & verlassen" optisch von der Primäraktion getrennt; ✅ Cockpit-Fokus-Kontext mobil (MED-D-121): `.mw-ctx` war unter 820px `display:none` — jetzt Toggle-Button "Kontext ↑" öffnet dieselbe Spalte als Bottom-Sheet; ✅ Inline-Styles Runde 1+2 (MED-D-122/126): 49 exakte Duplikate + 145 atomare Deklarationen konsolidiert, 215→132 (-39 %); ✅ World-2-Rollout Schritt 1 (MED-D-128): Verwaltung + die gemeinsame App-Shell (Header/Footer) auf Cockpit-Tokens umgestellt, über eine neue `.mw-scope`-Wrapper-Klasse mit descendant-gescopeten Overrides (kein Leck in die geteilten `.md-`-Basisregeln); ✅ Schritt 2* (MED-D-129): `mandant-detail.component.ts` + `mandant-kunde.component.ts` ziehen mit — die 6 Register-Unterkomponenten brauchten keinen eigenen Wrapper (Kind-Elemente im selben Template, CSS-Cascade greift automatisch), plus ~35 direkte Inline-Style-Fixes (`var(--md-)` → `var(--bd/--amber/--green/--accent/--mut/--red)`) für Stellen, die per CSS-Scoping nicht erreichbar waren; ✅ Schritt 3* (MED-D-130): die 4 öffentlichen Kundenstrecken (Onboarding/Ausfüll-Formular/Dentmarking-Fragebogen/Lead) + `pub-bausteine.ts` ziehen mit — diese Seiten haben keine App-Shell, daher brauchte `.md-pub` selbst direkt `background: var(--bg)`; 21 der 31 Fixes lagen in component-lokalen `styles:`-Blöcken (Angular-Emulated-gescopet, direkt editierbar ohne `.mw-scope`); Marken-Kopf (`.md-brand`/`.md-wordmark`) bewusst unverändert. Kein zweifarbiger Übergangszustand mehr irgendwo in der App.* Rest (bewusst offen): die verbleibenden 132 Einzelwert-Inline-Styles in Cockpit (und ~350 weitere app-weit) würden eine Spacing-/Typografie-Skala-Entscheidung erfordern; divergierende Absende-Button-Texte der 4 Kundenstrecken — geprüft, bewusst nicht vereinheitlicht.

5. Nächste Schritte (Vorschlag)

➡️ MED-OP-DOKU-7 vollständig geschlossen (B33–B41). Doku-Welle 5 (Doku-Audit v0.91.0 + Slices 5a/5b/5c + CodeRabbit-Nachlesen + B41-Currency-Pass, MED-D-180–186, PRs #215–#221 + B41-PR) ist vollständig gemergt. docs/architektur/Kunden-Struktur.md beschreibt jetzt das aktuelle Vollbild-3-Spalten-Cockpit (6 arbeits- gegliederte Register mit uebersicht-Default; Verlauf über den Sidebar-Link) statt der Vor-Cockpit- Prozessphasen-Gliederung (MED-D-186). Wichtig für den nächsten, der das Kunden-Detail anfasst: die live-IA sind 6 Tabs, nicht die in MED-D-179 entschiedene, aber nicht gebaute 5-Tab-"Basis"-Default-IA — deren Umsetzung ist der offene Punkt MED-OP-AKTE-2; nicht mit dem Doku-Stand verwechseln. Nächster kanonischer Meilenstein weiterhin 1.0.0 (echte Integrations-Adapter DocuSign/PandaDoc + E-Mail-Versand statt Fakes, s. §2). CI-Hinweis: CI_RUNNER=ubuntu-latest (GitHub-hosted) bleibt gesetzt (MED-D-185/RISK-29 — self-hosted hot-Pool kann Runs verklemmen); nicht ungefragt auf hot zurückstellen.

Historie der bisherigen Wellen:

✅ Doku-Welle 4 vollständig erledigt (MED-OP-DOKU-5+6, MED-D-133/134, 0.78.1→0.78.3): Doku-Wellen 1–3 (MED-D-98/110/113) hielten größtenteils, aber der Re-Audit (v0.78.1, MED-D-132) fand eine Wiederkehr derselben Wurzelursache — README/MVP-Scope erneut veraltet, Lastenheft.md nie für Beratungsaufträge nachgezogen + eigener Phantom-"Ablage"-Rückfall, Deploy.md widersprach der Live-Realität, Check hatte einen blinden Fleck (§8-Regex/Dateiliste). 4a+4b: Wahrheit wiederhergestellt (README/MVP-Scope/ Lastenheft/CLAUDE.md/Deploy.md/Management-Summary korrigiert, Phantom-"Ablage" an der Quelle behoben) + Check-Lücke geschlossen. 4c+4d: Compliance/Risikoregister echt neu geprüft, Weltmodell-Data-Dictionary/ agents.md-ID-System/docs-README-Index/Lesepfade nachgezogen, Dexman pyramidal umsortiert, zwei Vor-R2-Diagramme korrigiert, OP-DEX-Nummerierung vereinheitlicht. Alle 32 Befunde (B1–B32) aus beiden Doku-Reviews bearbeitet. Die einzig noch offene Ausnahme (CLAUDE.md-§Versionierung-Restrukturierung, MED-D-131) ist seither ebenfalls entschieden + umgesetzt (siehe Punkt 3 unten, MED-D-140). Danach: Audit-Kadenz (MED-OP-REVIEW-1) — nächster Doku-Audit gemäß Stale-Regel.
✅ App-UX-Audit aufgefrischt auf v0.83.0 (MED-D-153, 2026-07-19, keine Versionsänderung, s. §2): fünf Dimensions-Reviews + Live-Begehung bestätigen alle carry-over Befunde B1–B4/B6/B7 als behoben/ unverändert — kein Rückfall durch den MED-D-151-Zwei-Achsen-Umbau. Neuer, kleiner Backlog B8–B13 (Cockpit-Chip-Overflow, PHASE_LABEL-Dopplung/G-8, Lifecycle-Undo ohne Fehlerbehandlung, Playbook-Fehler ohne UI-Signal, Kleinbefunde) → MED-OP-UX-8 (Welle 9, s. §4). Nächster App-Audit gemäß Stale-Regel.
✅ Decision-Log-ID-Kollisionen bereinigt (MED-D-139, 2026-07-14, keine Versionsänderung): Nutzerfrage "Was ist MED-D-131?" deckte auf, dass MED-D-130/131/132/133 je doppelt vergeben waren — ein CI/Infra-Batch (07-13) und die UX-Welle-8/Doku-Welle-4-Serie (07-14) hatten unabhängig voneinander dieselben Nummern vergeben. Aufgelöst nach Referenz-Umfang: die vier CI-Infra-Einträge (je nur 1 Fundstelle außerhalb des Logs) auf MED-D-135–138 umnummeriert; die breiter zitierten Doku-/ UX-Welle-Einträge behalten 130–133. Details: Decision-Log.md MED-D-139.
✅ CLAUDE.md-§Versionierung restrukturiert (MED-D-140, 2026-07-14, keine Versionsänderung): löst die seit MED-D-131 offene CodeRabbit-Frage. Nutzerentscheidung "Trim to current-state only" — der laufend wachsende §Versionierung-Absatz (jede PR hängte einen weiteren Satz Feature-Historie an, faktisch eine Log-Kopie trotz gegenteiliger Selbstbeschreibung) auf 1–2 Sätze Ist-Stand + Version gekürzt. Volle Historie je Version lebt jetzt ausschließlich in CHANGELOG.md (einzige Log-Quelle), aktueller Feature-Stand in docs/fachlich/Feature-Liste.md, Detail-Fortschritt in HANDOFF.md §2/§4/§5 — CLAUDE.md selbst bleibt dadurch dauerhaft kurz statt jede PR weiter zu wachsen.
App-UX-Welle 9 (MED-OP-UX-8, Rest der Umbau-Nachschärfung) — der App-Audit ist jetzt auf v0.83.0 aufgefrischt (MED-D-153, 2026-07-19, s. Punkt 2 oben); MED-OP-UX-5/6 (Wellen 6/7) sowie der Token-Welten-Teil von MED-OP-UX-7 (Welle 8) bleiben abgeschlossen, keine Regression durch den MED-D-151-Umbau. Neu zu bearbeiten (B8–B12): PHASE_LABEL-Dopplung in cockpit.component.ts auflösen (G-8, lokale Konstante löschen, LIFECYCLE_LABEL importieren) ✅ MED-D-154; error:-Handler an lifecycleZuruecksetzen() ergänzen (Schwesterstelle zu lifecycleSetzen()) ✅ erledigt (MED-D-156, 0.84.0, im Zuge des Kunden-Cockpit-Redesigns mitgezogen). ✅ MED-OP-UX-8 damit vollständig abgearbeitet (Bestandsaufnahme 2026-07-25, MED-D-231): die restlichen B8–B12 wurden bei früheren Wellen bereits mitgezogen — Cockpit-Chip-Overflow (Phase+Auftrag-Chips in einem Ellipsis-Container, B8/B26, cockpit.component.ts); AKTION_LABEL['beratungsdoku.geprüft'] vorhanden; aria-describedby+role="alert" am Lifecycle-Fehlertext vorhanden; Fragebogen hat eine (bewusst produkt-eigene) Essenziell/Wichtig/Optional- Legende statt der generischen Pflicht-Legende. Zuletzt geschlossen (MED-D-231, 0.104.1): die Auftrag-Playbook-Fehler (auftrag.playbook_fehler bei Anlage/Statuswechsel) wurden nur auditiert, nie dem Nutzer gemeldet — jetzt liefert der Service ein transientes playbookFehler-Flag (analog dem Mandant-Lifecycle-Pfad B15), der Client warnt ehrlich (⚠ „Standard-Aufgaben konnten nicht angelegt werden"). +2 Vitest (572→574). Weiter bewusst zurückgestellt (B13, unverändert seit v0.72.0): die verbleibenden ~132 Einzelwert-Inline-Styles in Cockpit + ~~350 app-weit; divergente Absende-Button-Texte; Turnstile-Lücke im Ausfüll-Formular; 4xx-Ladefehler auf Sub-Ressourcen-Listen. Nächster App-Audit erst gemäß Stale-Regel (~~0.93 oder >90 Tage; MED-OP-REVIEW-1, agents.md §6.7).
Kunden-Cockpit-Redesign (MED-D-156, 0.84.0) — das Kunden-Detail (mandant-detail.component.ts) folgt jetzt demselben .mw-*/World-2-Vokabular wie das Cockpit statt einer separaten hellen Brand-Optik, per Nutzer-beauftragtem claude.ai/design-Mockup umgesetzt (3-Spalten-Layout, neuer Übersicht-Standard-Tab, Mandate-Tab voll verschmolzen mit inline Beratungsdoku-Bearbeitung). Details + zwei live gefundene und gefixte Mobil-/Tab-Bugs siehe §2. Offener Punkt (bewusst zurückgestellt, out of scope für diesen PR): die im Mockup gezeigte Zeiterfassungs-"Mandat"-Zuordnung ✅ erledigt (MED-D-157, 0.85.0): neues eigenständiges Feld Leistungszeit.auftragRef (nicht beratungRef wiederverwendet, s. §2) + validierender Backend-Endpunkt + Mandat-<select> am Timer/retroaktiven Formular.
Weg zu 1.0.0: echte Integrations-Adapter statt Fakes — E-Signatur DocuSign/PandaDoc AES/QES (MED-KB-5), realer E-Mail-Versand über den Benachrichtigungs-Seam (OP-DM-8), CRM-Anbindung (A-3) — plus HQ-Eigentümer-Zuordnung der Domain; dann 1.0.0 taggen (bewusste Meilenstein-Entscheidung).
Danach/parallel: Spezial-Tool Dexman (R10, OP-DEX-1..10) und Meisterwerk-Audits gemäß Kadenz (MED-OP-REVIEW-1, agents.md §6.7).

6. Repo-Setup / Betrieb

Doku-Site Deploy: Cloudflare Pages, Projekt medidentas-docs (siehe docs-site/wrangler.toml, .github/workflows/docs-deploy.yml). Benötigt Repo-Secrets CLOUDFLARE_API_TOKEN + CLOUDFLARE_ACCOUNT_ID (Pages: Edit). Bis Secrets/Domain gesetzt sind, ist der Deploy-Job ein bekannter offener Setup-Punkt.
Branch-Protection / Auto-Merge / Squash-only / delete-branch-on-merge: als Repo-Settings setzen (agents.md §6.5) — nicht per Datei abbildbar. Required Checks = checks + CodeRabbit (MED-D-59); "require branches up to date" = AUS (MED-D-109, gegen die Rate-Limit-Treadmill bei Parallel-Merges). ⚠️ Offener manueller Schritt (MED-D-109): das Häkchen "Require branches to be up to date before merging" in der Branch-Protection von main deaktivieren (Admin-UI oder gh api … strict=false) — vom Agenten/MCP nicht setzbar. Verifikation prüft alle drei Invarianten (strict=false und beide Required-Contexts): gh api repos/drkv-com/medidentas/branches/main/protection --jq 'if .required_status_checks.strict==false and (.required_status_checks.contexts|index("checks")) and (.required_status_checks.contexts|index("CodeRabbit")) then "ok" else error("branch-protection-Vertrag unvollständig") end'.

Pflege: Je PR nur Fragmente anlegen (handoff.d/, changelog.d/, timesheet.d/, ggf. entscheidungen.d/); diese Datei wird daraus gebaut (MED-D-359). Neue offene Punkte → GitHub-Issue.

1. Was ist Medidentas?​

2. Aktueller Stand (neueste Einträge zuerst; Version: beim Deploy gestempelt, höchster Tag v<semver>)​

2026-10-14 — Dexman: Person + Anstellungs-Zeitspannen · Performance-Tabelle mit Festschreiben (MED-D-693/694)​

2026-10-14 — Konzept Onboarding über Fragenkataloge (MED-D-703)​

2026-10-14 — Praxis-Pflicht und Eindeutigkeit entkoppelt (MED-D-712)​

2026-10-14 — App-Meisterwerk-Audit v0.161.0 (MED-D-713)​

2026-10-06 — Dexman: Regel-Katalog der Handlungsempfehlungen + Monatsbericht-Beleg (MED-D-683/684)​

2026-10-06 — Akten-Rail: mehr Platz, bessere Lesbarkeit (MED-D-675)​

2026-10-06 — Dexman-Mandat braucht eine Praxis (MED-D-686)​

3. Letzte Entscheidungen (mit IDs)​

4. Offene Punkte (Kurzform — Detail im Lastenheft §11)​

5. Nächste Schritte (Vorschlag)​

6. Repo-Setup / Betrieb​