195 lines
12 KiB
Markdown
195 lines
12 KiB
Markdown
<!-- 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
|