Jarvis-Ai/docs/ARCHITECTURE.md

Architektur

Ziel

Javis beginnt als modularer Monolith. Module besitzen klare Zuständigkeiten und kommunizieren über kleine, typisierte Schnittstellen. Erst reale Betriebsgründe rechtfertigen später separate Dienste.

Ebenen

1. Interface: implementierte CLI; später möglicherweise Sprache, Mobilzugriff und Living Mind.
2. Core: implementierter Gesprächsablauf und Sitzungslogik.
3. Providers: kleine Schnittstelle und implementierter lokaler Ollama-Adapter.
4. Memory: implementierte SQLite-Sitzungen; ein semantischer Index ist nur geplant.
5. Obsidian: zunächst lesender Adapter, später eng begrenzte Entwürfe.
6. Tools und Status: feste Schemas, Allowlists, Timeouts und bereinigte Ausgaben.
7. Security: Freigaben, Secret-Provider und Berechtigungsprüfung.
8. Audit: nachvollziehbare Aktionen ohne geheime Inhalte.

Plattformgrenzen

• Pfade werden zentral in Settings und mit pathlib aufgelöst.
• Betriebssystemspezifische Funktionen liegen hinter Adaptern.
• Produktname, Datenpfade und Provider werden zentral konfiguriert.
• Laufzeitdaten liegen außerhalb von Git.

Implementierter Chatfluss

interface.cli nimmt Text an, core.chat_service verbindet Sitzungsverlauf und Provider, providers.ollama spricht nur die lokale Ollama-HTTP-API an und memory.sqlite_store speichert erfolgreiche Benutzer-/Assistentenpaare atomar. Scheitert das Modell, wird keine erfundene Antwort gespeichert.

Es existiert kein Cloudadapter, Toolaufruf, Obsidian-Zugriff oder eigener öffentlicher Netzwerkdienst. Der Ollama-Endpunkt muss eine Loopback-Adresse sein.