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, lokaler Ollama- und optionaler Gemini-Adapter.
4. Memory: SQLite-Sitzungen und separates inhaltsfreies Provider-Audit.
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: lokaler Datenschutzrouter, Freigaben und Betriebssystem-Keyring.
8. Audit: Provider-Metadaten ohne Prompts, Antworten oder 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 und verbindet den core.provider_router. Dieser klassifiziert die aktuelle Anfrage vollständig lokal, minimiert den freigegebenen Kontext und wählt Gemini oder Ollama. core.chat_service speichert erst eine erfolgreiche Antwort zusammen mit der Benutzernachricht atomar.

Gemini ist nur bei lokaler Aktivierung, vorhandenem Key, free_only = true, bestätigtem Nicht-Billing und passender Datenschutzentscheidung erreichbar. Ollama bleibt Loopback-, Datenschutz-, Offline-, Quota- und Fehlerfallback. Es existiert weiterhin kein Toolaufruf, Obsidian-Zugriff oder eigener öffentlicher Netzwerkdienst.