Jarvis-Ai/docs/CHATGPT_HANDOFF.md

# ChatGPT Handoff

## Projektziel

Javis ist Pascals langfristiges, lokal-first ausgerichtetes Projekt für einen realistischen persönlichen KI-Assistenten. Geplant sind schrittweise:

- lokaler Textchat und nachvollziehbarer Sitzungsspeicher
- Aufgaben, Notizen und ein kontrolliertes Gedächtnis
- später lesender und danach eng begrenzter Obsidian-Zugriff
- feste, überprüfbare Werkzeuge statt freier Shell
- später Sprache, technische Statusabfragen, Mobilzugriff und Living Mind

Nicht Ziel sind ein fiktiver Film-Jarvis, unbegrenzte Autonomie oder ein selbst trainiertes Foundation Model. Hauptsprache für Pascal und Benutzeroberflächen ist Deutsch.

## Verbindliche Pfade und Umgebung

- Repository und Git-Toplevel: `D:\Javis-Projekt`
- Branch für stabile Arbeit: `main`
- Gitea-Remote: `https://git.peli-server.de/Dystroyer8/Jarvis-Ai.git`
- aktiver Obsidian-Vault: `D:\Obsidian Vault`
- alte OneDrive-Kopie: am früher vermuteten Pfad nicht vorhanden und niemals verändern
- kanonischer Handoff: `docs/CHATGPT_HANDOFF.md`
- historisches Vollarchiv: `docs/archive/handoffs/2026-07-30-full-initial-handoff.md`

Gaming-PC:

- Windows 11 Pro, Build 26200
- AMD Ryzen 7 9700X, 64 GB DDR5-6000
- MSI RTX 3060 VENTUS 2X 12G OC
- ASRock X870 Nova WiFi
- Projekt auf Samsung 870 QVO 1 TB unter `D:`

Späterer möglicher Javis-Host:

- ASUS ROG Strix GL553VD mit Ubuntu 24.04
- Intel i7-7700HQ, 16 GB RAM, GTX 1050 4 GB
- 128-GB-SSD plus 1-TB-HDD
- zeitweise alternativ ATM10-Server; Javis- und ATM10-Modus sollen getrennt sein

Rootserver:

- Netcup RS 2000 G11, 8 vCores, 16 GiB RAM, ungefähr 512 GB
- Ubuntu 24.04; Infrastruktur für Gitea, CouchDB, Reverse Proxy, AMP und Gameserver
- kein lokales Javis-Modell und kein freier Root- oder Shellzugang für Javis

## Aktueller technischer Stand

- Projektgrundgerüst ist auf `main` vorhanden und nach Gitea gepusht.
- Paketstruktur unter `src/javis` ist angelegt, enthält aber noch keinen Chatkern.
- Konfigurationsbeispiel, Sicherheitsdokumente, ADRs und Strukturtest sind vorhanden.
- Living-Mind-Verzeichnis ist ausschließlich ein inaktiver Vertrag ohne Frontend oder Fantasiedaten.
- Projektbezogene Codex-Rollen Scout, Architect, Builder, Verifier und Security Reviewer sind konfiguriert; maximal zwei Unteragenten, nur Builder schreibend.
- Toolchain eingerichtet: uv 0.11.32 und CPython 3.12.13 isoliert unter `D:\Javis-Tools`; Ruff 0.16.0 in der lokalen `.venv`.
- Offizielle VS-Code-Erweiterungen installiert: Python 2026.4.0, Pylance 2026.3.1, Python Environments 1.36.0 und Debugpy 2026.6.0.
- Windows-PATH und vorhandene Python-Installationen wurden nicht verändert.
- Ollama 0.32.5 ist portabel unter `D:\Javis-Tools\ollama` installiert.
- Genau ein Modell ist installiert: `qwen3:8b`, GGUF `Q4_K_M`, 5,2 GB, Apache-2.0.
- Modelle liegen außerhalb von Git unter `D:\Javis-Data\ollama-models`.
- Der lokale Ollama-Dienst bindet nur an `127.0.0.1:11434`; PATH, Registry,
  Autostart und Windows-Dienste blieben unverändert.
- Kein Obsidian-, Laptop- oder Rootserverzugriff wurde implementiert.
- Keine KI-, Sprach-, Mobil- oder Statusfunktion ist implementiert.

## Aktuelle Architektur

- modularer Monolith, bevorzugt Python
- plattformunabhängige Pfade und zentrale Konfiguration
- Modell-Provider als kleine austauschbare Schnittstelle
- SQLite für ersten Sitzungsspeicher
- Laufzeitdaten außerhalb von Git über `JAVIS_DATA_DIR` oder sicheren Plattformstandard
- lokale Modelle zuerst; keine kostenpflichtige API und kein stiller Cloud-Fallback
- Secret-Werte außerhalb von Code, Git, Prompts und Logs
- Modell erhält niemals Passwörter, Tokens oder private Schlüssel
- keine freie Shell; spätere Tools benötigen feste Schemas, Allowlists, Timeouts und Freigaben
- Obsidian zunächst nur lesend; `.obsidian` niemals verändern
- Obsidian-Wikilinks nur bei echter inhaltlicher Beziehung, niemals nur für Graphoptik

## Seit der letzten Übergabe erledigt

- Projekt- und Vault-Pfade erneut bestätigt.
- Sicheres, plattformunabhängiges Grundgerüst erstellt.
- `READ.ME` unter Erhalt des historischen Inhalts zu `README.md` überführt.
- Architektur, Sicherheit, Bedrohungsmodell, Berechtigungen und Roadmap dokumentiert.
- Tokenbewusster Arbeitsablauf festgelegt: gezielte Reads, kurze Ergebnisse, keine unnötigen Agenten oder Plugins.
- Werkzeugempfehlung auf `uv`, Microsoft Python/Pylance/Python Environments und Ruff begrenzt.
- Langer Handoff einmalig unverändert archiviert und durch diese kompakte aktuelle Zusammenfassung ersetzt.
- Handoff-Verdichtung als Commit `e6eb995` nach `origin/main` gepusht.
- Branch `feat/core-chat` von diesem Stand erstellt.
- uv, CPython 3.12, lokale `.venv`, Ruff, Lockfile und offizielle VS-Code-Python-Erweiterungen eingerichtet.
- Ollama und llama.cpp anhand offizieller Quellen verglichen; Ollama als einfachere
  erste Windows-Laufzeit gewählt.
- Ollama-Archiv gegen die offizielle SHA-256-Prüfsumme verifiziert und portabel installiert.
- `qwen3:8b` außerhalb des Repositories geladen und mit zwei echten deutschen
  Modellantworten auf der RTX 3060 geprüft.
- Obsidian, Ubuntu-Laptop und Rootserver blieben unverändert.

## Aktuelle Tests

Letzter bestätigter Grundgerüststand:

- Strukturprüfung: bestanden
- Unit-Test des Paketgerüsts: bestanden
- TOML-Parsing: bestanden
- UTF-8- und interne Markdown-Linkprüfung: bestanden
- Secret-Musterprüfung: keine Treffer
- Gitignore-Prüfung für lokale Secret-Dateien: bestanden
- uv-Lock und `uv sync --dev`: bestanden
- Python in `.venv`: 3.12.13
- Ruff in `.venv`: 0.16.0

Lokaler Modell-Smoke-Test:

- Ollama-Version/API: 0.32.5, localhost erreichbar
- Modell: 5.225.388.164 Byte, 8,2B, Q4_K_M, Apache-2.0
- kalter Aufruf: 36,19 s Wandzeit, davon 17,53 s Laden, ungefähr 7,22 Token/s
- warmer kurzer Aufruf: 0,56 s Wandzeit, ungefähr 55,51 Token/s
- GPU-Belegung: 1.418 MiB vorher, 6.842 MiB mit geladenem Modell
- Ollama meldet 100 % GPU und 5,6 GB Modellbelegung

Zwölf vorbereitete Unit-Tests für Konfiguration, SQLite, Kern, Provider und CLI
laufen in der Arbeitskopie bereits erfolgreich; sie sind noch nicht in den
Feature-Branch übernommen.

## Git-Stand

- aktueller Branch: `feat/core-chat`
- stabiler Branch: `main`
- Grundgerüstcommit: `6d04171`
- letzter Commit vor der Handoff-Verdichtung: `0e82748`
- Handoff-Verdichtung auf `main`: `e6eb995`
- Python-Entwicklungsumgebung auf dem Feature-Branch: `fa90a5c`
- `origin` verwendet HTTPS
- kein Force-Push und keine umgeschriebene Historie

## Kompakter Changelog

- `49a1dd3`: erster Gitea-Verbindungstest
- `6d04171`: sicheres Javis-Grundgerüst
- `0e82748`: Werkzeug-, Token- und Handoff-Regeln
- `e6eb995`: einmalige Archivierung und Verdichtung des Handoffs
- aktuell: isolierte Python-Toolchain und reproduzierbare Entwicklungsumgebung
- aktuell: portable Ollama-Laufzeit und `qwen3:8b` außerhalb von Git verifiziert

## Offene Entscheidungen und Fehler

- endgültiger Produkt-/Repositoryname bleibt offen
- Startmechanismus für Ollama ist noch bewusst manuell und nur pro Prozess konfiguriert
- genauer späterer Obsidian-Schreibbereich ist nicht freigegeben
- endgültiger Secret-Provider ist offen; lokale Klartext-XML wäre nur restriktiv geschützt und Git-ignoriert zulässig
- Gaming-PC zeigt derzeit nur 8 statt 16 logische CPU-Prozessoren; Ursache ungeklärt
- ASUS-Laptop ist nicht automatisch für dasselbe Modell wie die RTX 3060 geeignet

## Bekannte Risiken

- lokale Modellqualität und Geschwindigkeit unterscheiden sich stark zwischen RTX 3060 und GTX 1050
- ATM10 und Javis dürfen den ASUS-Laptop nicht gleichzeitig überlasten
- Secrets können über Logs, Prompts, Screenshots oder Git abfließen
- Prompt Injection aus später eingelesenen Notizen oder Webseiten
- unkontrollierter Obsidian-Schreibzugriff könnte Wissen beschädigen
- Self-hosted LiveSync ist kein Ersatz für ein getestetes Backup
- unnötige Plugins, Agenten und Cloud-Connectoren erhöhen Rechte-, Wartungs- und Tokenbedarf

## Nächster sinnvoller Auftrag

Der genehmigte nächste Meilenstein ist `feat/core-chat`:

1. vorbereiteten lokalen CLI-Chat mit Provider-Schnittstelle und SQLite-Sitzungen
   in den Feature-Branch übernehmen
2. Unit-, Ruff-, Persistenz-, Secret- und echten CLI-Modell-Smoke-Test ausführen
3. Dokumentation und Handoff auf den tatsächlichen Endstand bringen
4. Feature-Branch pushen und nur bei vollständig erfüllter Abnahme nach `main` mergen

Nicht Teil dieses Meilensteins: Obsidian-Integration, Serverzugriff, Sprache, Mobile Client oder Living-Mind-Code.