30-Minuten-Lösung: Vom KI-Gedanken zur ausführbaren Aufgabe
Problem: KIs erzeugen gute Ideen, diese werden aber nicht automatisch zu Arbeit. Der Benutzer dient als Paketbote zwischen ChatGPT und Claude Code.
Kernfrage: Was bauen wir JETZT in 30 Minuten, damit aus einer ChatGPT-Idee automatisch eine für Claude Code sichtbare, ausführbare Aufgabe wird — und das Ergebnis zurückfließt, ohne Paketbote?
Erfolgskriterium: ChatGPT-Auftrag → lokale Datei → Watcher erkennt → Status → Ergebnis als Datei → Benutzer sieht: offen / in Arbeit / erledigt / braucht Entscheidung.
Bauen: Atomares Datei-Queuing. Vier Ordner (OUTBOX/ PROCESSING/ DONE/ ERROR/), ein Python-Watcher, JSON-Dateien als Tasks. Der Status einer Aufgabe ist ihr physischer Speicherort.
Die Claude Code CLI (claude --print -p) läuft non-interaktiv. Das ist die fehlende Brücke die beide anderen Stimmen nicht kannten.
Was heute NICHT gebaut wird: Vollautomatik. V1 braucht manuelles Victor-Go pro Task. Das ist kein Mangel — das ist Sicherheit.
Lokaler Ordner als Übergabepunkt, JSON-Dateien als Auftragsmedium. Einfach, keine neuen Technologien. Risiko: Synchronisationsprobleme, fehlende Echtzeit-Fähigkeiten.
Einfaches CLI-Tool das JSON-Dateien verarbeitet und den Workflow automatisiert. Nutzt bestehende macOS-CLI-Infrastruktur, flexibel erweiterbar. Risiko: Konsolenaffinität nötig, Sicherheitsrisiken bei ungeprüften Eingaben.
Markdown-Dateien für Tasks und Statusverfolgung. Lesbar, gut in Notizsysteme integrierbar. Risiko: schwer automatisiert zu verarbeiten, fehlende Standardisierung.
Watcher erkennt Dateisystem-Änderungen und verarbeitet automatisch. Echtzeit, ohne Benutzerintervention. Risiko: stabile Implementierung schwierig, hohe Fehlerbehandlungs-Komplexität.
Siri oder lokales Sprachsystem initiiert Tasks und verfolgt Status. Gesteigerte Benutzerfreundlichkeit. Realistisch erst bei klar definierten Befehlen und stabiler Spracherkennung.
Geminis atomares Datei-Queuing ist die richtige Basis. Der entscheidende Schritt den beide Gutachten übersehen: claude --print -p "$(cat task.json)" existiert bereits. Die Claude Code CLI läuft non-interaktiv. Der Watcher ist 40 Zeilen Python.
dispatcher/OUTBOX/ — ChatGPT schreibt JSON-Dateien reindispatcher/PROCESSING/ — Watcher verschiebt atomar beim Aufnehmendispatcher/DONE/ und dispatcher/ERROR/ — Ergebnissewatcher.py — überwacht OUTBOX/, schreibt Status zurückclaude --print -p "Aufgabe: $(cat task.json)" gibt Ergebnis als Text zurück — kein interaktives UI nötigWatcher ruft Claude Code nicht autonom auf — Victor gibt manuell "go" pro Task. Vollautomatik ist V2.
Beide lösen ChatGPT→OUTBOX nicht. Victor muss die JSON-Datei immer noch erstellen und ablegen — er ist weiterhin Paketbote für den ersten Schritt. Die 30-Minuten-Lösung eliminiert Victor als Bote zwischen OUTBOX→Claude→Ergebnis. Der erste Schritt braucht Responses API — das ist Woche 2.
Python-Skript überwacht inbox/. JSON-Dateien werden atomar nach processing/ verschoben, an Claude übergeben, Ergebnis nach done/ oder error/. Der Status ist der physische Speicherort.
Vorteile: extrem robust, ein Blick in die Ordner genügt, keine Race Conditions (Verschieben ist atomar), minimaler Code.
Risiko: Skaliert nicht für parallele Verarbeitung. Metadaten müssen im Dateinamen kodiert werden.
Eine einzige tasks.jsonl. ChatGPT hängt neue Aufgaben an. Watcher liest nur neue Zeilen, schreibt Ergebnis in results.jsonl. Alle Tasks chronologisch in zwei Dateien. Risiko: Statusverwaltung komplexer als Ordner, Teilverlust bei Absturz.
Neue Aufgabe = neuer Commit. Watcher reagiert auf Commits. Vollständige Histoire, Audit Trail. Für 30-Minuten-Implementierung zu ambitioniert. Git als zusätzliche Abhängigkeit.
ChatGPT generiert .md-Datei mit Shell-Codeblock. Watcher extrahiert und führt aus. Infrastruktur trivial, KI hat maximale Flexibilität.
Interessant als Konzept (Inversion of Control), aber: Voraussetzung ist dass ChatGPT zuverlässig sichere Shell-Skripte für lokale Systeme generiert — das ist eine sehr riskante Annahme.
Schnittstelle zu Claude Code: "Existiert eine stabile, nicht-interaktive CLI? Wenn Claude Code nur eine GUI-Anwendung ist oder eine interaktive Shell erfordert, scheitern alle Ansätze sofort."
Antwort von Claude: Die Schnittstelle existiert. claude --print -p "..." läuft non-interaktiv und gibt Text zurück.
| Frage | ChatGPT | Claude | Gemini |
|---|---|---|---|
| Wahrscheinlichkeit H1 | 60% | 100% (einzige Option) | 85% |
| Claude CLI-Schnittstelle | nicht erwähnt | existiert: --print -p | größte Unbekannte |
| Outlier | Siri/Sprache | Shell-Script = Hintertür | interessant aber riskant |
| ChatGPT→OUTBOX | gelöst? | immer noch manuell | nicht adressiert |
claude --print -p existiert. Gemini hat das als "größte Unbekannte" formuliert — es ist keine Unbekannte.Alle drei Stimmen haben denselben Fehler: Sie beginnen die Lösung beim falschen Ende.
Das Problem hat zwei Hälften:
In 30 Minuten wird Hälfte 2 gelöst. Das ist legitim und wertvoll. Aber Victor muss wissen: Er gibt danach immer noch JSON-Dateien in OUTBOX/ ab — er ist jetzt Paketbote mit einem besseren Paket, nicht ohne Pakete.
Hälfte 1 kommt in Woche 2 mit Responses API File Search.
Rainers Frage: Wenn der Watcher läuft und Victor eine JSON-Datei in OUTBOX/ legt — wie lange bis das erste Ergebnis in DONE/ liegt? Das ist die Metrik die beweist dass das System funktioniert. Ziel: unter 60 Sekunden.
dispatcher/OUTBOX/ PROCESSING/ DONE/ ERROR/ — 4 Ordner, 30 Sekunden.dispatcher/OUTBOX/_TEMPLATE.json mit dem Pflichtformat (id, from, type, title, payload, priority, ts).claude --print -p "Aufgabe: {payload}" — Ergebnis als Text zurück. Timeout: 120 Sekunden.DONE/task-id_result.md. Bei Fehler nach ERROR/task-id_error.txt.dispatcher/STATUS.md — wird bei jedem Statuswechsel überschrieben: Anzahl offen / in Arbeit / erledigt / Fehler.python3 watcher.py & — läuft im Hintergrund. Logfile: dispatcher/watcher.log.| Feld | Pflicht | Bedeutung |
|---|---|---|
id | ✓ | Eindeutige ID (Datum + Zähler). Verhindert Duplikate. |
from | ✓ | Quelle: "chatgpt", "victor", "gemini" |
type | ✓ | "task" (ausführen), "decision" (nur notieren), "context" (Wissen) |
title | ✓ | Kurztitel für Statusanzeige (max. 60 Zeichen) |
payload | ✓ | Vollständiger Auftrag für Claude Code |
priority | "high" oder "normal" (default: normal) | |
ts | ✓ | ISO-Timestamp der Erstellung |
Nur type: "task" wird ausgeführt. decision und context werden nur gespeichert — kein Claude-Aufruf.
| Was | Erlaubt? | Begründung |
|---|---|---|
| Watcher liest Datei und zeigt Victor | ✓ ja | Nur lesen, keine Ausführung |
| Victor bestätigt manuell | ✓ pflicht | Sicherheitsstopp V1 |
| Claude Code führt Task aus | ✓ nach Go | Claude CLI ist nicht mehr als claude-code-session |
| Shell-Befehle aus KI-Output | ✗ verboten | Kein eval, kein subprocess auf KI-Output |
| Automatisch ausführen ohne Victor-Go | ✗ verboten V1 | V2-Feature, braucht Whitelist |
| Zugriff auf .env / API-Keys | ✗ verboten | Watcher-Scope: nur dispatcher/ Ordner |
| Task löscht Dateien | ? Victor entscheidet | Im payload beschrieben, Victor sieht es vor Go |
Warum dieser Task: kein Schaden möglich, Ergebnis sofort sichtbar, prüft die gesamte Kette.
OUTBOX/PROCESSING/DONE/ mit ErgebnisSTATUS.md zeigt: "Erledigt: 1 / Offen: 0 / Fehler: 0"Wenn diese 6 Punkte erfüllt sind: System ist gebaut.
Die 30-Minuten-Lösung löst nur die zweite Hälfte des Problems.
Das System eliminiert Victor als Paketbote zwischen Datei und Ergebnis. Es eliminiert ihn nicht als Paketbote zwischen ChatGPT und Datei. Victor schreibt nach dem Bau immer noch JSON-Dateien von Hand in OUTBOX/ — er ist nur ein besserer, bewussterer Bote.
Das ist kein Scheitern. Das ist der richtige erste Schritt. Aber wer glaubt, nach 30 Minuten sei der Bote komplett entfernt, hat den Aufbau falsch verstanden.
Die erste Hälfte (ChatGPT schreibt direkt in OUTBOX/) kommt mit der Responses API in Woche 2.