<!-- status: plan -->
<!-- started: 2026-05-14 -->
<!-- component: gateway | frontend-nyla | platform -->

# Lawyer Feature (Mandatsvorbereitung + Dashboards)

## Beschreibung und Kontext

Im Sales-Meeting mit David Vasella (WalderWyss) am 13.05.2026 hat sich ein klares Bild ergeben: Anwaltskanzleien arbeiten mit grossen Mengen **nicht human-readable Daten** (PDFs, E-Mails, frühere Mandate, Konflikt-Checks, KYC/AML, Buchungen). Zwischen internen Prozessen und der Mandantsbesprechung entsteht ein Overhead, den **Copilot nicht löst**. Existierende Branchen-Tools (Harvey.ai ~500 USD p/m/user, Legora, ClientFlex) sind teuer und decken die Anforderungen nicht voll ab. WW hat **kein CRM**.

PORTA hat bereits alle Bausteine: Workspace, Knowledge/RAG, Konnektoren, Neutralisierung, Private LLM. Das `lawyer`-Feature bündelt diese Bausteine zu einem **opinionated UI für Anwälte**: ein Feature-Modul mit zwei Hauptseiten – **Dashboards** (HR / Business-Client / IT) und **Matter Preparation** (Mandatsvorbereitung in 5 Minuten).

Business-Treiber:
- WW konkretes Sales-Asset (HTML-Präsentation und später Live-Demo).
- Eigene Use Cases für Homepage (`www.poweron.swiss`) – Sales-Story «echtes Produkt».
- Investor-Pitch (Founderful via Dominic + Philipp) braucht klare vertikale Geschichte.
- Wiederverwendbar für jede Anwaltskanzlei und mit Anpassung für Treuhand/Audit/Steuerberatung.

## Fokus und kritische Details

- **Berufsgeheimnis (StGB Art. 321)** – Mandantsdaten dürfen den Mandanten-Tenant nicht verlassen. Neutralisierung + Private LLM **zwingend** für jeden Pfad, der LLM nutzt (`wiki/b-reference/platform/neutralization.md`).
- RBAC korrekt: feature-instance roles, **NICHT** mit mandate roles vermischen (`.cursor/rules/rbac-role-separation.mdc`).
- Daten kommen aus heterogenen Quellen: Document Management System (DMS), E-Mail-Archiv, Zeiterfassung, Buchhaltung, KYC/AML, Konflikt-Check-DB. Konnektor-Pflege ist der **harte Teil**, nicht das UI.
- Mockup-Daten in der WW-Präsentation müssen klar als **synthetic** markiert sein.

## Ziel und Nicht-Ziele

- **Ziel:** Feature-Modul `lawyer` mit:
  - Dashboard-Seite mit Tabs pro Funktion (HR, Business/Client, IT, optional Finance).
  - Matter-Preparation-Seite: Anwalt definiert Kontext (Mandant, Matter, Meeting-Ziel, Datum), System aggregiert Quellen, AI-Agent generiert Briefing (Kerndaten, Risiken, Deadlines, offene Punkte, Agenda-Vorschlag).
- **Ziel:** Wiederverwendung der bestehenden PORTA-Bausteine (Workspace, Knowledge, Konnektoren, Neutralisierung, Private LLM).
- **Ziel:** Standard-Konnektoren für DMS (SharePoint, iManage), E-Mail (Outlook/Exchange), KYC-/Konflikt-Datenquellen, Buchhaltung (im ersten Schritt einer pro Kategorie).
- **Explizit NICHT:** vollständiges Practice-Management-System ersetzen (kein Time-Tracking-Replacement, kein Billing-System).
- **Explizit NICHT:** generische Vertragsanalyse / Drafting (das machen Harvey/Legora besser, wir sind komplementär).
- **Explizit NICHT:** eigene KYC/AML-Datenquelle aufbauen – wir konsumieren bestehende.

## Betroffene Module

- Gateway: 
  - Neues Feature-Modul `gateway/modules/features/lawyer/` mit `mainLawyer.py`, `datamodelLawyer.py`, `interfaceLawyer.py`, `routeFeatureLawyer*.py`.
  - Workflow-Method `gateway/modules/workflows/methods/methodLawyer/` für `lawyer.prepareMatter`, `lawyer.queryData`.
  - Konnektoren: prüfen, welche bestehen (`gateway/modules/connectors/`), welche neu (DMS, KYC).
- Frontend: 
  - Neue Komponenten `frontend_nyla/src/components/Lawyer/`.
  - Dashboard-View mit Tabs.
  - Matter-Preparation-View (analog Workspace, opinionated).
- DB-Migration: ja – neue Tabellen `LawyerMatter`, `LawyerPreparation`, `LawyerDashboardSnapshot`, `LawyerKpi`.
- Andere Komponenten: Knowledge/RAG (bestehend), Neutralisierung (bestehend), Private LLM (bestehend), Workspace-Agent-Tools (Erweiterung).

## Entscheidungen

| Datum | Entscheidung | Begründung |
|-------|-------------|------------|
| 2026-05-14 | Feature-Code `lawyer` (analog `trustee`, `realEstate`) | Konsistenz mit bestehenden Feature-Modulen |
| 2026-05-14 | Template-Rollen `lawyer-admin`, `lawyer-user`, `lawyer-viewer` | RBAC-Regel: feature-instance roles, mandate-getrennt |
| 2026-05-14 | Matter-Preparation nutzt bestehenden Workspace-Agent + neue opinionated Tool-Chain | Wiederverwendung statt Neubau |
| 2026-05-14 | Dashboards starten als read-only Aggregations-Views auf Konnektor-Daten | Schneller Time-to-Demo, Schreibpfad später |
| 2026-05-14 | Sprache UI primär Englisch | WW-Audience Management Board, Investor-tauglich; DE-Lokalisierung Phase 2 |

## Use Cases (User Stories)

### UC-1: Matter Preparation in 5 Minutes

**Given** ein Anwalt hat morgen ein Klienten-Meeting für Matter `M-2024-0042` (M&A-Transaktion).
**When** er auf der Matter-Preparation-Seite den Matter und das Meeting-Ziel eingibt ("Statusbesprechung Due Diligence, offene Punkte"),
**Then** sammelt das System innerhalb von ~60 Sekunden aus DMS (alle Dokumente zu M-2024-0042), E-Mails (letzte 30 Tage), Zeiterfassung (WIP + Deadlines), KYC/AML (Aktueller Status), Konflikt-Check.
**And** generiert ein strukturiertes Briefing:
  - Kerndaten Mandant + Matter
  - Stand Due Diligence (Dokumente, offene Punkte)
  - Risiken & Deadlines
  - Offene Aktionen seit letzter Besprechung
  - Vorschlag Agenda
  - Quellenliste (jeder Punkt mit Link zur Quelle)
**And** alle Mandantsdaten werden neutralisiert, bevor sie das LLM erreichen.

### UC-2: Partner-Dashboard

**Given** ein Partner möchte vor der Wochensitzung den Stand seines Teams sehen.
**When** er die Dashboard-Seite öffnet,
**Then** sieht er HR-KPIs (Billable Hours, Utilization, Realization) für sein Team, Top-3-Risk-Matters, AR Aging.
**And** kann pro KPI in die Detailansicht drillen (Drilldown via Konnektor-Live-Query).

### UC-3: IT/Compliance-Dashboard

**Given** der IT-Leiter braucht für ein Audit-Meeting den Compliance-Status.
**When** er den IT-Tab öffnet,
**Then** sieht er Uptime, Security-Incidents (letzte 90 Tage), Patch-Status, KYC/AML-Backlog, Conflict-Check-SLAs.

## Datenmodell-Skizze

| Modell | Felder (Kern) | Kommentar |
|--------|---------------|-----------|
| `LawyerMatter` | id, featureInstanceId, mandateCode, clientName, matterType, openedAt, status, leadLawyerUserId | Mandate spiegeln, nicht zweimal halten |
| `LawyerPreparation` | id, matterId, requestedBy, meetingGoal, createdAt, briefingJson, sourceRefs | Persistiert das generierte Briefing für Audit + Wiederverwendung |
| `LawyerDashboardSnapshot` | id, featureInstanceId, dashboardType, periodStart, periodEnd, dataJson, generatedAt | Cache für Dashboard-Daten, Refresh periodisch |
| `LawyerKpi` | id, featureInstanceId, kpiCode, label, formula, lastValue, lastValueAt, dashboardType | Konfigurierbare KPI-Definitionen pro Tenant |
| `LawyerSourceMap` | id, featureInstanceId, sourceType, connectorRef, mappingJson | Welcher Konnektor liefert welche Daten in welche KPI |

## Actions (Workflow-Method)

| Action | Eingabe | Output | Zweck |
|--------|---------|--------|-------|
| `lawyer.prepareMatter` | featureInstanceId, matterId, meetingGoal, lookbackDays | LawyerPreparation (briefingJson + sourceRefs) | Sammelt aus Quellen, neutralisiert, generiert Briefing via Workspace-Agent |
| `lawyer.refreshDashboard` | featureInstanceId, dashboardType, periodStart, periodEnd | LawyerDashboardSnapshot | Re-aggregiert KPI-Werte aus Konnektoren |
| `lawyer.queryData` | featureInstanceId, freie Filter | ActionResult mit Query-Resultat | Read-only Zugriff für AI-Agent (analog `trustee.queryData`) |

## UI-Skizze

```
/lawyer/<featureInstanceId>/
  ├── dashboards/
  │   ├── hr            (Tab)
  │   ├── business      (Tab)
  │   ├── it            (Tab)
  │   └── finance       (Tab, optional)
  └── matter-preparation/
      ├── <list of recent matters>
      └── <matterId>/
          ├── briefing       (generated)
          ├── sources        (drilldown)
          └── agenda-export  (PDF/Markdown)
```

## RBAC-Mapping

- Template-Rollen (Feature-Code `lawyer`, `mandateId=NULL`, `isSystemRole=False`):
  - `lawyer-admin` – Feature-Instance-Admin, Konnektor-Konfig, KPI-Definition.
  - `lawyer-user` – Anwalt, Matter-Preparation, Dashboard read.
  - `lawyer-viewer` – Read-only, z. B. Management Board.
- Nutzung: `FeatureAccessRole` mit `featureCode=lawyer, featureInstanceId=<id>, mandateId=<id>, roleId=<>`.
- Strikt getrennt von Mandate-Rollen (`admin`, `user`, `viewer`).

## Umsetzungs-Checkliste

- [ ] Datenmodell (`datamodelLawyer.py`) – 5 Modelle + PowerOnModel-Basis
- [ ] Migration: Auto-Schema reicht? (analog `trustee`)
- [ ] Feature-Modul (`mainLawyer.py`) inkl. Template-Rollen-Definition
- [ ] Workflow-Method `methodLawyer/` mit 3 Actions
- [ ] Konnektoren-Inventur: was haben wir, was fehlt
  - [ ] DMS-Konnektor (SharePoint vorhanden, iManage neu?)
  - [ ] E-Mail-Konnektor (Outlook/Exchange vorhanden?)
  - [ ] Zeiterfassung (mandantenabhängig, Anbindung über generisches Schema)
  - [ ] KYC/AML (extern, API-Anbindung mandantenspezifisch)
  - [ ] Konflikt-Check (intern WW-System – API klären)
- [ ] Routes (`routeFeatureLawyer.py`)
- [ ] Frontend-Komponenten (`Lawyer/Dashboard`, `Lawyer/MatterPreparation`)
- [ ] RBAC: Template-Rollen registrieren (siehe `.cursor/rules/rbac-role-separation.mdc`)
- [ ] Neutralisierung: `prepareMatter`-Action zwingend mit `PrivateLLM`-Pfad für sensitive Daten
- [ ] Navigation (Gateway → Frontend) – Feature-Eintrag
- [ ] Billing-Impact: prüfen (analog andere Features – pro Feature-Instance, Subscription-Capacity)
- [ ] Mockup-Daten-Set (synthetic) für WW-Präsentation + Demo
- [ ] Demo-Login-Mandant einrichten (für Live-Demo nach Präsentation)

## Akzeptanzkriterien

| # | Kriterium (Given-When-Then) | Prio |
|---|---------------------------|------|
| 1 | Given Anwalt mit `lawyer-user`-Rolle, When er Matter-Preparation für offenen Matter triggert, Then erhält er in <90s strukturiertes Briefing mit ≥3 Quellen | must |
| 2 | Given sensitive Mandantsdaten (Namen, Beträge), When `lawyer.prepareMatter` läuft, Then werden alle PII vor LLM-Call neutralisiert (Audit-Trail in Neutralization-Log) | must |
| 3 | Given User mit `lawyer-viewer`, When er Dashboard öffnet, Then sieht er KPIs read-only ohne Schreib-Buttons | must |
| 4 | Given User mit Mandate-Rolle `admin` aber ohne `lawyer-*`, When er Lawyer-Feature öffnet, Then Access Denied | must |
| 5 | Given Dashboard-Konnektor offline, When `refreshDashboard` läuft, Then Snapshot zeigt Fehlerstatus, Frontend zeigt klare Meldung statt leerer Werte | should |
| 6 | Given Briefing generiert, When Anwalt es exportiert, Then PDF/Markdown mit Quellenliste und «synthetic data» Wasserzeichen (im Demo-Mandanten) | should |

## Testplan

| ID | AC | Art | Automatisiert | Repo-Pfad | Status |
|----|----|-----|--------------|-----------|--------|
| T1 | 1 | api | ja | gateway/tests/test_lawyer_prepare_matter.py | pending |
| T2 | 2 | integration | ja | gateway/tests/test_lawyer_neutralization.py | pending |
| T3 | 3,4 | api | ja | gateway/tests/test_lawyer_rbac.py | pending |
| T4 | 5 | integration | ja | gateway/tests/test_lawyer_dashboard_refresh.py | pending |
| T5 | 1,6 | e2e | manuell | – | pending |

## Demo-Asset Plan (für WW-Präsentation)

- Synthetic Matter `M-DEMO-001` (M&A) mit fiktiven Dokumenten, E-Mails, Zeiteinträgen.
- Briefing-Output statisch generiert und in `30-presentation/src/data/matter-preparation.json` ablegen, damit die HTML-Präsentation **ohne Backend** funktioniert.
- Wenn David Live-Demo will: gleichen Demo-Mandanten im PORTA-Demo-Tenant live verfügbar machen.

## Links

- WW-Kontext: `pamocreate/projects/poweron/customer-walderwyss/20-objectives/20260514-zusammenfassung-meeting-dv.md`
- WW-Präsentation: `pamocreate/projects/poweron/customer-walderwyss/30-presentation/`
- Bestehende Feature-Doku als Vorbild: `wiki/b-reference/gateway/features/trustee.md`
- Plattform-Bausteine: `wiki/b-reference/platform/neutralization.md`, `wiki/b-reference/platform/rbac.md`
- PR: – (noch nicht)
- Issue: – (noch nicht)

## Abschluss

- [ ] `b-reference/gateway/features/lawyer.md` als neue Kanon-Seite anlegen
- [ ] `TOPICS.md` Eintrag für Lawyer-Feature
- [ ] Dieses Dokument → `2-build/` → `3-validate/` → `4-done/`
- [ ] Eintrag in `c-work/_CHANGELOG.md` pro Phase