Donnerstag, 28. Mai 2026

why

what

• Ursache im Shadow-Profil von Hermes identifiziert: In `.hermes/profiles/tyrone-shadow/.env` war die Umgebungsvariable `HERMES_INFERENCE_PROVIDER` explizit auf `alibaba-coding-plan` gesetzt. Dies überschrieb die korrekte Provider-Einstellung (`xai-oauth`) aus der `config.yaml` und erzeugte bei jedem neuen Telegram-Inbound-Turn eine fehlerhafte Alibaba-Modellzuordnung für `grok-4.3`.
• `.env` aktualisiert: `HERMES_INFERENCE_PROVIDER` von `alibaba-coding-plan` auf `xai-oauth` geändert.
• Stale Session-State bereinigt: Die `sessions.json` wurde geleert, um sicherzustellen, dass keine alten Session-Caches mit der Alibaba `base_url` geladen werden.
• `hermes-gateway-tyrone-shadow.service` neu gestartet.

verification

• Service `hermes-gateway-tyrone-shadow.service` läuft aktiv (`active (running)`) und ohne Fehler.
• Verbindungsaufbau zu Telegram im `gateway.log` erfolgreich verifiziert (`Connected to Telegram (polling mode)`).
• Neuer Inbound-Turn wird jetzt dank korrigierter Umgebungsvariable sauber über `xai-oauth` abgewickelt.

rest-risiko

why

what

• Root Cause im Hermes-Journal bestätigt: Der Telegram-Turn nutzte weiter `provider=alibaba-coding-plan` und `base_url=https://coding-intl.dashscope.aliyuncs.com/v1`, aber mit `model=grok-4.3`.
• Stale Session-State gesichert: `.hermes/backups/tyrone-shadow-stale-alibaba-telegram-sessions-20260528T1938Z/`.
• Akute stale Sessions gelöscht, übrige offene Telegram/Alibaba-Sessions in der DB beendet und `sessions/sessions.json` auf `{}` zurückgesetzt.
• `hermes-gateway-tyrone-shadow.service` neu gestartet.

verification

• `open_telegram_alibaba_count=0`.
• `sessions.json={}`.
• Hermes Default-Smoke: `HERMES_GROK_DEFAULT_AFTER_TELEGRAM_RESET_OK`.
• Letzte Hermes-Smoke-Session: `billing_provider=xai-oauth`, `model=grok-4.3`, `base_url=https://api.x.ai/v1`.
• Gateway-Service active; seit Restart kein neuer Alibaba/Grok-4.3-Fehler im Hermes-Gateway-Journal.

rest-risiko

why

what

• User-Crontab gesichert: `openclaw/backups/user-crontab-before-directrunner-utc-20260528T191523Z.txt`.
• Direct-Runner-Blöcke auf explizite UTC/CEST-Slots umgestellt; `CRON_TZ=Europe/Berlin` aus aktiver Crontab entfernt.
• Heute verpasste Slots manuell nachgezogen: `tli:market-data-feeder`, `ceo:daily-decision-briefing`, `tli:cf-market-feeder`, `tli:prediction-tracker`.
• Watchdog-Status neu geschrieben: `status=ok`, `issue_count=0`.
• EOD-Subagent-Smokes für `doug`, `bill`, `robin` über `xai/grok-4.3` ergänzt.

verification

• Alle vier Nachläufe exit 0 und Marker geschrieben; CEO-Briefing Telegram `ok`.
• `qwen-cron-watchdog.py --dry-run`: `status=ok`, `issue_count=0`.
• Aktive OpenClaw-Crons mit DashScope-/Qwen-/Kimi-Payload-Modell: 0.
• Doug/Bill/Robin: `provider=xai`, `model=grok-4.3`, `fallbackUsed=false`.
• `openclaw health` grün; OpenClaw- und Hermesto-Services active.

rest-risiko

why

what

• `[private-config]`: `agents.defaults.model.primary`, Heartbeat sowie `main`, `doug`, `bill`, `robin` auf `xai/grok-4.3`; DashScope-Fallbackkette geleert.
• Hermesto `tyrone-shadow`: Default auf `xai-oauth/grok-4.3`; Fallbackkette geleert.
• Hermesto-Auxiliary-Pfade `web_extract`, `compression`, `session_search`, `skills_hub`, `approval`, `title_generation` ebenfalls auf `xai-oauth/grok-4.3`.
• Hermes `MEMORY.md` aktualisiert, damit kein stale Alibaba-Default dokumentiert bleibt.
• Backups vor Cutover unter `openclaw/backups/` und `~/.hermes/backups/` abgelegt.
• `openclaw-gateway.service` und `hermes-gateway-tyrone-shadow.service` neu gestartet.

verification

• `openclaw config validate --json` valid.
• OpenClaw Default-Smoke: `OPENCLAW_GROK_DEFAULT_OK`, `provider=xai`, `model=grok-4.3`, `fallbackUsed=false`.
• Hermes Default-Smoke: `HERMES_GROK_DEFAULT_OK`.
• Beide systemd-User-Services aktiv; `openclaw health` nach kurzer Model-Call-Last wieder grün.

rest-risiko

why

was

• `ab-test-grok-vs-qwen-telegram-crons.md` §10 neu: 5 Runtime-Test-Punkte (Tyrone-Runtime auf Grok, Subagenten, Heartbeat, Hermes-Default-Pfad, Tool-Use-Stabilität) plus angepasste Entscheidungsmatrix („Grün" gilt nur, wenn Runtime auch grün).
• Memory `project_alibaba_cutover_runtime_risk.md` angelegt + im MEMORY.md verlinkt.
• Watchdog deckt diese Lücke explizit nicht ab (anderer Scope) — in Plan §10 dokumentiert.

attribution

why

was

• Cron-Zeile `15 * * * * qwen-cron-watchdog.py --notify` in die OS-Crontab eingetragen (Backup unter `/tmp/crontab.backup.[id]`).
• Read-only, alert-only Design (Telegram-Dedup analog Codex-Monitor); Qwen-Second-Opinion hinter Flag, Default aus.
• Migrations-Karenz pro `block` schluckt Slot-Lücken vor Crontab-REPLACE (Rest-Block ab 14:).
• Lifecycle: bis 2026-06-03 , danach Phase-3-Optionen A/B/C aus Plan §7.

artefakte

• Plan: `openclaw/workspace/plans/qwen-cron-watchdog-2026-05-28.md`
• Skript: `openclaw/workspace/scripts/qwen-cron-watchdog.py`
• Inventory: `openclaw/workspace/scripts/qwen-cron-watchdog-inventory.json`
• Status: `openclaw/workspace/memory/qwen-cron-watchdog.json`

attribution