HANDOFF — Medidentas
Zuerst lesen. Kompakter Gesamtstand + offene Punkte für jede neue Session. Danach
docs/fachlich/Lastenheft.md(Master-Spec) unddocs/konventionen/agents.md(Way-of-Working).
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 (Version 0.127.1, 2026-08-27)
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 umpraxen().length === 0erweitert), 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 gesetztemnextcloudPfad). 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 übernextcloudPfad); die echte NextCloud-Live-Spiegelung bleibt MED-OP-FILES-1. Beide reine Client-Änderungen inmandant-detail.component.ts(+.md-erwartet-Style instyles.css);ng buildgrü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 inmandant-detail.component.ts;ng buildgrü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 mitaria-current; Navigation Weiter/Zurück; Zwischenspeichern bleibt auf Schritt 1; Absenden erst auf Schritt 3 (Gateabsendbar()unverändert). Reine Client-Umstrukturierung — kein Server-/Datenmodell-/Migrations-Belang, nutzt die bestehenden Endpunkte (kontext/entwurf/einreichen).handynummer→tel-Autocomplete ergänzt. Clientng buildgrü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 plainmandant-Spalten (Migration v56) —handynummer·steuernummer·steuerberater{Name,Kanzlei,Email,Telefon}(Wertobjekte Kontakt/Steuer/Steuerberater). NICHT hash-versioniert (Anhängen an die fixeVERSIONIERTE_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_REGELNals Fundament, Erhebung folgt Slice B. Einwilligungs-Fassung2026-08-v2. PII-Begründung G-6/RISK-34; RISK-30 (Steuernummer-Teil) erledigt. +1 Vitest → 692 (ausfuellgrad75→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. Servertsc+Vitest 692 · Clientng 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 inupdateMandant(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+ RoutenPOST /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, StaffPOST /api/mandanten/:id/portal-konto. Golden Rule: flag-gated (PORTAL_AKTIVdormant-Default;PORTAL_TEST_MODEgibt 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 insessionKonto(gesperrtes Konto → Session 401),istEmailan beiden Eingängen. +9 Vitest → 691. Testen:PORTAL_AKTIV=true+PORTAL_TEST_MODE=truein der Umgebung setzen → Staff legt Konto an (POST /api/mandanten/:id/portal-konto {email}) →POST /oeffentlich/portal/anmelden {email}lieferttestLink→ 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 buildgrü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= bestehendesself_service(nichtportal). 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 Codemandant.eingesehenbleibt, G-4). Tier B: 14 Client-Dateien umbenannt (akte-*→mandant-*/overlay-shell/status-slider/versioned-field/vorgang;mandant-akte→mandant-druckansicht), Selektorenmd-akte-*→md-mandant-*, Route/mandant/:id/akte→/mandant/:id/druck, Server-Enumandere_akte→anderer_mandant. Behalten:Aktenreife,Akteur, Programmname „Akten-Cockpit-Redesign“, Design-Artefakte, append-only Log-Historie. Clienttsc+ng build· Servertsc+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 Tabelletimer_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) · Clientng buildgrü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, bleibt0.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/verwerfenräumen sie;korrigierenschließt das offene) → keine verlorene/doppelt gezählte Zeit. (b) Direkt-buchenverweigert Fehlzuordnung über mehrere Mandanten (verteilen_noetig→ 409{verteilen:true}; Client leitet ins verteilte Overlay). (c) Push härter & datensparsamer (G-6): keinuser_agent, Endpoint-Allowlist (HTTPS + FCM/Mozilla/Apple/WNS),unsubscribeuser-scoped, Zustellung non-blocking (waitUntil) + 5-s-Timeout. (d)vordergrundweist malformtemandantIdmit 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) · Clientng buildgrü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);korrigierengleicht 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 monotonenmandantenSeq-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 buildgrü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, geteiltemd-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 buildgrü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 ausverwaltung.component.tsin eine neueneuer-mandant-overlay.component.tsgewandert (nutzt die geteiltemd-overlay-Hülle: Scrim + Dialog- Semantik + Fokus-Falle, G-3); die Cockpit-Buttons „+ Neuer Mandant"/Command-Palette öffnen jetzt das Overlay statt nach/verwaltungzu 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 fehlendesmin-width:0/overflow-wrapan.md-grow(Flexbox-Default) + ungeschützte Wertzellen; Fixes instyles.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-Kopfflex-wrap:wrap, Self-Service-Labelwhite-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 ältererfragebogenStatistik()-Call setztestatistikFehler=truetrotz bereits geladener Daten → mit monotonemstatistikSeq-Guard behoben (nur die jüngste Antwort setzt den Zustand, gleiche Machart wie MED-D-263). (2) Docs nannten den Endpunktfragebogen-statistik, echte Route istGET /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 vorhandenenGET /api/fragebogen/statistik-Endpunkt.ng buildgrü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: aufgesetzterole="list"/role="listitem"entfernt → native Buttons, konsistent mit den bestehenden Cockpit-Listen.ng buildgrü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 buildgrü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) nurtextTabs; 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ürperson.geburtsdatumbliebe 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 + kanonischetabLabel-Referenz) und §8 korrigiert (MED-OP-FORM-6 „teilweise gebaut", Hausformular-Auto-Routing viadokumenttypist 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 → falscheFremdformularVorlage.attribute. Jetzt indsAutoErkanntverfolgt + bei jedem Wechsel (Dropdown und manuelle GUID viatemplateIdManuellGesetzt) zurückgesetzt, plus Out-of-order-Guard gegen veraltetetemplateFelder-Antworten. Minor:listeTemplates()paginiert jetzt übernextUri(>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- methodenlisteTemplates()/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): derakte-feld-editornutzte undefinierte CSS-Tokens--fg/--fg-faint/--gruen→ Feldname-Text im Light-Theme nahezu unsichtbar. Aufvar(--text)/var(--mut)/var(--green)(theme-fähig) umgestellt. Reine CSS,ng buildgrü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) undAUTH_BOOTSTRAP_ADMINnicht greift → jeder ist Default-berater. Gebaut:POST /api/ich/rolle(setzt die eigene Rolle, ohnebenutzer_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 aufbenutzer_verwaltengaten / verriegeln / entfernen
AUTH_BOOTSTRAP_ADMINkorrekt 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 —anlegenlehnt eine zweite aktive Vorlage je Hausformular-Dokumenttyp ab (sonst mehrdeutiger Match). (C) G-8 — Verwaltung-Dropdown ausDOKUMENTTYP_LABELabgeleitet + Client-TypDokumenttyp | 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, routetSignaturService.anfordernbeim Versenden eines Hausformulars ohne Datei automatisch auf dieses Template (HelperversuchAusfuellbaresTemplate: 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 (TabstabLabel=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 → 422kein_inhalt. Baustein 1 (gebaut):SignaturServiceerzeugt ein bekanntes Hausformular ohne Datei jetzt beim Versenden (vorlageFuerBezeichnung→befuelleVorlage→erzeugePdf→ Ablage +nextcloudPfad), dann Signatur; Fremdformulare ohne Vorlage bleibenkein_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 niemain/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 viacore.hooksPathim Session-Start-Hook, 4-Schritt-Push-Disziplin inagents.md §7(checkout -B · Remote==Local nach Push · PR-Diff sichten · Deploy verifizieren). (B) Signatur-Härtung (CodeRabbit #289):providerFehlerTextredigiert 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_fehlerstatt opaker 500), symmetrisch inanfordern/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üfenSignaturService.anfordern/vorOrtVorbereitenbeim 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 abgeleiteterMandantCockpit.offeneFakturierungMinuten(SummedauerMinutenje Mandant mitabrechenbar && !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.startenruft den Provider (anfordernAusTemplate) vor dem Anlegen des Dokuments — wirft er, entsteht keine Waise. Fake:markiereSignierterhält dieformularWerte(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ätFremdformularVorlage{name, templateId, attribute[], niveau}(v47, kein PDF-Blob/PII); ProvideranfordernAusTemplate(DocuSigncompositeTemplates); DomänebaueTabWerte+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-RolleUnterzeichner. 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). ProviderformularRuecklauf(externalId)(DocuSignform_data); DomäneATTRIBUT_ZU_STAMMZIEL+ruecklaufRegelnspeisen 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 → versionierterupdateMandant, Quelleformular) + 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 überschrittenemgueltigBiswar bisher in beiden Ableitungs-Sichten unsichtbar (bliebgeprüft→ nichtdokumenteOffen; kein Auto-Setter aufabgelaufen). Neuer reiner HelferdokumentAbgelaufen(d, jetzt);AktenreifeInputumdokumenteAbgelaufenerweitert → eigener Reifepunkt (dokument/Stufeaktiv/wichtig= fällig, kein Abschluss-Blocker) +naechsteSchritte-Schrittdokumente-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 ausgueltigBis. +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 zeigtev… · 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 Stempelv{SemVer} · Build {Nr.} · {Zeitpunkt}(Cockpit: Header-Chip vor dem Benutzer-Chip; Akte: „Stand:"-Zeile unter dem Lifecycle-Stepper). Reine Client-Anzeige über den bestehendenhealth-Endpunkt (version/build/buildZeit), kein Server-/Persistenz-Change;BUILD_NUMBER/BUILD_ZEITkommen weiterhin ausgen-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 inAkten-Cockpit-Redesign.md§4 auf den MED-D-241-Stand (direkt editierbar) korrigiert.ng buildgrü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 RoutenPOST /api/dokumente/:docId/signaturund/signatur/vor-orttrugen 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 fremdendocIdein 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 vorleseEmpfaenger/sig.anfordern/vorOrtVorbereitenin beide Signatur-Routen gesetzt → Fremd-Mandant 404 (kein Existenz-Leak), Schreiben verlangtmandant_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 ausBankkonto.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 optionalenempfaenger-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 Endpunkteapi.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). aktenreife.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.mdpräzisiert (nur die Self-Service-Karte sitzt in der Rail, der Onboarding-Umschalter in der Item-Liste); 4-Tasten- Umschalter bekamaria-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: imcanDeactivate/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ätAktiverTimer(Erweiterung von R13 Leistungszeit, R13-F12..F17, Tabelleaktiver_timer, Migration v43) — eine Zeile je Benutzer (G-2), ephemer bis zum Buchen. NeuerAktiverTimerService(start/pause/fortsetzen/korrigieren/buchen/verwerfen) + RoutenGET/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 stattdessenkonflikt:truemit dem bestehenden Timer. Client (mandant-detail.component.ts): lokale Timer-Signale durchaktiverTimer()(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;visibilitychangesynct beim Zurückkehren in einen Tab sofort den echten Server-Stand (behebt zugleich die Browser-Drossel- Symptomatik in Hintergrund-Tabs). Bewusstes Verhaltens-Update:beforeUnloadwarnt 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 buildgrü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.1PATCH): 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 dassverlassenAbbrechen()ihn je fortsetzt) — Reihenfolge korrigiert;/api/timer/start//api/timer/buchenhatten keinedarfSehen/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 + fehlendeskonflikt: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 diemandant_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 perDesignSync-MCP (MED-D-176,0.89.1→0.90.0, MINOR): auf Nutzerauftrag das aktuelleAkten-Cockpit 1a (Detail).dc.htmlerneut ausclaude.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 aufdisplay:nonegesetzt, 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 bestehendewiedervorlageStatus(id,'offen')-API) reaktivieren statt endgültig erledigt zu bleiben. Reine Client-Änderung.tsc+ng buildgrü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 zuorigin/maindivergiert, wodurch GitHub den Merge-Base fälschlich vor PR #210 statt auf den echtenmain-Kopf berechnete —app.ts/timer.test.tserschienen dadurch als "geändert", zwei längst korrekt behobene historische Zeilen als "in diesem PR überschrieben"; Branch pergit 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 keinendarfSehen/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 geteilterwiedervorlageScopeGuard(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 buildgrü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 vonorigin/mainaufgesetzt, 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/wvOeffnensetzten nie dasarbeitet()-Signal — der[disabled]="arbeitet()"-Doppelklick-Schutz griff dadurch nie; Busy-Flag ergänzt (analogwvAnlegen()). Veraltete522-Testzahlen inTest-Uebersicht.md/Management-Summary.md/MVP-Scope.mdauf523nachgezogen. 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 buildgrü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 beimmain-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-SchalterSIGNATUR_PROVIDER=docusignbleibt als nicht-geheimer, auskommentierter Toggle inwrangler.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 viaDeploy.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: "Akte" = CRM (Daylite) + Ablage + Beratungsmandate + Orchestrierung (MED-D-95); Betreuungsintensität Intensiv/Standard/Basis (nicht A/B/C — deckt sich mit gebautembetreuungsmodellR1-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 ausgenommenerdependabot[bot]-PR bekäme nie denCodeRabbit-Status → bliebe als Required Check am Gate hängen; Bot-PRs werden mitreviewt. Konvention inagents.md§7, gilt für alle Sessions (SessionStart-Hook liestagents.md/CLAUDE.md). - MED-D-59 CodeRabbit auto-merge-tauglich & rate-limit-sicher (Tooling, keine Versionsänderung; schärft
MED-D-52):
.coderabbit.yamlsetztcommit_status: true(Status-ContextCodeRabbit= als Required Check hinterlegbar),fail_commit_status: false(Rate-Limit bleibtpendingstattfailure→ kein Auto-Merge-Deadlock),auto_incremental_review(damalstrue; später auffalsegesetzt, MED-D-100 — EIN Review je PR beim "ready for review", keine inkrementellen Re-Reviews),collapse_walkthrough: true+ erweitertepath_filters(kompakter, Doku bleibt),drafts: false+ "nur bei offenem PR". Offen (Admin/gh api, agents.md §6.5): Status-ContextCodeRabbitin der Branch-Protection vonmainnebenCI Gateals 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 inindex.ts). Begründung: ein Origin → Cloudflare Access schützt UI und API in einer Policy, kein CORS. Domainmedidentas.comgekauft, Transfer an HQ ausstehend. Repo ist deploy-fertig (manuellerapp-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)
| ID | Kurz | Nächster Schritt |
|---|---|---|
| MED-OP-AKTE-2 | 🟡 **Akten-Cockpit-Redesign v2 (Design "Mandanten-Akte verbessern") — mehrteilig; voller Slice-Plan S1–S6 festgelegt (MED-D-188); S1–S6 vollständig gebaut — MED-OP-AKTE-2 ✅ geschlossen. Das überarbeitete Mockup "Akten-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/Akten-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 AkteBankrowComponent + 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 AkteVersionedFieldComponent (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-akte-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 AkteUnterschriftenAssistentComponent (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 akte-patterns-Komponenten gebaut → MED-OP-AKTE-2 (Akten-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 Auftrags-Akte im Scrim-Overlay (akte-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). |
✅ 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) | |
✅ erledigt (0.64.0, MED-D-91): UX-Welle 2 — eine Sprache (G-3/G-8-Pass): zentrale labels.ts (+ Datums-Utility + eine Aktenreife-Stufen-Ableitung), Akte/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) | |
✅ 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 | |
✅ abgeschlossen (0.67.0, MED-D-94) — Rest umgesetzt: Register-Sub-Komponenten (akte-meetings/akte-einladungen/akte-formulare/akte-stammuebernahme + akte-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 | |
| ✅ 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 | 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 | 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 | 🟡 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. |
✅ 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). | |
| ✅ 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 | 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 | migrate.ts ist über alle 42 Versionen hinweg nicht restart-sicher — _meta.schema_version wird erst einmal am Ende der gesamten SCHRITTE-Schleife gesetzt, nicht je Schritt; ein Absturz zwischen einer DDL (z. B. ALTER TABLE … ADD COLUMN) und diesem finalen Update lässt den nächsten Start dieselbe DDL erneut ausführen → duplicate column-Fehler blockiert den Worker-Start | CodeRabbit-Fund an MED-D-157/PR #197 (v42), aber systemisch seit v1 — nicht nur v42 betroffen, ein isolierter Fix nur für v42 wäre inkonsistent (würde einen falschen Sicherheitseindruck für die übrigen 41 Schritte erzeugen). Naheliegende Lösung: _meta.schema_version je Schritt (nicht erst am Ende) setzen, oder D1s db.batch() für DDL+Version-Update je Schritt nutzen; eigene, größere Migrations-Architektur-Entscheidung, daher als OP statt Teil eines Bugfixes umgesetzt (analog MED-OP-TEST-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 | 🟡 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. |
✅ gebaut (0.56.0, MED-D-80): Dokumente & Unterschriften als quer-liegende Achse (Dokument-Ledger) | Neues Register "Dokumente & Unterschriften" (phase: null) in Arbeitssicht + Akte 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 (aktenreife.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. | |
✅ 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 AktenreifeInput). Design: architektur/Prozessmodell.md §8 P3. | |
| ✅ 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 | 🟡 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 | 🟡 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 | 🟡 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 + Akte-„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 | 💡 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). |
✅ 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 | 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 (Akte+Audit), VideoIdent nur Fallback; QES enthält Ident. Bezug RISK-25, OP-SIGN-1. |
| ✅ Abstraktion + Regel-Check + Haftungsgrenze gebaut (Slice 5) | Rest: echtes Medidentas-GPT (Modell/Anbieter, EU-Residenz). | |
✅ 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). | |
✅ 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 | CRM: Daylite→HubSpot oder Eigenlösung | Build-vs-Buy entscheiden; Daylite-Migration inkl. Wiedervorlagen. |
| OP-SIGN-1 | ✅ 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. |
| ✅ Erledigt: Cloudflare | — (Folge-OPs: OP-AUDIT-1, OP-OBS-1, OP-DATA-1, OP-AUTH-1). | |
| ✅ MVP gebaut (Slice 2): WebDAV + App-Passwort + Ordner + Abgleich | Rest: OAuth2 (RISK-16), OCS-Group-Folders, Webhooks. | |
| ✅ 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). Akte-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 | 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. |
✅ MVP gebaut (Slice 7): Cloudflare Access + Rollen (benutzer-Tabelle) + RBAC + echter Audit-Actor | Rest: Access-Application/Policies (Deploy), RBAC je Mandant, SCIM/Gruppen-Sync. | |
| ✅ Gebaut (Slice 6): append-only + Hash-Chain + Verify | Rest: Cold-Storage-Archiv (R2), Restore, Concurrency-Härtung. | |
✅ 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 | 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 | 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 in der Akte 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 | 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 | Datenschutz-Konzept | AVV, Residenz, Löschkonzept. |
| OP-EXT-1 | Tool-Vertrag (Erweiterbarkeit) | Manifest-Schema, Scopes/Events, Isolation, Lizenz. |
| OP-MANDGRP-1 | 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 | 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 | 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 | Ruhende Mandate — Workflow | Status ruhend existiert (R1-F05); offen: Grund + Reaktivierungsdatum, Wiedervorlage-Pause solange ruhend, auditierte Reaktivierung (≠ archiviert), Reporting. |
| OP-ABC-1 | 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 | 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 | "Meaningful actions" — nächste sinnvolle Schritte ableiten & anzeigen | ✅ Erst-Slice gebaut (0.44.0, D-46): abgeleitete "Nächste Schritte"-Leiste im Aktendeckel (domain/naechste-schritte.ts → MandantDetail.naechsteSchritte, rein aus dem AktenreifeInput, 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 in der Akte; (3) ggf. Playbook-getriebene Zusatz-Empfehlungen. |
| OP-ASSIST-1 ✅ Design vorhanden (MED-D-74) | 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.). |
✅ Gebaut (0.40.0, D-43): Leitstand-Band auf echtes Aktenreife-Aggregat | GET /api/aktenreife (service.aktenreifeUebersicht(), { 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 | 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 | 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 | 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 | 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 | 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 | "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 | 🟡 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_REGELNs 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.tss 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 | 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 | 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 | 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 (akte-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.tss 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 | Aktenreife-Ring (rechte Sidebar der Akte) bewusst entfernt (20.07.), Wiedereinführung explizit auf später vertagt | Nutzeranstoß "Nimm die Aktenreife 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.tss rechter Sidebar raus (samt der dadurch verwaisten Methoden zuPunkt/offenGesamt/reifeLabel/ringOffset/ringUmfang). Bewusst erhalten (nutzen dieselbe AktenreifeInput-Berechnung, gelten aber nicht als "der Ring"): die Tab-Badges (tabBadge()), die "Jetzt dran"-Karte im Übersicht-Tab (inkl. "… blockieren die Aktenreife"-Zähler) und alles auf dem Cockpit (andere Seite, out of scope). Serverseitige domain/aktenreife.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 | UI-Aufräumarbeiten: Groß-/Kleinschreibung uneinheitlich + Dentmarking-Sektion falsch platziert | (a) Dentmarking/"Praxen"-Sektion: liegt im Aktendeckel 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. |
| 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. | |
✅ 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. | |
| ✅ 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. | |
✅ erledigt (2026-07-13): UX-Welle 6 — Zugang & Verlässlichkeit (App-Audit v0.72.0, B1/B3/B4) | ✅ (1) Akte mobil (B1, 0.72.1, MED-D-111): behoben — die Shell-Kopfzeile (.md-header) war eine einzeilige Flex-Zeile und zwang die Akte auf Desktop-Breite (390px → 944px Overflow); @media (max-width:640px) lässt sie umbrechen → Akte 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 Akte verlaufFehler/verlaufLaden() + Druck-Akte 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). | |
| ✅ 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). | |
| ✅ 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. | |
✅ 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.mds 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). | |
| ✅ 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. | |
✅ 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): 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).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ß. 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).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). 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).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 (Akte-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/Akte-Struktur.md beschreibt noch die prozessgegliederte Vor-Cockpit-Akte (§3 "Register = Prozessphasen", Phasen-Zeitstrahl) — überholt durch MED-D-151 (Prozessphase-Achse abgelöst) + MED-D-156 (Akten-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): Akte-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-Aktendeckel/§3 "Register = Prozessphasen"/Phasen-Zeitstrahl retired; Aktenreife-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-Akte-Struktur-Zeile entfernt. MED-OP-DOKU-7 damit vollständig geschlossen. | |
| MED-OP-REVIEW-1 | 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 Akten-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 Akten-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 akte-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 (akte-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. |
✅ 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): PHASE_LABEL-Dopplung0.83.1); (2) Cockpit-Chip-Overflow (offen → B8/MED-OP-UX-9); error:-Handler an lifecycleZuruecksetzen()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). | |
✅ UX-Welle 10 — Akten-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 — AkteOverlayComponent: role="dialog"/aria-modal/aria-label + Initial-Fokus + Fokus-Falle + Fokus-Rückgabe, alle 4 Overlays migriert); schliesseOverlay(), räumt bankPeek); flex-wrap, Schließen-Knopf auf 390px erreichbar, live 528→371). .mw-slider-seg/.mw-sepa/.mw-bankrow-archbtn/.mw-vfield-pill mit min-height:24px (WCAG 2.5.8, live = 24px); set([])-Ladefehler sichtbar machenrole="alert") + „Erneut versuchen"; Rest-Folgepunkt: die mit detail() verzahnten mandant-detail-Sub-Loader (~1483-1490) bleiben vorerst still. aria-describedby+role="alert" an md-errormd-error als role="alert". 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): nebendatenFehler-Banner + Retry im Stammdaten-Overlay), bdAnlegenUndBinden-Waisen-Schutz0.99.7): mandant-detail-Sub-LoadernebendatenFehler-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). | |
✅ 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): role="tablist" + roving tabindex + Pfeil-/Pos1-/Ende-Tastatur; role="tabpanel" bewusst ausgelassen — verstreute [hidden]-Sektionen, kein 1-Panel-je-Reiter) · role="alert" außerhalb des Kerns--mut-Kontrast <AA#5f6d62, 5,45:1). Band C/D Vereinheitlichung (Slice 3, MED-D-216): labels.ts; AuftragStatus-Doppelvokabel → AUFTRAG_STATUS_LABEL Langform + AUFTRAG_STATUS_KURZ_LABEL Kurzsicht, EINE Quelle, live verifiziert) · .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) · .md-status-*-Regelsatz-Drifterhalten 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 + 1.09 oder >90 Tage). | |
✅ 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 | 🟡 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). akte-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 (akte-feld-editor.component.ts:111/112/114/120); Fix = echte Tokens.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 (akte-auftraege:146). |
| MED-OP-DOKU-9 | 🟡 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-Akte.md:6 Stand-Stempel 0.99.12 stale → nach Inhalts-Stichprobe re-stempeln. |
| MED-OP-UX-11 | 🟡 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-akte:335 primärer Fehler + akte-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. |
✅ 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 (Druck-Akte 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 Akte. | |
| MED-OP-UX-7 | 🟡 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 akte-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-akte.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/Akte-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 die Akte 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.mdnie für Beratungsaufträge nachgezogen + eigener Phantom-"Ablage"-Rückfall,Deploy.mdwidersprach 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/133je 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) aufMED-D-135–138umnummeriert; die breiter zitierten Doku-/ UX-Welle-Einträge behalten130–133. Details:Decision-Log.mdMED-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 inCHANGELOG.md(einzige Log-Quelle), aktueller Feature-Stand indocs/fachlich/Feature-Liste.md, Detail-Fortschritt inHANDOFF.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.0aufgefrischt (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 incockpit.component.tsauflösen (G-8, lokale Konstante löschen,LIFECYCLE_LABELimportieren) ✅ MED-D-154;error:-Handler anlifecycleZuruecksetzen()ergänzen (Schwesterstelle zulifecycleSetzen()) ✅ erledigt (MED-D-156,0.84.0, im Zuge des Akten-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_fehlerbei Anlage/Statuswechsel) wurden nur auditiert, nie dem Nutzer gemeldet — jetzt liefert der Service ein transientesplaybookFehler-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 seitv0.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.93oder >90 Tage; MED-OP-REVIEW-1, agents.md §6.7). - Akten-Cockpit-Redesign (MED-D-156,
0.84.0) — die Akte (mandant-detail.component.ts) folgt jetzt demselben.mw-*/World-2-Vokabular wie das Cockpit statt einer separaten hellen Brand-Optik, per Nutzer-beauftragtemclaude.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 FeldLeistungszeit.auftragRef(nichtberatungRefwiederverwendet, 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; dann1.0.0taggen (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(siehedocs-site/wrangler.toml,.github/workflows/docs-deploy.yml). Benötigt Repo-SecretsCLOUDFLARE_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 =
CI Gate+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 vonmaindeaktivieren (Admin-UI odergh 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("CI Gate")) and (.required_status_checks.contexts|index("CodeRabbit")) then "ok" else error("branch-protection-Vertrag unvollständig") end'.
Pflege: Bei jedem PR §2 (Stand) und §4 (OPs) nachziehen; CHANGELOG-Eintrag je PR; Timesheet-Session aktualisieren.