18 lines
1.9 KiB
Markdown
18 lines
1.9 KiB
Markdown
---
|
|
name: archiv-suchindex-konzept
|
|
description: "Geplanter Volltext-Suchindex fürs Panel-Archiv — SQLite FTS5 (Empfehlung) oder tantivy, MCP-Tool search_archive; Konzeptphase, kein Go"
|
|
metadata:
|
|
node_type: memory
|
|
type: project
|
|
originSessionId: 836a1699-2525-4d4b-8164-7efdb98d3b9b
|
|
modified: 2026-07-19T09:30:27.994Z
|
|
---
|
|
|
|
Marcus' Idee (2026-07-17): Inhalts-Index für das Panel-Archiv für schnelles Suchen — „vielleicht ein leichter Elastic-Clone". Abgestimmtes Konzept:
|
|
|
|
- **Engine:** Empfehlung SQLite FTS5 (rusqlite) — eine DB-Datei neben dem Archiv, BM25, Phrasen/Präfix, inkrementelles Update; für Markdown-Archive pro Projekt ausreichend. Alternative tantivy (Rust-Lucene, wörtlich der leichte Elastic-Clone) erst, wenn Fuzzy/Facetten gebraucht werden. Wechsel bleibt möglich, weil Tool-Schnittstelle und Panel-Darstellung engine-unabhängig sind.
|
|
- **Einbindung:** `archive_panel` aktualisiert den Index beim Archivieren (serverseitig, deterministisch). Neues MCP-Tool `search_archive(query)` → Treffer mit Pfad + Snippet, im Panel als Kacheln ([[command-panel-konzept]]); Treffer-Klick lädt das Dokument über den `path`-Parameter von write_panel.
|
|
- **Reproduzierbarkeit:** Index jederzeit aus dem Archiv-Ordner neu baubar, Rebuild-Kommando gehört dazu — gleiches Prinzip wie [[dokument-index-konzept]].
|
|
|
|
Stand 2026-07-19: umgesetzt (Go am 2026-07-19) — FTS5 über rusqlite (bundled), Index wird pro Anfrage in-memory aus dem Archiv-Baum gebaut statt persistiert (bei dieser Archiv-Größe Millisekunden; keine Staleness, nichts zu syncen, Rebuild-Kommando überflüssig — Persistenz kann später nachgerüstet werden, Tool-Schnittstelle bleibt gleich). MCP-Tool `search_archive(query, tag)`; Treffer als Kacheln im Panel (Suchtreffer-Datei + AI_CONTROL_SEARCH + Watcher `search-update`, dritter Panel-Modus „Suche"), Klick lädt das Dokument. Cargo-Tests grün; App-Verifikation steht aus. Baustein des Blocks ([[archiv-wiki-konzept]]).
|