Mandant-Struktur — Cockpit-Mandant-Ansicht (D-41, Cockpit-Redesign MED-D-156)

Terminologie-Hinweis (MED-D-277): Der Begriff „Akte" ist in App und UI-Sprache durch „Mandant" ersetzt (die Detailsicht heißt jetzt Mandant-Ansicht/Mandant-Druckansicht). Dieses Dokument beschreibt dieselbe Struktur; die Prosa nutzt durchgängig „Mandant" (Doku-Sweep MED-OP-DOCS-2 abgeschlossen, MED-D-278) — nur der Dateiname trägt den Alt-Begriff bewusst weiter (ein Rename bräche die Historie-Links aus den append-only Logs). Der Programmname „Akten-Cockpit-Redesign" und das Fachwort „Aktenreife" bleiben bewusst bestehen.

Kurz: Die Mandant-Ansicht (UC-6, True North #3) ist ein Vollbild-3-Spalten-Cockpit: links die Person-Rail (Lebenszyklus + Sprung-Navigation), in der Mitte ein Arbeitsbereich mit sechs Registern (Übersicht · Mandate · Dokumente · Fristen & Aufgaben · Stammdaten & Onboarding · Zeiterfassung), rechts die Kontext-Rail (Timer · Aktenreife · letzte Aktivität). Die Register sind arbeits-, nicht prozessphasen-gegliedert — die frühere "Register = Prozessphasen"-Achse ist mit der Prozessphase selbst entfallen (MED-D-151). Die Aktenreife bleibt das strukturierte, abgeleitete Modell hinter True North #3, jetzt Lifecycle-stufen- statt phasen-zugeordnet.

Prozess-Kontext: Wie die Achsen (Lifecycle-Status der Person · Auftrag-Status je Beratungsauftrag) zueinander stehen und wie Dokumente & Unterschriften als quer-liegende Achse geführt werden, steht in Prozessmodell.md (MED-D-79/MED-D-151) — die autoritative Prozess-Landkarte. Die Register-Achse "Prozessphase" der ersten Mandant-Ansicht ist dort abgelöst.

Laufzeit-Topologie & SBOM: dieses Doc beschreibt die UX-/IA-Struktur des Mandanten; die technische Runtime-Sicht (Worker · D1 · R2 · NextCloud · Signatur · CRM) + die SBOM-Fundstelle stehen kanonisch in Architektur-Uebersicht.md (nicht hier dupliziert).

Geplanter Umbau: dieser 6-Reiter-Stand wird durch das Akten-Cockpit-Redesign (Handoff "Akten- Cockpit 1a (Detail)", MED-D-188) abgelöst — Ziel-IA = 5 Reiter (Basis-Informationen default) + 4 Overlays, zehn neue Komponenten, Slices S1-S6. Programm & Slice-Plan: Akten-Cockpit-Redesign.md. Dieses Doc bleibt der Ist-Stand, bis S1 gebaut ist.

1. Motivation & Werdegang

Die erste Mandant-Ansicht war nach System-Modul sortiert — ein langer Scroll aus ~10 gleichrangigen Karten (Stammdaten · Praxen · Onboarding · Dokumente · Unterschriften · Beratungsdoku · Dokumentgenerierung · Leistungszeit · Wiedervorlagen · Audit). Das beantwortet True North #1 ("Wo steht der Kunde?") gerade nicht auf einen Blick.

Die zweite Fassung (D-41) gliederte die Module nach Prozessphase (Erstkontakt → Onboarding → Beratung → Unterschrift → Betreuung). Diese Phasen-Achse ist inzwischen zweifach überholt:

• MED-D-95 / Beratungsaufträge: die feine Granularität (beratung/unterschrift/betreuung) lebt heute je Beratungsauftrag (AUFTRAG_STATUS, domain/auftrag-reife.ts) — eine Person kann mehrere Produkte gleichzeitig in unterschiedlichen Stadien haben, was eine einzige Personen-Prozessphase nie abbilden konnte.
• MED-D-151 / Prozessphase entfernt: Mandant.prozessphase / PROZESS_PHASE sind komplett entfallen; die grobe, personenbezogene Achse ist der Lifecycle-Status (lead · onboarding · aktiv · ruhend · archiviert).

Die aktuelle Mandant-Ansicht (Cockpit-Redesign, MED-D-156) ist daher arbeits- statt phasen-gegliedert: sechs Register, die sich an der täglichen Arbeit orientieren, im dunklen Cockpit-Look der übrigen App.

2. Layout — Vollbild-3-Spalten-Cockpit

Für /mandant/:id weicht der globale App-Header dem akte-eigenen mw-header (Marke · "Cockpit › {{ Name }}"-Breadcrumb · Lebenszyklus-Status-Pill · Suche · User-Chip) — derselbe Vollbild-Mechanismus wie das Leitstand-Cockpit. Darunter drei Spalten:

Spalte	Inhalt	True North
Person-Rail (links, mw-rail)	Anzeigename · klickbarer Lebenszyklus-Pill (öffnet den Status-Wechsel mit Guard/409/Undo) · Sprung-Navigation zu Beratungsmandaten nach Auftrag-Status	① Wo steht der Kunde?
Arbeitsbereich (Mitte, mw-scroll)	die sechs Register (§3), Register-Leiste als mw-seg	alle drei
Kontext-Rail (rechts, mw-rail)	Live-Timer (Zeiterfassung, D-49) · Aktenreife (Score + "N blockieren die Aktenreife") · letzte Aktivität (Verlauf-Auszug, eager geladen) + "Ganzen Verlauf öffnen →"	② fällig · ③ vollständig

Unter 820 px klappt die Kontext-Rail zu einem Bottom-Sheet ("Kontext ↑").

3. Register (Arbeitsbereich)

Sechs Register, frei umschaltbar; Übersicht ist der Standard-Tab (aktiv = signal('uebersicht')). Die Register sind ein freies String-Signal — Sprungziele aus Aktenreife/nächsten Schritten setzen es direkt (waehleReg(key), gemäß SPRUNGZIEL_REGISTER → einer der sechs Reiter). Denselben waehleReg-Mechanismus nutzt der Verlauf-Link der Kontext-Rail, um das nicht als Reiter geführte audit zu setzen (s. u.) — audit ist also über die Sidebar erreichbar, aber kein Aktenreife-Sprungziel.

Register (key)	Inhalt (Module)	Aktenreife-Beitrag
Übersicht (uebersicht)	"Jetzt dran" (nächste Schritte) · Vorschau Mandate/Dokumente/Unterschriften — kuratierter Einstieg, kein eigener State	— (fasst nur zusammen)
Mandate (auftraege)	Beratungsaufträge (R6/MED-D-95) mit Status + Reife je Auftrag · inline-Beratungsdoku · Dentmarking-Karte	Protokolle vollständig & freigegeben (je Auftrag)
Dokumente (dokumente)	angeforderte/abgelegte Dokumente (R3) · Dokument-Erzeugung (R12) · Signatur-Vorgänge (R4) — ein quer-liegendes Ledger (MED-D-80)	fehlende Belege · offene Signaturen (Stufe onboarding)
Fristen & Aufgaben (wiedervorlagen, Stufe aktiv)	Wiedervorlagen (R5) · Jahrescheck (Playbook)	offene Wiedervorlagen (Hinweis, kein Blocker)
Stammdaten & Onboarding (stammdaten, Stufe onboarding)	Stammdaten (R1) · Praxen/Objekte · CRM-Link · Onboarding-Items (R2)	Pflicht-Items erledigt · Stammdaten vorhanden
Zeiterfassung (leistung)	Leistungszeit-Ledger (R13) · Abrechnung (SevDesk, OP-INVOICE-1)	— (abrechenbare Doku, kein Reife-Gate)

Nicht als Reiter geführt:

• Verlauf / Audit (audit, R8) ist bewusst kein Nav-Reiter, sondern nur über den Link "Ganzen Verlauf öffnen →" in der Kontext-Rail erreichbar (waehleReg('audit')) — der Nachweis über alle Stufen, nicht der tägliche Arbeitsweg.
• Erstkontakt (frühere Phase) ist in Stammdaten & Onboarding aufgegangen.

Dokumente & Unterschriften quer (MED-D-80). Dokumente entstehen stufen-übergreifend (Eigentümer- Vorgabe) → ein Ledger über R3/R12/R4 im Register Dokumente. Die Aktenreife-Zuordnung bleibt stufengenau (fehlende Belege und offene Signaturen gaten onboarding); nur die Anzeige liegt quer.

Zeiterfassung (D-49, MED-D-172). In der Kontext-Rail läuft ein Live-Timer (Stoppuhr HH:MM:SS + "Was wurde getan?"), pausier-/fortsetz-/überschreibbar; "Zeit buchen" (Kommentar Pflicht) schreibt gerundete Minuten ins Leistungszeit-Ledger (R13). Seit MED-D-172 ist der aktive Timer ein serverseitiger Zustand je Benutzer (nicht mehr je Browser-Tab). Die Leistungszeit trägt kein Aktenreife-Gate (abrechenbare Doku ≠ Abschluss-Hindernis).

4. Aktenreife-Datenmodell (server/src/domain/aktenreife.ts)

Rein abgeleitet (G-2), nichts gespeichert. Ersetzt das frühere offenePunkte: string[]; seit MED-D-151 Lifecycle-stufen- statt prozessphasen-zugeordnet:

export type OffenSchwere = 'blockierend' | 'wichtig' | 'hinweis';
export type AktenreifeKategorie = 'onboarding' | 'dokument' | 'unterschrift' | 'beratungsdoku' | 'wiedervorlage';

export interface AktenreifePunkt {
  kategorie: AktenreifeKategorie;
  stufe: LifecycleStatus;     // gruppiert den Mangel nach Lifecycle-Stufe (war: phase: ProzessPhase)
  schwere: OffenSchwere;      // nur 'blockierend' verhindert Aktenreife
  text: string;               // sprechend (G-3)
  anzahl: number;
  sprungziel: string | null;  // Anker im Register zur Behebung
}
export interface StufeReife {  // war: PhaseReife
  stufe: LifecycleStatus;
  status: 'abgeschlossen' | 'aktiv' | 'offen';
  offen: number;              // blockierende Punkte dieser Stufe
  hinweis: number;            // fällige, aber nicht blockierende Positionen (MED-OP-REG-1)
}
export interface Aktenreife { reif: boolean; score: number; punkte: AktenreifePunkt[]; jeStufe: StufeReife[]; }

Alle vor-aktiv-Mängel (Onboarding · fehlende Dokumente · Beratungsprotokolle · offene Unterschriften) fallen in die Stufe onboarding; offene Wiedervorlagen sind ein hinweis in Stufe aktiv. jeStufe läuft über die geführte Spine (lead · onboarding · aktiv); ruhend/archiviert sind administrativ (kein Fortschritt).

Kernentscheidungen (D-41)

• Schwere trennt Abschluss von Betrieb. reif = kein blockierender Punkt. Offene Wiedervorlagen sind hinweis (fällig, aber kein Abschluss-Hindernis) — behebt das frühere "nie aktenreif"-Problem (das Jahrescheck-Playbook legt eine 365-Tage-Wiedervorlage an, die den Mandanten sonst dauerhaft blockiert hätte).
• score ist eine transparente Reife-Heuristik (100 minus gewichtete Abzüge: blockierend 25 · wichtig 10 · hinweis 4, auf 0..100 geklemmt) — reif ist die autoritative Aussage, nicht der Score.
• jeStufe ist ein echtes Server-Aggregat je Stufe (Status + blockierende Punkte). Es speist das Leitstand-Band (GET /api/aktenreife, D-43) statt eines Client-Proxys.

Anzeige-Hinweis: Die frühere Fassung zeigte die Aktenreife als Reife-Ring im Aktendeckel. Mit dem Cockpit-Redesign (MED-D-156) ist der Ring entfallen — die Aktenreife erscheint als Score + Klartext ("N blockieren die Aktenreife") in der Kontext-Rail. Das Datenmodell oben bleibt davon unberührt (MED-OP-REIFE-1).

5. Verhaltensänderung (bewusst)

Gegenüber der modul-gestapelten Ur-Fassung ändert sich eine Reife-Semantik: eine offene Wiedervorlage macht einen Mandanten nicht mehr "nicht aktenreif" (sie ist ein Hinweis, kein Blocker). Alle anderen Gates (Onboarding vollständig · keine fehlenden Dokumente · keine offene Signatur · Beratungsprotokolle vollständig & freigegeben) bleiben blockierend.

6. Offene Punkte

• OP-AKTE-1 ✅ erledigt (0.40.0, D-43): Das Leitstand-Band nutzt das autoritative Server-Aggregat GET /api/aktenreife (service.aktenreifeUebersicht() → { reif, score, blockierend } je Mandant, geteilter Helper baueAktenreifeInput) statt des Client-Proxys.
• Stammdaten-Gate: Das Register Stammdaten & Onboarding trägt für die reinen Stammdaten derzeit keinen eigenen Aktenreife-Blocker (Pflichtfelder je Mandant-Typ noch nicht definiert) — Kandidat, sobald der Stammdaten-Pflichtkatalog steht.