Skip to content

TODO.md

Latest commit

 

History

History
101 lines (86 loc) · 5.94 KB

TODO.md

File metadata and controls

101 lines (86 loc) · 5.94 KB
Raw

KAiOSS — TODOs

Stand: 08.07.2026

Phase 1 — Foundation & Security

  • #25 Architektur-Review Workflow etablieren
  • #23 Task-Schema + useTaskDB + TodoPanel Migration
  • #16 Datensicherung mit Hash-Werten (sha256)
  • #30a Legacy Wiki-TODOs Migration (obsolet — keine Legacy-Daten)
  • #31 TODO.md → SurrealDB Sync (todo-sync.js)
  • #31b ROADMAP.md → SurrealDB Sync (Erweiterung von todo-sync.js)
  • #21 Human-in-the-Loop Konzept (HITL Bestätigung für kritische Befehle)
  • #33 Pflanternen Stufe 1 Optimierungen (Commit-Hash als ID, Root-Commit Fallback, Branch + Author Metadaten)
  • #34 Dependency-Graph View (D3/vis.js) — Phase 2 Feature (Kommentar bereits in WikiPanel.jsx vorhanden)
  • #35 Markdown-Rendering in Task-Titeln (text → bold, kein Raw-Asterisk anzeigen)
  • #36 Agent Memory: scripts/memory.js via cmd-runner für In-Database GraphRAG - [x] 1. Dedizierte Tabellen (memory_node, memory_edge als TYPE RELATION) - [x] 2. Ollama JSON-Mode (format: "json") für zuverlässige Extraktion - [x] 3. Selektiver Trigger (commands.json Alias memory-extract, sandbox: false) - [x] 4. Graph-Tiefe limitieren beim Abruf (SELECT *, ->memory_edge->(->memory_node LIMIT 5) FROM ...) - [x] 5. Deduplication in JS (Vor RELATE abfragen, ob Edge bereits existiert, um Doppelungen zu vermeiden)
  • #40 KAi SurrealDB Permissions & Isolation einrichten - [x] 1. DB-User kai definieren (ROLES EDITOR - wegen SurrealDB 3.x Kompatibilität) - [x] 2. Table-level Permissions in init_clean.surql integrieren (restrictive SELECT, CREATE, UPDATE, DELETE für tasks, todos, wiki, projects, kai_log) - [x] 3. kai.*-Subfelder (kai.notiz, kai.aktion, kai.ts) auf tasks und todos definieren (TYPE option) - [x] 4. Test-Queries ausführen und Zugriffsrestriktionen verifizieren

    Phase 2 — KAi Bootstrap

    • #29 Agent-Priorisierung (KAi + LearnAgent + GitAgent)
    • #7 Modell-Wahl für KAi (Qwen2.5-Coder vs qwen2.5:32b)
    • #2 Skills erstellen (.kai/)
    • #15 Modulare Prompt-Pipeline
    • #8 KAi Priorisierungslogik
    • #30b useTaskDB in DetailPanel integrieren
    • #32 cmd-runner (Sicherer Hintergrund-Prozess-Executor auf Basis von #3 & #21)

    Phase 3 — Infrastruktur & Resilienz

    • #19 SurrealDB als Event-Bus
    • #4 Resilienz (Recovery, Locking)
    • #22 Task-Verifikation + proaktives Review (Sandbox-NixOS-VM via Firecracker/crosvm als Spielbrett & Test-Environment)
    • #11 NixOS-native Integration (agents.nix, Pflanternen Stufe 3: Automatische Build-Evaluation und VM-Checks)
    • #38 Auto-Reconnect & State Machine für SurrealDB (Stabilitäts-Upgrade für db.js)
    • #39 agenix-Integration für API-Keys (Lokales sicheres Secrets-Management anstatt localStorage)

    Phase 4 — Ecosystem & Expansion

    • #13 Agent-Pipeline
    • #18 Agent-Governance
    • #17 LearnAgent Quellen
    • #24 FalkorDB Phase 2 (CabellistPro)
    • #37 Cross-Platform OS-Module: setup.sh OS-Detection für modules/systemd/ (Ubuntu/Arch) und modules/macos/ (launchd) analog zur NixOS-nativen Pflanternen-Integration

    Phase 5 — Horizon

    • #26 Fine-Tuning auf kai_log-Daten (Reinforcement Learning aus nixos_training_game Versuchen via Unsloth & Ollama)
    • #28 KAi Native GraphRAG Pipeline (In-Database Entity Extraktion statt Cognee - memory.js & memory_query.js)
    • #6 TUI evaluieren
    • #9 Multi-User → GitHub Issue
    • #10 Pi.dev evaluieren
    • #14 Hermes Agent als Referenz
    • #20 Skills als Nix-Flake-Outputs
    • #30 Voice-Interface (Pipecat > LiveKit)
    • #41 KI-Generierte Zusammenfassungen für ObsidianGraph Hover-Tooltips (Ollama API)
    • #42 Context-Aware Wiki Docs Assistant (Fokus-Modus für spezifische Dokumenten-Analyse)
    • #43 Proaktive "Next-Action" Predictions (Holografische Suggestion-Buttons im KAiPanel)
    • #44 Automatisiertes Tagging & Sentiment-Analyse für neue Todos und Wiki-Docs

    Ideenliste — RAGFlow-Vergleich (08.07.2026)

    Quelle: Analyse von github.com/infiniflow/ragflow. Konzepte übernehmen, Architektur nicht: deren Stack (Elasticsearch/Infinity + MinIO + Redis + MySQL) verletzt Invariant 4 (SurrealDB = einzige Autorität) und kommt NICHT ins Projekt. Was RAGFlow besser kann und hier fehlt: (1) layout-aware Dokument-Ingestion (DeepDoc), (2) Reranking + Hybrid Recall, (3) erklärbares Chunking mit Human-Intervention, (4) Citation-Traceability-UX, (5) konfigurierbare Ingestion-Pipeline + Cross-Language Query. Alle Einträge sind IDEEN — sie kommen HINTER die aktive Sequenz, nicht davor (kein Feature-Creep, Invariant 10).

    • #45 Reranking-Stage nach MTREE-Recall (Idee A — höchster ROI, ADR-Kandidat): bge-reranker lokal via Ollama als zweite Stufe; Reranker liefert nur Scores, entscheidet nicht (Invariant 2). Einbau als Modus 4 (hybrid+rerank) in scripts/memory_query.js Phase 2.
    • #46 Hybrid Retrieval SurrealDB-nativ (Idee B — kein ADR nötig): BM25-Volltext via DEFINE ANALYZER + DEFINE INDEX ... SEARCH ... BM25 + @@/search::score() kombiniert mit Vektor-Recall + Rerank. Bewusst KEIN Elasticsearch — alles bleibt in der Single Source. Erweiterung von db/memory_query.surql.
    • #47 Docling als Ingestion-Actuator (Idee C — eigenes ADR wegen neuer Dependency): layout-aware Parsing (PDF/Tabellen/Scans/Slides, Apache/MIT, lokal, Nix-fähig) statt DeepDoc-Nachbau; Output = provenance-behaftete Chunks in SurrealDB ("Hand und Ohr, nie Hirn").
    • #48 Chunk-Inspection-HITL (Idee D): Chunk-Grenzen visualisieren + menschliche Korrektur VOR dem Index-Write; jeder Chunk mit Provenance (quelle, verifikation). Risk-based-Autonomy auf den Ingestion-Layer angewandt (human-review-Level).
    • #49 Template-based Chunking (Idee E): deterministische, erklärbare Chunking-Strategien pro Dokumenttyp statt naivem Fixed-Size — passt zur deterministischen Orchestrator-Doktrin.