ROBUSTER CHERRY↔WATSON-AUTOMATIONSKANAL auf macOS — Architektur-Entscheidung:
Cherry (ChatGPT im Browser mit MCP-Tools) soll Watson (lokaler Claude-Code-Dispatcher in tmux) zuverlässig Aufträge geben und Antworten lesen, ohne Nutzer-Copy/Paste oder Terminal-Bestätigungen. Nutzer bleibt Regisseur.
Aktueller Stand: MCP-Tool 'send_watson_job' schreibt Job-Markdown in Queue-Ordner + sendet Kurzmarker an tmux-Pane. Test funktioniert, aber ChatGPT zeigt Bestätigungsdialoge für Schreib-/Sendeaktionen. Rückkanal (latest.md) nicht stabil.
Vorgeschlagenes Pull-Modell:
- Cherry legt nur Jobdatei in CHERRY_WATSON/JOBS_FROM_CHERRY/
- Watson pollt alle 2-5s, liest Jobs, schreibt Antworten nach OUTBOX_TO_CHERRY/
- MCP-Tools: nur queue_watson_job() + get_watson_job_status() — keine tmux, keine Shell, keine Pfade
- Feste Ordnerstruktur, Job-IDs, Status-Tracking
Fragen (bitte konkret, kein Enterprise-Overhead):
1. Pull-Modell vs. aktuelles Push+tmux-Modell — welches ist robuster?
2. Minimales Toolset für wenig ChatGPT-Sicherheitsdialoge?
3. Ist 'queue_watson_job' (reine Datei-Aktion) weniger problematisch als 'send_watson_job' (klingt nach Fernsteuerung)?
4. Rückkanal-Design: wie weiß Cherry zuverlässig ob Job angekommen/läuft/fertig/Fehler/hängt?
5. Welche Dateien/Ordner/Statusfelder empfehlt ihr? Pragmatisch.
6. Race Conditions bei schnellen Mehrfach-Jobs vermeiden?
7. Watson pollt selbst ODER LaunchAgent/Watcher stößt Watson an — was ist stabiler?
8. Gibt es eine bessere Alternative ohne Nutzer-Bestätigungen?
9. Übersehene Risiken: Tool-Dialoge, blockierte Mehrzeileninhalte, stale latest.md, hängende Jobs, falscher tmux-Kontext?
10. Klare Empfehlung: A) Pull-Modell bauen, B) Push+tmux verbessern, C) anderes Modell, D) erst Sicherheitsschicht?
Einzel-Nutzer, macOS, schnell baubar, lokal — keine Cloud, kein Redis, keine Message-Queue-Infrastruktur.2026-06-01$0.0305