feat(roadmap): Querschnitt-Lücken + Unified Task System integriert

Querschnitt-Regeln:
- Graceful Shutdown / Connection Draining (B.15)
- Observability / trace_id-Korrelation (B.14)
- API Versioning Strategie (B.16)
- Cost Overrun Protection / Tenant Cost-Cap (B.17)
- Backup/DR Restore-Test (A-RESTORE)
- Concurrency / Race Conditions (E-IX-EVT, F-PERM, G-RUN)

Unified Task System (F.14):
- Task-Modell erweitern: polymorphe Assignees, Entity-Links, Subtasks, Dependencies
- Agent ↔ Task Integration (create_task, assign_to_agent, AgentSubtask→Task Migration)
- Task → Workstream (task_card Block-Typ)
- Task UI erweitern (Filter, Kanban, Assignment-Dropdown)
- Phase I: Task-basierter Handoff (I-WORK-HANDOFF)

+11 Tage Aufwand verteilt über 52 Wochen

PLATFORM_ROADMAP.md

@@ -265,6 +265,7 @@ Später — Advanced Autonomy/Automation nur bei echtem Bedarf
 | A-VERIFY | Installation, CI, E2E, Auth, Cross-Tenant, Worker verifizieren |
 | A-TEST | Test-Pipeline (8 Checks) ausführen — alle müssen grün sein |
 | A-PERF | Performance-Baseline messen (Response-Times, DB-Query-Counts) für spätere Vergleiche |
+| A-RESTORE | **Automatisierter Backup-Restore-Test** — bestehendes `backup_service.py` + `restore_test.sh` verifizieren und als ARQ-Cron-Job einrichten: Backup erstellen → in Test-DB restore → Schema/Row-Count validieren → Ergebnis loggen. Ein Backup das nie getestet wurde ist kein Backup |
 | A-DOC | `docs/test-strategy.md` aktualisieren mit verbindlicher Test-Pipeline |
 
 ---
@@ -465,7 +466,44 @@ Bestehende Resilience-Patterns (CircuitBreaker, `retry_db`, Outbox DLQ/Replay, P
 | B-ERR-PROP | **Error-Propagation-Konvention** — Plugin/Service → Core → API → Frontend → User. Technische Details (Tracebacks, interne Pfade) nur geloggt/monitoriert; dem User verständliche Nachricht mit `trace_id`. Im Plugin-Dev-Guide (B-PLUGIN-GUIDE) als Kapitel 22 dokumentieren | 0.5 Tage |
 | B-ERR-TEST | Tests: Error-Response-Format, Kategorisierung, WS-Error-Handling, Error-Propagation | 1 Tag |
 
-**Deliverables Phase B:** Zentraler LLM Client, zentraler Redis Pool, gemeinsamer File Storage, WebSocket Helpers, Event-System dokumentiert, Schema Authority definiert, schlanker Plugin-Guide, MiniApp-Contribution-Wiring, klarer Plugin-Frontend-Vertrag, gezieltes Rate-Limiting, Sensitive Data Boundary + AI/Data Exposure Policy, AIProvider-Compliance-Metadaten, konsistente Lifecycle-Hooks + relevante Domain-Outbox-Events, gemeinsamer Trigger-Kern, vollständige Notification→Message-Konsolidierung sowie systematische Error-Handling-Infrastruktur (einheitliches Response-Format, Error-Kategorisierung, WS-Error-Handling, Error-Propagation-Konvention).
+### B.14 Observability & trace_id-Korrelation
+
+Bestehendes `structlog` (JSON-Logging) und `monitoring.py` (Prometheus-Metriken) werden um systematische Request-/Trace-Korrelation ergänzt. Kein zweites Monitoring-System, sondern `trace_id`-Propagation durch alle Ebenen.
+
+| Task | Beschreibung | Aufwand |
+|------|-------------|---------|
+| B-OBS-TRACE | **trace_id-Propagation** — Request-ID wird pro API-Request erzeugt, im `structlog` contextvars gesetzt, in jeden Log-Eintrag eingebettet, an ARQ-Worker weitergereicht (ARQ `job_metadata`), in LLM-Client-Calls injiziert, in Error-Responses zurückgegeben. Frontend kann `trace_id` aus Response anzeigen/melden | 1 Tag |
+| B-OBS-LOG | **Strukturiertes Logging konsolidieren** — alle Module nutzen `structlog.get_logger()`, keine `logging.getLogger()` mehr. Log-Level konfigurierbar pro Modul. Sensitive Fields aus Logs filtern (wie Sensitive Data Boundary) | 0.5 Tage |
+| B-OBS-TEST | Tests: trace_id durch alle Ebenen korreliert, Sensitive Fields nicht in Logs | 0.5 Tage |
+
+### B.15 Graceful Shutdown & Connection Draining
+
+Bei Coolify-Deploy oder Worker-Restart dürfen laufende Requests, WebSocket-Connections und ARQ-Jobs nicht abrupt abgebrochen werden. Bestehende `lifespan` und `on_shutdown` werden um sauberes Draining ergänzt.
+
+| Task | Beschreibung | Aufwand |
+|------|-------------|---------|
+| B-SHUT-API | **API Graceful Shutdown** — SIGTERM-Handler: keine neuen Requests akzeptieren, in-flight Requests abschließen (Timeout 30s), dann sauber beenden. `lifespan` shutdown-Phase erweitern | 0.5 Tage |
+| B-SHUT-WS | **WebSocket Connection Draining** — bei Shutdown: WS-Clients über Reconnect-Hint informieren, Connections nach Grace-Period schließen. In B-WS Helpers integriert | 0.5 Tage |
+| B-SHUT-WORKER | **ARQ Worker Graceful Stop** — laufende Jobs abschließen oder Checkpoint setzen (WorkflowRun `status='paused'`), keine Jobs abrupt abbrechen. `on_shutdown` erweitern | 0.5 Tage |
+| B-SHUT-TEST | Tests: SIGTERM → in-flight Requests abschließen, WS drain, Worker checkpoint | 0.5 Tage |
+
+### B.16 API Versioning Strategie
+
+| Task | Beschreibung | Aufwand |
+|------|-------------|---------|
+| B-API-VER | **API Versioning Strategie** — `/api/v1` bleibt. Konvention dokumentieren: Breaking Changes → neue `/api/v2`-Router parallel, alte Routes deprecated für 1 Release, dann entfernt. Non-breaking Changes (neue Felder, neue Endpoints) innerhalb v1. Im Plugin-Dev-Guide ergänzen | 0.5 Tage |
+
+### B.17 Cost Overrun Protection (Tenant-weit)
+
+Bestehendes `budget_limit_usd` pro Agent-Definition schützt pro Agent-Run. Es fehlt ein Tenant-weites Cost-Cap das alle LLM-Calls (Agenten, Workflows, Search-Embeddings, Proactive) aggregiert.
+
+| Task | Beschreibung | Aufwand |
+|------|-------------|---------|
+| B-COST-CAP | **Tenant Cost-Cap** — `TenantSettings` um `llm_monthly_budget_usd` und `llm_hard_cutoff` ergänzen. Zentraler LLM-Client prüft vor jedem Call: Tenant-Monatskosten + Cost-Cap. Bei Überschreitung → Hard-Stop (nur noch kostenlose Calls) oder Alert. Cost-Tracking in Redis (inkrementell) | 1 Tag |
+| B-COST-ALERT | **Cost Alerts** — bei 50%/80%/100% des Tenant-Budgets → System-Message im Workstream + E-Mail an Admin. Konfigurierbar | 0.5 Tage |
+| B-COST-TEST | Tests: Cost-Cap greift, Alerts feuern, Hard-Stop blockiert LLM-Calls | 0.5 Tage |
+
+**Deliverables Phase B:** Zentraler LLM Client, zentraler Redis Pool, gemeinsamer File Storage, WebSocket Helpers, Event-System dokumentiert, Schema Authority definiert, schlanker Plugin-Guide, MiniApp-Contribution-Wiring, klarer Plugin-Frontend-Vertrag, gezieltes Rate-Limiting, Sensitive Data Boundary + AI/Data Exposure Policy, AIProvider-Compliance-Metadaten, konsistente Lifecycle-Hooks + relevante Domain-Outbox-Events, gemeinsamer Trigger-Kern, vollständige Notification→Message-Konsolidierung, systematische Error-Handling-Infrastruktur (einheitliches Response-Format, Error-Kategorisierung, WS-Error-Handling, Error-Propagation-Konvention), Observability/trace_id-Korrelation, Graceful Shutdown/Connection Draining, API-Versioning-Strategie und Tenant-weites Cost-Cap/Alerts.
 
 ---
 
@@ -621,7 +659,7 @@ Die spezifischen Suchen bleiben für gute Fach-UX erhalten, laufen technisch abe
 | E-FUSE | RRF Result-Fusion über alle Modi | 1 Tag |
 | E-LLM | LLM Query Understanding (Intent, Entities, Semantic Terms) — über zentralen LLM Client | 1 Tag |
 | E-PERM | Permission-aware Search (Tenant, RBAC, Visibility-Filter) | 1 Tag |
-| E-IX-EVT | Auto-Indexierung: Mutation → Outbox → Worker → Index aktualisieren. Ein Weg, nicht Hook + EventBus parallel. **Index-Fehler-Handling**: bei Embedding-LLM-Fehlern, pgvector-Errors oder Timeouts → Retry über Outbox-DLQ, Dead-Letter bei permanentem Fehler, Index-Konsistenz-Check. Kein stummes Fehlschlagen von Suchergebnissen | 2.5 Tage |
+| E-IX-EVT | Auto-Indexierung: Mutation → Outbox → Worker → Index aktualisieren. Ein Weg, nicht Hook + EventBus parallel. **Index-Fehler-Handling**: bei Embedding-LLM-Fehlern, pgvector-Errors oder Timeouts → Retry über Outbox-DLQ, Dead-Letter bei permanentem Fehler, Index-Konsistenz-Check. Kein stummes Fehlschlagen von Suchergebnissen. **Concurrency**: zwei Events die dasselbe Dokument indexieren → dedup über `entity_type+entity_id+version` Lock, kein verlorenes Update | 2.5 Tage |
 | E-IX-RE | Re-Indexierung: Batch-Reindex Kommando, Delete-Handling, Retry | 1 Tag |
 | E-DATA-LIFE | **Derived-Data Lifecycle für Search/Vector** — Correction/Delete/Erasure-Signal aktualisiert oder entfernt FTS-/Search-Dokumente und Embeddings reproduzierbar; Rebuild aus authoritative Quelle möglich. Retention-/Legal-Hold-Entscheidung bleibt fachlich konfiguriert | 1.5 Tage |
 | E-K-MAIL | Mail-spezifische Suche behalten, interne ILIKE-Logik aber auf `MailSearchProvider`/Unified Search Core umstellen | 1 Tag |
@@ -681,7 +719,7 @@ Kein vollständiger interner Chain-of-Thought; der Extended Trace ist ein expliz
 | F-TRANS | **AI Transparency** — Agent-/AI-Teilnehmer im Workstream und relevanten UIs eindeutig als AI kennzeichnen; generierte Inhalte können typisierte Herkunfts-/Kennzeichnungsmetadaten tragen | 0.5 Tage |
 | F-SKILL | **Kleiner Skill-Baustein** — `SkillDefinition`/Registry + `skill_definitions`-Plugin-Contribution (oder gleichwertig) mit Name/Beschreibung/Instructions, erlaubten Tool-IDs und optionaler Context-Policy. Skills sind Orchestrierungsmetadaten, **keine Rechtequelle**, kein `SkillRole`, kein zweites RBAC | 1.5 Tage |
 | F-TOOL | Tool-/Skill-Binding — Agent definiert, welche Tools und Skills er nutzen darf. Skills dürfen nur freigegebene Tools/Services orchestrieren und keine Permissions umgehen | 1 Tag |
-| F-PERM | Permission-Context: Agent agiert im Kontext eines Users/Run-as. RBAC/ABAC pro Tool-/Service-Aufruf, Visibility-Filter und EntityPermission. Effektiv: User/Run-as ∩ Agent ∩ Skill ∩ Tool. Aktuelle Rechte bei jedem Call neu prüfen | 2 Tage |
+| F-PERM | Permission-Context: Agent agiert im Kontext eines Users/Run-as. RBAC/ABAC pro Tool-/Service-Aufruf, Visibility-Filter und EntityPermission. Effektiv: User/Run-as ∩ Agent ∩ Skill ∩ Tool. Aktuelle Rechte bei jedem Call neu prüfen. **Concurrency**: zwei Agenten die dieselbe Entity mutieren → optimistisches Locking über `version`-Feld oder Row-Level Lock, kein verlorenes Update | 2.5 Tage |
 | F-PERM-VIS | User-Agent Visibility: User sehen nur Agenten die für sie freigeschaltet sind (`agents:read` + EntityPermission). Über bestehendes RBAC/ABAC | 1 Tag |
 | F-PERM-USE | User-Agent Usage: `agents:execute` Permission pro Agent | 0.5 Tage |
 | F-MEM | Memory-Integration — agent_memory Plugin | 1 Tag |
@@ -706,7 +744,21 @@ Kein vollständiger interner Chain-of-Thought; der Extended Trace ist ein expliz
 | F-TEST | Tests: ReAct-Loop, Tool-Calling, Permissions, Approval, Budget-Limits | 3 Tage |
 | F-DOC | `docs/api-documentation.md`, `docs/plugin-development-guide.md` (Agent-Kapitel) | 1 Tag |
 
-**Deliverables Phase F:** ReAct-Agenten auf vorhandener Agentenbasis, kleiner Skill-Baustein, Tool-/Skill-Calling, Permission-Modell (User/Run-as ∩ Agent ∩ Skill ∩ Tool), AI-Use-Case-/Transparency-Metadaten, Provider/Data-Policy-Enforcement, Standard+Extended Trace, LLM-Fehlerstrategie (Rate-Limit-Backoff, Provider-Failover, Timeout-Graceful-Stop), strukturiertes Tool-Error-Handling mit ErrorCategory, trigger-basierte Proaktivität, UI Control ohne Permission-Bypass, zentraler ApprovalRequest-Kern + Human-Oversight-Record, Workstream-Ausgabe, Agent UI und 4 Pre-Built Agenten.
+### F.14 Unified Task System
+
+Das bestehende Tasks-Plugin (713 Zeilen, nur `contact_id`, nur User-Assignment) wird zu einem **systemweiten Assignment-System** upgegradet. Kein zweites System, sondern das bestehende Tasks-Plugin das erwachsen wird. AI, Menschen, Gruppen und Workflows können Aufgaben erstellen, zugewiesen bekommen und mit jedem Objekt verknüpfen.
+
+| Task | Beschreibung | Aufwand |
+|------|-------------|---------|
+| F-TASK-MODEL | **Task-Modell erweitern** — `assignee_type` (user/agent/group) + `assignee_id` (polymorph), `entity_type` + `entity_id` (polymorph, wie EntityLink), `creator_type` (user/agent/workflow/system) + `creator_id`, `parent_task_id` (Self-Reference für Subtasks), `depends_on` (Task-Dependencies), `task_type` (todo/approval/follow_up/review), Lifecycle: open/in_progress/review/blocked/done/cancelled | 2 Tage |
+| F-TASK-API | **Task API erweitern** — bestehende Tasks-Routes um polymorphe Entity-Links, polymorphe Assignees, Subtasks, Dependencies und neue Lifecycle-Status ergänzen. Bestehende Contact-Tasks bleiben kompatibel | 1.5 Tage |
+| F-TASK-AGENT | **Agent ↔ Task Integration** — Agenten können Tasks erstellen (`create_task` Tool), Tasks zugewiesen bekommen (`assignee_type='agent'`), Task-Status aktualisieren und Tasks als Subtasks zerlegen. `AgentSubtask` wird zu `Task` mit `task_type='agent_subtask'` migriert | 1.5 Tage |
+| F-TASK-WORK | **Task → Workstream** — Tasks erscheinen als `task_card` Block-Typ im Communication-System: Titel, Assignee, Due-Date, Status, Entity-Deep-Link, Action-Buttons (Done/Reassign/Comment). Status-Änderungen posten Updates in den Workstream | 1 Tag |
+| F-TASK-UI | **Task UI erweitern** — Task-Liste mit Filter (nach Assignee, Entity, Status, Due-Date), Task-Detail mit Subtasks/Dependencies, Task-Board (Kanban-View optional), Task-Assignment-Dropdown (User/Agent/Group) | 2 Tage |
+| F-TASK-MIG | **Migration** — bestehende `Task.contact_id` → `entity_type='contact' + entity_id`, `Task.assigned_to` → `assignee_type='user' + assignee_id`. `AgentSubtask` → `Task` mit `task_type='agent_subtask'`. Daten-Migration + View für Übergang | 1 Tag |
+| F-TASK-TEST | Tests: Polymorphe Assignment, Entity-Links, Subtasks, Agent-Task-Creation, Workstream-Integration, Migration | 1.5 Tage |
+
+**Deliverables Phase F:** ReAct-Agenten auf vorhandener Agentenbasis, kleiner Skill-Baustein, Tool-/Skill-Calling, Permission-Modell (User/Run-as ∩ Agent ∩ Skill ∩ Tool) mit Concurrency-Schutz, AI-Use-Case-/Transparency-Metadaten, Provider/Data-Policy-Enforcement, Standard+Extended Trace, LLM-Fehlerstrategie (Rate-Limit-Backoff, Provider-Failover, Timeout-Graceful-Stop), strukturiertes Tool-Error-Handling mit ErrorCategory, trigger-basierte Proaktivität, UI Control ohne Permission-Bypass, zentraler ApprovalRequest-Kern + Human-Oversight-Record, Workstream-Ausgabe, Agent UI, 4 Pre-Built Agenten und Unified Task System (polymorphe Assignment, Entity-Links, Subtasks, Agent↔Task, Workstream-Integration).
 
 ---
 
@@ -746,7 +798,7 @@ Kein vollständiger interner Chain-of-Thought; der Extended Trace ist ein expliz
 | G-APPROVAL | **Generischer Approval-Step auf zentralem `ApprovalRequest`** — den in Phase F angelegten gemeinsamen Kern für Workflows verwenden/erweitern; für beliebige Workflows, Entities und Aktionen nutzbar; Approver/Gruppe, `pending/approved/rejected/expired`, Referenz auf Workflow/Run/Aktion, Kommentar, Zeitstempel, System-Message, Approval-Queue, Audit und optional Timeout. **Keine pauschalen `pending_approval/active/rejected`-Statusfelder auf allen Entities**; fachliche Status nur im jeweiligen Modul, wenn benötigt. Derselbe Mechanismus wird von Agent-Approvals verwendet | 2.5 Tage |
 | G-HUMAN-DEC | **Automated-Decision Guard** — für entsprechend konfigurierte AI-Use-Cases dürfen Workflow-/Agent-Ergebnisse keine definierte personen-/risikorelevante Außenwirkung automatisch auslösen, bevor die geforderte Human-Review-/Approval-Policy erfüllt ist. Kein pauschaler Zwang für normale CRM-Automation | 1 Tag |
 | G-CTX | **Persistenter Execution-Context** — Daten-Flow zwischen Steps (Variablen, Expressions) wird zusammen mit WorkflowRun dauerhaft gespeichert und kann nach Wait, Restart, Worker-Crash oder Event-Resume fortgesetzt werden | 2 Tage |
-| G-RUN | **Durable WorkflowRun / Resume-Semantik** — bestehendes `WorkflowInstance`-Model wird zu `WorkflowRun` erweitert/umbenannt. Run-State, Step-State und Resume-Grund (`resume_at`, Event/Approval/Webhook) persistent halten. Resume lädt denselben Run und setzt exakt am vorgesehenen Step fort; keine zweite Workflow-Runtime | 1.5 Tage |
+| G-RUN | **Durable WorkflowRun / Resume-Semantik** — bestehendes `WorkflowInstance`-Model wird zu `WorkflowRun` erweitert/umbenannt. Run-State, Step-State und Resume-Grund (`resume_at`, Event/Approval/Webhook) persistent halten. Resume lädt denselben Run und setzt exakt am vorgesehenen Step fort; keine zweite Workflow-Runtime. **Concurrency**: zwei Worker die denselben Run resume → Redis-Lock pro `WorkflowRun.id`, nur ein Worker resume, anderer wartet oder überspringt | 2 Tage |
 | G-IDEMP | **Idempotency-/Deduplizierungsschutz für Side Effects** — Side-Effect-Steps (z. B. Mail, HTTP, CRM-Mutation) erhalten pro Execution einen stabilen Idempotency-/Execution-Key bzw. deduplizierbare Ausführungslogik, damit Retry/Worker-Restart keine unbeabsichtigten Doppelaktionen erzeugt | 1 Tag |
 | G-UI-FORM | Form-basierter Step-Editor — Step-Liste mit Up/Down, Formular pro Step-Typ | 2 Tage |
 | G-UI-JSON | JSON-Expert-Mode — Toggle zwischen Form und JSON | 0.5 Tage |
@@ -823,7 +875,7 @@ Alle in Phase E-H gebauten Systeme müssen miteinander verbunden werden.
 | I-MINI-RENDER | **`MiniAppBlock` Placeholder ersetzen** — `app_id` über gemeinsamen Registry/Resolver zu echter interaktiver Darstellung auflösen; Fehler-/Fallback-State sauber behandeln | 2 Tage |
 | I-MINI-SDK | **Kleines MiniApp UI/Schema-SDK** — Standardbausteine für Entity Card/Detail, Form, Auswahl, Liste, Action Buttons, Approval, Progress und Deep-Link. `render_schema` validieren; Aktionen gehen über reguläre APIs/Services + Permissions | 2 Tage |
 | I-WORK-ACTOR | **Einheitlicher Posting-Pfad** — Human/System/Agent/Workflow können Text, Entity Cards, Action Cards, Knowledge Evidence, Approval und MiniApps über denselben Communication-Service posten | 1 Tag |
-| I-WORK-HANDOFF | **Human↔Agent Handoff** — `review_needed`/`action_required`/`waiting_for_user` als typisierte Workstream-Semantik; Aktion oder User-Änderung kann denselben AgentRun/WorkflowRun fortsetzen | 1.5 Tage |
+| I-WORK-HANDOFF | **Human↔Agent Handoff** — `review_needed`/`action_required`/`waiting_for_user` als typisierte Workstream-Semantik; Aktion oder User-Änderung kann denselben AgentRun/WorkflowRun fortsetzen. **Task-basierter Handoff**: Handoff erstellt automatisch einen `Task` mit `assignee_type` (user/agent/group), `entity_type+entity_id` Referenz und `task_type='handoff'`; Task-Status-Änderung fortsetzt den Run | 2 Tage |
 | I-WORK-PROACTIVE | **Proactive Workstream Feed** — UI-/Domain-Trigger erzeugen kontextuelle Vorschläge/Actions im Workstream mit Priority, Dedupe, Cooldown und User-Einstellungen; kein störendes Popup-/Clippy-Verhalten | 1.5 Tage |
 | I-WORK-GROUP | **Shared Group Workstreams** — vorhandene Conversation-/Participant-Rechte für mehrere Menschen + Agenten verifizieren; Mentions/Unread/Assignment/Handoffs auf Gruppenfluss testen | 1 Tag |
 | I-WORK-MOBILE | **Mobile/PWA Workstream** — bestehendes mobile Sidebar/Overlay + PWA so fertigstellen, dass alle Standard-Blocks/MiniApps touch-tauglich sind; Datei-/Foto-Upload, Actions, Approval, Deep-Links und Agent-Interaktion mobil E2E testen. Keine Offline-ERP-Sync-Architektur | 2 Tage |
@@ -836,7 +888,7 @@ Alle in Phase E-H gebauten Systeme müssen miteinander verbunden werden.
 | Task | Beschreibung | Aufwand |
 |------|-------------|---------|
 | I-DASH | **Platform Dashboard** — Agent-Status, Workflow-Stats, Search-Metrics, Knowledge-Coverage, Workstream-/Suggestion-Metriken, System-Health | 2 Tage |
-| I-COST | **Cost-Tracking Dashboard** — LLM-Kosten pro Agent/Workflow/User, Budget-Alerts, Cost-Trends. LLM Client hat Cost-Tracking (B.1), hier wird die UI gebaut | 1.5 Tage |
+| I-COST | **Cost-Tracking Dashboard** — LLM-Kosten pro Agent/Workflow/User, Budget-Alerts, Cost-Trends. LLM Client hat Cost-Tracking (B.1) und Tenant-Cost-Cap (B-COST-CAP), hier wird die UI gebaut: Live-Kosten, Budget-Auslastung, Alert-History, Cost-Per-Tenant/Agent/Workflow, Hard-Stop-Events | 2 Tage |
 | I-USE | **Usage-/Collaboration-Analytics** — Feature-Nutzung, Search-Queries, Agent-Runs, Workflow-Executions sowie angenommene/verwerfene Proactive Suggestions/Handoffs als Basis für Phase J | 1 Tag |
 
 ### I.4 Performance Review & gezielte Optimierung