Ka-Note/roadmap.md

Ka-Note Roadmap

[LOW] Sync: Soft-delete Restrisiko bei neuem Gerät / DB-Reset

Problem Wenn ein Gerät noch nie gepusht hat (neues Gerät oder IndexedDB gelöscht), ist !local = true für alle Pull-Einträge. Der Pull überschreibt dann keine lokale Version, sondern legt neu an — auch wenn der Eintrag auf einem anderen Gerät bereits gelöscht wurde. Das gelöschte Item erscheint wieder, bis das löschende Gerät seinen Push durchführt.

Bereits gefixt

• Push läuft jetzt vor Pull (doSync)
• Merge-Bedingung auf > statt >= (lokale Änderung gewinnt bei Versionsgleichstand)

Restrisiko Szenario: Gerät A löscht Item (version N+1), hat aber noch nie gepusht. Gerät B macht Full-Sync: Pull bringt Server-Version N (nicht gelöscht), !local → wird eingespielt. Gerät B sieht das Item als vorhanden.

Lösungsoptionen

1. Serverseitig: deletedAt-Items aus Pull-Response ausfiltern Server gibt bei Pull keine soft-deleted Items zurück. Gerät B bekommt das Item gar nicht erst. Problem: Wenn Gerät B das Item schon lokal hat (z.B. eigene ältere Version), wird es nie als gelöscht markiert.

2. Tombstone-Tabelle Separate Tabelle deletions(entityId, deletedAt, version) — wird immer mitübertragen. Client wertet Tombstones aus und löscht lokale Items explizit. Robusteste Lösung, erhöht aber Komplexität.

3. Server filtert + Client löscht lokale Einträge die der Server nicht mehr liefert Server sendet nur aktive Items. Client vergleicht lokale IDs mit Pull-Response und markiert fehlende als deletedAt. Einfacher als Tombstones, aber fehleranfällig bei partiellen Pulls (since-Filter).

Empfehlung Option 2 (Tombstones) für korrekte Multi-Gerät-Unterstützung. Option 3 als pragmatischer Zwischenschritt wenn Full-Sync (since=null) garantiert ist.

---

[LOW] Verlinkung: Index für @F:/@P:/@NAME-Tags

Aktueller Stand CompanyPersonsView und ähnliche Views scannen beim Öffnen alle Topics + History-Einträge per Regex (O(n) über gesamten Content, in-memory via Dexie).

Skalierbarkeit Für den typischen PKM-Anwendungsfall (< 10.000 Einträge, ein User, lokal) kein Problem. Ab ~5.000 Einträgen potenziell spürbar (> 200ms).

Lösungsoptionen

1. Berechnetes Feld beim Schreiben (pragmatisch) Beim Speichern eines Topics/History-Eintrags die Tags extrahieren und als Array in einer eigenen Spalte speichern (companyRefs: string[], personRefs: string[]). Dexie kann darauf einen echten MultiEntry-Index anlegen → O(1) Lookup statt O(n) Scan. Kein Background-Worker nötig.

2. SQLite FTS5 (serverseitig) Volltext-Index auf dem Server, Lookup per API. Höherer Aufwand, sinnvoll erst bei Multi-User-Szenarien.

Empfehlung Nichts ändern bis die Query spürbar langsam wird. Dann Option 1 (berechnetes Feld + Dexie MultiEntry-Index) als einfachster Mittelweg.