From 6d041711bc4c1377cdb9ca437ecaf2e9dd9095f1 Mon Sep 17 00:00:00 2001 From: Dystroyer8 Date: Thu, 30 Jul 2026 16:10:02 +0200 Subject: [PATCH] chore: initialize safe Javis project scaffold --- .codex/agents/architect.toml | 7 + .codex/agents/builder.toml | 8 + .codex/agents/scout.toml | 7 + .codex/agents/security-reviewer.toml | 8 + .codex/agents/verifier.toml | 7 + .codex/config.toml | 2 + .env.example | 4 + .gitattributes | 11 + .gitignore | 42 + AGENTS.md | 13 + CHANGELOG.md | 22 + PLANS.md | 21 + READ.ME | 1 - README.md | 40 + config/README.md | 5 + config/javis.example.toml | 19 + docs/ARCHITECTURE.md | 27 + docs/CHATGPT_HANDOFF.md | 1119 ++++++++++++++++++ docs/DATA_MODEL.md | 23 + docs/DECISIONS.md | 11 + docs/ENVIRONMENT_VERIFICATION.md | 39 + docs/FUTURE_LINUX_MIGRATION.md | 38 + docs/NEXT_SESSION.md | 24 + docs/PERMISSIONS.md | 14 + docs/PROJECT_STATUS.md | 26 + docs/ROADMAP.md | 15 + docs/SECURITY.md | 32 + docs/THREAT_MODEL.md | 26 + docs/adr/0001-modular-monolith.md | 5 + docs/adr/0002-secret-isolation.md | 5 + docs/adr/0003-meaningful-obsidian-links.md | 7 + docs/adr/README.md | 5 + interface/living-mind/DATA_CONTRACT_DRAFT.md | 14 + interface/living-mind/README.md | 7 + interface/living-mind/STATUS.md | 9 + interface/living-mind/reference/README.md | 3 + pyproject.toml | 17 + runtime/README.md | 3 + scripts/verify_structure.py | 63 + src/javis/__init__.py | 6 + src/javis/audit/__init__.py | 1 + src/javis/config/__init__.py | 1 + src/javis/core/__init__.py | 1 + src/javis/interface/__init__.py | 1 + src/javis/memory/__init__.py | 1 + src/javis/obsidian/__init__.py | 1 + src/javis/providers/__init__.py | 1 + src/javis/security/__init__.py | 1 + src/javis/status/__init__.py | 1 + src/javis/tools/__init__.py | 1 + tests/fixtures/README.md | 3 + tests/integration/README.md | 3 + tests/unit/test_package_metadata.py | 14 + 53 files changed, 1784 insertions(+), 1 deletion(-) create mode 100644 .codex/agents/architect.toml create mode 100644 .codex/agents/builder.toml create mode 100644 .codex/agents/scout.toml create mode 100644 .codex/agents/security-reviewer.toml create mode 100644 .codex/agents/verifier.toml create mode 100644 .codex/config.toml create mode 100644 .env.example create mode 100644 .gitattributes create mode 100644 .gitignore create mode 100644 AGENTS.md create mode 100644 CHANGELOG.md create mode 100644 PLANS.md delete mode 100644 READ.ME create mode 100644 README.md create mode 100644 config/README.md create mode 100644 config/javis.example.toml create mode 100644 docs/ARCHITECTURE.md create mode 100644 docs/CHATGPT_HANDOFF.md create mode 100644 docs/DATA_MODEL.md create mode 100644 docs/DECISIONS.md create mode 100644 docs/ENVIRONMENT_VERIFICATION.md create mode 100644 docs/FUTURE_LINUX_MIGRATION.md create mode 100644 docs/NEXT_SESSION.md create mode 100644 docs/PERMISSIONS.md create mode 100644 docs/PROJECT_STATUS.md create mode 100644 docs/ROADMAP.md create mode 100644 docs/SECURITY.md create mode 100644 docs/THREAT_MODEL.md create mode 100644 docs/adr/0001-modular-monolith.md create mode 100644 docs/adr/0002-secret-isolation.md create mode 100644 docs/adr/0003-meaningful-obsidian-links.md create mode 100644 docs/adr/README.md create mode 100644 interface/living-mind/DATA_CONTRACT_DRAFT.md create mode 100644 interface/living-mind/README.md create mode 100644 interface/living-mind/STATUS.md create mode 100644 interface/living-mind/reference/README.md create mode 100644 pyproject.toml create mode 100644 runtime/README.md create mode 100644 scripts/verify_structure.py create mode 100644 src/javis/__init__.py create mode 100644 src/javis/audit/__init__.py create mode 100644 src/javis/config/__init__.py create mode 100644 src/javis/core/__init__.py create mode 100644 src/javis/interface/__init__.py create mode 100644 src/javis/memory/__init__.py create mode 100644 src/javis/obsidian/__init__.py create mode 100644 src/javis/providers/__init__.py create mode 100644 src/javis/security/__init__.py create mode 100644 src/javis/status/__init__.py create mode 100644 src/javis/tools/__init__.py create mode 100644 tests/fixtures/README.md create mode 100644 tests/integration/README.md create mode 100644 tests/unit/test_package_metadata.py diff --git a/.codex/agents/architect.toml b/.codex/agents/architect.toml new file mode 100644 index 0000000..de63208 --- /dev/null +++ b/.codex/agents/architect.toml @@ -0,0 +1,7 @@ +name = "architect" +description = "Read-only architecture reviewer for bounded design decisions." +sandbox_mode = "read-only" +developer_instructions = """ +Evaluate the requested architecture question without editing production files. +Offer at most three realistic options, label assumptions, and make one clear recommendation with tradeoffs. +""" diff --git a/.codex/agents/builder.toml b/.codex/agents/builder.toml new file mode 100644 index 0000000..3665434 --- /dev/null +++ b/.codex/agents/builder.toml @@ -0,0 +1,8 @@ +name = "builder" +description = "The only custom agent allowed to make scoped production-file changes." +sandbox_mode = "workspace-write" +developer_instructions = """ +Implement only explicitly approved, narrowly scoped changes. +Preserve existing work, avoid architecture drift, run relevant tests, and summarize changed files. +Never edit Obsidian, servers, system configuration, or secrets. +""" diff --git a/.codex/agents/scout.toml b/.codex/agents/scout.toml new file mode 100644 index 0000000..1efa526 --- /dev/null +++ b/.codex/agents/scout.toml @@ -0,0 +1,7 @@ +name = "scout" +description = "Read-only repository scout for locating relevant files and relationships." +sandbox_mode = "read-only" +developer_instructions = """ +Work read-only. Find only the files and relationships needed for the assigned question. +Return at most ten concise points with file references. Do not dump full logs or propose unrelated work. +""" diff --git a/.codex/agents/security-reviewer.toml b/.codex/agents/security-reviewer.toml new file mode 100644 index 0000000..7f54bcd --- /dev/null +++ b/.codex/agents/security-reviewer.toml @@ -0,0 +1,8 @@ +name = "security_reviewer" +description = "Read-only reviewer for actual security-sensitive changes." +sandbox_mode = "read-only" +developer_instructions = """ +Review only the security-relevant scope requested. +Prioritize authentication, permissions, paths, secrets, tools, APIs, networking, and deployment. +Return findings ordered by severity with evidence and do not modify files. +""" diff --git a/.codex/agents/verifier.toml b/.codex/agents/verifier.toml new file mode 100644 index 0000000..b6a7147 --- /dev/null +++ b/.codex/agents/verifier.toml @@ -0,0 +1,7 @@ +name = "verifier" +description = "Read-only verifier for tests, structure, and behavior claims." +sandbox_mode = "read-only" +developer_instructions = """ +Run or inspect the requested verification without changing production files. +Report commands, pass/fail results, and concise evidence. Do not hide failures or silently repair them. +""" diff --git a/.codex/config.toml b/.codex/config.toml new file mode 100644 index 0000000..b345ee4 --- /dev/null +++ b/.codex/config.toml @@ -0,0 +1,2 @@ +[agents] +max_concurrent_threads_per_session = 2 diff --git a/.env.example b/.env.example new file mode 100644 index 0000000..6b1c274 --- /dev/null +++ b/.env.example @@ -0,0 +1,4 @@ +# Non-secret process overrides only. +JAVIS_DISPLAY_NAME=Javis +JAVIS_CONFIG_PATH=config/javis.toml +JAVIS_SECRETS_PROVIDER=none diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 0000000..9236d76 --- /dev/null +++ b/.gitattributes @@ -0,0 +1,11 @@ +* text=auto eol=lf + +*.bat text eol=crlf +*.cmd text eol=crlf +*.ps1 text eol=crlf +*.png binary +*.jpg binary +*.jpeg binary +*.gif binary +*.webp binary +*.pdf binary diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..956b6fc --- /dev/null +++ b/.gitignore @@ -0,0 +1,42 @@ +# Local environments and caches +.venv/ +venv/ +__pycache__/ +*.py[cod] +.pytest_cache/ +.mypy_cache/ +.ruff_cache/ + +# Local configuration and secrets +.env +.env.* +!.env.example +key-pw.xml +secrets.local.xml +*.local.xml +config/javis.toml +config/*secret*.xml +!config/*.example.xml + +# Runtime data +runtime/* +!runtime/README.md +*.db +*.sqlite +*.sqlite3 +logs/ +models/ +indexes/ + +# Private knowledge and editor state +.obsidian/ +Obsidian Vault/ +.vscode/ + +# Build and operating-system artifacts +build/ +dist/ +*.egg-info/ +.DS_Store +Thumbs.db +desktop.ini diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000..0f344ee --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,13 @@ +# Javis – dauerhafte Codex-Regeln + +- Erkläre Pascal Änderungen und Ergebnisse auf Deutsch; Code und technische Bezeichner dürfen Englisch sein. +- Prüfe vor Änderungen Pfad, Branch, Arbeitsbaum und betroffene Dateien. +- Bevorzuge kleine, nachvollziehbare Änderungen und führe passende Tests ehrlich aus. +- Lies oder veröffentliche keine Geheimwerte. Maskiere Secrets in Ausgaben und Logs. +- Lösche oder verschiebe nichts außerhalb dieses Repositorys. +- Kein Force-Push und kein Umschreiben bestehender Git-Historie. +- Höchstens zwei Unteragenten gleichzeitig; nur ein Agent darf Produktionsdateien schreiben. +- Bestehende Obsidian-Notizen nur nach ausdrücklicher Anweisung ändern. `.obsidian` nie verändern. +- Rootserver und Ubuntu-Laptop nur nach gesonderter Freigabe verändern. +- Aktualisiere nach wesentlichen Sitzungen `docs/PROJECT_STATUS.md`, `docs/DECISIONS.md`, `docs/NEXT_SESSION.md`, `docs/CHATGPT_HANDOFF.md` und `CHANGELOG.md`. +- Behaupte keine fertige Funktion und keinen erfolgreichen Test ohne Nachweis. diff --git a/CHANGELOG.md b/CHANGELOG.md new file mode 100644 index 0000000..169eb1a --- /dev/null +++ b/CHANGELOG.md @@ -0,0 +1,22 @@ +# Changelog + +Alle wesentlichen Projektänderungen werden hier in verständlicher Form dokumentiert. + +## Unreleased + +### Added + +- Sicheres, plattformunabhängiges Projektgrundgerüst. +- Architektur-, Sicherheits-, Berechtigungs- und Statusdokumentation. +- Inaktiver Living-Mind-Bereich ohne Demo- oder Fantasiedaten. +- Eng begrenzte projektinterne Codex-Agentenrollen. +- Abhängigkeitsfreier Strukturprüfer. + +### Changed + +- Der historische Verbindungstest aus `READ.ME` wurde in `README.md` übernommen. + +### Security + +- Lokale Secret-Dateien, Laufzeitdaten, Modelle, Datenbanken und Logs werden von Git ausgeschlossen. +- Das Sprachmodell darf keine Secret-Werte erhalten. diff --git a/PLANS.md b/PLANS.md new file mode 100644 index 0000000..7930105 --- /dev/null +++ b/PLANS.md @@ -0,0 +1,21 @@ +# Arbeitsplan + +## Phase 0 – Grundgerüst + +- [x] Projekt- und Vault-Pfade lesend prüfen +- [x] Architektur- und Sicherheitsgrenzen dokumentieren +- [x] Schlankes Repository-Grundgerüst vorbereiten +- [ ] Strukturtests im Ziel-Repository ausführen +- [ ] Grundgerüst committen und pushen + +## Phase 1 – Textkern + +Erst nach Pascals Abnahme: + +1. Branch `feat/core-chat` erstellen. +2. lokale Python-Toolchain auswählen und nach Freigabe installieren. +3. Konfigurations- und Provider-Schnittstellen implementieren. +4. einfache lokale CLI mit echtem Provider, Sitzungsverlauf und klaren Fehlern bauen. +5. Unit- und Integrationstests ergänzen. + +Spätere Phasen stehen in [docs/ROADMAP.md](docs/ROADMAP.md). diff --git a/READ.ME b/READ.ME deleted file mode 100644 index c68166f..0000000 --- a/READ.ME +++ /dev/null @@ -1 +0,0 @@ -Hi. Test Commit für verknüpfung \ No newline at end of file diff --git a/README.md b/README.md new file mode 100644 index 0000000..880e749 --- /dev/null +++ b/README.md @@ -0,0 +1,40 @@ +# Javis + +Javis ist ein langfristiges, lokal-first ausgerichtetes Projekt für einen persönlichen, modularen KI-Assistenten. Das Ziel umfasst später Textchat, Gedächtnis, Aufgaben und Notizen, kontrollierte Werkzeuge, technische Statusabfragen, Sprache und eine beobachtende Living-Mind-Oberfläche. + +## Aktueller Stand + +Dieses Repository enthält ausschließlich das sichere Projektgrundgerüst und die Architektur-Dokumentation der Phase 0. Es gibt noch: + +- keinen KI-Chat, +- keine Modellanbindung, +- keinen Obsidian-Schreibzugriff, +- keinen Serverzugriff, +- keine Sprachpipeline, +- keine Living-Mind-Implementierung. + +Der nächste Entwicklungsschritt beginnt erst nach Pascals Prüfung auf einem eigenen Feature-Branch. + +## Grundregeln + +- Plattformunabhängiger modularer Monolith, voraussichtlich in Python. +- Lokal-first; Cloudanbieter sind optionale und standardmäßig deaktivierte Adapter. +- Keine Secrets im Code, in Git, in Prompts oder Logs. +- Keine freie Shell für ein Sprachmodell. +- Obsidian-Verknüpfungen bilden nur echte inhaltliche Beziehungen ab. Eine gehirnartige Graphansicht soll aus sinnvoller Struktur entstehen, nicht aus Dekorationslinks. +- Kritische oder schreibende Aktionen benötigen klar definierte Berechtigungen und Freigaben. + +## Orientierung + +- [Projektstatus](docs/PROJECT_STATUS.md) +- [Roadmap](docs/ROADMAP.md) +- [Architektur](docs/ARCHITECTURE.md) +- [Sicherheit](docs/SECURITY.md) +- [Nächste Sitzung](docs/NEXT_SESSION.md) +- [Vollständiger Handoff](docs/CHATGPT_HANDOFF.md) + +## Historischer Verbindungstest + +Der bisherige Inhalt von `READ.ME` wird hier unverändert erhalten: + +> Hi. Test Commit f?r verkn?pfung diff --git a/config/README.md b/config/README.md new file mode 100644 index 0000000..7707c37 --- /dev/null +++ b/config/README.md @@ -0,0 +1,5 @@ +# Konfiguration + +`javis.example.toml` dokumentiert ausschließlich nicht geheime Einstellungen. Für den lokalen Betrieb wird später eine ignorierte `javis.toml` erzeugt. + +Secret-Werte gehören nicht in TOML, Code oder Git. Die bevorzugte Zielarchitektur verwendet einen Secret-Provider, beispielsweise Betriebssystem-Keyring, geschützte Umgebungsvariablen oder später Docker Secrets. Falls Pascal XML nutzt, liegt die echte Datei nur lokal, mit restriktiven Rechten und Git-Ausschluss. Das Modell erhält niemals ihren Inhalt. diff --git a/config/javis.example.toml b/config/javis.example.toml new file mode 100644 index 0000000..c6d8538 --- /dev/null +++ b/config/javis.example.toml @@ -0,0 +1,19 @@ +[app] +display_name = "Javis" +language = "de" + +[paths] +runtime_dir = "runtime" + +[providers] +model = "disabled" +cloud_fallback = false + +[obsidian] +enabled = false +vault_path = "" +write_areas = [] + +[security] +secrets_provider = "none" +require_approval_for_writes = true diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md new file mode 100644 index 0000000..e6a6937 --- /dev/null +++ b/docs/ARCHITECTURE.md @@ -0,0 +1,27 @@ +# 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. + +## Vorgesehene 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. +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. +8. Audit: nachvollziehbare Aktionen ohne geheime Inhalte. + +## Plattformgrenzen + +- Pfade werden später per Konfiguration und `pathlib` aufgelöst. +- Betriebssystemspezifische Funktionen liegen hinter Adaptern. +- Produktname, Datenpfade und Provider werden zentral konfiguriert. +- Laufzeitdaten liegen außerhalb von Git. + +## Noch nicht implementiert + +Es existieren nur Paketgrenzen und Dokumentation. Es gibt keinen Chat, Provider, Speicher, Toolaufruf oder Netzwerkdienst. diff --git a/docs/CHATGPT_HANDOFF.md b/docs/CHATGPT_HANDOFF.md new file mode 100644 index 0000000..ae6abbd --- /dev/null +++ b/docs/CHATGPT_HANDOFF.md @@ -0,0 +1,1119 @@ +# ChatGPT Project Handoff + +## 1. Übergabezweck + +Diese Datei übergibt ChatGPT den nachweisbaren aktuellen Stand von Pascals geplantem persönlichen KI-Assistenten. ChatGPT soll daraus zusammen mit seinem eigenen tatsächlich verfügbaren Gesprächskontext einen endgültigen Masterprompt für die spätere Entwicklung erstellen. + +Wichtig: Der eigentliche Assistent soll noch nicht gebaut werden. Zuerst erstellt ChatGPT den Masterprompt, Pascal prüft und genehmigt ihn, und erst danach darf Codex mit der Entwicklung beginnen. + +Die Schreibweise ist derzeit nicht einheitlich: Der lokale Ordner heißt `Javis-Projekt`, während das verknüpfte Gitea-Repository tatsächlich `Jarvis-Ai` heißt. Es wurde keine automatische Umbenennung vorgenommen. Bis Pascal die gewünschte endgültige Schreibweise bestätigt, dürfen weder Ordner noch Repository eigenmächtig umbenannt werden. + +## 2. Verwendete Informationsquellen + +Folgende Quellen waren tatsächlich verfügbar: + +- Quelle: vom Nutzer bestätigter Ausgangspunkt im aktuellen Auftrag. +- Quelle: aktuelle lokale Prüfung des Ordners `D:\Javis-Projekt`. +- Quelle: lokale Git-Befehle im Repository. +- Quelle: vorhandene Datei `D:\Javis-Projekt\READ.ME`. +- Quelle: aktuelle Codex-Unterhaltung. +- Quelle: vom Nutzer bereitgestellter Screenshot der Alternate-Bestellübersicht zu den Komponenten des Gaming-PCs. +- Quelle: über die Codex-App lesbar gewordene frühere ChatGPT- und Codex-Aufgaben, insbesondere: + - `KI-Assistent mit Codex` + - `Claude-Link öffnen und einlesen` + - `Erinnerung Überprüfung` + - `Erinnerung Anfrage` + - `Codex mit Gitea koppeln` + - `Codex auf dem Handy` + - `ATM10:CC` + - `Root-Server einrichten` + - `MSI-Laptop genauer identifizieren` – trotz des Titels wurde dort der für dieses Projekt relevante alte Laptop als ASUS ROG Strix GL553VD identifiziert. + - `LS25 Mod mit Animationen schreiben` + - die Aufgabenübersicht mit weiteren Titeln wie `Ls25-Mine programieren`, `Behebe LS25 Shader-Kompilierung`, `Analysiere Spark-Lagspikes` und `Create Automatisierung mit CC`. +- Quelle: die in dieser Codex-Sitzung ausgewiesenen verfügbaren Skills, Plugins, Werkzeuge und Modelle. +- Quelle: lokale Versions- und rein lesende Hardwareabfragen auf dem Windows-PC. + +Nicht zugänglich oder nur teilweise zugänglich: + +- Gelöschte Chats sind nicht zugänglich. +- Eine allgemeine, vollständige ChatGPT-Memory-Datenbank war nicht direkt auslesbar. Lesbar waren nur konkrete vorhandene Aufgaben und deren Nachrichten. +- Anhänge älterer Chats waren nicht generell als Dateien verfügbar. Einzelne alte Aufgaben enthielten Zusammenfassungen oder Hinweise auf frühere Anhänge. +- Der frühere Claude-Chat lag in einer anderen Aufgabe zeitweise als Export vor, ist in dieser lokalen Projektumgebung aber nicht als eigenständige Datei erreichbar. Relevante daraus bereits verdichtete Entscheidungen waren über den späteren ChatGPT-Verlauf lesbar. +- Der tatsächliche Obsidian-Vault-Inhalt und sein lokaler Pfad waren nicht zugänglich. +- Server, Ubuntu-Laptop, Gitea-Weboberfläche, CouchDB, Portainer und Obsidian wurden in diesem Auftrag nicht live verbunden oder neu geprüft. + +## 3. Zeitstempel und Umgebung + +- Prüfung: 30.07.2026, etwa 15:00 Uhr, Zeitzone Europe/Berlin beziehungsweise Windows-Zeitzone `W. Europe Standard Time`, UTC+02:00. +- Aktueller Rechner: selbst zusammengestellter Windows-Gaming-PC auf Basis eines ASRock-X870-Mainboards. +- Betriebssystem: Microsoft Windows 11 Pro, 64 Bit, Version `10.0.26200`, Build `26200`. +- Tatsächlicher Projektpfad: `D:\Javis-Projekt`. +- Ursprünglich von Codex bereitgestellter, aber nicht zum Projekt gehörender Sitzungsordner: `C:\Users\pasca\Documents\Codex\2026-07-30\er`. +- Codex läuft als lokale Windows-App. + +Quelle: aktuelle lokale Prüfung und vom Nutzer bestätigt. + +## 4. Informationen über Pascal + +- Name: Pascal. +- Er betreibt eine private, selbst gehostete technische Umgebung mit Rootserver, Gitea, Docker-Diensten, Obsidian-Synchronisation und Gameservern. +- Er entwickelt und testet auf einem Windows-Gaming-PC und verwendet VS Code und Codex. +- Er beschäftigt sich intensiv mit Minecraft-Modpacks und Automatisierung, insbesondere ATM10, AE2/ME, Create, ComputerCraft/CC:Tweaked, Mekanism, Modern Industrialization und weiteren Technikmods. +- Er arbeitet außerdem an beziehungsweise mit LS25-Modding, Lua, XML, Giants Editor/Blender-Konzepten und AutoDrive. +- Er möchte einen realistischen persönlichen Assistenten nach dem Grundgedanken von Jarvis aus Iron Man, ohne den fiktiven Umfang zu erwarten. +- Er legt Wert auf niedrige laufende Kosten, lokale Kontrolle, nachvollziehbare Schritte und die Weiterverwendung seiner vorhandenen Infrastruktur. + +Nicht zugänglich: Beruf, genauer Arbeitsalltag, Ausbildung, Alter und weitere persönliche Daten wurden in den erreichbaren Quellen nicht sicher genannt. Sie dürfen nicht erfunden werden. + +## 5. Technische Erfahrung und bevorzugte Arbeitsweise + +Pascal ist kein ausgebildeter Programmierer; dies wurde in einem früher vorbereiteten Masterauftrag ausdrücklich so festgehalten. Er kann technische Zusammenhänge und konkrete Schritte grundsätzlich nachvollziehen, benötigt aber bei neuen oder riskanten Themen klare, schrittweise Anleitungen ohne unnötige Fachsprache. + +Nachweisbare praktische Erfahrung: + +- Windows, VS Code und lokale Projektarbeit. +- Git-Grundworkflow mit eigenständigen Repositories, Branches, Commit, Clone, Pull und Push. +- Selbst gehostetes Gitea und funktionierender SSH-Zugriff. +- Linux-Serververwaltung mit konkreten Diagnosebefehlen. +- Docker und Portainer. +- Nginx Proxy Manager, Subdomains und Reverse Proxy. +- UFW-Regeln und Prüfung tatsächlich lauschender Ports. +- AMP und Minecraft-Serverbetrieb. +- Discord-Bots, Webhooks und RCON-bezogene Serverautomatisierung. +- Obsidian und Self-hosted LiveSync über CouchDB. +- LS25-Modding mit Lua/XML sowie Verständnis dafür, dass ein Code-/XML-Gerüst noch kein getestetes 3D-Spielasset ist. +- Komplexe Ingame-Automatisierung in ATM10. + +Bevorzugter Workflow: + +1. Idee und Ziel verständlich erklären. +2. Zustand und Abhängigkeiten zuerst prüfen. +3. Änderungen in kleine, kontrollierbare Etappen teilen. +4. Diff beziehungsweise konkrete geänderte Dateien zeigen. +5. Lokal testen. +6. Erst nach Prüfung committen und pushen. + +Wichtige Fehlerquellen, die vermieden werden sollen: + +- Nicht behaupten, ein Gerüst sei bereits ein fertiges oder getestetes Produkt. +- Keine pauschalen Vermutungen als Fakten darstellen. +- Keine langen, ungefilterten Terminalausgaben verlangen, wenn eine sichere Diagnose möglich ist. +- Keine Zugangsdaten, Webhook-URLs, Tokens oder Passwörter in Chats oder Dateien wiedergeben. +- Keine gleichzeitigen unkoordinierten Änderungen mehrerer Agenten an denselben Dateien. +- Keine unnötig große Projektstruktur oder Agentensammlung auf einmal erzeugen. +- Nicht ohne Freigabe committen, pushen, Dienste veröffentlichen oder Serverkonfigurationen verändern. + +## 6. Frühere relevante Projekte und Erfahrungen + +### Rootserver und Serverwerkzeuge + +In der Aufgabe `Root-Server einrichten` wurde eine größere Serverumgebung gemeinsam diagnostiziert und teilweise ein Werkzeugpaket für Gameserverbetrieb vorbereitet. Dazu gehörten unter anderem: + +- Prüfung von AMP-Instanzen und tatsächlichen Java-Listenern. +- Abgleich von Minecraft-Ports, UFW-Regeln und DNS/SRV-Zielen. +- Unterscheidung zwischen „AMP-Instanz aktiv“ und „Minecraft-Prozess lauscht tatsächlich“. +- Discord- und RCON-basierte Status-, Ankündigungs- und Neustartfunktionen. +- Neustartankündigungen mit längeren Vorwarnungen, 30-Sekunden-Warnung und kurzem Ingame-Countdown. +- Sichere Diagnose, ob Konfigurationswerte gesetzt sind, ohne geheime Werte auszugeben. +- Erkennung eines Discord-403-Problems, weil ein Bot noch nicht auf dem Server beziehungsweise nicht für den Kanal berechtigt war. +- Hinweis, sichtbar gewordene Webhook-URLs wie Passwörter zu behandeln und gegebenenfalls zu erneuern. + +Diese Historie zeigt, dass Pascal konkrete Serverbefehle ausführen und Ausgaben zur Diagnose liefern kann, dabei aber von klaren Prüfblöcken und sicheren Schrittfolgen profitiert. + +### ATM10, ComputerCraft und modulare Fabrikplanung + +Aus `ATM10:CC`, `Create Automatisierung mit CC` und dem erreichbaren Chatkontext: + +- Geplant ist beziehungsweise war eine zentrale ATM10-Basis mit ME-Zentrale, großer CC-Schaltzentrale, Stromüberwachung und Monitoren. +- Kernmods wie Mekanism und Ars Nouveau sollen eigene Bereiche oder Räume erhalten. +- Jedes größere Produktionsgebäude soll einen eigenen lokalen CC-Computer beziehungsweise Server besitzen. +- Ein zentraler CC-Hauptserver soll Gebäudezustände anzeigen und ganze Gebäude starten, stoppen oder in Automatik versetzen können. +- Für Create ist eine modulare Produktion vorgesehen: Bestände überwachen, bei Unterschreitung produzieren, bei Zielbestand stoppen. +- ME dient als zentral sichtbarer Bestand; lokale Puffer und Vaults sollen Produktionsmodule entkoppeln. +- Create-Stress, Drehzahl, Ausgangsbestände und Störungen sollen überwacht werden. +- Hysterese ist wichtig: getrennte Ein- und Ausschaltwerte, damit Maschinen nicht ständig takten. +- Der sichere Grundzustand soll „Maschine aus“ sein, falls der Computer oder das Steuersignal ausfällt. +- CC soll koordinieren und überwachen; Create-Logistik, Factory Gauges, Frogports, Packager und lokale Mechanik sollen nicht unnötig komplett in Lua nachprogrammiert werden. +- Rednet beziehungsweise ein vergleichbares lokales Kommunikationsschema wurde als Verbindung zwischen Hauptleitwarte und Gebäudecomputern betrachtet. +- Weitere konkrete Erfahrungen betreffen AE2-Processing-Patterns, Pattern Provider, gefilterte Ein-/Ausgänge, Modern-Industrialization-Multiblocks, Flüssigkeitsautomation, Create-Spouts/Mixer und Fake-Player-Alternativen. +- Bei einer Runic-Enchanter-Diagnose war der tatsächliche Fehler ein fehlendes Energie-/Leistungsupgrade; Pascal testet Hypothesen praktisch und korrigiert falsche Interpretationen anhand von Screenshots und Gegenproben. + +Diese Erfahrungen sind für Jarvis relevant: Pascal denkt bereits in modularen Steuerungen, lokalen Verantwortungsbereichen, zentraler Übersicht, sicheren Ausfallzuständen und messbaren Systemzuständen. + +### Minecraft- und Modpackbetrieb + +- ATM10 wird überwiegend lokal beziehungsweise privat genutzt. +- Ein ATM10-Server auf dem Ubuntu-Laptop benötigt ungefähr 8 bis 10 GB RAM. +- Es gibt Erfahrung mit großen Modpacks, Chunkloading, FTB Chunks, Performanceproblemen und Spark-Profilen. +- Aus früheren Gesprächen ist bekannt, dass sehr hohe Sichtweiten und große Modpacks erhebliche Ressourcenlast erzeugen. +- Der Rootserver bleibt wegen seiner übrigen Dienste und 16 GB RAM zu knapp für eine zusätzliche lokale KI-Engine. + +### LS25-Modding und Gitea + +Aus `LS25 Mod mit Animationen schreiben`: + +- Ein separates Gitea-Repository für einen LS25-Mod-Prototyp wurde geklont und mit einer Grundstruktur befüllt. +- Erstellt wurden unter anderem `modDesc.xml`, Placeable-XML, eine Platzhalter-i3d, AutoDrive-Layout-Dokumentation und Platzhaltergrafiken. +- XML-Lesbarkeit wurde geprüft, anschließend wurde ein Commit erstellt und nach Gitea gepusht. +- Danach wurde ausdrücklich klargestellt, dass Transform-Nodes und Platzhalter noch kein sichtbares, kollidierendes und getestetes LS25-Modell ergeben. +- Pascal versteht die Trennung zwischen Code-/XML-Gerüst, 3D-Assets, Giants-Editor-Arbeit und tatsächlichem Ingame-Test. +- Für komplett unabhängige Modideen bevorzugt er eigene Repositories statt zweckfremder Branches im bestehenden Projekt. + +### Relevante allgemeine Erkenntnisse + +- Pascal nutzt ChatGPT gern für Konzept, Erklärung und Einordnung; Codex für konkrete lokale Projektarbeit. +- Er möchte unterwegs beziehungsweise vom Handy Aufgaben verfolgen oder steuern können, während Dateien und Zugangsdaten auf dem ausführenden Rechner bleiben. +- Er bevorzugt tatsächliche Funktionalität gegenüber Marketingbegriffen wie „Godmode“ oder hunderten vorgefertigten Agentenrollen. + +## 7. Bestätigte Projektpfade + +- Bestätigter lokaler Projektpfad: `D:\Javis-Projekt` +- Ordnername auf dem Dateisystem: `Javis-Projekt` +- Windows behandelt Groß-/Kleinschreibung üblicherweise nicht als unterschiedliche Pfade; die Buchstabenfolge lautet aber tatsächlich `Javis`, nicht `Jarvis`. +- Git-Toplevel: `D:/Javis-Projekt` +- Vorhandene Projektdatei: `D:\Javis-Projekt\READ.ME` +- Zu erstellende Übergabedatei: `D:\Javis-Projekt\CHATGPT_HANDOFF.md` + +Nicht zugänglich: lokaler Pfad des Obsidian-Vaults. + +## 8. Git-, VS-Code- und Gitea-Status + +Quelle: aktuelle lokale Prüfung. + +- `D:\Javis-Projekt` ist ein Git-Repository. +- Aktueller Branch: `main`. +- Status vor Erstellung dieser Übergabe: sauber, `main...origin/main`. +- Remote-Name: `origin`. +- Remote für Fetch und Push: `https://git.peli-server.de/Dystroyer8/Jarvis-Ai.git` +- Die Remote-Adresse enthält keine eingebetteten Zugangsdaten. +- Lokaler `main` und `origin/main` zeigten vor der Übergabe auf denselben Commit. +- Git-Zugriff auf das Repository funktioniert mindestens lokal; nach Nutzerangabe funktioniert auch SSH zu Gitea grundsätzlich. +- Aus dem früheren LS25-/Gitea-Workflow existiert bereits eine lokale SSH-Schlüsseldatei. Ihr konkreter Pfad und ihr Inhalt sind in dieser Übergabe bewusst nicht dokumentiert; sie darf niemals in Git gelangen oder dem Sprachmodell als Text übergeben werden. +- Der konkret konfigurierte Remote dieses Repositories verwendet aktuell HTTPS, nicht SSH. +- Es wurden keine VS-Code-Projektdateien wie `.vscode/` oder `*.code-workspace` gefunden. +- VS Code wird laut Nutzer verwendet und Git ist dort bereits eingebunden; dies wurde in diesem Auftrag nicht über eine VS-Code-API live geprüft. + +Widerspruch: + +- Im Ausgangspunkt hieß das neue Repository „vermutlich `javis-ai`“. +- Tatsächlich zeigt `origin` auf `Jarvis-Ai.git`. +- Keine Umbenennung vornehmen. Pascal muss später entscheiden, welche Schreibweise endgültig gewünscht ist. + +## 9. Git-Historie und bisherige Projektänderungen + +Quelle: Git-Historie. + +Es existiert genau ein erreichbarer Commit: + +- Kurz-ID: `49a1dd3` +- Vollständige ID: `49a1dd371876350f73e70e11c0e08549fc247722` +- Datum: `2026-07-30T14:26:33+02:00` +- Nachricht: `Test` +- Inhalt: eine neue Datei `READ.ME` mit einer Zeile. + +Der Commit ist sowohl `HEAD -> main` als auch `origin/main`. + +Keine weitere Projektimplementierung war vorhanden. Es existieren noch kein Assistentenkern, keine Architekturdateien, keine Tests, keine Konfiguration und keine Living-Mind-Dateien. + +## 10. Aktuell vorhandene Dateien + +Vor Erstellung dieser Übergabe bestand der Arbeitsbaum außerhalb von `.git` ausschließlich aus: + +- `READ.ME` — 33 Byte; Inhalt sinngemäß: „Hi. Test Commit für Verknüpfung“. + +Besonderheiten: + +- Die Datei heißt tatsächlich `READ.ME`, nicht `README.md`. +- Keine `AGENTS.md`. +- Keine `.gitignore`. +- Keine `.codex/`. +- Keine `.vscode/`. +- Keine `README.md`. +- Keine `living-mind.md`. +- Keine Quellcodedateien. +- Keine Abhängigkeits- oder Paketdateien. + +Nach diesem Auftrag kommt ausschließlich `CHATGPT_HANDOFF.md` hinzu. + +## 11. Lokale Entwicklungsumgebung + +Quelle: aktuelle lokale Versionsabfragen sowie rein lesende Windows-CIM/WMI- und Nvidia-Abfragen. + +### Gaming-PC – genaue Identifikation + +- Plattform/Mainboard: ASRock `X870 Nova WiFi`, Alternate-Art.-Nr. `100147397`, x64. +- BIOS: American Megatrends International, LLC., Version `3.30`, veröffentlicht am 16.06.2025. +- CPU: AMD Ryzen 7 9700X als Boxed-Version, Alternate-Art.-Nr. `100065791`, Sockel AM5, 8 Kerne und hardwareseitig 16 Threads. +- Auffälligkeit: Windows meldete zum Prüfzeitpunkt nur 8 verfügbare logische Prozessoren. Der Hypervisor ist vorhanden und Firmware-Virtualisierung ist aktiviert. Ob die Abweichung durch SMT-, Boot- oder Hypervisor-Konfiguration entsteht, wurde nicht abschließend geklärt und darf nicht als Hardwaredefekt interpretiert werden. +- Arbeitsspeicher: Kingston FURY DIMM 64 GB DDR5-6000 Dual-Kit (2 × 32 GB), Alternate-Art.-Nr. `100052226`; Modul-Teilenummer `KF560C30-32`, aktuell mit 6000 MT/s konfiguriert, SPD-Basistakt 4800 MT/s. Das Board meldet vier RAM-Steckplätze. +- CPU-Kühlung: Alphacool Eisbaer Aurora 280 CPU – Digital RGB, 280-mm-Wasserkühlung, Alternate-Art.-Nr. `1623488`. +- Netzteil: be quiet! Pure Power 13 M 1000W, Alternate-Art.-Nr. `100136411`. +- Dedizierte GPU: MSI GeForce RTX 3060 VENTUS 2X 12G OC, Produktnummer `912-V397-662`, mit 12 GB beziehungsweise 12.288 MiB VRAM, bei Amazon gekauft; Nvidia-Treiber/KMD `610.74`, CUDA-UMD `13.3`. +- Integrierte GPU: AMD Radeon Graphics. +- Die von älteren 32-Bit-WMI-Feldern für die RTX 3060 gemeldeten 4 GB sind ein Überlaufwert und falsch; maßgeblich ist die Nvidia-Abfrage mit 12 GB. + +### Lokale Datenträger und Netzwerk + +- Systemlaufwerk: Samsung SSD 970 EVO Plus 250 GB, NVMe, Zustand gesund; `C:` heißt `Windows+Programme`, NTFS, rund 249 GB nutzbar. +- Daten-/Spielelaufwerk: Samsung SSD 870 QVO 1 TB, SATA, Zustand gesund; `D:` heißt `Games`, NTFS. Dort liegt `D:\Javis-Projekt`. +- Der freie Speicher zum Prüfzeitpunkt betrug ungefähr 74 GB auf `C:` und 210 GB auf `D:`; diese Werte sind Momentaufnahmen. +- Aktiver Netzwerkadapter: Realtek 8922AE WiFi 7 PCI-E NIC; beobachtete Verbindung ungefähr 0,9 Gbit/s. +- Zusätzlich vorhanden, aber zum Prüfzeitpunkt deaktiviert: Realtek PCIe 5GbE Family Controller und Bluetooth-PAN. +- IP-Adressen, MAC-Adressen, Seriennummern und UUIDs wurden nicht in diese Übergabe übernommen. + +### Entwicklungswerkzeuge + +- Windows PowerShell: `5.1.26100.8875`. +- Git: `2.55.0.windows.2`, erreichbar unter `C:\Program Files\Git\cmd\git.exe`. +- Visual Studio Code: `1.131.0`, als Benutzerinstallation vorhanden. +- Codex-Windows-App-Paket: `OpenAI.Codex_26.721.4979.0`. +- Erkennbarer Codex Command Runner: `0.146.0-alpha.3.1`. +- `codex --version`: in der ausgeführten PowerShell-Umgebung nicht aufrufbar. +- Python: nur der WindowsApps-Ausführungsalias wurde gefunden; kein nutzbarer Python-Laufzeitstand und kein `py`-Launcher bestätigt. +- Node.js, npm, Docker CLI und Ollama waren im `PATH` nicht aufrufbar. +- `wsl.exe` ist vorhanden; eine installierte und einsatzbereite WSL-Distribution ließ sich aus der Abfrage jedoch nicht bestätigen. +- Nvidia CUDA wird vom Grafiktreiber bis UMD-Version `13.3` unterstützt. Das bestätigt noch keine installierte CUDA-Entwicklungsumgebung. + +Noch unbestätigt: + +- Gehäuse und weitere Gehäuselüfter des Gaming-PCs. +- Ursache dafür, dass Windows derzeit nur 8 statt 16 logische CPU-Prozessoren bereitstellt. +- Installierte VS-Code-Erweiterungen. +- Nutzbare WSL-Distribution und lokal installierte Python-/Node-/Docker-Laufzeiten außerhalb des geprüften `PATH`. + +Es wurde nichts installiert, keine Firmware- oder Systemeinstellung geändert und keine Umgebungsvariable verändert. + +## 12. Verfügbare Codex-Funktionen + +In dieser Sitzung waren nachweisbar verfügbar: + +- Lesen und Bearbeiten lokaler Dateien innerhalb freigegebener Bereiche. +- PowerShell-Befehle und lokale Diagnose. +- Git-Abfragen. +- Websuche. +- Bildgenerierung und lokale Bildprüfung. +- Codex-App-Aufgaben auflisten und frühere Aufgaben lesend auswerten. +- Projektübersicht der Codex-App. +- Thread-/Aufgabenkoordination. +- Planverwaltung. +- Native Zusammenarbeit mit Subagenten ist als Plattformfunktion vorhanden. +- Plugin- und Tool-Discovery. +- Automationen und wiederkehrende Aufgaben sind als App-Funktion vorhanden. +- Dokument-, PDF-, Präsentations- und Tabellenfunktionen sind über Skills/Plugins verfügbar. + +Modelle, die in der aktuellen Codex-App für Aufgaben ausgewiesen wurden: + +- `gpt-5.6-sol` +- `gpt-5.6-terra` +- `gpt-5.6-luna` +- `gpt-5.5` +- `gpt-5.4` +- `gpt-5.4-mini` + +Hinweis: Native Subagenten sind verfügbar, wurden für diesen Übergabeauftrag aber nicht eingesetzt. Für das spätere Projekt bedeutet Verfügbarkeit nicht automatisch, dass viele Agenten sinnvoll oder tokensparend sind. + +## 13. Vorhandene Skills, Plugins und MCP-Verbindungen + +In der aktuellen Sitzung ausgewiesene System-Skills: + +- `imagegen` +- `openai-docs` +- `plugin-creator` +- `skill-creator` +- `skill-installer` + +Ausgewiesene Plugin-Skills: + +- Browser-Steuerung +- Documents +- PDF +- Presentations +- Sites Building +- Sites Hosting +- Spreadsheets +- Excel Live Control +- Template Creator +- Visualize + +Ausgewiesene Werkzeug-/MCP-Funktionen umfassten unter anderem: + +- Node-REPL +- Plugin Management +- Codex Document Control +- Codex-App-Aufgaben/Projekte +- Webzugriff +- Bildgenerierung + +Projektlokal: + +- Keine `.codex`-Konfiguration vorhanden. +- Keine projektlokale MCP-Konfiguration gefunden. +- Keine projektlokalen Agentendefinitionen vorhanden. +- Keine `AGENTS.md` vorhanden. + +Als verfügbar, aber laut aktuellem Kontext nicht installiert ausgewiesene optionale Plugins/Connectoren: + +- Atlassian Rovo +- Box +- Figma +- GitHub +- Gmail +- Google Calendar +- Google Drive +- Notion +- Outlook Calendar +- Outlook Email +- SharePoint +- Slack +- Teams + +Keine dieser optionalen Verbindungen wurde für diesen Auftrag installiert oder verbunden. + +## 14. Bekannte Rootserver-Infrastruktur + +Quelle: vom Nutzer bestätigt und ausführlich aus der früheren Aufgabe `Root-Server einrichten` rekonstruiert; in diesem Auftrag nicht live mit dem Server verbunden. + +- Anbieter und Tarif: Netcup KVM Root Server `RS 2000 G11`. +- CPU-Zuteilung: 8 vCores. Als Hostplattform ist AMD EPYC wahrscheinlich, das konkrete EPYC-Modell wurde in der erreichbaren Historie jedoch nicht erfasst. +- Arbeitsspeicher: 16 GiB nominal, im früheren Systeminventar ungefähr 15 GiB nutzbar. +- Speicher: rund 512 GB nominal; das Root-Dateisystem wurde mit ungefähr 503 GiB auf `/dev/vda3` erfasst. +- Aktuelles Betriebssystem laut Einrichtungshistorie nach der Neuinstallation: Ubuntu 24.04 LTS, Codename Noble. +- Ein älterer Inventarstand mit Ubuntu 22.04.5 LTS stammt von vor der Neuinstallation und ist für den heutigen OS-Stand überholt. +- Administrationsmodell: Benutzer `pascal` besitzt `sudo`- und Docker-Rechte; `root` bleibt für Notfall-/Provider-Wiederherstellung vorgesehen. +- Dienste umfassen nach Nutzerangabe unter anderem: + - Docker + - Portainer + - Cockpit + - Gitea + - Nginx Proxy Manager + - CouchDB + - AMP + - mehrere Gameserver + - `peli-warden` beziehungsweise Gameserver-Werkzeuge +- AMP-Daten liegen unter `/home/amp/.ampdata/instances`; in der Historie waren die Instanzen `ADS01`, `Modpack01`, `Satisfactory01`, `Sky01` und `Vanillamc01` vorhanden. +- Für Backups relevante Docker-Daten umfassen insbesondere das Gitea-Datenvolume sowie die Daten- und Let's-Encrypt-Volumes von Nginx Proxy Manager und das Portainer-Datenvolume. Die konkreten Volume-Pfade sollten vor einem Restore live verifiziert werden. +- Dienste werden überwiegend über Subdomains unter `peli-server.de` erreicht. +- Beispiele aus früherem Kontext: `vanilla.peli-server.de` und `simpleinterface.peli-server.de`. +- UFW ist restriktiv konfiguriert. +- Nur ausdrücklich benötigte Ports sollen öffentlich geöffnet sein. +- Bei früheren Diagnosen wurden UFW-Regeln mit tatsächlich lauschenden Prozessen und DNS/SRV-Zielen abgeglichen. +- Der Rootserver soll langfristig Infrastrukturserver bleiben: Gitea, CouchDB, Reverse Proxy, Backups und Gameserver. + +Entscheidung: + +- Der Rootserver soll nicht zusätzlich ein lokales Sprachmodell für Jarvis betreiben. 16 GB RAM sind angesichts der bestehenden Dienste zu knapp. +- Jarvis darf den Rootserver später nur über eng definierte, überprüfbare Werkzeuge ansprechen. + +Nicht live geprüft: + +- Aktuelle Auslastung. +- Aktuelle Containerliste. +- Aktuelle Backups. +- Aktuelle Firewallregeln. +- Aktueller Patchstand. +- Genaue physische Host-CPU und aktueller Swap-Stand. + +## 15. Bekannter Ubuntu-Laptop und geplanter KI-Host + +Quelle: vom Nutzer bestätigt und aus der früheren Aufgabe `MSI-Laptop genauer identifizieren` rekonstruiert. Der Aufgabentitel ist irreführend: Der hier relevante alte Laptop ist kein MSI-Gerät. + +- Gerät: ASUS ROG Strix GL553VD. +- Hostname im früheren Ubuntu-System: `pascal-GL553VD-server`. +- CPU: Intel Core i7-7700HQ, 4 Kerne/8 Threads, 2,8 GHz Basistakt. +- Arbeitsspeicher: 16 GB DDR4; Ubuntu meldete im Betrieb ungefähr 15,5 GiB nutzbar. +- GPU: Nvidia GeForce GTX 1050 mit 4 GB VRAM. +- Primärer Datenträger: SanDisk M.2-SATA-SSD mit 128 GB. +- Zweiter Datenträger: Seagate `ST1000LM035`, 2,5-Zoll-SATA-HDD mit 1 TB und 5400 U/min. +- Die frühere grobe Angabe „ungefähr 1,25 TB“ war ungenau. Die identifizierten physischen Laufwerke ergeben nominal 128 GB plus 1 TB; die aktuelle Partitionsaufteilung ist nicht vollständig rekonstruiert. +- Dual-Boot: Ubuntu 24.04 LTS (Noble) und ein beibehaltenes Windows für gelegentliche Nutzung. +- Auf Ubuntu läuft zeitweise der private ATM10-Server per Java in `tmux`, mit ungefähr 10 GB Heap. +- Unter realer ATM10-Last wurden 20 TPS, typische Tickzeiten um 25–33 ms, CPU-Temperaturen ungefähr 64–70 °C und Lüfterdrehzahlen um 3.600–3.800 U/min beobachtet. Kurze Lastspitzen waren unkritisch; die GTX 1050 blieb beim Serverbetrieb weitgehend ungenutzt. + +Geplante Rolle: + +- Wahrscheinlicher späterer Host für den Jarvis-Kern. +- Lokale Datenbank und Suchindex. +- Web-/API-Dienst. +- Lokale Sprachverarbeitung. +- Kleines lokales Modell, soweit Hardware und Geschwindigkeit ausreichen. + +Ressourcenentscheidung: + +- ATM10 und ein lokales KI-Modell müssen nicht gleichzeitig mit voller Leistung laufen. +- Sinnvoll ist ein klarer Betriebsmodus: + - ATM10-Modus: lokales Modell gestoppt oder Jarvis stark reduziert. + - Jarvis-Modus: ATM10 gestoppt, Ressourcen für KI und Sprache frei. +- Der Assistent soll hostunabhängig und containerfähig geplant werden, damit ein späterer Umzug möglich bleibt. + +Risiko: + +- 4 GB VRAM begrenzen lokale Modelle deutlich. +- Vor einer Modellentscheidung sind reale KI-Benchmarks nötig; die Hardwareidentifikation selbst ist abgeschlossen. +- Die langsame 1-TB-HDD eignet sich eher für Daten und Backups als für latenzkritische Modell- oder Indexdateien; diese sollten nach Möglichkeit auf der 128-GB-SSD liegen, deren freier Platz vorher geprüft werden muss. + +## 16. Obsidian-, CouchDB- und Synchronisationsaufbau + +Quelle: vom Nutzer bestätigt und frühere Unterhaltung. + +- Obsidian ist auf Pascals PC eingerichtet. +- Synchronisation funktioniert über Self-hosted LiveSync und CouchDB. +- CouchDB läuft auf dem Rootserver. +- Der eigentliche Assistenten-Quellcode darf nicht im Obsidian-Vault liegen. +- Der Vault soll menschlich lesbarer Wissens- und Gedächtnisspeicher werden. +- Die Obsidian-Graphansicht ist ein wichtiger Bestandteil des gewünschten visuellen Wissensnetzes. + +Geplante Trennung: + +- Gitea-Repository: Quellcode, Tests, technische Architektur und maschinenbezogene Konfiguration. +- Obsidian-Vault: Wissen, Entscheidungen, Projekte, Aufgaben, freigegebene Erinnerungen und menschlich lesbare Dokumentation. +- Strukturierte Laufzeitdaten: voraussichtlich SQLite oder eine andere kleine, lokale Datenbank. +- Semantischer Index: separat regenerierbar; nicht die einzige Quelle der Wahrheit. + +Sicherheitsidee aus früherem Kontext: + +- Zunächst nur lesender Zugriff auf den Vault. +- Später begrenzter Schreibbereich, beispielsweise ein klarer KI-Entwurfs-/Inbox-Ordner. +- Keine Änderungen an `.obsidian/` ohne ausdrückliche Freigabe. +- Backups und Wiederherstellung vor Schreibautomatisierung. + +Nicht zugänglich: + +- Lokaler Vault-Pfad. +- Vault-Struktur. +- Installierte Obsidian-Plugins. +- LiveSync-Konfiguration. +- CouchDB-Zugangsdaten. + +## 17. Zielbild des persönlichen Assistenten + +Das Ziel ist ein eigener, langfristig erweiterbarer persönlicher KI-Assistent nach dem Grundgedanken von Jarvis aus Iron Man. + +Realistisches Ziel: + +- Natürliche Text- und Sprachkommunikation. +- Persönliches, nachvollziehbares Gedächtnis. +- Aufgaben und Projekte verstehen und organisieren. +- Wissen aus Obsidian finden und verknüpfen. +- Eng definierte Werkzeuge benutzen. +- Server, Gitea und weitere Systeme zunächst lesend prüfen. +- Später nach Bestätigung ausgewählte Aktionen ausführen. +- Programmieraufgaben sinnvoll für Codex vorbereiten oder an Codex übergeben. +- Auf PC und später mobil nutzbar sein. +- Langfristig eine Living-Mind-/Trillion-artige Visualisierung erhalten. + +Nicht Ziel: + +- Ein fiktiver, allwissender Iron-Man-Jarvis. +- Ein selbst trainiertes Foundation Model. +- Unbegrenzte autonome Kontrolle über Server, Dateien, E-Mail oder persönliche Daten. + +## 18. Gewünschte Hauptfunktionen + +Bestätigt beziehungsweise klar gewünscht: + +- Textchat. +- Sprachkommunikation. +- Sprache-zu-Text. +- Text-zu-Sprache. +- Später möglicherweise Wake Word. +- Kurz- und Langzeitgedächtnis. +- Obsidian-Wissenszugriff. +- Aufgabenbearbeitung und Planung. +- Werkzeugnutzung. +- Menschliche Freigaben für kritische Aktionen. +- Gitea-/Projektbezug. +- Serverstatus und Infrastrukturbezug. +- Spätere Automatisierung. +- Spätere Nutzung vom Handy. +- Spätere Unteragenten für klar abgegrenzte Aufgaben. + +Technische Ideen, noch nicht implementiert: + +- Lokaler Web-/API-Kern. +- Provider-Abstraktion für lokales Modell und optionale Fallbacks. +- Tool-Registry mit festen Schemas. +- Audit-Log für Aktionen. +- Berechtigungs- und Freigabematrix. +- Aufgabenwarteschlange zwischen dauerhaftem Host und Gaming-PC. +- Benachrichtigungen und Statusanzeigen. + +## 19. Geplantes Gedächtnissystem + +Noch keine Implementierung vorhanden. + +Sinnvolle, aus den bisherigen Entscheidungen abgeleitete Ebenen: + +1. Kurzzeit-/Sitzungskontext: + - aktuelles Gespräch, + - laufende Aufgabe, + - temporäre Tool-Ergebnisse. +2. Strukturierte Laufzeitdaten: + - Aufgaben, + - Freigaben, + - Tool-Ausführungen, + - Status, + - Konversationen, + - voraussichtlich SQLite in der ersten Ausbaustufe. +3. Menschlich lesbares Langzeitwissen: + - Obsidian-Markdown, + - Wikilinks, + - Projekte, + - Entscheidungen, + - freigegebene Erinnerungen. +4. Semantischer Index: + - Embeddings beziehungsweise lokale semantische Suche, + - aus den Originaldaten regenerierbar. + +Wichtige Regeln: + +- Obsidian-Dateien bleiben lesbar und exportierbar. +- Der Vektorindex ist nicht die einzige Kopie. +- Neue dauerhafte Erinnerungen sollen nachvollziehbar, überprüfbar und gegebenenfalls bestätigungspflichtig sein. +- Keine automatische Speicherung jedes Gesprächsdetails. +- Herkunft, Zeitstempel und Vertrauensgrad einer Erinnerung sollen erkennbar bleiben. +- Löschung, Korrektur und Export müssen möglich sein. + +Offen: + +- Exaktes Datenmodell. +- Welche Inhalte automatisch gespeichert werden dürfen. +- Welche Vault-Ordner gelesen oder beschrieben werden dürfen. +- Welches Embedding-Modell auf dem Laptop praktikabel ist. + +## 20. Geplante Sprachverarbeitung + +Gewünscht: + +- Deutsche Sprachkommunikation als naheliegender Hauptfall; endgültig noch zu bestätigen. +- Sprache-zu-Text. +- Text-zu-Sprache. +- Später ein Wake Word. + +Frühere technische Ideen: + +- `whisper.cpp` oder eine vergleichbare lokale STT-Lösung. +- Piper oder eine vergleichbare lokale TTS-Lösung. +- `openWakeWord` oder eine vergleichbare lokale Wake-Word-Lösung. + +Empfohlene Reihenfolge: + +1. Textmodus. +2. Push-to-Talk. +3. Lokale STT/TTS-Benchmarks auf dem Ubuntu-Laptop. +4. Erst danach dauerhaftes Wake Word. + +Gründe: + +- Push-to-Talk ist leichter zu testen. +- Dauerhaftes Zuhören erhöht Datenschutz-, Ressourcen- und Fehlaktivierungsrisiken. +- Die Laptop-Hardware ist begrenzt. + +Offen: + +- Endgültiges Wake Word. +- Stimme, Akzent und Sprechgeschwindigkeit. +- Offline-Anforderung. +- Mikrofon-/Lautsprecherhardware. +- Verhalten bei Hintergrundgeräuschen. + +## 21. Lokale Modelle und kostenlose API-Fallbacks + +Bestätigte Zielrichtung: + +- Lokal-first. +- Möglichst keine dauerhaft kostenpflichtige KI-API. +- Codex ist Entwicklungswerkzeug, nicht die spätere dauerhaft laufende Modell-Engine. +- Claude Code wird zunächst nicht genutzt. +- Claude kann später höchstens gelegentlich als unabhängige Kontrolle dienen. + +Frühere Ideen: + +- Ollama oder eine vergleichbare lokale Laufzeit. +- Kleines quantisiertes Modell, passend zu 16 GB RAM und vermutlich 4 GB VRAM. +- Kostenlose Cloud-Fallbacks wurden als Möglichkeit diskutiert, unter anderem Gemini oder Groq. + +Wichtig: + +- Anbieter, kostenlose Kontingente, Datenschutz und Nutzungsbedingungen ändern sich. Vor einer späteren Entscheidung muss aktuell neu geprüft werden. +- Ein kostenloser Fallback darf nicht als garantiert dauerhaft kostenloses Fundament behandelt werden. +- Provider müssen austauschbar sein. +- Sensible Obsidian-Inhalte dürfen nicht ungeprüft an Cloudmodelle gesendet werden. +- Lokales Modell und ATM10 benötigen gegebenenfalls getrennte Betriebsmodi. + +Offen: + +- Konkretes lokales Modell. +- Inferenzlaufzeit. +- CPU-/GPU-Offloading. +- Kontextlänge. +- Qualitätsgrenze, ab der ein Fallback erlaubt ist. +- Datenschutzregeln pro Provider. + +## 22. Codex- und VS-Code-Arbeitsweise + +Bestätigt: + +- Entwicklung auf dem Windows-Gaming-PC. +- VS Code als Arbeitsoberfläche. +- Codex läuft lokal. +- Projekt ist mit Git/Gitea verbunden. +- Codex kann grundsätzlich lokal Dateien bearbeiten, testen und Git verwenden. + +Gewünschter Ablauf: + +- ChatGPT erstellt zuerst den endgültigen Masterprompt. +- Pascal prüft ihn. +- Codex führt später kleine, klar abgegrenzte Phasen aus. +- Vor Änderungen Zustand und Plan zeigen. +- Keine Installation oder umfassende Struktur ohne Freigabe. +- Tests und Diff vor Commit. +- Commit/Push nur nach ausdrücklicher Freigabe. + +Mobile Nutzung: + +- Das Handy soll eher Fernbedienung und Statusoberfläche sein. +- Dateien, lokale Umgebung und Zugangsdaten bleiben auf dem ausführenden Rechner beziehungsweise Host. + +## 23. Geplante Agenten, Skills und Aufgabenverteilung + +Noch keine Agenten im Projekt angelegt. + +Früher diskutierte, sinnvolle Rollen: + +- Scout: findet Dateien und Zusammenhänge, schreibt nicht. +- Architect: plant größere Änderungen, schreibt keinen Produktionscode. +- Builder: einziger Agent, der in einer konkreten Implementierungsphase Code ändert. +- Verifier: prüft Tests, Laufzeit und Abnahmekriterien. +- Security Reviewer: prüft Authentifizierung, Rechte, Secrets und öffentliche Schnittstellen. + +Wichtige Entscheidung: + +- Keine Sammlung aus 160 allgemeinen Agenten installieren. +- Mehr Agenten sparen nicht automatisch Tokens. +- Für kleine Aufgaben arbeitet der Hauptagent allein. +- Parallelisierung nur bei unabhängigen Aufgaben. +- Nur ein Agent darf gleichzeitig dieselben Projektdateien verändern. +- Ergebnisse von Unteragenten sollen kurz zusammengefasst werden, nicht als vollständige Logs in den Hauptkontext gelangen. + +Offen: + +- Ob projektspezifische native Codex-Agenten tatsächlich benötigt werden. +- Welche Rollen erst bei wachsender Codebasis aktiviert werden. +- Welche Skills lokal erstellt werden sollen. + +## 24. Token- und Ressourceneffizienz + +Pascals Ziel ist sinnvolle Arbeitsteilung ohne unnötigen Tokenverbrauch. + +Empfohlene Regeln: + +- Kleine Aufgaben nicht delegieren. +- Nur unabhängige Recherche, Tests oder Reviews parallelisieren. +- Logs filtern und nur relevante Ausschnitte behalten. +- Große Dateien gezielt statt vollständig laden. +- Architekturentscheidungen in kurzen ADRs dokumentieren. +- `AGENTS.md` später knapp und eindeutig halten. +- Skills nur für wiederkehrende Arbeitsabläufe erstellen. +- Nicht jede denkbare Integration sofort installieren. +- Lokale Benchmarks statt theoretischer Modellversprechen. +- Caches und semantische Indizes regenerierbar halten. +- Modellrouting nach Aufgabe, Datenschutz und Ressourcenbedarf. + +Hardwareeffizienz: + +- Rootserver nicht mit Modellinferenz belasten. +- Ubuntu-Laptop im ATM10- beziehungsweise Jarvis-Modus betreiben. +- Speicher- und CPU-Grenzen für Dienste vorsehen. +- Wake Word erst nach funktionierendem Text-/Push-to-Talk-Kern. + +## 25. Living-Mind- beziehungsweise Trillion-Oberfläche + +Quelle: frühere ChatGPT-Unterhaltungen. + +- Pascal interessiert sich stark für eine grafische, gehirnartige Wissensdarstellung. +- Obsidian wurde auch wegen seiner Graphansicht ausgewählt. +- Eine `living-mind.md`-Referenz aus dem Trillion-/Hello-Trillion-Umfeld wurde in einer früheren Unterhaltung analysiert. +- Diese Referenz ist eine umfangreiche Bau- und Designspezifikation für die Visualisierung eines bereits bestehenden Agentensystems. +- Sie baut nicht den eigentlichen KI-Kern. +- Sie setzt echte Erinnerungen, Tools, Gespräche, Agenten und Ereignisse voraus. +- Im aktuellen Repository ist keine `living-mind.md` vorhanden. + +Entscheidung: + +- Zuerst funktionsfähiger KI-Kern. +- Die Oberfläche zunächst nur dokumentieren beziehungsweise als inaktives Konzept berücksichtigen. +- Keine erfundenen Demo-Erinnerungen, Knoten, Kanten oder Live-Ereignisse. +- Die echte Oberfläche erst anbinden, wenn reale Daten existieren. +- Obsidian-Graph kann bis dahin als erste sichtbare Wissensdarstellung dienen. + +Spätere Anforderungen: + +- Echte Datenquellen. +- Sichtbar unterschiedliche Verbindungstypen, etwa Wikilink, semantische Ähnlichkeit und tatsächlicher Abruf. +- Authentifizierung für API und WebSocket. +- Mobile Leistungsprofile. +- Kein ungeschützter öffentlicher Zugriff auf persönliche Erinnerungen. +- Festgelegte lokale Abhängigkeiten statt unkontrollierter CDN-Einbindung, soweit praktisch. + +## 26. Sicherheits- und Freigaberegeln + +Verbindliche Grundsätze für den späteren Masterprompt: + +- Keine freie Shell für das Sprachmodell. +- Nur definierte, schematisierte Tools. +- Standardmäßig geringste Rechte. +- Lesende Werkzeuge zuerst. +- Schreibende und destruktive Aktionen nur nach ausdrücklicher Freigabe. +- Keine Ausgabe von Passwörtern, Tokens, Cookies, privaten Schlüsseln oder Webhook-URLs. +- Secrets nur über sichere lokale Mechanismen; echte `.env`- oder XML-Secret-Dateien niemals in Git. +- Pascal bevorzugt für leichtes Ergänzen und Ändern eine lokale XML-Datei, vorläufig beispielsweise `key-pw.xml`. Als weniger missverständlicher technischer Name kommt `secrets.local.xml` infrage; der endgültige Dateiname bleibt beim Projektstart festzulegen. +- Diese XML-Datei wäre ein lokaler, strukturierter Secret-Speicher für API-Keys, Tokens und gegebenenfalls Passwörter. Da XML keine Verschlüsselung bietet, benötigt sie restriktive Dateirechte und darf weder synchronisiert noch als Anhang, Logausgabe oder Promptinhalt weitergegeben werden. +- Nicht das KI-Modell selbst liest die Geheimwerte: Eine eng begrenzte Secrets-/Tool-Schicht liest nur den für eine genehmigte Aktion benötigten Wert und verwendet ihn intern. Das Modell erhält höchstens Secret-Namen, Verfügbarkeitsstatus und bereinigte Ergebnisse, niemals den Wert. +- Die echte Secret-Datei muss vor dem ersten Commit in `.gitignore` stehen. Ins Repository gehört höchstens eine `key-pw.example.xml` beziehungsweise `secrets.example.xml` mit leeren Platzhaltern und dokumentiertem Schema. +- Logs, Fehlerausgaben, Toolantworten und Audit-Einträge müssen Secret-Werte maskieren. Ein späterer Secret-Scan vor Commits ist empfohlen. +- Audit-Log für Tool-Aufrufe, Freigaben und Ergebnisse. +- Dry-Run, wo möglich. +- Timeouts, Ressourcenlimits und sichere Fehlerzustände. +- Keine öffentliche Bereitstellung ohne Authentifizierung, TLS, Backup und Sicherheitsprüfung. +- Obsidian zunächst lesend; später Schreiben nur in klar freigegebenen Bereichen. +- Serverzugriff über eigenen eingeschränkten Nutzer beziehungsweise eng definierte API/Tools, nicht als Root. +- Backups und Wiederherstellung testen, nicht nur dokumentieren. +- Keine automatische Selbstmodifikation oder Installation fremder Plugins. +- Kein zweiter Agent darf unkoordiniert dieselben Dateien schreiben. + +## 27. Bereits durchgeführte Arbeiten + +Für dieses neue Repository: + +- Lokaler Ordner `D:\Javis-Projekt` wurde angelegt. +- Gitea-Repository wurde verbunden. +- Ein Test-Commit wurde erstellt und auf `origin/main` übertragen. +- Die Datei `READ.ME` wurde als Verbindungstest angelegt. +- Obsidian wurde auf dem PC eingerichtet und LiveSync funktioniert nach Nutzerangabe. +- Ubuntu wurde auf dem alten Laptop eingerichtet. +- Zielrichtung, Infrastrukturrollen und Sicherheitsprinzipien wurden in früheren Gesprächen ausführlich diskutiert. +- Die Living-Mind-Referenz wurde konzeptionell bewertet. +- Codex-/Gitea-/VS-Code-Arbeitsweise wurde erprobt, auch in früheren LS25-Projekten. + +Noch nicht durchgeführt: + +- Kein Assistentenkern. +- Kein Python-/Node-Projekt. +- Kein lokales Modell. +- Keine Sprachpipeline. +- Kein Gedächtnissystem. +- Kein Obsidian-Zugriff aus Jarvis. +- Keine Tool-Registry. +- Keine Agenten. +- Keine Living-Mind-Implementierung. +- Kein Deployment. + +## 28. Bereits getroffene Entscheidungen + +- Schreibweise und bestehende Namen nicht automatisch ändern. +- Quellcode bleibt außerhalb des Obsidian-Vaults. +- VS Code und Codex sind die primäre Entwicklungsumgebung. +- Gitea ist die Quellcodeverwaltung. +- Claude Code wird zunächst nicht verwendet. +- Claude höchstens später gelegentlich zur unabhängigen Kontrolle. +- Lokal-first und geringe laufende Kosten. +- Rootserver bleibt Infrastrukturserver und soll kein lokales LLM hosten. +- Ubuntu-Laptop ist der wahrscheinliche spätere KI-Host. +- ATM10 und lokale KI dürfen in getrennten Betriebsmodi laufen. +- Erst KI-Kern, dann Living-Mind-Oberfläche. +- Obsidian ist menschlich lesbare Wissensbasis; strukturierte Laufzeitdaten werden separat benötigt. +- Kritische Aktionen benötigen menschliche Freigabe. +- Keine riesige Agentensammlung; wenige spezialisierte Rollen. +- Entwicklung und Produktivbetrieb werden getrennt. +- API-Keys, Tokens und Passwörter werden später außerhalb des Codes in einer lokalen, Git-ignorierten Secret-Datei verwaltet; das Modell erhält keinen direkten Zugriff auf deren Inhalte. +- Ein möglicher späterer Wechsel des Gaming-PCs von Windows 11 zu Linux ist derzeit nur eine Überlegung, keine beschlossene Anforderung und kein Bestandteil der freigegebenen Jarvis-Entwicklung. +- Falls Pascal diesen Wechsel später beschließt, soll er gemeinsam mit Codex als eigenes Migrationsprojekt vorbereitet werden: vollständige Bestandsaufnahme, Kompatibilitätsprüfung, mehrfach geprüftes Backup, Wiederherstellungsplan und möglichst verlustarme schrittweise Migration. Ohne gesonderte Freigabe dürfen weder Partitionen noch Bootloader, Betriebssystem oder vorhandene Daten verändert werden. +- Noch keinen Assistenten bauen, bevor ChatGPT den Masterprompt erstellt und Pascal ihn geprüft hat. + +## 29. Noch offene Entscheidungen + +Offen: + +- Endgültige Schreibweise und Produktname: `Javis`, `Jarvis` oder ein anderer Name. +- Soll der lokale Ordner oder das Remote später umbenannt werden? Nicht Teil dieses Auftrags. +- Exakter Obsidian-Vault-Pfad und freigegebene Ordner. +- Lokales Modell und Laufzeit. +- Programmiersprache und Framework des Kerns. +- Exaktes Gedächtnismodell und Speicherkriterien. +- Embedding- und Suchlösung. +- STT-, TTS- und Wake-Word-Komponenten. +- Primäre Sprache, Stimme und Akzent. +- Erste drei konkreten Alltagsfunktionen. +- Freigabematrix je Werkzeug. +- Endgültiger Name, Speicherort und Schutz der lokalen XML-Secret-Datei (`key-pw.xml` oder `secrets.local.xml`). +- Fernzugriff: VPN/Tailscale, Reverse Proxy oder andere Lösung. +- Backupziele, Intervalle, Aufbewahrung und Wiederherstellungstest. +- Zulässige kostenlose Cloud-Fallbacks. +- Datenschutzregeln für Cloudanfragen. +- Schnittstelle zwischen Ubuntu-Host und Windows-Gaming-PC. +- Ob der Gaming-PC überhaupt von Windows 11 zu Linux wechseln soll; derzeit ausdrücklich unentschieden und nicht vorauszusetzen. +- Zeitpunkt und Umfang späterer Unteragenten. +- Herkunft, Lizenz und lokaler Ablageort der Living-Mind-Referenz. + +## 30. Unbestätigte Angaben + +Unbestätigt: + +- Konkretes AMD-EPYC-Modell des Netcup-Hosts; sicher bestätigt sind nur die 8 zugeteilten vCores des RS 2000 G11. +- Aktuelle Partitionsaufteilung und freier Speicher des ASUS-Laptops. +- Gehäuse und weitere Gehäuselüfter des Gaming-PCs. +- Ursache für die Beschränkung des Ryzen 7 9700X auf 8 für Windows sichtbare logische Prozessoren. +- Beruf und Arbeitsalltag Pascals. +- Ob Python, Node.js, Docker oder eine WSL-Distribution außerhalb des geprüften Kontexts einsatzbereit sind. +- Ob der endgültige Name absichtlich `javis` geschrieben werden soll. +- Ob kostenlose Cloud-Fallbacks tatsächlich genutzt werden. +- Ob SQLite die endgültige strukturierte Datenbank bleibt. +- Ob Ollama, whisper.cpp, Piper und openWakeWord nach Benchmarks geeignet sind. +- Ob die frühere `living-mind.md` lokal noch vorhanden ist. + +## 31. Erkannte Widersprüche + +Widerspruch 1 – Projektname: + +- Ausgangspunkt: `javis-projekt`. +- Lokale Prüfung: `D:\Javis-Projekt`. +- Das ist abgesehen von Großschreibung konsistent mit `Javis`, aber nicht mit `Jarvis`. + +Widerspruch 2 – Repositoryname: + +- Ausgangspunkt: vermutlich `javis-ai`. +- Lokale Prüfung: Remote `Jarvis-Ai.git`. +- Keine automatische Korrektur oder Umbenennung. + +Widerspruch 3 – Git-Transport: + +- Nutzerangabe: SSH-Zugriff zu Gitea funktioniert und Codex kann über SSH arbeiten. +- Aktuelles Repository: `origin` ist als HTTPS-URL konfiguriert. +- Beides kann gleichzeitig wahr sein; der konkrete Repository-Remote verwendet derzeit HTTPS. + +Widerspruch 4 – frühe Architekturideen: + +- In älteren Gesprächen wurde OpenAI API als pragmatischer Start diskutiert. +- Später wurde lokal-first ohne dauerhaft kostenpflichtige API als klare Zielrichtung festgelegt. +- Aktueller Stand: OpenAI-API darf nicht vorausgesetzt werden; Cloud höchstens austauschbarer Fallback. + +Widerspruch 5 – früher Living-Mind-Aufbau: + +- Frühere Entwürfe wollten teilweise schon eine funktionierende Three.js-Anwendung. +- Spätere Klarstellung: zunächst nur dokumentiertes, inaktives Konzept; erst der KI-Kern. +- Die spätere Klarstellung ist für den aktuellen Masterprompt maßgeblich. + +Widerspruch 6 – alter Laptop: + +- Früher wurde der relevante Ubuntu-Laptop teilweise als MSI-Gerät und sein Speicher grob mit etwa 1,25 TB bezeichnet. +- Die Bild- und Hardwareauswertung identifiziert ihn als ASUS ROG Strix GL553VD mit einer 128-GB-SanDisk-SSD und einer 1-TB-Seagate-HDD. + +## 32. Technische Risiken + +- 4 GB VRAM und 16 GB RAM begrenzen lokale Modellqualität und Parallelbetrieb. +- ATM10 und Jarvis können gemeinsam RAM, CPU und Kühlung überlasten. +- Der Gaming-PC stellt Windows derzeit nur 8 logische Prozessoren des 8-Kern-/16-Thread-Prozessors bereit; vor CPU-intensiven Benchmarks sollte die Ursache geklärt werden. +- Kostenlose Cloudangebote können sich ändern oder sensible Daten verarbeiten. +- Ein Assistent mit Serverzugriff kann bei zu breiten Rechten erheblichen Schaden verursachen. +- Prompt Injection aus Webseiten, E-Mails, Notizen oder Repository-Inhalten. +- Geheimnisse in Logs, Screenshots, Git-Historie oder Fehlermeldungen. +- Obsidian-Schreibzugriff kann Notizen überschreiben, umbenennen oder falsch verknüpfen. +- Self-hosted LiveSync ersetzt kein geprüftes Backup. +- Semantische Suche kann falsche Erinnerungen abrufen oder Zusammenhänge überbewerten. +- Ungeprüfte automatische Erinnerungen können langfristig falsches Wissen verfestigen. +- Gleichzeitige Agentenänderungen können Konflikte und schwer nachvollziehbare Fehler erzeugen. +- Living-Mind-Visualisierung kann sensible persönliche und technische Daten offenlegen. +- Öffentlicher Fernzugriff erhöht Authentifizierungs-, WebSocket- und Reverse-Proxy-Risiken. +- Aktuelle Entwicklungswerkzeuge Python/Node/Docker sind im geprüften `PATH` nicht einsatzbereit; vor Implementierung muss die Toolchain bewusst gewählt und geprüft werden. +- Der aktuelle Repositoryzustand ist extrem minimal; vorschnelles Scaffolden kann frühe Fehlentscheidungen festschreiben. + +## 33. Empfohlene Reihenfolge der Entwicklung + +Diese Reihenfolge ist eine Empfehlung für den späteren Masterprompt, keine Freigabe zur sofortigen Umsetzung: + +1. ChatGPT erstellt den endgültigen Masterprompt. +2. Pascal prüft Name, Umfang, Sicherheitsregeln und erste Anwendungsfälle. +3. Codex dokumentiert Bestand, Architektur, Bedrohungsmodell, Datenflüsse und Abnahmekriterien. +4. Toolchain auf Windows und Zielhardware prüfen; nichts unnötig installieren. +5. Minimaler lokaler Textassistent ohne Serverrechte und ohne Autonomie. +6. Modell-Provider abstrahieren und lokales Modell auf dem Ubuntu-Laptop benchmarken. +7. Strukturierte Sitzungen, SQLite und Audit-Log. +8. Obsidian zunächst ausschließlich lesend anbinden. +9. Semantische Suche mit nachvollziehbaren Quellen ergänzen. +10. Erste rein lesende Tools, beispielsweise lokaler Status oder Gitea-Projektstatus. +11. Freigabesystem und Berechtigungen vor jeder schreibenden Aktion. +12. Push-to-Talk mit lokaler STT/TTS. +13. Erst danach Wake Word und Hintergrundbetrieb. +14. Mobile beziehungsweise entfernte Nutzung über abgesicherten Zugang. +15. Wenige spezialisierte Unteragenten nur bei echtem Bedarf. +16. Backup- und Wiederherstellungstest. +17. Sicherheitsreview vor öffentlichem Zugriff. +18. Living-Mind-Oberfläche erst mit echten Daten anbinden. + +## 34. Informationen, die ChatGPT für den Masterprompt noch benötigt + +Fragen, die voraussichtlich noch beantwortet werden müssen: + +1. Soll der Assistent endgültig `Javis`, `Jarvis` oder anders heißen? +2. Sollen lokaler Ordner und Remote später vereinheitlicht werden, oder bleiben die bestehenden Namen bewusst erhalten? +3. Wo liegt der lokale Obsidian-Vault? +4. Welche Vault-Ordner darf der Assistent lesen und später eventuell beschreiben? +5. Welche drei Funktionen sollen in Version 1 echten Alltagsnutzen liefern? +6. Welche Aktionen dürfen niemals automatisch erfolgen? +7. Soll Deutsch die Hauptsprache sein, und welche Stimme beziehungsweise welcher Akzent ist gewünscht? +8. Welches Wake Word ist gewünscht? +9. Welches lokale Modell erreicht auf dem ASUS ROG Strix GL553VD bei 4 GB VRAM eine akzeptable Qualität und Antwortzeit? +10. Welche Cloud-Fallbacks sind datenschutzseitig akzeptabel? +11. Wie soll der sichere Zugriff vom Handy erfolgen? +12. Welche Backupziele und Wiederherstellungsanforderungen gelten? +13. Wo befindet sich die Living-Mind-Referenz, und darf sie lizenzrechtlich in das Repository übernommen werden? +14. Welche persönlichen Wissensbereiche sollen zuerst in Obsidian abgebildet werden? +15. Möchte Pascal Beruf und typische Arbeitsabläufe nennen, damit der Assistent darauf zugeschnitten werden kann? + +Fragen, die nicht erneut grundsätzlich gestellt werden müssen: + +- Ob das Ziel ein realistischer persönlicher Jarvis-artiger Assistent ist: ja. +- Ob der fiktive Filmumfang erwartet wird: nein. +- Ob VS Code und Codex genutzt werden: ja. +- Ob Gitea die Quellcodeverwaltung ist: ja. +- Ob der Quellcode im Obsidian-Vault liegen soll: nein. +- Ob Obsidian als menschlich lesbares Gedächtnis dienen soll: ja. +- Ob der Rootserver ein lokales LLM hosten soll: nein. +- Ob der Ubuntu-Laptop als möglicher KI-Host vorgesehen ist: ja. +- Ob laufende Kosten niedrig und lokale Nutzung bevorzugt werden: ja. +- Ob Claude Code anfangs Teil des Workflows ist: nein. +- Ob kritische Aktionen menschliche Freigaben benötigen: ja. +- Ob die Living-Mind-Oberfläche vor dem Kern gebaut werden soll: nein. +- Ob viele allgemeine Agenten automatisch gewünscht sind: nein. + +## 35. Empfohlener nächster Codex-Auftrag + +Erst nachdem ChatGPT den Masterprompt erstellt und Pascal ihn geprüft hat: + +> Prüfe den genehmigten Masterprompt gegen den tatsächlichen Zustand von `D:\Javis-Projekt`. Arbeite zunächst nur lesend. Lege keine Implementierung an. Zeige Pascal zuerst: +> +> 1. erkannte Ziele und Nicht-Ziele, +> 2. offene Entscheidungen, +> 3. geplante erste Phase, +> 4. betroffene Dateien, +> 5. benötigte Werkzeuge oder Installationen, +> 6. Sicherheits- und Abnahmekriterien. +> +> Warte anschließend auf Pascals Freigabe. Kein Commit, kein Push, keine Installation, kein Serverzugriff und keine Änderung am Obsidian-Vault ohne ausdrückliche Zustimmung. + +## 36. Vollständige Liste geprüfter Dateien und Befehle + +Geprüfte Dateien und Verzeichnisse: + +- Angehängter aktueller Auftrag `pasted-text.txt`. +- `D:\Javis-Projekt` +- `D:\Javis-Projekt\READ.ME` +- Vorhandensein von: + - `AGENTS.md` + - `.gitignore` + - `.codex` + - `.vscode` + - `living-mind.md` + - `README.md` + - `README` + - `READ.ME` +- Sichtbarer Sitzungsordner `C:\Users\pasca\Documents\Codex\2026-07-30\er`. +- Vom Nutzer bereitgestellter Screenshot der Alternate-Komponentenbestellung; Versanddaten und Preise wurden nicht in die technische Übergabe übernommen. + +Ausgeführte lokale Prüfungen, sinngemäß: + +- Projektordner auf `C:\`/im erreichbaren Dokumentbereich suchen. +- Nach Nutzerhinweis `D:\` rekursiv nach `javis-projekt` suchen. +- `Get-Location` +- `Get-ChildItem -Force` +- `git rev-parse --show-toplevel` +- `git branch --show-current` +- `git status --short --branch` +- `git log --oneline --decorate --all -20` +- `git remote -v` +- `git ls-tree -r --name-only HEAD` +- `git show -1` mit Commit-ID, Datum, Nachricht und Statistik +- `Get-Content .\READ.ME -Raw` +- `Test-Path` für die genannten Sonderdateien +- `codex --version` +- `git --version` +- `python --version` +- `py --version` +- `node --version` +- `npm --version` +- `docker --version` +- `docker compose version` +- lokale Zeit- und Windows-Versionsabfrage +- Prozess-/Paketprüfung der laufenden Codex-App +- rein lesende CIM/WMI-Abfragen zu System, Mainboard, BIOS, CPU, RAM, Datenträgern und Netzwerkadaptern +- `nvidia-smi` zur verlässlichen Identifikation von Nvidia-GPU, VRAM, Treiber und CUDA-Unterstützung +- Prüfung vorhandener Entwicklungswerkzeuge und ausführbarer Pfade + +Gelesene frühere Aufgaben: + +- Aufgabenliste der Codex-App. +- Relevante Nachrichten aus `KI-Assistent mit Codex`. +- Relevante Nachrichten aus `Claude-Link öffnen und einlesen`. +- Relevante Nachrichten aus `Erinnerung Überprüfung` und `Erinnerung Anfrage`. +- `Codex mit Gitea koppeln`. +- `Codex auf dem Handy`. +- Relevante Teile aus `ATM10:CC`. +- Relevante Teile aus `Root-Server einrichten`. +- `MSI-Laptop genauer identifizieren` zur Identifikation des tatsächlich relevanten ASUS ROG Strix GL553VD. +- `LS25 Mod mit Animationen schreiben`. + +Nicht ausgeführt: + +- Keine Installation. +- Kein `git pull`. +- Kein `git push`. +- Kein neuer Commit. +- Keine Änderung an Git-, SSH-, Gitea-, VS-Code-, Docker-, Server-, Firewall-, CouchDB- oder Obsidian-Konfiguration. +- Keine Abfrage oder Ausgabe von Passwörtern, Tokens, privaten Schlüsseln oder Cookies. +- Keine Aufnahme von Seriennummern, UUIDs, MAC- oder IP-Adressen in diese Übergabe. +- Kein Zugriff auf den Rootserver oder Ubuntu-Laptop. + +Abschlusszustand: + +- Ausschließlich `CHATGPT_HANDOFF.md` wird in diesem Auftrag neu erstellt. +- Der bestehende Test-Commit und `READ.ME` bleiben unverändert. +- Der eigentliche Assistent wurde nicht begonnen. + +## 37. Fortschreibung nach genehmigtem Masterauftrag + +Stand: 30.07.2026, Grundgerüstphase. + +Die Aussagen zum damaligen Abschlusszustand in Abschnitt 36 dokumentieren den historischen Handoff-Auftrag. Danach hat Pascal einen neuen Masterauftrag freigegeben. Folgender Stand ersetzt diese alten Abschlussaussagen: + +- Projektpfad und Git-Toplevel wurden erneut als `D:\Javis-Projekt` bestätigt. +- Aktiver Branch war `main`; Ausgangscommit war `49a1dd3`, identisch mit `origin/main`. +- Der aktive Obsidian-Vault wurde eindeutig als `D:\Obsidian Vault` bestätigt. +- `.obsidian`, `Test.md` und das Pluginverzeichnis `obsidian-livesync` waren vorhanden. +- Die globale Obsidian-Konfiguration markierte nur diesen Vault als geöffnet. +- Die früher vermutete OneDrive-Kopie war am genannten Pfad nicht vorhanden. +- Der Vault wurde ausschließlich gelesen und nicht verändert. +- `READ.ME` wurde unter Erhalt seines historischen Inhalts zu `README.md` umbenannt. +- Der Handoff liegt ab jetzt kanonisch unter `docs/CHATGPT_HANDOFF.md`. +- Ein schlankes Grundgerüst mit Dokumentation, Paketgrenzen, Tests, Konfigurationsbeispielen und inaktivem Living-Mind-Bereich wurde angelegt. +- Die aktuelle offizielle Codex-Dokumentation bestätigte `.codex/agents/*.toml` als Syntax für projektbezogene Agenten. Scout, Architect, Builder, Verifier und Security Reviewer wurden eng begrenzt angelegt; maximal zwei Unteragenten dürfen gleichzeitig laufen und nur der Builder besitzt Schreibmodus. +- Im normalen Windows-Benutzer-`PATH` waren Git und VS Code nutzbar, aber keine Projektinstallation von Python, Node.js, npm oder Docker. Es wurde nichts installiert. +- Der mit Codex gebündelte Python-Interpreter wurde ausschließlich für abhängigkeitfreie Struktur- und Unit-Tests des Grundgerüsts verwendet. + +Neue verbindliche Obsidian-Regel: + +- Javis soll sinnvolle Wikilinks erzeugen, damit aus echten Wissensbeziehungen langfristig eine organische, gehirnartige Graphansicht entsteht. +- Ein Link benötigt eine nachvollziehbare inhaltliche Beziehung, etwa Projektzugehörigkeit, Herkunft, Abhängigkeit oder Entscheidung. +- Unnötige Verbindungen ausschließlich für die Optik sind verboten. +- Bestehende Notizen bleiben bis zu einer konkreten Freigabe unverändert. + +Weiterhin nicht implementiert: + +- kein KI-Chat und keine Modellanbindung +- kein Gedächtnis oder semantischer Index +- kein Obsidian-Adapter oder Obsidian-Schreibzugriff +- kein lokaler oder entfernter Statusadapter +- kein SSH-, Laptop- oder Rootserverzugriff +- keine Sprachpipeline +- kein Living-Mind-Frontend + +Nach Pascals Abnahme ist `feat/core-chat` der empfohlene nächste Branch. Vor jeder Installation einer Python-Toolchain oder Modelllaufzeit ist weiterhin seine Freigabe erforderlich. diff --git a/docs/DATA_MODEL.md b/docs/DATA_MODEL.md new file mode 100644 index 0000000..25e83db --- /dev/null +++ b/docs/DATA_MODEL.md @@ -0,0 +1,23 @@ +# Datenmodell – Entwurf + +## Laufzeitdaten + +Eine spätere strukturierte Datenbank kann mindestens enthalten: + +- `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 + +SQLite ist der bevorzugte erste Kandidat, aber noch nicht implementiert. + +## Obsidian + +Obsidian bleibt die menschlich lesbare Wissensschicht. Ein Link wird nur erzeugt, wenn die Zielnotiz für das Verständnis, die Herkunft, eine Entscheidung oder eine echte Projektbeziehung relevant ist. Graphästhetik allein ist kein Linkgrund. + +## Semantischer Index + +Der Index ist jederzeit aus Quellen regenerierbar. Er speichert Quellpfad und Änderungszeit, ist nie die einzige Wissenskopie und gehört nicht in Git. diff --git a/docs/DECISIONS.md b/docs/DECISIONS.md new file mode 100644 index 0000000..59a9d92 --- /dev/null +++ b/docs/DECISIONS.md @@ -0,0 +1,11 @@ +# Entscheidungen + +| ID | Entscheidung | Status | +|---|---|---| +| ADR-0001 | Modularer Monolith statt früher Microservices | angenommen | +| ADR-0002 | Secrets bleiben außerhalb von Modellkontext und Git | angenommen | +| ADR-0003 | Obsidian-Links benötigen echte inhaltliche Beziehungen | angenommen | + +Offen bleiben insbesondere die konkrete lokale Modelllaufzeit, das endgültige Runtime-Secret-System, der genaue Obsidian-Schreibbereich und der Produktname. + +Ausführliche Begründungen stehen unter [`docs/adr`](adr/README.md). diff --git a/docs/ENVIRONMENT_VERIFICATION.md b/docs/ENVIRONMENT_VERIFICATION.md new file mode 100644 index 0000000..80266ad --- /dev/null +++ b/docs/ENVIRONMENT_VERIFICATION.md @@ -0,0 +1,39 @@ +# Environment Verification + +Prüfzeitpunkt: 30.07.2026, Europe/Berlin. + +## Projekt + +- Erwarteter und bestätigter Pfad: `D:\Javis-Projekt` +- Git-Toplevel: `D:/Javis-Projekt` +- Branch: `main` +- Ausgangsstand: `main` entsprach `origin/main` bei `49a1dd3` +- Nachvollziehbare unversionierte Datei vor dem Grundgerüst: `CHATGPT_HANDOFF.md` +- Bestehende versionierte Datei: `READ.ME` +- Remote: `origin` zeigt per HTTPS auf das Gitea-Repository `Jarvis-Ai.git` +- Der aktuelle Codex-Thread läuft in einem generierten Sitzungsordner. Dieser ist kein zweites Repository und nicht der Projektpfad. + +Es wurden keine eingebetteten Zugangsdaten ausgegeben. + +## Obsidian + +- Aktiver und bestätigter Vault: `D:\Obsidian Vault` +- `.obsidian` vorhanden +- `Test.md` vorhanden +- genau eine Markdown-Datei zum Prüfzeitpunkt +- Pluginverzeichnis `obsidian-livesync` vorhanden +- globale Obsidian-Konfiguration markiert ausschließlich `D:\Obsidian Vault` als geöffnet +- alte Kopie `C:\Users\pasca\OneDrive\Dokumente\Obsidian Vault` am genannten Pfad nicht vorhanden + +Der Vault und `.obsidian` wurden ausschließlich gelesen und nicht verändert. + +## Lokale Toolchain + +- Git: `2.55.0.windows.2` +- Visual Studio Code: `1.131.0` +- Python, `py`, Node.js, npm und Docker: im normalen Benutzer-`PATH` nicht verfügbar +- Ein mit Codex gebündelter Python-Interpreter darf für die Strukturprüfung genutzt werden; er ersetzt keine bewusst installierte Projekt-Toolchain. + +## Ergebnis + +Die Abbruchbedingungen der Phase 0 trafen nicht zu. Das Grundgerüst durfte im bestätigten Repository vorbereitet werden. diff --git a/docs/FUTURE_LINUX_MIGRATION.md b/docs/FUTURE_LINUX_MIGRATION.md new file mode 100644 index 0000000..d21da80 --- /dev/null +++ b/docs/FUTURE_LINUX_MIGRATION.md @@ -0,0 +1,38 @@ +# Mögliche spätere Linux-Migration + +Ein Wechsel des Gaming-PCs von Windows 11 zu Linux ist nicht beschlossen und nicht Teil der aktuellen Entwicklung. + +## Plattformunabhängig vorgesehen + +- Python-Kern und standardisierte Projektkonfiguration +- relative Pfade und `pathlib` +- UTF-8 und definierte Zeilenenden +- SQLite und dateibasierte Laufzeitdaten +- austauschbare Modell-, Status- und Tooladapter + +## Später betriebssystemspezifisch zu prüfen + +- GPU-Treiber, CUDA und lokale Modelllaufzeit +- Spiele, Anti-Cheat, VR und Windows-spezifische Programme +- Audio-, Mikrofon- und Wake-Word-Geräte +- Autostart und Dienstverwaltung +- Dateirechte, Keyring und Hardwaremonitoring + +## Vor einem Wechsel zu sichern + +- vollständige Benutzerdateien und Projekt-Repositories +- aktiver Obsidian-Vault einschließlich geprüftem LiveSync-Zustand +- lokale Datenbanken und Laufzeitdaten +- Browser- und Anwendungsprofile nach bewusster Auswahl +- SSH-Schlüssel und andere Secrets verschlüsselt, getrennt und mit Restore-Test +- Lizenzinformationen und Installationslisten + +## Sicheres Vorgehen + +1. vollständige Bestands- und Kompatibilitätsliste +2. mindestens zwei unabhängige Backups +3. stichprobenartiger Wiederherstellungstest +4. bevorzugt Test auf separatem Datenträger oder Dual-Boot +5. erst danach eine gesondert freigegebene Migration + +Codex darf keine Partition, keinen Bootloader und kein Betriebssystem ohne konkrete Freigabe verändern. diff --git a/docs/NEXT_SESSION.md b/docs/NEXT_SESSION.md new file mode 100644 index 0000000..40c5add --- /dev/null +++ b/docs/NEXT_SESSION.md @@ -0,0 +1,24 @@ +# Nächste Sitzung + +## Ziel + +Pascal prüft zuerst das Grundgerüst. Danach kann Phase 1 auf `feat/core-chat` beginnen. + +## Vor Änderungen erneut prüfen + +1. `git status --short --branch` +2. `git log -1 --oneline` +3. `docs/PROJECT_STATUS.md` +4. offene Entscheidungen in `docs/DECISIONS.md` + +## Vorgeschlagener Umfang + +- zwei bis drei geeignete lokale Python-Installationswege vergleichen +- Installation nur nach Pascals Freigabe +- echte Konfigurationsladefunktion mit Tests +- Provider-Protokoll ohne Cloudaufruf +- minimale CLI-Struktur ohne fest programmierte KI-Antworten + +## Nicht beginnen + +Noch keine Modellinstallation, kein Obsidian-Schreiben, kein SSH-/Serverzugriff, keine Sprache und kein Living-Mind-Frontend. diff --git a/docs/PERMISSIONS.md b/docs/PERMISSIONS.md new file mode 100644 index 0000000..2809877 --- /dev/null +++ b/docs/PERMISSIONS.md @@ -0,0 +1,14 @@ +# Berechtigungen + +| Bereich | Anfangszustand | Spätere Erweiterung | +|---|---|---| +| Projektdateien | Codex darf im freigegebenen Auftrag schreiben | weiterhin Git- und Testpflicht | +| Obsidian | gesamter Vault lesend | neue Dateien nur in einzeln freigegebenen Ordnern | +| Bestehende Notizen | keine Änderung | nur konkrete ausdrückliche Freigabe | +| Lokaler PC | definierte lesende Statusabfragen | schreibende Tools einzeln freigeben | +| Ubuntu-Laptop | kein Zugriff | eigener Schlüssel, Benutzer und begrenzte Verzeichnisse | +| Rootserver | kein Zugriff | eigener rein lesender Adapter oder Benutzer | +| Secrets | Modell sieht keine Werte | Tool-Schicht nutzt einzelne Werte intern | +| Externe Nachrichten | verboten | nur mit konkreter Freigabe und Empfängerprüfung | + +Jede Tooldefinition benötigt Eingabeschema, Ausgabegrenze, Timeout, Fehlerverhalten, Berechtigungsstufe und Auditregel. diff --git a/docs/PROJECT_STATUS.md b/docs/PROJECT_STATUS.md new file mode 100644 index 0000000..af447cc --- /dev/null +++ b/docs/PROJECT_STATUS.md @@ -0,0 +1,26 @@ +# Projektstatus + +Stand: Grundgerüstphase am 30.07.2026. + +## Erreicht + +- Projekt- und Vault-Pfade lesend bestätigt +- Sicherheits- und Architekturgrenzen dokumentiert +- plattformunabhängige Paketstruktur vorbereitet +- Obsidian-Linkregel als verbindliche Entscheidung dokumentiert +- Living-Mind-Bereich als inaktiver Vertrag vorbereitet +- projektinterne Codex-Agentensyntax anhand der aktuellen offiziellen Codex-Dokumentation geprüft + +## Nicht implementiert + +KI, Chat, Provider, Gedächtnis, Obsidian-Adapter, Tools, Serverzugriff, Sprache, Mobile Client und Living-Mind-Frontend. + +## Git + +- Branch: `main` +- Ausgangscommit: `49a1dd3` +- Der Commit, der dieses Dokument enthält, ist der Grundgerüstcommit; die konkrete ID ist mit `git log -1` zu ermitteln. + +## Bekannte Einschränkung + +Im normalen Windows-`PATH` ist noch keine nutzbare Python-Installation verfügbar. Es wurde nichts installiert. diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md new file mode 100644 index 0000000..97101ef --- /dev/null +++ b/docs/ROADMAP.md @@ -0,0 +1,15 @@ +# Roadmap + +Jede Phase beginnt erst nach Abnahme der vorherigen Phase. + +1. **Grundgerüst:** Pfade, Regeln, Architektur, Sicherheit und Strukturtests. +2. **Core Chat:** echte lokale Texteingabe, Provider-Abstraktion, Sitzung und klare Fehler. +3. **Memory:** SQLite-Entscheidung, Auditmodell und nachvollziehbare Speicherung. +4. **Obsidian:** lesender Index, Quellenangaben und später freigegebene Entwurfsordner. +5. **Status Tools:** zuerst lokaler PC und Git, später eingeschränkte Remoteadapter. +6. **Lokales Modell:** Benchmarks auf RTX 3060 und ASUS-Laptop; Installation nur nach Freigabe. +7. **Sprache:** Push-to-Talk vor Wake Word. +8. **Living Mind:** echte Datenverträge, Herkunfts-/Lizenzprüfung und danach Implementierung. +9. **Mobil:** authentifizierter, verschlüsselter Client ohne öffentliche ungeschützte Oberfläche. + +Der mögliche Windows-zu-Linux-Wechsel ist kein Roadmap-Schritt, sondern gegebenenfalls ein eigenes späteres Migrationsprojekt. diff --git a/docs/SECURITY.md b/docs/SECURITY.md new file mode 100644 index 0000000..068576f --- /dev/null +++ b/docs/SECURITY.md @@ -0,0 +1,32 @@ +# Sicherheit + +## Grundsätze + +- geringste Rechte und lesende Funktionen zuerst +- keine freie Shell für das Modell +- feste Tool-Schemas, Befehls-Allowlist, Timeouts und Ausgabelimits +- menschliche Freigabe vor schreibenden oder destruktiven Aktionen +- keine Root- oder normalen Administratorkonten für Javis +- keine öffentliche Schnittstelle ohne Authentifizierung und TLS +- Backups müssen wiederherstellbar getestet werden + +## Secrets + +Secrets dürfen nie in Code, Git, Prompts, Chatverläufe oder Logs gelangen. Das Modell erfährt nur den Namen, die Verfügbarkeit und ein bereinigtes Aktionsergebnis. + +Bevorzugt wird eine Secret-Provider-Abstraktion. Eine optionale lokale XML-Datei wie `key-pw.xml` oder `secrets.local.xml` ist nur als restriktiv geschützte, Git-ignorierte Klartextdatei zulässig. Ins Repository darf höchstens eine leere Beispielstruktur. + +Eine vorhandene SSH-Schlüsseldatei aus früherer LS25-/Gitea-Arbeit bleibt lokal. Pfad, privater Inhalt und Gerätekennung werden nicht dokumentiert. + +## Obsidian + +- gesamter Vault zunächst nur lesend +- `.obsidian` niemals verändern +- bestehende Notizen nicht automatisch bearbeiten oder löschen +- spätere Schreibbereiche einzeln freigeben +- Wikilinks nur bei echter semantischer Beziehung +- keine künstlichen Links zur bloßen Verdichtung der Graphansicht + +## Meldung eines Problems + +Bei möglichem Secret-Leak, unerwartetem Schreibzugriff oder falschem Zielpfad sofort stoppen, betroffene Aktion benennen und keine automatische Bereinigung durchführen. diff --git a/docs/THREAT_MODEL.md b/docs/THREAT_MODEL.md new file mode 100644 index 0000000..d50df1c --- /dev/null +++ b/docs/THREAT_MODEL.md @@ -0,0 +1,26 @@ +# Bedrohungsmodell + +## Schutzwerte + +- persönliche Notizen und Erinnerungen +- API-Keys, Tokens, Passwörter und SSH-Schlüssel +- Projekt- und Git-Historie +- lokale und entfernte Systeme +- Auditdaten und Freigabeentscheidungen + +## Wesentliche Bedrohungen + +| Bedrohung | Beispiel | Gegenmaßnahme | +|---|---|---| +| Prompt Injection | Notiz oder Webseite fordert einen Toolaufruf | Inhalte sind Daten, keine Berechtigung; Tool-Allowlist und Freigabe | +| Secret-Abfluss | Token erscheint in Prompt oder Log | Secret-Provider, Maskierung, keine Modellrückgabe | +| Zu breite Rechte | Modell erhält Shell oder Rootzugriff | eng definierte Adapter und eigene eingeschränkte Konten | +| Falscher Pfad | OneDrive-Vault statt aktivem Vault | kanonische Pfadprüfung und Abbruch | +| Datenverlust | Notiz, Partition oder Datenbank wird überschrieben | Backups, Dry-Run, konkrete Freigabe, Restore-Test | +| Falsche Erinnerung | semantischer Treffer wird als Fakt gespeichert | Quellenpfad, Zeitstempel, Korrektur und menschliche Bestätigung | +| Öffentliche Exposition | ungeschützte mobile Oberfläche | Authentifizierung, TLS und Sicherheitsreview | +| Lieferkette | ungeprüftes Plugin oder Referenzprojekt | Herkunft, Version und Lizenz prüfen; nichts blind ausführen | + +## Vertrauensgrenzen + +Modell, eingelesene Inhalte und externe Dienste sind nicht vertrauenswürdig. Tool-Schicht, Freigabesystem und Secret-Provider erzwingen die Grenze unabhängig vom Modelltext. diff --git a/docs/adr/0001-modular-monolith.md b/docs/adr/0001-modular-monolith.md new file mode 100644 index 0000000..9b9a3c5 --- /dev/null +++ b/docs/adr/0001-modular-monolith.md @@ -0,0 +1,5 @@ +# ADR-0001: Modularer Monolith + +Status: angenommen. + +Javis beginnt als ein deploybarer Kern mit klar getrennten internen Modulen. Das reduziert Betriebsaufwand, Ressourcenverbrauch und verteilte Fehlerbilder auf der vorhandenen Hardware. Einzelne Dienste werden erst ausgelagert, wenn Messwerte oder Sicherheitsgrenzen dies rechtfertigen. diff --git a/docs/adr/0002-secret-isolation.md b/docs/adr/0002-secret-isolation.md new file mode 100644 index 0000000..b7366d6 --- /dev/null +++ b/docs/adr/0002-secret-isolation.md @@ -0,0 +1,5 @@ +# ADR-0002: Secret-Isolation + +Status: angenommen. + +Secret-Werte werden ausschließlich von einer begrenzten Runtime-Schicht geladen und intern für genehmigte Aktionen eingesetzt. Weder Modellkontext noch Audit-Log erhalten die Werte. Echte Secret-Dateien sind lokal, restriktiv geschützt und Git-ignoriert; Beispielkonfigurationen enthalten nur leere Platzhalter. diff --git a/docs/adr/0003-meaningful-obsidian-links.md b/docs/adr/0003-meaningful-obsidian-links.md new file mode 100644 index 0000000..acdc144 --- /dev/null +++ b/docs/adr/0003-meaningful-obsidian-links.md @@ -0,0 +1,7 @@ +# ADR-0003: Sinnvolle Obsidian-Verknüpfungen + +Status: angenommen. + +Die Obsidian-Graphansicht soll langfristig eine organische, gehirnartige Wissensstruktur zeigen. Javis erzeugt einen Wikilink jedoch nur, wenn eine nachvollziehbare fachliche Beziehung besteht, etwa gemeinsame Projekte, Herkunft, Abhängigkeit oder Entscheidung. + +Links, die ausschließlich die Optik verdichten, sind verboten. Qualität und Erklärbarkeit der Wissensbeziehungen haben Vorrang vor der Anzahl sichtbarer Kanten. diff --git a/docs/adr/README.md b/docs/adr/README.md new file mode 100644 index 0000000..b80cc88 --- /dev/null +++ b/docs/adr/README.md @@ -0,0 +1,5 @@ +# Architecture Decision Records + +- [ADR-0001: Modularer Monolith](0001-modular-monolith.md) +- [ADR-0002: Secret-Isolation](0002-secret-isolation.md) +- [ADR-0003: Sinnvolle Obsidian-Verknüpfungen](0003-meaningful-obsidian-links.md) diff --git a/interface/living-mind/DATA_CONTRACT_DRAFT.md b/interface/living-mind/DATA_CONTRACT_DRAFT.md new file mode 100644 index 0000000..9ce9497 --- /dev/null +++ b/interface/living-mind/DATA_CONTRACT_DRAFT.md @@ -0,0 +1,14 @@ +# Datenvertrag – unverbindlicher Entwurf + +Eine spätere Oberfläche könnte bereinigte, authentifizierte Beobachtungsereignisse erhalten: + +- `core`: Betriebszustand des Kerns +- `working_memory`: Größe und Aktivität, nicht vertraulicher Inhalt +- `memory`: Index- und Abrufstatus +- `agents`: freigegebene Rollen und Aktivitätsstatus +- `knowledge`: echte, quellengestützte Beziehungen +- `tools`: Toolname, Status und Freigabezustand +- `events`: bereinigte zeitliche Ereignisse +- `system_status`: freigegebene technische Messwerte + +Noch sind weder Schema, Transport noch Authentifizierung festgelegt. Secret-Werte, private Notizinhalte und rohe Prompts dürfen nicht Teil des Vertrages werden. diff --git a/interface/living-mind/README.md b/interface/living-mind/README.md new file mode 100644 index 0000000..d3a0ebf --- /dev/null +++ b/interface/living-mind/README.md @@ -0,0 +1,7 @@ +# Living Mind + +Dieser Bereich reserviert ausschließlich die spätere beobachtende Oberfläche. Er enthält aktuell kein Frontend, kein Backend, keine Animation und keine Datenquelle. + +Vor einer Implementierung müssen die offizielle Trillion-Quelle, konkrete Herkunft und Lizenz geprüft werden. Ohne klare Lizenz wird kein fremder Quellcode übernommen. + +Die spätere „Gehirnoptik“ muss echte Zustände und nachvollziehbare Beziehungen darstellen. Weder im Interface noch in Obsidian werden Fantasiedaten oder künstliche Verbindungen nur für die Optik erzeugt. diff --git a/interface/living-mind/STATUS.md b/interface/living-mind/STATUS.md new file mode 100644 index 0000000..4410180 --- /dev/null +++ b/interface/living-mind/STATUS.md @@ -0,0 +1,9 @@ +# Status + +- Backend: nicht implementiert +- Frontend: nicht implementiert +- Live-Ereignisse: nicht implementiert +- Authentifizierung: nicht implementiert +- echte Datenquellen: nicht angeschlossen +- Trillion-Quelle und Lizenz: nicht geprüft +- Demo- und Fantasiedaten: verboten diff --git a/interface/living-mind/reference/README.md b/interface/living-mind/reference/README.md new file mode 100644 index 0000000..7a7edb1 --- /dev/null +++ b/interface/living-mind/reference/README.md @@ -0,0 +1,3 @@ +# Reference placeholder + +Hier darf später ausschließlich eine eindeutig identifizierte, lizenzgeprüfte Referenz oder eine Dokumentation ihrer Herkunft liegen. In Phase 0 wurde nichts heruntergeladen oder kopiert. diff --git a/pyproject.toml b/pyproject.toml new file mode 100644 index 0000000..8a7ccd6 --- /dev/null +++ b/pyproject.toml @@ -0,0 +1,17 @@ +[build-system] +requires = ["setuptools>=68"] +build-backend = "setuptools.build_meta" + +[project] +name = "javis-ai" +version = "0.0.0" +description = "Safe, local-first personal assistant project scaffold" +readme = "README.md" +requires-python = ">=3.11" +dependencies = [] + +[tool.setuptools.packages.find] +where = ["src"] + +[tool.pytest.ini_options] +testpaths = ["tests"] diff --git a/runtime/README.md b/runtime/README.md new file mode 100644 index 0000000..7440bb9 --- /dev/null +++ b/runtime/README.md @@ -0,0 +1,3 @@ +# Runtime + +Dieses Verzeichnis enthält im Repository nur diese Erklärung. Lokale Datenbanken, Sitzungen, Indizes, Modelle, Logs und temporäre Dateien werden ignoriert und niemals als produktive Daten committet. diff --git a/scripts/verify_structure.py b/scripts/verify_structure.py new file mode 100644 index 0000000..9565853 --- /dev/null +++ b/scripts/verify_structure.py @@ -0,0 +1,63 @@ +"""Verify the dependency-free phase-0 repository structure.""" + +from __future__ import annotations + +import sys +import tomllib +from pathlib import Path + + +ROOT = Path(__file__).resolve().parents[1] +REQUIRED = ( + "README.md", + "AGENTS.md", + "CHANGELOG.md", + "PLANS.md", + "pyproject.toml", + ".gitignore", + ".gitattributes", + "config/javis.example.toml", + "docs/ARCHITECTURE.md", + "docs/ENVIRONMENT_VERIFICATION.md", + "docs/SECURITY.md", + "docs/THREAT_MODEL.md", + "docs/PROJECT_STATUS.md", + "docs/NEXT_SESSION.md", + "docs/CHATGPT_HANDOFF.md", + "src/javis/__init__.py", + "interface/living-mind/STATUS.md", +) + + +def main() -> int: + missing = [relative for relative in REQUIRED if not (ROOT / relative).is_file()] + if missing: + print("Missing required files:") + for relative in missing: + print(f"- {relative}") + return 1 + + with (ROOT / "pyproject.toml").open("rb") as handle: + project = tomllib.load(handle)["project"] + if project["name"] != "javis-ai": + print("Unexpected project name in pyproject.toml") + return 1 + + forbidden = [ + path + for path in ROOT.rglob("*") + if path.is_file() + and path.name.lower() in {"key-pw.xml", "secrets.local.xml", ".env"} + ] + if forbidden: + print("Forbidden local secret files are present:") + for path in forbidden: + print(f"- {path.relative_to(ROOT)}") + return 1 + + print(f"Structure verified: {len(REQUIRED)} required files present.") + return 0 + + +if __name__ == "__main__": + sys.exit(main()) diff --git a/src/javis/__init__.py b/src/javis/__init__.py new file mode 100644 index 0000000..a9fbbc8 --- /dev/null +++ b/src/javis/__init__.py @@ -0,0 +1,6 @@ +"""Javis package scaffold. + +No assistant runtime is implemented in phase 0. +""" + +__version__ = "0.0.0" diff --git a/src/javis/audit/__init__.py b/src/javis/audit/__init__.py new file mode 100644 index 0000000..e244c15 --- /dev/null +++ b/src/javis/audit/__init__.py @@ -0,0 +1 @@ +"""Audit boundary for Javis.""" diff --git a/src/javis/config/__init__.py b/src/javis/config/__init__.py new file mode 100644 index 0000000..2dd0edf --- /dev/null +++ b/src/javis/config/__init__.py @@ -0,0 +1 @@ +"""Configuration boundary for Javis.""" diff --git a/src/javis/core/__init__.py b/src/javis/core/__init__.py new file mode 100644 index 0000000..a2c8661 --- /dev/null +++ b/src/javis/core/__init__.py @@ -0,0 +1 @@ +"""Conversation orchestration boundary for Javis.""" diff --git a/src/javis/interface/__init__.py b/src/javis/interface/__init__.py new file mode 100644 index 0000000..ea0ee3d --- /dev/null +++ b/src/javis/interface/__init__.py @@ -0,0 +1 @@ +"""User-interface boundary for Javis.""" diff --git a/src/javis/memory/__init__.py b/src/javis/memory/__init__.py new file mode 100644 index 0000000..bf9a7a1 --- /dev/null +++ b/src/javis/memory/__init__.py @@ -0,0 +1 @@ +"""Memory boundary for Javis.""" diff --git a/src/javis/obsidian/__init__.py b/src/javis/obsidian/__init__.py new file mode 100644 index 0000000..8448ca5 --- /dev/null +++ b/src/javis/obsidian/__init__.py @@ -0,0 +1 @@ +"""Obsidian adapter boundary for Javis.""" diff --git a/src/javis/providers/__init__.py b/src/javis/providers/__init__.py new file mode 100644 index 0000000..d78f586 --- /dev/null +++ b/src/javis/providers/__init__.py @@ -0,0 +1 @@ +"""Model-provider boundary for Javis.""" diff --git a/src/javis/security/__init__.py b/src/javis/security/__init__.py new file mode 100644 index 0000000..899ab84 --- /dev/null +++ b/src/javis/security/__init__.py @@ -0,0 +1 @@ +"""Security and approval boundary for Javis.""" diff --git a/src/javis/status/__init__.py b/src/javis/status/__init__.py new file mode 100644 index 0000000..5f55328 --- /dev/null +++ b/src/javis/status/__init__.py @@ -0,0 +1 @@ +"""Technical status-adapter boundary for Javis.""" diff --git a/src/javis/tools/__init__.py b/src/javis/tools/__init__.py new file mode 100644 index 0000000..d9550e3 --- /dev/null +++ b/src/javis/tools/__init__.py @@ -0,0 +1 @@ +"""Controlled tool-registry boundary for Javis.""" diff --git a/tests/fixtures/README.md b/tests/fixtures/README.md new file mode 100644 index 0000000..d6d085c --- /dev/null +++ b/tests/fixtures/README.md @@ -0,0 +1,3 @@ +# Test fixtures + +Only synthetic, non-secret fixtures may be stored here. Personal Obsidian notes, tokens, logs and production exports are forbidden. diff --git a/tests/integration/README.md b/tests/integration/README.md new file mode 100644 index 0000000..9043c6d --- /dev/null +++ b/tests/integration/README.md @@ -0,0 +1,3 @@ +# Integration tests + +Integration tests will be added with the first real provider, persistence, or adapter. Phase 0 performs no network or service integration. diff --git a/tests/unit/test_package_metadata.py b/tests/unit/test_package_metadata.py new file mode 100644 index 0000000..ecc87ef --- /dev/null +++ b/tests/unit/test_package_metadata.py @@ -0,0 +1,14 @@ +"""Dependency-free smoke tests for the phase-0 package.""" + +import unittest + +import javis + + +class PackageMetadataTests(unittest.TestCase): + def test_scaffold_version_is_explicit(self) -> None: + self.assertEqual(javis.__version__, "0.0.0") + + +if __name__ == "__main__": + unittest.main()