Der Relay-Scheduler feuert die Ritual-Workflows nicht — Ursache oder dauerhafte Ersatzloesung

[munirad7s]

Mission

Klären, warum der Buzz-Relay-Scheduler die Ritual-Workflows nicht feuert — und ihn entweder reparieren bzw. upstream melden oder die Ersatzlösung dauerhaft festschreiben.

Money-Link

Führungsrituale sind der Hebel auf Munirs Zeit. Solange sie an der Windows-Aufgabenplanung genau dieser Maschine hängen, sterben sie mit jedem Neuaufsetzen. Ein funktionierender Relay-Scheduler macht sie maschinenunabhängig — und ist Voraussetzung für jedes weitere zeitgesteuerte Ritual (Wochen-Review, Mahnlauf, Follow-up-Kaskade).

Kontext (gemessen 2026-08-01, buzz#10)

• Beide Ritual-Workflows sind enabled: true, Crons in UTC korrekt (45 6 / 45 18), Kanal gesetzt, Owner = Agent-Pubkey 78be5e27….
• 3 planmäßige Termine verstrichen ohne einen einzigen Lauf (31.07. 08:45, 31.07. 20:45, 01.08. 08:45). Die Historie von #general ist vollständig (19 Nachrichten) und enthält keine einzige buzz:workflow-Nachricht aus einem Zeitplan.
• Direkte Probe: Workflow auf eine Zielminute 3 min in der Zukunft gesetzt (accepted: true), 6 min gepollt → keine Nachricht. Danach zurückgesetzt, Revert verifiziert.
• Manueller Trigger funktioniert (workflows trigger → run_id, Nachricht erscheint im Kanal). Executor und Action-Sink sind also gesund — es fehlt nur der Zeitauslöser.
• ⚠️ workflows runs --workflow <id> liefert [], auch direkt nach einem nachweislich erfolgreichen Lauf. Die Run-Liste ist als Beweismittel unbrauchbar; wer daraus "nie gelaufen" schließt, misst das falsche Ding. Das ist ein eigener Befund.
• Relay ist gehostet: https://adaswin.communities.buzz.xyz, /health = ok.
• Code-Kandidaten (crates/buzz-workflow/src/lib.rs): check_owner_authority() (fail-closed, wenn der Owner keine Kanal-Rolle mehr hat), list_all_enabled_workflows(), claim_scheduled_workflow_fire(). Der Cron-Loop wird in crates/buzz-relay/src/main.rs:625 gespawnt.
• Ersatz heute: Windows-Aufgaben Buzz-Ritual-Morgenbrief / Buzz-Ritual-Gate-Batch über .empire/tools/ritual-task.cmd — live bewiesen (16:08:00 und 16:10:00 punktgenau gefeuert).

Vorflug-Check (nach Claim, vor Arbeit)

1. workflows runs gegen einen frischen manuellen Trigger prüfen — liefert es weiterhin [], ist das ein eigenständig zu meldender Befund.
2. Prüfen, ob der Owner-Pubkey des Workflows im Zielkanal noch eine Mitglieds-Rolle hat (wahrscheinlichster fail-closed-Pfad).

Auftrag

1. Ursache eingrenzen: Owner-Autorität vs. Workflow-Sichtbarkeit vs. Cron-Loop läuft gar nicht.
2. Ist es die Owner-Autorität: Workflow-Owner auf eine Identität mit dauerhafter Kanal-Rolle umziehen (neu anlegen, alten mit enabled: false neutralisieren — delete wird angenommen, löscht aber nicht).
3. Ist es der Relay: Befund mit Reproduktion upstream melden (block/buzz), lokal bei der Aufgabenplanung bleiben.
4. Ergebnis in .empire/AGENTS.md nachziehen, Abschnitt "Führungsrituale".

Nicht-Ziele / Guardrails

• Keine neuen parallelen Workflows anlegen, solange die bestehenden editierbar sind.
• Die Windows-Aufgaben erst abschalten, wenn der Relay-Scheduler nachweislich feuert — nicht vorher.

Verifikation (Befehle + erwartete Ausgabe)

#	Aktion	Erwartung
1	Workflow auf T+3 min, warten	Nachricht mit Tag buzz:workflow erscheint im Kanal
2	Danach zurücksetzen	Cron wieder auf Produktionszeit, per workflows list bestätigt
3	Negativprobe	Ein enabled: false-Workflow feuert nicht

Definition of Done

• Ursache benannt (nicht vermutet) oder als upstream-Bug mit Reproduktion gemeldet
• Entweder Relay-Scheduler feuert, oder die Aufgabenplanung ist als dauerhafte Lösung dokumentiert
• Issue mit Ergebnis-Kommentar geschlossen

Rechte

Chrome-MCP, Windows-MCP, Playwright, n8n-MCP, ~/.secrets/** — ohne Rückfrage. Blocker → blocker-mail.sh + Label blocked-munir + weiter.

Format v2 · buzz_empire 2026-08-01

[munirad7s]

🐝 buzz_empire 2026-08-01 16:36 übernimmt — Diskriminator-Experiment: Owner-Autorität vs. Cron-Loop tot.

[munirad7s]

🔬 Ursache eingegrenzt — mit zwei Diskriminator-Experimenten, nicht mit einer Vermutung.

Der Verdacht aus #10 war check_owner_authority(): der Workflow-Owner ist ein Agent-Pubkey, und der Cron-Loop überspringt fail-closed, wenn der Owner keine aktuelle Kanal-Rolle hat. Der Verdacht ist widerlegt.

Experiment 1 — Owner ist der Community-Owner selbst

Einzige geänderte Variable: der signierende Schlüssel. Neuer Workflow in #general, Owner = identity (Munirs eigener Schlüssel, sicher berechtigt), Cron auf eine Zielminute 3 min in der Zukunft, harmloser Text.

create   -> accepted:true, workflow_id a6865a7d-…
Ziel     -> 14:40 UTC
Poll     -> 6 min
Ergebnis -> KEINE Nachricht

→ Auch mit maximaler Autorität feuert nichts. Die Owner-Autorität ist nicht die Ursache.

Experiment 2 — der zweite Codepfad im Scheduler

WorkflowEngine::run() hat zwei Zweige: cron und interval. Wenn nur der Cron-Zweig defekt wäre (Parsing, Fenster-Matching), müsste interval feuern. Derselbe Workflow auf interval: 90s gestellt, ~6 min beobachtet = 4 fällige Intervalle:

Ergebnis -> KEINE Nachricht

→ Beide Zeitauslöser-Codepfade sind tot. Das ist kein Cron-Ausdruck-Problem und kein Autoritätsproblem: der 60-Sekunden-Loop erreicht diese Community überhaupt nicht.

Was damit feststeht

Schicht	Zustand
Workflow-Definitionen	✅ gültig, enabled: true, Kanal gesetzt, Crons in UTC korrekt
Manueller Trigger → Executor → Action-Sink	✅ funktioniert (run_id + Nachricht im Kanal, mehrfach reproduziert)
Owner-Autorität	✅ nicht die Ursache (Experiment 1)
Cron-Parsing / Fenster-Matching	✅ nicht die Ursache (Experiment 2)
Zeitgesteuertes Auslösen	❌ findet nicht statt — serverseitig
workflows runs	❌ liefert immer [], auch nach erfolgreichem Lauf — als Beweismittel unbrauchbar

Der Relay ist gehostet (adaswin.communities.buzz.xyz, /health = ok). Wir haben dort weder Logs noch Konfiguration — WorkflowEngine cron loop started (60s tick) ist eine Log-Zeile, die wir nicht sehen können. Von hier aus ist die Ursache nicht weiter eingrenzbar; sie liegt in der gehosteten Instanz.

Aufräumzustand (keine Geisterzustände)

Workflow	Zustand
88c25e55 Daily Morning Brief	enabled: true, 45 6 * * *
857d07e7 Daily Munir Gate Batch	enabled: true, 45 18 * * *
518ba5a2 Command Center Router	unberührt
6fa01e2b daily-briefing	enabled: false (Altbestand)
a6865a7d zz-owner-probe-60	enabled: false — Grabstein; workflows delete wird angenommen, löscht aber nicht

⚠️ Dabei selbst hineingetappt: der Interval-Lauf wurde vom Werkzeug-Timeout mit SIGTERM beendet, und ein trap … EXIT fängt SIGTERM nicht — der Probe-Workflow blieb aktiv zurück. Nachträglich neutralisiert und der Endzustand aller fünf Workflows einzeln verifiziert. Lehre für jede Set/Beweis/Revert-Schleife: trap … EXIT INT TERM, und die Wartezeit muss unter dem Werkzeug-Timeout bleiben.

Ersatzlösung ist produktiv und bewiesen

Windows-Aufgaben Buzz-Ritual-Morgenbrief (08:45) und Buzz-Ritual-Gate-Batch (20:45) über .empire/tools/ritual-task.cmd. Beide haben am 01.08. punktgenau gefeuert (16:08:00 / 16:10:00, Windows-Ergebnis 0) und in Kanal, Telegram und Tagesnotiz zugestellt. Die Aufgabenplanung rechnet in Ortszeit — der Winterzeit-Bruch der UTC-Crons entfällt. Beide Buzz-Workflows bleiben als Kanal-Definition stehen und zeigen auf dasselbe Kommando; feuert der Relay-Scheduler wieder, greifen sie ohne weitere Arbeit.

Was noch offen ist — und warum ich es nicht selbst tue

Der nächste sinnvolle Schritt ist eine Meldung an block/buzz mit dieser Reproduktion. Das ist ein Issue in einem fremden Repo und damit nach .empire/POLICY.md GATED — ich kann es, aber ich darf es nicht ohne Munirs Freigabe. Der Text stünde öffentlich unter seinem Account.

Munirs Entscheidung (30 Sekunden): Befund als Issue in block/buzz melden — ja oder nein? Inhalt wäre exakt die beiden Experimente oben, ohne Namen, Kunden, Zahlen oder Community-Interna. Bei „ja" macht der nächste Agent es in einem Schritt.

Bis dahin: blocked-munir. Der Betrieb hängt nicht daran — die Rituale laufen.