# 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. ## 38. Tokenbewusste Arbeitsweise und empfohlene Werkzeuge Pascal wünscht ausdrücklich einen möglichst sparsamen Tokenverbrauch, ohne Qualitätsverlust. Für ChatGPT und Codex gelten deshalb: - zu Beginn einer neuen großen Projektphase den vollständigen Handoff wie im Masterauftrag gefordert lesen; innerhalb derselben laufenden Phase anschließend mit `docs/PROJECT_STATUS.md`, `docs/NEXT_SESSION.md`, `docs/DECISIONS.md`, Git-Status und gezielten Abschnitten weiterarbeiten, statt den Handoff unnötig erneut vollständig einzulesen - gezielte Suchen und relevante Dateiausschnitte statt wiederholter Vollscans - unabhängige lesende Prüfungen sinnvoll bündeln - Rohlogs begrenzen und Ergebnisse knapp mit konkreten Dateiverweisen zusammenfassen - vorhandene Prüfergebnisse innerhalb einer Sitzung wiederverwenden - kleine Aufgaben durch den Hauptagenten erledigen; Unteragenten nur bei klar trennbaren größeren Arbeiten - maximal zwei Unteragenten gleichzeitig; keine parallelen Schreiber - keine Dokumentation allein zur Textmenge erzeugen und keine unnötigen Alternativen ausarbeiten - notwendige Sicherheitsprüfung, Tests, Quellenprüfung und verständliche Erklärung niemals aus Tokenersparnis weglassen - nach jedem abgeschlossenen logischen Arbeitspaket diesen Handoff aktualisieren: Auftrag, Ergebnis, geänderte Dateien, Tests, Git-Stand, offene Punkte und nächster Schritt - einzelne Such-, Lese- oder Prüfkommandos nicht als eigene Handoff-Version behandeln; sie werden im Ergebnis des zugehörigen Arbeitspakets zusammengefasst ### Empfohlene minimale Werkzeuge für Phase 1 Noch nichts davon ist installiert oder freigegeben. Vor jeder Installation muss Pascal zustimmen. 1. **Python-/Projektverwaltung: `uv` von Astral bevorzugt prüfen.** Es ist plattformübergreifend, verwaltet virtuelle Umgebungen und erzeugt einen reproduzierbaren Lockfile. Das passt zum späteren Wechsel zwischen Windows und Ubuntu. Offizielle Dokumentation: `https://docs.astral.sh/uv/` 2. **VS Code: Microsoft Python-Erweiterung mit Pylance und Python Environments.** Das genügt zunächst für Interpreterwahl, IntelliSense, Debugging und Tests. Keine große Python-Erweiterungssammlung installieren. Offizielle Dokumentation: `https://code.visualstudio.com/docs/languages/python` 3. **Ruff.** Als schneller gemeinsamer Linter und Formatter reduziert Ruff mehrere Einzelwerkzeuge. Installation und Konfiguration erst zusammen mit der Python-Toolchain. Offizielle Dokumentation: `https://docs.astral.sh/ruff/` 4. **Tests.** Zunächst das eingebaute `unittest` weiterverwenden. `pytest` erst ergänzen, wenn Fixtures, Parametrisierung oder Plugins einen echten Vorteil bringen. ### Später und nur bei tatsächlichem Bedarf - **VS Code Remote – SSH:** erst beim Aufbau des eingeschränkten Zugangs zum ASUS-Ubuntu-Laptop. Kein Rootzugang und eigener Javis-Schlüssel. Offizielle Dokumentation: `https://code.visualstudio.com/docs/remote/ssh` - **Lokale Modelllaufzeit:** auf dem Gaming-PC und ASUS-Laptop zunächst `Ollama` und `llama.cpp` gegeneinander benchmarken. Ollama ist einfacher zu bedienen; llama.cpp bietet feiner kontrollierbare GGUF-, Quantisierungs- und CPU/GPU-Offload-Optionen. Keine Vorentscheidung ohne Messwerte. Offizielle Quellen: `https://docs.ollama.com/` und `https://github.com/ggml-org/llama.cpp` - **Secret-Scan:** vor der ersten echten Provider- oder Serveranbindung ein schlankes Secret-Scanning im Commit-Workflow bewerten. `.gitignore` und Modellisolierung bleiben unabhängig davon Pflicht. - **Container:** Docker erst für einen konkreten späteren Deploymentbedarf auf dem Ubuntu-Host einführen, nicht für den ersten lokalen Textkern. ### Obsidian - Self-hosted LiveSync bleibt die einzige derzeit notwendige Community-Erweiterung. - Für die gewünschte Gehirnoptik zunächst Obsidian-Core-Funktionen wie Graph View, Local Graph, Backlinks, Tags und Gruppen verwenden. - Keine Graph-, Dataview- oder Automations-Erweiterung nur für die Optik installieren. - Dataview oder ein anderes Plugin erst prüfen, wenn eine konkrete Abfrage nicht sinnvoll mit Markdown, Metadaten und dem Javis-Index lösbar ist. - Interne Links bleiben fachlich begründet. Obsidian bildet über diese Links bereits ein Wissensnetz; zusätzliche künstliche Kanten sind nicht nötig. Offizielle Dokumentation: `https://obsidian.md/help/plugins/graph` und `https://obsidian.md/help/links` ### Codex-Skills, Plugins und Connectoren - Die vorhandenen projektbezogenen Rollen Scout, Architect, Builder, Verifier und Security Reviewer reichen vorerst aus. - `openai-docs` nur für aktuelle OpenAI-/Codex-Fragen einsetzen. - Browser-Steuerung erst bei einer realen lokalen Weboberfläche für Tests verwenden. - Dokument-, PDF-, Tabellen-, Präsentations- und Bildfunktionen nur bei einer passenden konkreten Aufgabe aktiv nutzen. - Keinen GitHub-Connector installieren, solange Gitea die Quellcodeverwaltung ist. - Notion-, Google-Drive-, Slack-, Teams-, Mail- und Kalender-Connectoren zunächst nicht verbinden. Sie erhöhen Berechtigungsfläche und Kontextverbrauch, ohne für Phase 1 benötigt zu werden. - Keine große Plugin-, Skill- oder Agentensammlung vorsorglich installieren. Empfohlener Minimalstand für die nächste Phase: `uv` plus verwaltetes Python, Microsoft Python/Pylance/Python Environments und Ruff. Alles Weitere bleibt bedarfsabhängig. ### Verbindlicher Kommunikationsrhythmus `docs/CHATGPT_HANDOFF.md` ist die gemeinsame Übergabeschnittstelle zwischen Codex und GPT. Codex hält sie nach jedem abgeschlossenen logischen Arbeitspaket aktuell. Ein Arbeitspaket ist beispielsweise eine Dokumentationsänderung, eine implementierte und getestete Funktion, eine abgeschlossene Diagnose oder eine freigegebene Infrastrukturmaßnahme. Der Eintrag nennt knapp: 1. Auftrag und Ergebnis, 2. tatsächlich geänderte Dateien oder Systeme, 3. ausgeführte Tests und deren Ergebnis, 4. Branch, Commit und Push-Status, 5. offene Entscheidungen oder Fehler, 6. den sicheren nächsten Schritt. Damit die Datei nutzbar bleibt, werden keine vollständigen Chats, Rohlogs oder redundanten Wiederholungen angehängt. ## 39. Arbeitspaket: Werkzeugempfehlungen und Handoff-Rhythmus Auftrag und Ergebnis: - Pascal bat um sinnvolle Add-on-, Plugin- und Werkzeugempfehlungen sowie möglichst tokensparende Arbeit ohne Qualitätsverlust. - Die Empfehlungen wurden anhand aktueller offizieller Dokumentation auf einen phasenbezogenen Minimalumfang begrenzt. - Zusätzlich wurde festgelegt, dass dieser Handoff nach jedem abgeschlossenen logischen Arbeitspaket aktualisiert wird. Geänderte Projektdateien: - `AGENTS.md` - `CHANGELOG.md` - `docs/CHATGPT_HANDOFF.md` - `docs/DECISIONS.md` - `docs/NEXT_SESSION.md` - `docs/PROJECT_STATUS.md` - `docs/adr/README.md` - `docs/adr/0004-token-efficient-workflow.md` Prüfungen: - Repository war vor der Änderung sauber auf `main` bei Grundgerüstcommit `6d04171`. - UTF-8, Handoff-Struktur und Secret-Muster wurden geprüft. - Es wurden keine Plugins, Programme, Python-Versionen oder Modelllaufzeiten installiert. - Obsidian, Rootserver und Ubuntu-Laptop wurden nicht verändert. Git-Stand: - Branch: `main` - Basis dieses Arbeitspakets: `6d04171` - Der Commit, der Abschnitt 39 enthält, ist mit `git log -1 --oneline` zu bestimmen. Offen: - Pascal muss vor Phase 1 der konkreten Python-/`uv`-Installation zustimmen. - Modelllaufzeit, Obsidian-Zusatzplugins und Remote-SSH bleiben bis zu ihrem tatsächlichen Bedarf zurückgestellt. Nächster sicherer Schritt: - diesen aktualisierten Handoff an GPT übergeben oder nach Pascals Freigabe Phase 1 auf `feat/core-chat` beginnen.