docs: add tooling and handoff guidance

docs/CHATGPT_HANDOFF.md

@@ -1117,3 +1117,109 @@ Weiterhin nicht implementiert:
 - 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.