2026 OpenClaw Frontend-Praxis:
Vercel Deployment Hook → Smoke, Security-Headers & Build-Summary

Unter Project → Settings → Git → Deploy Hooks erzeugen Sie eine Hook-URL für Production (oder getrennt für Preview). Diese URL darf nur Ihr OpenClaw-Ingress (Gateway, Edge-Worker oder kleiner Dienst mit gemeinsamem Geheimnis) aufrufen — niemals direkt den Mac-Runner. Der Ingress validiert Authorization: Bearer … oder einen HMAC über den Rohbody, antwortet dem Hook sofort mit 202 Accepted, vergibt OPENCLAW_RUN_ID und stößt asynchron scripts/vercel/openclaw-post-deploy.sh auf dem Remote Mac an.

Aus dem Hook-Body (JSON) oder aus von Vercel gesetzten Umgebungsvariablen lesen Sie mindestens: VERCEL_URL (Host ohne Schema), VERCEL_DEPLOYMENT_ID und VERCEL_GIT_COMMIT_SHA. Daraus bilden Sie DEPLOY_URL="https://${VERCEL_URL}" — bei Custom Domains zusätzlich eine Tabelle „Deployment-Kontext → kanonische öffentliche URL“, damit Smoke und Header-Checks dieselbe Adresse treffen wie Ihre Nutzer.

Reproduzierbare Mindestschritte (Ingress → Runner):

1. Signatur prüfen; Body mit jq parsen; bei unbekanntem target abbrechen und nur loggen (keine Secrets).
2. export VERCEL_URL VERCEL_DEPLOYMENT_ID VERCEL_GIT_COMMIT_SHA DEPLOY_URL OPENCLAW_RUN_ID; Host gegen Allowlist (z. B. *.vercel.app + Produktionsdomain).
3. Pro VERCEL_DEPLOYMENT_ID ein kurzes Datei-Lock (flock), damit parallele Hook-Lieferungen nicht dieselbe Suite doppelt starten.
4. Schwere Arbeit nie im HTTP-Thread: Queue oder Fork; Timeouts am Ingress kurz halten.

Die Pipeline besteht aus drei klar getrennten Phasen mit stabiler Schnittstelle zum Gateway-Log (NDJSON, ein JSON-Objekt pro Zeile, Feld phase).

(A) Warm-up: Solange curl -fsS -o /dev/null -w "%{http_code}" "$DEPLOY_URL" nicht 200 liefert oder ein definierter HTML-Marker fehlt, warten Sie mit exponentiellem Backoff (z. B. 2 s, 4 s, 8 s, max. 60 s). So fangen Sie Propagation und CDN-Warm-up ab, ohne willkürliche sleep-Werte im Skript zu hinterlegen.

(B) Security-Headers-Patrouille: In config/headers_expect.json (oder pro Branch headers_expect.production.json) listen Sie erwartete Präsenz oder Teilstrings für strict-transport-security, content-security-policy bzw. content-security-policy-report-only, x-frame-options, referrer-policy, permissions-policy usw. Messung mit curl -sSI "$DEPLOY_URL" (ggf. -H "Host: …" wie beim Monitoring). Normalisieren Sie Header-Namen klein, vergleichen Sie strukturiert; Abweichungen nach .openclaw/reports/headers_diff.txt. Optional: nur „kritische“ Keys als hart, andere als Warnung — das Skript exitiert dann mit unterschiedlichen Codes (2 hart, 3 weich), damit das Gateway den Digest unterscheidet.

(C) Smoke: npx playwright test tests/smoke --project=webkit --project=chromium mit BASE_URL=$DEPLOY_URL. Auf Apple-Silicon priorisieren Sie WebKit, um Safari-nah zu bleiben; bei Fehlern trace on und Artefakte unter .openclaw/traces/${OPENCLAW_RUN_ID}/. Jede Teilphase schreibt eine NDJSON-Zeile mit phase (warmup | headers | smoke), http_status, duration_ms, optional exit_code.

Konvention für Skript-Exit-Codes (empfohlen): 0 alles bestanden; 1 Warm-up-Timeout; 2 Header-Härtefehler; 3 Header nur Warnung; 4 Playwright-Fehler. So kann das Gateway in einem Satz melden: „Deploy abc123: Smoke fehlgeschlagen (Exit 4), Header Warnung (3)“. Dieselbe Tabelle dokumentieren Sie in README-openclaw-vercel.md im Repo — Support und Entwickler sprechen dann dieselbe Sprache.

Schnittstelle zum Betrieb: Ein einziges Einstiegskommando, z. B. make openclaw-vercel-post-deploy, ruft intern die drei Phasen in fester Reihenfolge auf und bricht bei hartem Header-Fehler vor dem teuren Browserlauf ab (spart Minuten pro fehlgeschlagenem Deploy). Optional hängen Sie nach erfolgreichem Smoke noch einen leichten Pre-Deploy-Smoke-Check nur für kritische Pfade an — nicht verdoppeln, sondern ergänzen.

Alle Phasen grün: schreiben Sie .openclaw/reports/build_summary.json im Schema build_summary/v1 mit git_sha, deploy_id, Dauer je Phase, headers_diff_bytes (oder 0) und status: "ok". Schlägt etwas fehl: status: "failed", failed_phase (z. B. headers), kompakte Fehlermeldung (erste Zeile Stack oder curl-Fehler), exit_code und Pfade zu Artefakten — ohne Tokens oder Rohtext mit Secrets.

Übertragen Sie die Summary per POST an Ihren Chat-Webhook, PR-Kommentar-API oder OpenClaw-Callback. Setzen Sie Idempotency-Key: ${VERCEL_GIT_COMMIT_SHA}:${VERCEL_DEPLOYMENT_ID}:summary (Namespace strikt von Netlify- und Cloudflare-Keys trennen). Wiederholte Hook-Lieferungen desselben Deployments erzeugen so höchstens ein sichtbares Update, nicht zehn Duplikate. Bearer und Webhook-Secrets nur aus dem Secret-Store; in NDJSON Felder maskieren (Authorization: ***).

Wenn Sie bereits Build-Metriken-PR-Summaries nutzen, können Sie Kennzahlen-Felder angleichen — Dashboards vergleichen dann Deployments über Plattformen hinweg.

Lange E2E-Suites nicht in den synchronen Hook-Pfad legen: Worker-Queue oder nächtlicher Cron für Volllast; der Hook soll nur annehmen und entkoppeln.