docs(roadmap): Phase N Workspace-Scopes + Workspace/Dashboard-Abgrenzung (user-korrigiert)

- Phase N: Modul-Teilmengen pro Workspace (N1 Scope-Registry via Contract, N2 dynamischer Scope-Editor, N3 Contacts/DMS/Mail/Calendar, N4 restliche Module)
- KLARE TRENNUNG Workspace vs Dashboard: Workspace = Admin-Gruppen-Kontext (was verfuegbar ist, workspace_widgets); Dashboard = persoenlich (Phase M, dashboards-Tabelle)
- 0 Umbau: config JSONB + X-Workspace-ID + /context + Sidebar-Consumer existieren bereits
- Security-Invariante dokumentiert: Scope = reine UND-Einschraenkung zu RLS/ABAC/Permissions

PLATFORM_ROADMAP.md

@@ -1652,6 +1652,13 @@ Der AI Assistent ist ein paralleles System das die Kommunikation-Plattform dupli
 
 **Architektur-Entscheidung (user-bestiätigt):** EINE Universal-Registry statt zweier paralleler Systeme — `dashboard_widgets` wird Alias von `miniapps`; jedes Plugin/System registriert MiniApps via Contribution (gleiches Muster wie settings_pages/print document blocks, #359-Philosophie). Ein Host-Set: Chat-Block (fertig), Dashboard (neu), Windows (M6), AI-Agenten-Tool-Ausgabe (M6).
 
+
+**⚠️ Abgrenzung Workspace ≠ Dashboard (user-korrigiert 2026-08-30):**
+- **Dashboard (diese Phase M)** = PERSÖNLICH: jeder User baut eigene Dashboards (Layout/Tabs/Instanzen) — Speicher ist die NEUE `dashboards`-Tabelle (owner-basiert). NIEMALS `workspace_widgets` dafür verwenden.
+- **Workspace (Phase N)** = ADMIN-Kontext für Gruppen: welche Module sichtbar sind (fertig) + Modul-Teilmengen (Scopes) + welche Widget-TYPEN der Workspace anbietet (`workspace_widgets`, existiert bereits — Workspace-Eigentum).
+- Schnittstelle: der aktive Workspace begrenzt nur die VERFÜGBAREN Widget-Typen; das persönliche Layout bleibt User-Eigentum und wird von keinem Workspace überschrieben.
+
+
 ### M1 — Universal-MiniApp-Registry (2-3 Tage)
 - miniapp_registry aus kommunikation-Plugin in Plugin-Layer heben (Plattform-Konzept, kommunikation behält Chat-Hosting)
 - MiniAppDef/MiniAppContribution erweitern: `permission` (Pflicht-Feld, fail-closed), `settings_schema` (generisches Settings-Form), `col_span`/`row_span`, `min_size`
@@ -1693,3 +1700,45 @@ Der AI Assistent ist ein paralleles System das die Kommunikation-Plattform dupli
 **Abhängigkeiten:** M3 benötigt M1+M2. M4/M5 nach M3 (Host muss stehen). M6 zuletzt.
 
 **Verwandte Phasen/Issues:** Phase L (Gleiche Contribution-Philosophie), #359 (Contract-Muster), Phase F (Agenten für M6).
+
+---
+
+## Phase N — Workspace-Scopes: Modul-Teilmengen pro Arbeitskontext (geplant, user-abgestimmt 2026-08-30)
+
+**Ziel:** Workspaces werden zu voll anpassbaren Arbeitskontexten: jedes Modul kann pro Workspace auf eine Teilmenge eingeschränkt werden (z.B. nur Kontakt-Ordner X+Y, nur DMS-Ordner „Angebote", nur Mail-Postfach vertrieb@, nur Kalender „Vertrieb"). Admin-definiert für zugewiesene User-Gruppen — klar getrennt vom persönlichen Dashboard (Phase M).
+
+**Klare Trennung (user-korrigiert):**
+- Workspace = Admin-Kontext, Gruppen-Feature: WAS ist sichtbar/verfügbar (Module, Teilmengen, Widget-Typ-Angebot via `workspace_widgets`)
+- Dashboard = persönlich, User-Feature: WIE ICH mein Dashboard baue (Phase M, `dashboards`-Tabelle)
+- Beide Systeme berühren sich NUR an einer Schnittstelle: der aktive Workspace begrenzt das Widget-Typ-Angebot; das persönliche Layout bleibt unberührt.
+
+**Basis (Live-Bestand, 0 Umbau):**
+- `workspace_modules.config` (JSONB) — existiert, ungenutzt → Scope-Speicher pro Modul
+- `X-Workspace-ID` Header + API-Client-Interceptor (pro Tab) — existiert, wird vom Backend gelesen
+- `/api/v1/workspaces/context` — existiert, liefert Modul-Konfiguration aus
+- Sidebar filtert bereits live (isModuleVisible — Consumer-Beweis)
+- 17/17 Workspace-Tests grün, RLS auf allen 4 Tabellen
+- Contract-Muster für die Scope-Registry (wie document_placeholders)
+
+**Security-Invariante:** Scope = reine UND-Einschränkung. Sichtbarkeit = Workspace-Scope ∧ RLS ∧ ABAC ∧ Permissions. Ein Workspace kann NIE mehr sichtbar machen, nur weniger. Ohne aktiven Workspace = kein Filter (rückwärtskompatibel, wie Sidebar).
+
+### N1 — Scope-Registry via Contract (2 Tage)
+- Plugins deklarieren `workspace_scopes()` → verfügbare Scope-Dimensionen + Wertequellen (z.B. „folder_ids, Multiselect, via /contacts/folders")
+- `/context` liefert `config` der Module mit aus; Scope-Definitionen-Endpoint für den Editor
+
+### N2 — Dynamischer Scope-Editor (2-3 Tage)
+- WorkspaceManager: pro Modul automatisches Filter-UI aus der Registry (Multiselects für Ordner/Postfächer/Kalender, Toggles, Standard-Ansichten)
+- Speicherung in `workspace_modules.config`
+
+### N3 — Erste vier Module integrieren (2-3 Tage)
+- Contacts: Ordner-Teilmengen, Firmen/Personen-Filter, Standard-Saved-View
+- DMS: Ordner-Teilmengen, Datei-Typ-Filter
+- Mail: Postfach-Teilmengen
+- Calendar: Kalender-Teilmengen, Standard-Ansicht
+- Backend respektiert X-Workspace-ID bei Listen (additive Filter-Logik, kein Umbau bestehender Routes)
+
+### N4 — Restliche Module (2-3 Tage)
+- Tasks (Boards/Listen, „nur meine"), Kommunikation (Räume), Wiki (Kategorien), Reports/Dokumente (Vorlagen), Automation (Agenten), Tags, Suche (Provider), Navigation (Menü-Reihenfolge, Startseite pro Workspace)
+- Dashboard-Schnittstelle: workspace_widgets bestimmt verfügbare Widget-TYPEN pro Workspace (Admin) — persönliches Layout bleibt Phase M
+
+**Abhängigkeiten:** unabhängig von Phase M. N3/N4 nach N1+N2.