feat(workspace): implement Yjs CRDT real-time collaborative editing (resolves FLAW-01)

Doku/modules/workspace.md

@@ -46,33 +46,40 @@ Der Bullet-Dot dient gleichzeitig als Drag-Anfasser. Wird ein Block verschoben,
 
 ---
 
-## 💾 3. Pure-Database Architecture (Keine MD-Dateien auf Platte)
+---
 
-MindSift speichert Notizen und Outliner-Bäume **zu 100% relational in SQLite**. Es werden bewusst **keine Markdown-Dateien auf dem Dateisystem** abgelegt:
+## ⚡ 3. Yjs CRDT Real-Time Engine & Dual-Persistence
 
+Ab MindSift v2.1 setzt der Workspace auf ein **konfliktfreies Replicated Data Type (CRDT) Modell** auf Basis von [Yjs](https://yjs.dev/):
+
+### Funktionsweise
+1. **CRDT-Struktur im Client:**
+   - Ein `Y.Doc` pro geöffnetem Dokument.
+   - `Y.Array<string>` (`blocks`): Führt die Block-IDs in korrekter Reihenfolge. Der YATA-Algorithmus garantiert, dass simultanes Einfügen, Verschieben oder Löschen von Blöcken durch mehrere Nutzer deterministisch und konfliktfrei konvergiert.
+   - `Y.Map` (`block:<id>`): Speichert Inhalt (`content`), Einrückung (`level`), Erledigungsstatus (`checked`) und Faltungsstatus (`collapsed`).
+2. **Kollaborative Bearbeitung ohne Sperren:**
+   - Nutzer können simultan dieselbe Notiz bearbeiten.
+   - Fokus- und Cursor-Positionen werden via `CRDT_AWARENESS` übertragen und als farbige Benutzer-Pillen direkt am jeweiligen Block visualisiert.
+
+### Dual-Persistence in SQLite
 ```
-Client (Block-Editor)
-        │ PUT /api/v1/documents/:id/blocks (oder WebSocket)
-        ▼
-   Backend Engine
-   ┌──────────────────────────────────────────────┐
-   │ Atomare Transaktion in SQLite:               │
-   │ 1. DELETE FROM document_blocks WHERE doc_id  │
-   │ 2. Batch INSERT der Blöcke:                  │
-   │    -> id, doc_id, content, level, checked,   │
-   │       sort_order, collapsed                  │
-   │ 3. WebSocket Broadcast an Raum (doc:id)      │
-   └──────────────────────────────────────────────┘
+Client (Y.Doc Mutation)
+        │
+        ├──▶ WebSocket (CRDT_UPDATE Base64 Delta)
+        │         │
+        │         ▼
+        │    SQLite: document_crdt_updates / document_crdt_state
+        │    (Mathematisch exakte CRDT-Konvergenz)
+        │
+        └──▶ Periodischer Snapshot / Flush
+                  │
+                  ▼
+             SQLite: document_blocks
+             (Relationale Indizes für Global To-Dos, Tag-Explorer & FTS)
 ```
 
-### Vorteile der reinen Datenbank-Architektur
-1. **Kein Dual-Storage & kein Drift:**
-   - Keine Inkonsistenzen zwischen Festplattendateien und Datenbankzeilen.
-   - Keine Dateisystem-Sperren, Race-Conditions oder Berechtigungskonflikte auf Betriebssystemebene.
-2. **Atomare Transaktionen (ACID):**
-   - Strukturänderungen (Einrücken, Unterbaum verschieben, Blöcke löschen) sind atomar in einer Transaktion gekapselt.
-3. **Skalierbare Abfragen & Rollups:**
-   - Aggregationen (wie das globale To-Do Dashboard oder Tag-Suchen) erfolgen mit hochoptimierten SQL-Abfragen über relationale Indizes, anstatt Hunderte `.md`-Dateien von der Festplatte parsen zu müssen.
+1. **Mathematische CRDT-Garantie:** Binäre Yjs-Updates werden in `document_crdt_updates` und periodisch als Snapshot in `document_crdt_state` gesichert. Auch nach einem Server-Neustart oder Offline-Phasen konvergieren alle Clients verlustfrei.
+2. **Relationale Query-Fähigkeit:** Um schnelle SQL-Abfragen für das globale To-Do Rollup Dashboard und Hashtags zu ermöglichen, werden die Blöcke parallel in `document_blocks` materialisiert. Es existieren **keine Markdown-Dateien auf der Festplatte**.
 
 ---