2026 OpenClaw MeshMac en pratique : Zulip Incoming Webhook pour diffuser l’état de build multi-nœuds, les synthèses d’échec et la rotation des jetons (URL)

1. Secrets éparpillés : l’URL Zulip agit comme jeton porteur — la copier sur chaque Mac multiplie les fuites et le chaos en rotation.
2. Vérité CI ambiguë : sans file, deux runners peuvent publier des états partiels en concurrence.
3. Fatigue d’alerte : cartes séparées pour sondes, tempêtes 429 et échecs build noient la chronologie incident.

Objectif. Obtenir une URL https:// dont la requête ou le chemin joue le rôle de secret porteur : quiconque peut POST vers elle peut écrire dans le flux ou la cible DM choisie. Cette URL vit uniquement sur la passerelle OpenClaw, pas sur les builders du pool.

1. Admin organisation Zulip. Paramètres → Intégrations (libellés selon version), ajouter Incoming webhooks ou un bot dédié, choisir le flux et le sujet par défaut pour la CI (ex. flux builds, sujet meshmac).
2. Générer l’URL une fois. Copier l’URL complète affichée ; conserver l’exemple curl de Zulip comme référence de forme JSON pour ce gabarit d’intégration.
3. Fichier secret sur la passerelle. Ex. /etc/openclaw/secrets.d/zulip/build-status.url, mode 0440, propriétaire root, groupe openclaw-notify — voir secrets et moindre privilège MeshMac.

Emplacement capture d’écran : dialogue d’intégration Zulip montrant flux, sujet et URL webhook générée (flouter la clé dans la doc publiée).

Sonde depuis le shell passerelle (URL réelle ; sujet de test d’abord) :

sudo install -o root -g openclaw-notify -m 0440 /dev/null /etc/openclaw/secrets.d/zulip/build-status.url
sudo sh -c 'printf "%s" "https://votre-org.zulipchat.com/api/v1/external/...?api_key=COLLEZ_ICI" > /etc/openclaw/secrets.d/zulip/build-status.url'
sudo chown root:openclaw-notify /etc/openclaw/secrets.d/zulip/build-status.url
sudo chmod 0440 /etc/openclaw/secrets.d/zulip/build-status.url
sudo -u openclaw-notify -i
export ZULIP_INCOMING_WEBHOOK_URL="$(cat /etc/openclaw/secrets.d/zulip/build-status.url)"
curl -sS -w "\nhttp_code:%{http_code}\n" -X POST "$ZULIP_INCOMING_WEBHOOK_URL" \
  -H 'Content-Type: application/json' \
  --data-binary '{"content":"**Sonde OpenClaw** — egress passerelle OK"}'

Si le gabarit attend un autre champ (ex. text façon Slack), alignez le mapper passerelle sur l’échantillon Zulip — ne pas deviner en production.

Rotation URL bot (= rotation jeton). Fuite ou départ prestataire : générer une nouvelle URL dans Zulip, remplacer le fichier secret, recharger le notifieur, envoyer une sonde une ligne, valider le message, puis révoquer l’ancienne intégration. Documenter propriétaire et ordre de rollback à côté des pratiques canaux d’alerte et rotation des jetons.

Un seul émetteur. Un seul processus passerelle doit appeler Zulip. Les workers MeshMac publient des enregistrements build_finished vers une file ou RPC — file partagée et sync — au lieu d’ouvrir le TLS Zulip depuis chaque Mac.

1. Résoudre l’hôte depuis l’URL (Zulip Cloud souvent *.zulipchat.com ; self-host = votre domaine).
2. Pare-feu ou proxy sortant : autoriser TCP 443 depuis le sous-réseau passerelle uniquement vers cet hôte ; refuser la même destination depuis les VLAN builders pour échouer fermé en cas de runner mal configuré.
3. Inspection TLS : si proxy d’entreprise, importer le même magasin de confiance qu’OpenClaw ; journaliser hôte + statut HTTP, jamais l’URL complète.

Emplacement capture d’écran : ligne de règle pare-feu montrant VLAN passerelle → hôte Zulip:443 autorisé, VLAN builders → Zulip refusé.

Vérification DNS / SNI depuis la passerelle avant mise en service :

dig +short votre-org.zulipchat.com
openssl s_client -connect votre-org.zulipchat.com:443 -servername votre-org.zulipchat.com </dev/null | head -n 8

Normaliser avant rendu. Chaque worker émet : workflow, state terminal (succeeded / failed / cancelled), branch, commit court, run_url, mesh_node_id, provider_run_id, et si échec un failure_excerpt borné (environ 5–15 lignes, sans secrets).

Format synthèse multi-nœuds (exemple markdown). Un message par transition terminale ; en-tête compact pour mobile :

**CI** `ios-nightly` → **failed** · `main` @ `a1b2c3d`
**Nœud** `meshmac-pool-3` · **Run** [#1842](https://ci.exemple/runs/1842)
**Extrait**
\`\`\`
error: no space left on device
\`\`\`

Mapper ce bloc vers le champ JSON attendu — souvent content pour le markdown Zulip. Limiter la taille totale (restez largement sous quelques dizaines de ko) pour éviter les 400. Harmoniser timeouts avec rate limit et concurrence passerelle.

Emplacement capture d’écran : message Zulip rendu dans l’UI web (flux, sujet, bloc de code replié).

Saturation transitoire → 429 ou 5xx. Utiliser backoff exponentiel avec jitter complet, plafonner les tentatives, honorer Retry-After, sérialiser les posts par flux en incident — aligné sur retry file de tâches et backpressure streaming.

Clé d’idempotence. Avant émission, idempotency_key = sha256(provider_run_id + ":" + state) ; si cette clé a été livrée avec succès dans la fenêtre de dédup (souvent 24–72 h pour la CI), ne pas reposter. Cela coupe les doublons après Wi-Fi instable ou redémarrage worker.

Emplacement capture d’écran : extrait de journal passerelle montrant un POST unique http_code:200 et un cache idempotence évitant un doublon.

Sondes planifiées (curl vers Zulip), profondeur de file et taux d’erreurs HTTP webhook ne doivent pas chacune saturer un sujet pendant une panne. Émettre un message opérateur fusionné lorsqu’une combinaison dépasse les seuils : succès/échec sonde, résumé des cinq derniers statuts de livraison, file toujours alimentée ou bloquée.

Réutiliser le même gabarit markdown avec un préfixe distinct, ex. **[ops]**, et router vers un flux incidents pour garder le flux builds lisible. Fenêtre de refroidissement 5–15 min, comme les idées d’alertes fusionnées dans le guide streaming / backpressure.

Sonde cron minimale (même utilisateur service ; journaliser code sortie, pas l’URL) :

TS=$(date -u +%Y-%m-%dT%H:%M:%SZ)
BODY=$(printf '%s' "{\"content\":\"**[ops sonde]** ${TS}\"}")
/usr/bin/curl -fsS -m 15 -X POST "$ZULIP_INCOMING_WEBHOOK_URL" \
  -H 'Content-Type: application/json' \
  --data-binary "$BODY" \
  || logger -t openclaw-zulip-probe "probe_failed"

Lors d’exercices de bascule passerelle, suivre permissions cluster et failover pour éviter que deux passerelles ne double-postent le même webhook pendant la coupure.

• Sonde curl retourne HTTP 200 et message visible dans Zulip.
• Workers n’émettent que des transitions terminales ; la passerelle possède la dédup.
• Pare-feu : Zulip:443 depuis passerelle uniquement ; builders sans egress direct.
• Runbook rotation : propriétaire, commande sonde, étape révocation ancienne URL.
• Échecs santé + livraison fusionnés sous fenêtre de refroidissement.