Zum Hauptinhalt springen

Akten-Cockpit-Redesign — Programm & Slice-Plan (Bezug: Handoff "Akten-Cockpit 1a (Detail)", 2026-07-23)

Kurz: Der High-Fidelity-Handoff "Akten-Cockpit 1a (Detail)" (claude.ai/design-Projekt Mandanten-Akte verbessern) baut den internen Mandanten zu einem fokussierten Akten-Cockpit um: fünf arbeits-gegliederte Reiter (Basis-Informationen [Default] · Mandate · Alle Dokumente · Fristen & Aufgaben · Praxen) plus vier Overlays (Mandat · Zeiten · Stammdaten · Unterschriften- Assistent) statt der heutigen sechs Reiter. Das ist ein Mehr-PR-Programm, kein einzelner PR — dieser Plan legt die Slice-Reihenfolge S1–S6 fest. Drei Nutzer-Entscheidungen (2026-07-23) sind eingebaut: (1) voller Slice-Plan zuerst (dieses Dokument), dann top-down; (2) Unterschriften-Assistent jetzt gegen die bestehenden Fake-Provider bauen (echte DocuSign/E-Mail-Adapter — MED-KB-5/OP-DM-8 — später eingehängt); (3) 1:n-Bankkonten-Modell jetzt bauen (kehrt die Zurückstellung aus MED-D-179 um).

Quellen der Wahrheit (seit MED-D-218 im Repo archiviert): verbindliche Spezifikation = akte-patterns.md (§1 Wording/Zustandsmodelle · §2 zehn Komponenten mit Maßen/Tokens · §3 Interaktionsregeln · §4 Enum-Vorschläge); pixelgenaues Markup = Akten-Cockpit-1a-Detail.dc.html; Soll-Zustände = screenshots/01–17; das Warum je Entscheidung in produkt/Design-Entscheidungen-Akte.md (AD-001…AD-015). Handoff-Archiv: docs/design/akten-cockpit-handoff/. Governance/Architektur siehe Root-CLAUDE.md; IA-Hintergrund siehe Akte-Struktur.md (MED-D-186, aktueller 6-Reiter-Stand) — dieser Plan löst ihn ab.

Laufzeit-Topologie & SBOM: die implementierte Runtime-Sicht (Worker · D1 · R2 · NextCloud · Signatur · CRM) + die SBOM-Fundstelle stehen kanonisch in Architektur-Uebersicht.md; dieser Plan beschreibt die UX-/IA-Ziele des Mandanten, nicht die Laufzeit-Topologie (nicht dupliziert).

1. Ausgangslage — gebaut vs. Lücke​

BereichHeute (gebaut)Ziel (Design)Lücke
IA6 Reiter (Übersicht · Mandate · Dokumente · Fristen & Aufgaben · Stammdaten & Onboarding · Zeiterfassung)5 Reiter + 4 Overlays, "Basis-Informationen" DefaultIA-Umbau (MED-OP-AKTE-2), Overlay-Shell, LifecycleRing
DokumentstatusServer-Enum angefordert/erhalten/geprüft/abgelaufen/entfälltSlider Fehlt·Erhalten·Geprüft + Flags versendet/nicht_erforderlich/abgelaufen, zustandsgetriebene AktionenStatusSlider, RequirementCheckbox, DocumentRow-Zustandsmaschine, Ablauf-Auto-Rückfall, Fortschritt nur Erforderliches
Stammdaten-VersionierungMandant append-only versioniert, "Stand: vN"-Pille + Historie (MED-D-179)VersionedField je Feld (Anschrift-Muster), Self-Service-Karte im OverlayFeld-Historie-Rail breiter, Self-Service-Upload-Sektion
Bankverbindungje ein Einzel-IBAN-Feld (Mandant ibanPrivat, Praxis iban)1:n Bankkonten (Inhaber · Zeichnungsberechtigung · Prüfstatus · SEPA), Swipe-to-Archiveneues Entitäts-Modell (Backend + UI)
ZeiterfassungTimer in der Kontext-Rail (MED-D-172)Timer bleibt; "Erfasste Zeiten" als Overlay statt ReiterZeiten-Overlay
UnterschriftenSignatur-Vorgänge lesend; DocuSign/PandaDoc = Fake (MED-KB-5)3-Schritt-Assistent + Vor-Ort-Strecke (Screens 09–17), SES/AES/QES, Sammel-Umschlag, Write-backAssistent-UI + Zustands-Write-back gegen die Fakes

2. Ziel-Informationsarchitektur​

3. Slice-Plan (S1–S6, je Slice ein PR)​

Reihenfolge = Abhängigkeit: das IA-Fundament trägt alle Screens; die Zustandsmaschine speist Dokumente und die Assistent-Einstiege; das Bank-Modell ist Voraussetzung für den SEPA-Schritt des Assistenten.

SliceInhaltBackend?Abhängig vonStatus
S1 — IA-Fundament & Overlay-ShellReiter → Basis-Informationen (Default) · Mandate · Alle Dokumente · Fristen & Aufgaben · Praxen; generische Overlay-Shell (Scrim/ESC/Scrim-Klick, align-items:flex-start, Panel min(760px,100%)); Zeiten + Stammdaten + Mandat als Overlays; LifecycleRing-Avatar (5 Segmente)nein (Client)—✅ gebaut (2026-07-23, MED-D-191, 0.92.0) — 5-Reiter-IA + Basis-Default + Praxen-Reiter, Overlay-Shell mit Stammdaten- & Zeiten-Overlay, LifecycleRing. Mandat-Overlay (hängt am Mandate-Rework) + Assistent-Overlay (= S5) bewusst zurückgestellt; Mandate bleibt vorerst ein Reiter. → Mandat-Overlay nachgezogen (2026-07-23, MED-D-200, 0.99.0): Mandate-Reiter jetzt kompakte Liste + Detail-Overlay (akte-auftraege.component.ts), damit sind alle 4 Overlays gebaut.
S2 — Dokument-ZustandsmaschineStatusSlider (Fehlt·Erhalten·Geprüft), RequirementCheckbox + Inaktiv-Trenner, DocumentRow zustandsgetrieben, Ablauf-Chip + Auto-Rückfall auf Fehlt, Gruppen (Uploads/Formulare), Fortschritt zählt nur Erforderlichesnein (Client/UI-Mapping) — geplante Enum-Flags versendet/nicht_erforderlich + Ablauf-Logik zu spaeterem Enum-Slice verschobenS1✅ gebaut (2026-07-23, MED-D-192, 0.93.0) — StatusSlider (neue Komponente md-status-slider) an Onboarding-Items & Ablage-Dokumenten; RequirementCheckbox + Trenner nur an den Onboarding-Items; Ablauf-Chip an den Ablage-Dokumenten; reines UI-Mapping (Server-Enums unverändert — Design-Konflikt so entschieden, statt der geplanten Enum-Flags). Fortschritt-nur-Erforderliches bereits serverseitig (domain/progress.ts). Assistent-abhängige DocumentRow-Zustände (versendet/"Zur Unterschrift"/Fremdformular) + die eigentlichen Server-Enum-Flags zu S5 bzw. einem späteren Enum-Slice verschoben.
S3 — 1:n Bankkonten + SEPANeue Entität Bankkonto (Inhaber · IBAN · Zeichnungsberechtigung · Prüfstatus neu/geprüft/archiviert · sepa_gueltig), Migration/Repo/Service/Routen/Tests; BankRow-UI im Stammdaten-Overlay + Swipe-to-Archive + Peek-Teachja (neues Modell)S1✅ gebaut — S3a (Backend, MED-D-195, 0.94.0): Bankkonto-Entität + Migration v45 + Repo/Service/Routen + crash-/nebenläufigkeitssicherer Backfill (UNIQUE-quell_schluessel + ON CONFLICT DO NOTHING; Alt-Felder zwei-phasig lesbar), +12 Vitest, live verifiziert. S3b (BankRow-UI, MED-D-196, 0.95.0): BankRow im Stammdaten-Overlay (Inhaber · Kontext · IBAN-4er-Gruppen · Zeichnungsberechtigung), Prüfstatus-Slider (Neu/Geprüft) + SEPA-Toggle als getrennte Achsen, Swipe-to-Archive (Geste über Schwelle → archivieren + Undo-Toast) + dezenter Desktop-/Tastatur-Archiv-Button + Peek-Teach, archivierte Konten schreibgeschützt unter Trenner; neue AkteBankrowComponent. Live gegen wrangler dev + Playwright verifiziert (11/11, append-only kein DELETE).
S4 — VersionedField-Ausbau + Self-ServiceFeld-Historie-Rail nach dem "Anschrift"-Muster über die versionierten Felder, Versions-Pille im Overlay-Kopf, Self-Service-Karte (Link kopieren/übernehmen/neu · "über den Link hochgeladen"-Sektion)teils (Self-Service-Upload-Sicht)S1, MED-D-179✅ gebaut (2026-07-23, MED-D-197, 0.96.0) — VersionedField (md-versioned-field) im Stammdaten-Overlay: je versioniertes Feld aktueller Wert + vN-Pille → aufklappbare Feld-Historie (aus den MED-D-179-Snapshots abgeleitet, kein Zweit-Fetch); Versions-Pille auch im Overlay-Kopf (Stand: vN). Live 9/9 verifiziert. §2.8 Self-Service: Link-Verwaltung (kopieren/übernehmen/neu) bereits gebaut (MED-D-170); hochgeladene Dokumente erscheinen im Reiter "Alle Dokumente" (S2) → als erfüllt bewertet, keine Duplizierung.
S5 — Unterschriften-Assistent3 Schritte (Prüfen · Versenden · Verfolgen) + Vor-Ort-Strecke; SES/AES/QES-Slider, Sammel-Umschlag, Frist/Erinnerung; Write-back (Dokument versendet→erhalten, SEPA gültig, Aufgabe erledigt, Verlaufseintrag); Einstiege aus DocumentRow/TaskCard/BankRowja (gegen die Fake-Provider MED-KB-5, E-Mail-Seam OP-DM-8)S2, S3✅ gebaut (2026-07-23, MED-D-198, 0.97.0) — AkteUnterschriftenAssistentComponent als Overlay: 3 Schritte Prüfen/Versenden/Verfolgen + Vor-Ort-Strecke, eIDAS-Slider (SES/AES/QES, auto aus Rechtsmatrix oder manuell), Sammel-Umschlag (Client-Bündelung), Frist→Wiedervorlage, durchgehender Attrappe-Hinweis (MED-KB-5). Server: Vor-Ort-/Demo-Abschluss-Seam (abschliessenDemo? nur am Fake → echte Vorgänge nie fälschbar) + vorOrtAbschluss + Route + Niveau-Override. Write-back via bestehenden abgleich-Pfad. Einstiege: DocumentRow · Dokumente-Tab · BankRow "SEPA einholen". +5 Vitest, live 9/9 verifiziert. Slice B nachgezogen (MED-D-227, 0.102.0): Vor-Ort-Signatur landet jetzt auf erhalten (Prüfung offen) statt unterschrieben/geprüft (Attrappe erzeugt keine rechtsgültige Signatur, G-4/MED-KB-5; gemeinsamer erhaltenAblegen-Helfer mit Sign-on-Paper, idempotent); geführte In-Person-Strecke (Übergabe → Kunden-Signaturansicht → Danke → Schritt 3, Vollflächen-Takeover) statt Ein-Klick; Write-back-Automatik SEPA-Konto→gültig (ersetzt manuellen Button) + auslösende Aufgabe→erledigt (aufgabeId-Input), best-effort/idempotent. Delta C nachgezogen (MED-D-229, 0.103.0): Prüfen-Schritt (§2.5) ausgebaut — Pflichtdaten-Checkliste (abgeleitet, ✓/●; fehlende → Self-Service/Formular statt Inline-Stammdaten-Write, MED-D-147-Grenze), SEPA-Konto-Auswahlkarten + „Neues Konto erfassen" (bestehende Bankkonto-Route; gewähltes Konto steuert den SEPA-Write-back), Formular-Vorschau (read-only). Delta D nachgezogen (MED-D-230, 0.104.0): Fremdformular-Klassifikation (abgeleitet aus DOKUMENTTYP_LABEL, keine neuen Enum-Flags) — amber „Fremdformular"-Pill an der Schritt-1-Dokumentzeile + neutrale Hinweisbox „Im Feld-Editor öffnen →" statt Formular-Vorschau (Vorschau bleibt nur für Eigenformulare); kein Eigenbau-Feld-Editor (G-1), der Button meldet ehrlich „folgt mit der DocuSign-Anbindung" (OP-SIGN-1/MED-KB-5). Deferiert (Rest): versendet/nicht_erforderlich-Enum-Flags (S2-Entscheidung, weiterhin abgeleitet statt persistiert); der echte Feld-Editor mit DocuSign-Template-Bindung (an OP-SIGN-1 gekoppelt).
S6 — Feinschliff & AbnahmeTaskCard-Politik (blockierend/fällig/erledigt, Live-Zähler), Wording zentral nach labels.ts-Muster, Motion-Kurve cubic-bezier(.22,1,.36,1) + prefers-reduced-motion, Screens 01–17 als Abnahme-ReferenzneinS1–S5✅ gebaut (2026-07-23, MED-D-199, 0.98.0) — TaskCard (§2.9): die Fristen-&-Aufgaben-Zeilen sind jetzt Karten 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-Aufgaben bekommen den "Im Unterschriften-Assistenten →"-Einstieg (schließt die letzte TaskCard→ovSig-Kante). Reiner Präsentations-Feinschliff (kein Sub-Komponent — die Zeile trägt viel inline-State; Extraktion wäre Churn, analog S1). Live 9/9 verifiziert. Damit alle 10 akte-patterns-Komponenten gebaut. Restliche Feinschliff-Punkte beide erledigt: globale Motion-Kurve ✅ (MED-D-232, 0.104.2) — ein Token --mw-ease statt 6× Literal + prefers-reduced-motion auf die dekorativen Entrance-Pops/Fades erweitert; Wording-Zentralisierung ✅ (MED-D-233, 0.104.3) — Kunden-Feldmarkierung „weiß ich nicht"/„wird nachgeliefert" 3× dupliziert → ein MARKIERUNG_LABEL in labels.ts (G-3). Damit ist der S6-Feinschliff vollständig, keine offenen Politur-Reste mehr; Mandat-Overlay = eigener Mandate-Rework, ausdrücklich kein Feinschliff (→ nachgezogen 2026-07-23, MED-D-200, 0.99.0 — alle 4 Overlays jetzt gebaut).

S3-Backfill & Rückwärts-Kompatibilität (verbindlich)​

Die Umstellung auf die 1:n-Bankkonto-Entität ist verlustfrei und zwei-phasig (analog der Beratungsauftrag-Migration MED-D-95 und dem Stammdaten-Backfill MED-D-179):

  • Quelle → Entität: je nicht-leerem Alt-IBAN-Feld genau ein Bankkonto — Mandant.ibanPrivat → Konto mit Inhaber = die natürliche Person, Praxis.iban → Konto im Kontext der Gesellschaft/Praxis. Prüfstatus initial neu, sepa_gueltig=false. Leere Felder erzeugen kein Konto (kein Leer-Datensatz).
  • Erhaltung: kein bestehender IBAN-Wert geht verloren oder wird dedupliziert weg-gerundet; identische IBANs an verschiedenen Trägern bleiben getrennte Konten (unterschiedlicher Inhaber/Kontext).
  • Zwei Phasen: die Alt-Felder ibanPrivat/iban bleiben nach dem Backfill lesbar erhalten (kein sofortiger DROP); erst nach bestätigter Umstellung aller Lese-/Schreibpfade werden sie entfernt — so gibt es keinen Zwischenzustand, in dem Code ein Feld erwartet, das schon weg ist.
  • Idempotenz & Crash-/Concurrency-Sicherheit: der Backfill leitet je Quelle einen stabilen Herkunfts-Schlüssel ab (traeger_typ + traeger_id + quelle='backfill') und erzwingt Eindeutigkeit in der DB (UNIQUE-Index über diesen Schlüssel + INSERT … ON CONFLICT DO NOTHING/Upsert bzw. transaktionaler Claim) — nicht über ein nachgelagertes "erledigt"-Flag. So kann weder ein Absturz zwischen Insert und Markierung noch ein nebenläufiger Zweit-Lauf doppelte Bankkonto-Zeilen erzeugen (dasselbe Muster wie der MED-D-179-Backfill: UNIQUE-Index + Catch-Retry + atomarer db.batch). Tests decken abgebrochenen (Insert ohne Marker) und nebenläufigen (zwei parallele Läufe) Backfill ab. MED-OP-MIGRATE-1 gilt hier nur für die Deploy-Ordnung (Migration + Code im selben Deploy, kein Zwischenzustand) — die Backfill-Idempotenz selbst trägt die DB-Eindeutigkeit, nicht der Migrate-Runner.
  • Abnahme: (1) kein Alt-IBAN-Wert ohne zugehöriges Konto (keine Waise); (2) jedes Alt-Feld ist als Konto auffindbar; (3) leere Alt-Felder erzeugen kein Konto; (4) jedes neue Konto startet mit Prüfstatus neu und sepa_gueltig=false; (5) identische IBANs an verschiedenen Trägern/Kontexten bleiben getrennte Konten (keine falsche Dedup); (6) Doppel- und Crash-/Wiederholläufe erzeugen keine Duplikate (Idempotenz, DB-erzwungen); (7) wrangler dev-Lauf gegen eine D1-Kopie zeigt Migration + Backfill grün, Alt-Felder noch lesbar. Bank-PII bleibt G-5/G-6-minimal; Verschlüsselung/Retention = MED-KB-6.

4. Neue Komponenten (Detail: akte-patterns.md §2)​

Status (2026-07-23): alle 10 Komponenten gebaut ✅ — StatusSlider/RequirementCheckbox/DocumentRow (S2) · Overlay-Shell/LifecycleRing (S1) · BankRow (S3b) · VersionedField (S4) · Self-Service-Karte (S4, MED-D-170) · UnterschriftenAssistent (S5) · TaskCard (S6). Damit ist MED-OP-AKTE-2 vollständig.

Pixel-Fidelity-Abnahme (v0.99.13, MED-D-219): nach dem Import der Design-Rohartefakte (MED-D-218, docs/design/akten-cockpit-handoff/) wurde die Implementierung Pixel-für-Pixel gegen die .dc.html + akte-patterns.md §2 + Screenshots 01–17 abgeglichen. Behoben (8): BankRow-Swipe/Peek auf die Design-Motion-Kurve cubic-bezier(.22,1,.36,1) (statt ease) + Peek-Plateau −26px/Delay .6s; IBAN .8rem; SEPA-Pill „ohne gültiges SEPA" in Amber; dezentes „‹"-Wisch-Chevron; Assistent-Overlay 720px/z-70 (via neue [breite]/[erhoeht]-Inputs der Shell); Signaturniveau-Default SES (§2.5); VersionedField-Toggle als „⟲ N frühere Werte"-Text-Link statt „vN"-Pill (§2.7). Bewusste, dokumentierte Divergenzen (kein Fehler): Scrim nutzt den World-2-Token --overlay statt des Prototyp- Literals rgba(10,14,12,.45) (Token-Disziplin ist im Handoff vorgeschrieben); BankRow-Swipe committet direkt statt Zwei-Stufen-Reveal (bewusste UX-Entscheidung, tastaturfähig); DocumentRow-Send-Aktionen („versendet"/„Erinnern"/„Signiert hochladen") + AD-008/AD-009-Formular-Rücklauf kommen mit der echten DocuSign-Anbindung (OP-SIGN-1; heute UI-Mapping gegen die Fakes); Assistent-„(Demo)"-Wortlaut ist bewusst (MED-KB-5). (Der frühere read-only-Stand des Stammdaten-Overlays ist überholt — seit MED-D-241 sind die Stammdaten direkt editierbar, die MED-D-147-Sperre ist damit abgelöst.)

StatusSlider (2.1) · RequirementCheckbox + Inaktiv-Trenner (2.2) · DocumentRow-Zustandsmaschine (2.3) · Overlay-Shell (2.4) · UnterschriftenAssistent (2.5) · BankRow + Swipe-to-Archive (2.6) · VersionedField + Versions-Pille (2.7) · Self-Service-Karte (2.8) · TaskCard (2.9) · LifecycleRing + TimerCard (2.10). Alle Maße/Tokens verbindlich aus akte-patterns.md; ausschließlich vorhandene World-2-Tokens (--bg --panel --card --chip --bd --bd2 --text --mut --faint --accent --accentInk --green --amber --red --selBg --selBd --shadow --overlay), keine neuen Farben, Icons als Inline-Line-SVG.

5. Zustandsmodelle & Enum-Angleichung (Detail: akte-patterns.md §1/§4)​

  • Dokumentstatus (Slider, vom Berater): Fehlt → Erhalten → Geprüft + Systemflags versendet ("wartet auf Signatur"), abgelaufen (Gültigkeitsdatum überschritten ⇒ Auto-Rückfall auf Fehlt, kein 4. Slider- Wert), nicht_erforderlich. Angleichung an das bestehende angefordert/erhalten/geprüft/abgelaufen/entfällt (Server) — G-3-Wording führt (Fehlt statt angefordert im UI; nie "Nötig"/"Da").
  • Konto: Prüfstatus neu → geprüft → archiviert getrennt von SEPA (SEPA gültig / ohne gültiges SEPA); je Konto Inhaber + Zeichnungsberechtigung.
  • Stammdaten: feld-versioniert, append-only, Quelle je Version (MED-D-179).
  • Append-only überall: das Verb "löschen" existiert im UI nicht (Archivieren statt Löschen, G-4).
  • Fortschritt zählt nur Erforderliches; 100 % muss erreichbar sein.

6. Entscheidungen, Compliance & Flags​

  • MED-D-188 (dieser Plan): volles Programm dokumentiert; Slices S1–S6; die drei Nutzer-Entscheidungen (Plan-first · Assistent-gegen-Fakes · Bank-1:n-jetzt) sind verbindlich eingebaut.
  • eIDAS/E-Signatur (OP-SIGN-1, DE/AT/CH): der Assistent bietet SES/AES/QES je Dokumenttyp an — das gewählte Niveau ist rechtswirkungs-abhängig zu begründen; AES/QES verlangen zusätzliche Identifikation (ID-Check). Schweiz: ZertES. Der Assistent bleibt zunächst UI gegen Fake-Provider (MED-KB-5); echte DocuSign/PandaDoc-Adapter + E-Mail-Versand (OP-DM-8) sind der spätere, reale Einbau. Beim Bau sichtbar halten, dass Versand/Signatur noch Attrappe ist (kein stiller Echt-Eindruck).
  • Datenschutz (G-5/G-6): IBAN/Bankdaten sind Bank-PII (MED-D-71). Das neue 1:n-Bankkonten-Modell persistiert je Konto minimal Nötiges; Verschlüsselung/Retention der sensiblen Historie bleibt MED-KB-6.
  • Weiche Validierung (MED-OP-VALID-1): überall — Freitext geht durch, Formatvorschlag amber statt Fehler.
  • Golden Rule / Zero Trust: der interne Mandant bleibt hinter Cloudflare Access; keine neue öffentliche Strecke.

7. Offene Punkte & Bezug​

  • MED-OP-AKTE-2 (5-Reiter-IA, Basis-Default) wird von S1 eingelöst; dieser Plan erweitert es zum vollen Programm (S1–S6).
  • Praxen als eigener Reiter vs. Sektion im Basis-/Stammdaten-Bereich (Screen 06) — beim Bau von S1 gegen Akten-Cockpit 1a (Detail).dc.html final ablesen; Standard hier: eigener Reiter.
  • Sammel-Umschlag (eine Signatur-Sitzung für mehrere Dokumente) — Datenmodell-Frage beim Assistenten (S5): ein Envelope über n Dokumente; gegen die Fake-Provider zunächst als Gruppierung abbilden.
  • Detail-Fortschritt/Status je Slice: HANDOFF.md §4 (MED-OP-AKTE-2) + je PR CHANGELOG/Decision-Log.