2026 OpenClaw Frontend-Praxis auf dem Remote Mac:
GitHub Deployments API, Lighthouse-Regression, Schwellenwerte und PR-lesbare Zusammenfassung

Webhook liefert Kontext; das Deployment-Objekt korreliert Logs; deployment_status bleibt lesbar ohne Actions-Tiefgang. Gateway-Observability: OPENCLAW_RUN_ID über NDJSON und Lighthouse-JSON identisch halten.

1. Kontext exportieren. GIT_SHA, PREVIEW_URL, PR_NUMBER, REPO als owner/name, OPENCLAW_RUN_ID und optional BASELINE_REF setzen.
2. Deployment anlegen. POST /repos/{owner}/{repo}/deployments mit ref gleich Commit-SHA, environment etwa preview/lighthouse, Metadaten mit Run-ID; deployment.id speichern.
3. Pending setzen. POST Status pending mit kurzer Beschreibung remote-mac: warme Preview, damit die UI den Lauf sichtbar macht.
4. Preview erwärmen. Zwei idempotente GETs auf HTML und Haupt-JS vom Mac mit dem User-Agent, den Lighthouse nutzt; bei 429 kurz warten und exponentiell wiederholen.
5. Lighthouse ausführen. CLI oder LHCI mit gepinntem Chromium; lhr.json nach .openclaw/reports/${OPENCLAW_RUN_ID}.lhr.json schreiben, analog zu Schwellen- und Alarmmustern.
6. Schwellen auswerten. Performance-Score, LCP, CLS, TBT gegen perf/baselines.json oder rollierenden Median vergleichen; nur Deltas in die Summary, keine vollständigen Traces im Status-Text.
7. deployment_status finalisieren. success oder failure posten, optional environment_url auf die Preview, log_url nur auf kurzlebigen Objektspeicher.
8. PR spiegeln. Identischen Kurztext als Issue-Kommentar setzen, damit Timeline und Deployments konsistent bleiben.
9. Idempotency erzwingen. Header Idempotency-Key: ${GIT_SHA}:${OPENCLAW_RUN_ID}:lighthouse am Gateway, damit doppelte Plattform-Hooks nicht forken.
10. NDJSON-Phase. Eine Zeile phase=lighthouse_github mit deployment_id, verdict, duration_ms anhängen; passt zu Service-Worker-PR-Summaries und weiteren Gates.

curl -H "Authorization: Bearer ${GITHUB_TOKEN}" \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  -H "Idempotency-Key: ${GIT_SHA}:${OPENCLAW_RUN_ID}:lighthouse" \
  https://api.github.com/repos/${REPO}/deployments

Klassische PATs mit vollem repo-Umfang sind bequem, erhöhen aber die Blast-Radius auf einem dauerhaft erreichbaren Mac. Besser: feingranularer PAT auf ein Repository oder ein GitHub-App-Installationstoken pro Lauf. Secrets nur im Gateway oder macOS-Schlüsselbund, niemals in Lighthouse-HTML oder Preview-Bundles exportieren.

Webhook-Signaturprüfung bleibt am Gateway; der Mac braucht kein admin:repo_hook, wenn der Hook zentral registriert ist. Rotation häufiger als die langlebigste Preview-URL.

• 404 bei Deployments: Repository-Zuordnung des feingranularen PAT prüfen; fehlende Ressourcenliste führt zu stillen Fehlern.
• Doppelte Deployments je Commit: Serverseitig auf (environment, ref) deduplizieren oder letzte Deployment-ID per List-API wiederverwenden.
• Lighthouse grün lokal, rot auf Preview: fehlende Auth-Cookies oder Geo-Header; Test-Credentials nur per Umgebungsvariablen injizieren.
• Starke LCP-Schwankungen: Chromium pinnen, Hintergrundprozesse auf dem Mac drosseln, Median der letzten drei grünen Läufe statt eines starren Goldwerts.
• Kommentarflut: Einen Marker-Kommentar pro SHA mit verstecktem HTML-Kommentar aktualisieren, falls der Bot Eigentümer ist.

Optional Pre-Deploy-Web-Smoke nachziehen.