Dystroyer8/Jarvis-Ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: update core chat status

Browse Source
This commit is contained in:
Dystroyer8
2026-07-30 17:04:46 +02:00
parent b153daa989
commit 5d567e5301
13 changed files with 173 additions and 63 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ARCHITECTURE.md
+14 -8
View File
@@ -4,12 +4,12 @@
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.
## Vorgesehene Ebenen
## Ebenen
1. Interface: CLI, später Sprache, Mobilzugriff und Living Mind.
2. Core: Gesprächsablauf, Sitzungszustand und Orchestrierung.
3. Providers: austauschbare lokale und optionale Cloud-Modellanbindungen.
4. Memory: strukturierte Laufzeitdaten und regenerierbarer semantischer Index.
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.
@@ -17,11 +17,17 @@ Javis beginnt als modularer Monolith. Module besitzen klare Zuständigkeiten und
## Plattformgrenzen
- Pfade werden später per Konfiguration und `pathlib` aufgelöst.
- 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.
## Noch nicht implementiert
## Implementierter Chatfluss
Es existieren nur Paketgrenzen und Dokumentation. Es gibt keinen Chat, Provider, Speicher, Toolaufruf oder Netzwerkdienst.
`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.