docs: update core chat status

2026-07-30 17:04:46 +02:00
parent b153daa989
commit 5d567e5301
13 changed files with 173 additions and 63 deletions
@@ -1,4 +1,6 @@
-# Non-secret process overrides only.
-JAVIS_DISPLAY_NAME=Javis
-JAVIS_CONFIG_PATH=config/javis.toml
-JAVIS_SECRETS_PROVIDER=none
+# Optionale, nicht geheime Prozesswerte. Diese Datei wird nicht automatisch geladen.
+JAVIS_DATA_DIR=D:\Javis-Data\runtime
+JAVIS_PROVIDER=ollama
+JAVIS_MODEL=qwen3:8b
+JAVIS_OLLAMA_URL=http://127.0.0.1:11434
+JAVIS_MODEL_TIMEOUT=180
@@ -14,6 +14,10 @@ Alle wesentlichen Projektänderungen werden hier in verständlicher Form dokumen
 - Phasenbezogene Empfehlung für Entwicklungswerkzeuge, VS-Code-Erweiterungen, Obsidian und lokale Modelllaufzeiten.
 - Dokumentierte, portable Ollama-Laufzeit 0.32.5 und genau ein lokales Modell
  `qwen3:8b` außerhalb des Repositories.
+- Lokaler Ollama-Provider und ausführbarer `javis chat`-Einstiegspunkt.
+- SQLite-Sitzungen mit geordneter Nachrichtenhistorie außerhalb des Repositories.
+- CLI-Befehle für neue, gelistete, geladene, geleerte und beendete Sitzungen.
+- Unit-Tests für Konfiguration, Speicher, Chatkern, Provider und CLI.

 ### Changed

@@ -24,6 +28,7 @@ Alle wesentlichen Projektänderungen werden hier in verständlicher Form dokumen
 - Isolierte Python-3.12-Entwicklungsumgebung mit uv-Lockfile und Ruff vorbereitet.
 - Offizielle VS-Code-Erweiterungen für Python, Pylance und Python Environments eingerichtet.
 - `qwen3:8b` mit echten deutschen Antworten und GPU-/Zeitmessungen auf der RTX 3060 geprüft.
+- Projektstatus, Architektur und Datenmodell auf den funktionierenden Textchat aktualisiert.

 ### Security

@@ -4,16 +4,33 @@ Javis ist ein langfristiges, lokal-first ausgerichtetes Projekt für einen pers

 ## Aktueller Stand

-Dieses Repository enthält ausschließlich das sichere Projektgrundgerüst und die Architektur-Dokumentation der Phase 0. Es gibt noch:
+Der erste lokale Textchat funktioniert auf Windows mit Ollama und `qwen3:8b`.
+Er bietet echte lokale Modellantworten ohne Cloud-Fallback, neue und fortsetzbare
+Sitzungen sowie SQLite-Persistenz außerhalb des Repositories.

- keinen KI-Chat,
- keine Modellanbindung,
- keinen Obsidian-Schreibzugriff,
- keinen Serverzugriff,
- keine Sprachpipeline,
- keine Living-Mind-Implementierung.
+Noch nicht implementiert sind Obsidian-Zugriff, Serverzugriff, Sprache, Mobile
+Client und Living Mind.

-Der nächste Entwicklungsschritt beginnt erst nach Pascals Prüfung auf einem eigenen Feature-Branch.
+## Lokaler Start
+
+Ollama läuft in einem eigenen Terminal ausschließlich auf localhost:
+
+```powershell
+$env:OLLAMA_MODELS = 'D:\Javis-Data\ollama-models'
+$env:OLLAMA_HOST = '127.0.0.1:11434'
+& 'D:\Javis-Tools\ollama\ollama.exe' serve
+```
+
+Der Chat startet aus dem Repository in einem zweiten Terminal:
+
+```powershell
+$env:UV_CACHE_DIR = 'D:\Javis-Tools\uv-cache'
+$env:JAVIS_DATA_DIR = 'D:\Javis-Data\runtime'
+& 'D:\Javis-Tools\uv\uv.exe' run javis chat
+```
+
+Im Chat zeigt `/help` alle Befehle. Ohne `JAVIS_DATA_DIR` nutzt Javis einen
+sicheren benutzerspezifischen Plattformstandard.

 ## Grundregeln

@@ -29,9 +46,11 @@ Der nächste Entwicklungsschritt beginnt erst nach Pascals Prüfung auf einem ei
 - [Projektstatus](docs/PROJECT_STATUS.md)
 - [Roadmap](docs/ROADMAP.md)
 - [Architektur](docs/ARCHITECTURE.md)
+- [Lokales Modell](docs/LOCAL_MODEL.md)
+- [Entwicklungsumgebung](docs/DEVELOPMENT_SETUP.md)
 - [Sicherheit](docs/SECURITY.md)
 - [Nächste Sitzung](docs/NEXT_SESSION.md)
- [Vollständiger Handoff](docs/CHATGPT_HANDOFF.md)
+- [Kompakter Handoff](docs/CHATGPT_HANDOFF.md)

 ## Historischer Verbindungstest

@@ -1,12 +1,18 @@
+# Entwurf für eine spätere TOML-Konfiguration.
+# Der erste Chat liest die in .env.example genannten Umgebungsvariablen.
+
 [app]
 display_name = "Javis"
 language = "de"

 [paths]
-runtime_dir = "runtime"
+data_dir = ""

 [providers]
-model = "disabled"
+active = "ollama"
+model = "qwen3:8b"
+ollama_base_url = "http://127.0.0.1:11434"
+timeout_seconds = 180
 cloud_fallback = false

 [obsidian]
@@ -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.
@@ -45,8 +45,8 @@ Rootserver:

 ## 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.
+- Der erste lokale Textchat ist auf `feat/core-chat` implementiert und abgenommen.
+- `uv run javis chat` liefert echte lokale Antworten und speichert Sitzungen in SQLite.
 - 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.
@@ -58,15 +58,19 @@ Rootserver:
 - 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.
+- CLI-Befehle: `/new`, `/sessions`, `/load <ID>`, `/clear`, `/help`, `/exit`.
+- Sitzungsdaten liegen über `JAVIS_DATA_DIR` außerhalb von Git; der bestätigte
+  Smoke-Test nutzte `D:\Javis-Data\runtime\core-chat-smoke`.
 - Kein Obsidian-, Laptop- oder Rootserverzugriff wurde implementiert.
- Keine KI-, Sprach-, Mobil- oder Statusfunktion ist implementiert.
+- Keine Tool-, Sprach-, Mobil-, Status- oder Living-Mind-Funktion 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
+- Ollama-Provider akzeptiert nur lokale HTTP-Loopback-Adressen
+- SQLite-Sitzungsspeicher mit atomaren Benutzer-/Assistentenpaaren
 - 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
@@ -92,11 +96,15 @@ Rootserver:
 - 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.
+- Chatkern, Ollama-Provider, zentrale Konfiguration, SQLite-Speicher und CLI implementiert.
+- 13 Unit-Tests für Konfiguration, Speicher, Verlauf, Providervertrag und CLI ergänzt.
+- Echten CLI-Chat ausgeführt und dieselbe Sitzung in einem neuen Prozess geladen,
+  aufgelistet und erfolgreich mit einer weiteren Modellantwort fortgesetzt.
 - Obsidian, Ubuntu-Laptop und Rootserver blieben unverändert.

 ## Aktuelle Tests

-Letzter bestätigter Grundgerüststand:
+Letzter bestätigter Projektstand:

 - Strukturprüfung: bestanden
 - Unit-Test des Paketgerüsts: bestanden
@@ -107,6 +115,9 @@ Letzter bestätigter Grundgerüststand:
 - uv-Lock und `uv sync --dev`: bestanden
 - Python in `.venv`: 3.12.13
 - Ruff in `.venv`: 0.16.0
+- Unit-Tests: 13 bestanden
+- Ruff Lint: bestanden
+- Ruff Formatprüfung: bestanden

 Lokaler Modell-Smoke-Test:

@@ -117,9 +128,12 @@ Lokaler Modell-Smoke-Test:
 - 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.
+CLI-/Persistenz-Smoke:
+
+- neuer CLI-Prozess erzeugte eine Sitzung und erhielt eine echte Modellantwort
+- zweiter CLI-Prozess lud dieselbe UUID und zeigte zwei gespeicherte Nachrichten
+- `/sessions` listete Provider, Modell und Nachrichtenanzahl korrekt
+- fortgesetzte Frage erhielt die echte lokale Antwort `4`

 ## Git-Stand

@@ -129,6 +143,9 @@ Feature-Branch übernommen.
 - letzter Commit vor der Handoff-Verdichtung: `0e82748`
 - Handoff-Verdichtung auf `main`: `e6eb995`
 - Python-Entwicklungsumgebung auf dem Feature-Branch: `fa90a5c`
+- Laufzeit-/Modelldokumentation: `10d7cd7`
+- Chatkern und CLI: `ec9b2f9`
+- Unit-Tests: `b153daa`
 - `origin` verwendet HTTPS
 - kein Force-Push und keine umgeschriebene Historie

@@ -140,11 +157,13 @@ Feature-Branch übernommen.
 - `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
+- aktuell: lokaler CLI-Chat und persistente SQLite-Sitzungen vollständig abgenommen

 ## Offene Entscheidungen und Fehler

 - endgültiger Produkt-/Repositoryname bleibt offen
 - Startmechanismus für Ollama ist noch bewusst manuell und nur pro Prozess konfiguriert
+- Antworten werden noch nicht gestreamt; Sitzungen besitzen noch keine Titel oder Suche
 - 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
@@ -162,12 +181,10 @@ Feature-Branch übernommen.

 ## 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
+Nach Merge von `feat/core-chat` den Chat gemeinsam im Alltag benutzen und zuerst
+konkrete Bedienungs- oder Stabilitätsprobleme sammeln. Mögliche kleine Folgepakete
+sind ein klarer Start-/Stoppablauf, Streaming, Sitzungstitel oder eine explizite
+lokale TOML-Konfiguration. Das spätere Laptop-Modell wird erst auf dessen Hardware
+gemessen und separat entschieden.

 Nicht Teil dieses Meilensteins: Obsidian-Integration, Serverzugriff, Sprache, Mobile Client oder Living-Mind-Code.
@@ -1,18 +1,23 @@
-# Datenmodell – Entwurf
+# Datenmodell

 ## Laufzeitdaten

-Eine spätere strukturierte Datenbank kann mindestens enthalten:
+Der erste Chat verwendet SQLite mit zwei Tabellen:

- `sessions`: Beginn, Ende und aktiver Kontext
- `messages`: Rolle, Inhalt, Zeit und Providerreferenz
- `tasks`: Status, Projekt, Fälligkeit und Quelle
- `approvals`: angefragte Aktion, Entscheidung und Zeitpunkt
- `tool_calls`: Toolname, bereinigte Parameter, Ergebnisstatus und Dauer
- `memories`: Aussage, Quelle, Gültigkeit und Bestätigung
- `source_documents`: Pfad, Änderungszeit und Indexstatus
+- `sessions`: UUID, Erstellungs-/Änderungszeit, Provider und Modell
+- `messages`: Sitzungsbezug, feste Reihenfolge, Rolle, Inhalt und Zeitstempel

-SQLite ist der bevorzugte erste Kandidat, aber noch nicht implementiert.
+Nachrichtenrollen sind auf `user` und `assistant` begrenzt. Ein Benutzer-/
+Assistentenpaar wird erst nach erfolgreicher Modellantwort in einer Transaktion
+gespeichert. Fremdschlüssel und eine eindeutige Nachrichtenposition sichern die
+Reihenfolge.
+
+Der Pfad ist über `JAVIS_DATA_DIR` konfigurierbar. Ohne Override wird unter Windows
+`%LOCALAPPDATA%\Javis` und unter Linux `$XDG_DATA_HOME/javis` beziehungsweise
+`~/.local/share/javis` verwendet. Die Datenbank liegt nie im Repository.
+
+Aufgaben, Freigaben, Toolaufrufe, Erinnerungen und Quelldokumente sind noch nicht
+implementiert und werden erst bei einem konkreten Arbeitspaket modelliert.

 ## Obsidian

@@ -7,7 +7,9 @@
 | ADR-0003 | Obsidian-Links benötigen echte inhaltliche Beziehungen | angenommen |
 | ADR-0004 | Tokenbewusst arbeiten, ohne Qualität oder Sicherheit zu senken | angenommen |
 | ADR-0005 | Laufenden Handoff kompakt halten und Vollstände nur zu Meilensteinen archivieren | angenommen |
+| ADR-0006 | Ollama und qwen3:8b für den ersten Windows-Chat verwenden | angenommen |

-Offen bleiben insbesondere die konkrete lokale Modelllaufzeit, das endgültige Runtime-Secret-System, der genaue Obsidian-Schreibbereich und der Produktname.
+Offen bleiben insbesondere das endgültige Runtime-Secret-System, der genaue
+Obsidian-Schreibbereich, das spätere Laptop-Modell und der Produktname.

 Ausführliche Begründungen stehen unter [`docs/adr`](adr/README.md).
@@ -30,9 +30,24 @@ Typische Befehle aus dem Repository:
 $env:UV_PYTHON_INSTALL_DIR = 'D:\Javis-Tools\python'
 $env:UV_CACHE_DIR = 'D:\Javis-Tools\uv-cache'
 & 'D:\Javis-Tools\uv\uv.exe' sync --dev
-& 'D:\Javis-Tools\uv\uv.exe' run javis chat
+& 'D:\Javis-Tools\uv\uv.exe' run python -m unittest discover -s tests/unit -v
 & 'D:\Javis-Tools\uv\uv.exe' run ruff check .
 & 'D:\Javis-Tools\uv\uv.exe' run ruff format --check .
 ```

+Vor dem Chat wird Ollama in einem eigenen Terminal gestartet:
+
+```powershell
+$env:OLLAMA_MODELS = 'D:\Javis-Data\ollama-models'
+$env:OLLAMA_HOST = '127.0.0.1:11434'
+& 'D:\Javis-Tools\ollama\ollama.exe' serve
+```
+
+Danach:
+
+```powershell
+$env:JAVIS_DATA_DIR = 'D:\Javis-Data\runtime'
+& 'D:\Javis-Tools\uv\uv.exe' run javis chat
+```
+
 Die absoluten Pfade sind ausschließlich lokale Entwicklungsdokumentation. Der Anwendungscode darf keine festen Windows-Pfade enthalten.
@@ -2,8 +2,8 @@

 ## Ziel

-Nächstes Arbeitspaket auf `feat/core-chat`: den vorbereiteten lokalen CLI-Textchat
-mit SQLite-Sitzungen übernehmen, vollständig testen und dokumentieren.
+Nach Abschluss und Merge von `feat/core-chat`: den ersten Textchat gemeinsam
+benutzen und nur konkrete Bedienungs- oder Stabilitätsprobleme priorisieren.

 ## Vor Änderungen erneut prüfen

@@ -14,10 +14,11 @@ mit SQLite-Sitzungen übernehmen, vollständig testen und dokumentieren.

 ## Vorgeschlagener Umfang

- lokale Konfiguration, Provider-Schnittstelle und SQLite-Sitzungen implementieren
- CLI mit neuen, gelisteten und fortsetzbaren Sitzungen
- Unit-, Ruff-, Persistenz-, Secret- und echter CLI-Modell-Smoke-Test
- Feature-Branch pushen und nur bei erfüllter Abnahme nach `main` mergen
+- Start-/Stoppablauf von Ollama auf Alltagstauglichkeit prüfen
+- reale mehrteilige Gespräche und verständliche Fehlermeldungen beobachten
+- bei Bedarf Streaming, Sitzungstitel oder eine explizite lokale TOML-Konfiguration
+  als eigenes kleines Feature planen
+- erst nach Messung auf der Zielhardware ein kleineres Laptop-Modell auswählen

 ## Nicht beginnen

@@ -1,6 +1,6 @@
 # Projektstatus

-Stand: lokale Modelllaufzeit auf `feat/core-chat`, 30.07.2026.
+Stand: lokaler Textchat auf `feat/core-chat`, 30.07.2026.

 ## Erreicht

@@ -19,21 +19,29 @@ Stand: lokale Modelllaufzeit auf `feat/core-chat`, 30.07.2026.
 - `qwen3:8b` (Q4_K_M, 5,2 GB, Apache-2.0) unter `D:\Javis-Data` geladen
 - zwei echte deutsche Modellantworten erfolgreich vollständig auf der RTX 3060 erzeugt
 - kalter Test 36,19 s, warmer Kurztest 0,56 s; geladene GPU-Belegung 6.842 MiB
+- lokaler Ollama-Provider, zentrale Konfiguration und SQLite-Sitzungsspeicher implementiert
+- CLI mit `/new`, `/sessions`, `/load`, `/clear`, `/help` und `/exit` implementiert
+- echte CLI-Modellantwort sowie Laden und Fortsetzen derselben Sitzung in einem
+  neuen Prozess bestätigt
+- 13 Unit-Tests, Ruff und Strukturprüfung erfolgreich

 ## Nicht implementiert

-CLI-Chat, Provider im Repository, Sitzungsspeicher, Obsidian-Adapter, Tools,
-Serverzugriff, Sprache, Mobile Client und Living-Mind-Frontend.
+Obsidian-Adapter, Tools, Serverzugriff, Sprache, Mobile Client,
+Living-Mind-Frontend und automatische Ollama-Prozessverwaltung.

 ## Git

 - Branch: `feat/core-chat`
 - Grundgerüstcommit: `6d04171`
 - Basis des Feature-Branches: `e6eb995`
- Der aktuelle Feature-Commit ist mit `git log -1` zu ermitteln.
+- Toolchain: `fa90a5c`
+- Laufzeit/Modell: `10d7cd7`
+- Chatkern: `ec9b2f9`
+- Tests: `b153daa`

 ## Bekannte Einschränkung

-Toolchain und lokale Modelllaufzeit sind nutzbar, ohne den Windows-`PATH`, Registry,
-Autostart oder Windows-Dienste zu verändern. Der Textchat ist als Nächstes in den
-Feature-Branch zu übernehmen und vollständig gegen das reale Modell zu prüfen.
+Ollama wird bewusst manuell in einem eigenen Terminal gestartet. Antworten werden
+noch nicht gestreamt; Sitzungen haben noch keine Titel, Suche oder Löschfunktion.
+`qwen3:8b` ist nicht automatisch für die GTX 1050 des späteren Zielhosts geeignet.
@@ -0,0 +1,23 @@
+# ADR-0006: Erste lokale Modelllaufzeit
+
+Status: angenommen am 30.07.2026.
+
+## Entscheidung
+
+Der erste Windows-Textchat verwendet die portable Ollama-Laufzeit 0.32.5 und genau
+das Modell `qwen3:8b` in der GGUF-Quantisierung Q4_K_M. Laufzeit und Modell liegen
+außerhalb des Repositories. Javis akzeptiert für diesen Provider ausschließlich
+eine lokale HTTP-Loopback-Adresse.
+
+## Begründung
+
+Ollama stellt ohne Build, Installer oder Systemdienst eine kleine stabile lokale
+API bereit. Das Modell bleibt unter 10 GB, passt beim bestätigten Test vollständig
+in die RTX 3060 mit 12 GB und liefert deutsche Antworten.
+
+## Folgen
+
+Die Entscheidung gilt für den ersten Gaming-PC-Meilenstein. Sie legt weder die
+endgültige Modelllaufzeit noch das Modell für den ASUS-Laptop mit GTX 1050 4 GB
+fest. Ein späterer Vergleich mit llama.cpp bleibt möglich, wenn messbare
+Anforderungen an Offloading, Quantisierung oder Ressourcensteuerung entstehen.
@@ -5,3 +5,4 @@
 - [ADR-0003: Sinnvolle Obsidian-Verknüpfungen](0003-meaningful-obsidian-links.md)
 - [ADR-0004: Tokenbewusster Arbeitsablauf](0004-token-efficient-workflow.md)
 - [ADR-0005: Kompakter Handoff](0005-compact-handoff.md)
+- [ADR-0006: Erste lokale Modelllaufzeit](0006-first-local-runtime.md)