2026 OpenClaw, pratique front sur Mac distant :
Webhook de preview, Lighthouse CLI, seuils JSON, codes de sortie et digest lisible en pull request

Les capacités webhook de la passerelle OpenClaw s’articulent autour de quatre responsabilités : terminaison TLS, vérification HMAC (ou mTLS si vous préférez certificats mutuels), limite de débit et journalisation structurée (souvent une ligne NDJSON par phase). Lorsque Vercel, Netlify, Cloudflare Pages ou votre orchestrateur interne envoie un deployment webhook, la passerelle rejette les corps hors fenêtre temporelle, déduplique avec Idempotency-Key, puis confie l’exécution lourde au Mac loué afin que les PAT GitHub et secrets PaaS ne transitent pas sur le bord public. Vous réutilisez la même ingress pour d’autres portes documentées, par exemple Lighthouse pré-déploiement ou métriques de build en synthèse PR.

Après Lighthouse (Chromium), programmez une courte session Safari / WebKit — Playwright webkit, XCTest web, ou capture manuelle pilotée — sur le même profil machine. L’objectif n’est pas de dupliquer Lighthouse : c’est d’aligner la discussion produit sur « ce que voit Safari » tout en conservant une porte numérique automatisable pour la fusion.

1. Publier le hook. POST JSON vers la route HTTPS OpenClaw avec en-tête de signature ; rejeter les horodatages obsolètes (> quelques minutes).
2. Normaliser les champs. Mapper les clés fournisseur vers PREVIEW_URL, capturer GIT_SHA, PR_NUMBER, émettre OPENCLAW_RUN_ID unique.
3. Mettre en file sur le Mac. Écrire un job sous .openclaw/queue/ ; un agent launchd ou observateur local relance le worker pour survivre aux micro-coupures SSH.
4. Chauffer la preview. Deux GET (document + bundle JS principal) avec le user-agent Lighthouse ; backoff exponentiel sur 429.
5. Lancer Lighthouse CLI. Par exemple pnpm exec lighthouse "$PREVIEW_URL" --only-categories=performance --output=json --output-path=".openclaw/reports/${OPENCLAW_RUN_ID}.lhr.json" --chrome-flags="--headless=new" ; épinglez la révision Chromium par branche.
6. Évaluer les seuils. Lire perf/thresholds.json au commit courant ; produire verdict.json avec deltas chiffrés.
7. Codes de sortie. 0 succès, 2 régression produit, 3 infra (timeout, 403 persistant, certificat) après une relance contrôlée.
8. Publier le digest. Remplir le gabarit ci-dessous, POST vers l’API commentaires ou Checks, ajouter une ligne NDJSON phase=preview_lighthouse pour corrélation.

# Garde minimale avant fork worker (exemple)
set -euo pipefail
test -n "${PREVIEW_URL:-}" && test -n "${GIT_SHA:-}" || exit 3
# openclaw-hook-verify --secret "$HOOK_SECRET" --body "$RAW_BODY" --sig "$SIG_HEADER" || exit 3

{
  "performance": { "minScore": 0.85 },
  "metrics": {
    "largest-contentful-paint": { "maxNumericValue": 2500 },
    "cumulative-layout-shift": { "maxNumericValue": 0.08 },
    "total-blocking-time": { "maxNumericValue": 200 }
  }
}

Code 0 : tous les budgets respectés. Code 2 : régression mesurable — bloquer ou signaler la fusion selon votre politique. Code 3 : infrastructure ou authentification — relève de l’exploitation, pas du produit front.

Restez sous ~4 Ko pour l’application mobile GitHub. Si vous synchronisez aussi l’onglet Déploiements, réutilisez le même texte comme dans le guide API Deployments + Lighthouse.

### OpenClaw · Porte Lighthouse (preview)
- **Run** `OPENCLAW_RUN_ID` @ `GIT_SHA` sur Mac distant (Chromium épinglé)
- **URL** `PREVIEW_URL`
- **Scores** perf **{{score}}** (Δ {{delta}} vs baseline)
- **Métriques** LCP **{{lcp}} ms**, CLS **{{cls}}**, TBT **{{tbt}} ms**
- **Verdict** {{pass_or_fail}} — journaux `.openclaw/reports/{{run}}.lhr.json`
- **WebKit** {{webkit_smoke_one_liner}}