Files
Jarvis-Ai/docs/ARCHITECTURE.md

37 lines
1.7 KiB
Markdown

# 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.