ellmos-ai PingPong
Betreibe zwei oder mehr Systeme als Funkstellen über einen gemeinsamen Sync-Ordner. Halte den fachlichen Vertrag providerneutral; nur der Fortsetzungsadapter unterscheidet sich.
Modus bestimmen
- ListenSync: Genau ein systematischer Listener pro Host. Er scannt, übernimmt passende Aufträge und führt bei Antworten auch WriteSync aus.
- WriteSync: Jeder arbeitende Akteur darf eigene relevante Deltas, Aufträge, Neuigkeiten und Receipts senden. Dieser Modus startet keinen Listener.
- Fehlt der Modus, verwende ListenSync.
Laufvertrag festlegen
- Verwende standardmäßig 24h. Akzeptiere auch relative Dauern wie 15m, 2h, 3d oder einen absoluten ISO-8601-Endzeitpunkt.
- Messe die lokale Startzeit und nenne expires_at mit Datum, Uhrzeit und Zeitzone.
- Starte mit 15 Minuten. Nutze die Kadenz aus references/protocol.md, sofern der User keine feste Kadenz verlangt.
- Definiere Zielerfüllung als: Endzeit erreicht, abschließender FileCommander-Scan belegt, alle bis dahin erkannten passenden Eingänge bearbeitet oder präzise blockiert dokumentiert, State aktualisiert und eigener Scheduler beendet.
- Behaupte ohne FileCommander-Beleg weder Scan noch Zielerfüllung.
Provider-Adapter verwenden
Codex
Erstelle vor dem ersten Scan ausdrücklich ein persistiertes Goal mit dem vollständigen Laufvertrag und expires_at. Bearbeite pro Fortsetzung genau einen vollständigen Scanzyklus. Beende das Goal nicht nach einem leeren oder erfolgreichen Einzelzyklus. Warte danach real bis next_scan_at, beispielsweise mit:
python "<skill-root>/scripts/pingpong_runtime.py" wait --until "<next_scan_at>"
Führe am Ablaufzeitpunkt den Abschlusszyklus aus. Markiere das Goal nur bei erfülltem Erfolgskriterium als abgeschlossen.
Claude Code
Starte den Auftrag als /loop $pingpong. Wenn der Skill bereits aus einem geplanten Lauf kommt, lege keinen zweiten Loop an. Ersetze bei einer Kadenzänderung nur den eigenen Cron-Job. Lösche ihn nach dem Abschlusszyklus.
Zyklus ausführen
Lies references/protocol.md vollständig und führe genau einen dort beschriebenen Scan-, Bearbeitungs- und State-Zyklus aus. Verwende für jeden Zugriff im Sync-Ordner ellmos FileCommander. Ein Shell-Listing, ein Scheduler-Eintrag oder ein Dateiname allein ist kein Scanbeleg.
Erfinde bei Leerlauf keine Arbeit. Melde knapp: Scanzeit, gelesene Freshness-Dateien, aktuelle Kadenz, empty_runs, next_scan_at und expires_at.
WriteSync ausführen
Schreibe nur in den eigenen Systemslot oder einen ausdrücklich globalen Kanal. Nenne Absender, Empfänger, Zeit, Bezug, Handlung, Ergebnis, offene Punkte und gewünschte Kadenz. Merge statt Überschreiben; keine Credentials; Locks respektieren. Lies die kanonische Datei nach dem Schreiben mit FileCommander zurück.
Changelog
1.0.1 (2026-09-09)
- Deklarative Rollenmetadaten nach dem optionalen Modul-v2-Rollenvertrag ergänzt; kein neutraler Starter deklariert. Bestehende Protokollidentität und Discovery-Pfad bleiben erhalten.
1.0.0 (2026-08-04)
- Providerneutraler ListenSync-/WriteSync-Vertrag mit Codex-Goal- und Claude-Loop-Adaptern.
- FileCommander-Beleg, Freshness-Guard, adaptive Kadenz und absolute Ablaufbedingung ergänzt.