2026 OpenClaw Frontend-Praxis:
Remote Mac: Vite/Webpack-Buildzeiten aggregieren — PR-Performance-Regression-Summary zurückspielen

Legen Sie auf dem Remote Mac ein festes Ausgabeverzeichnis fest, etwa .openclaw/reports/${GITHUB_SHA:-$(git rev-parse HEAD)}/, und ignorieren Sie es in Git. Die ausführbare Kette beginnt mit reproduzierbarer Tooling-Basis: gleiche Node-LTS-Minor wie in der CI, npm ci oder pnpm install --frozen-lockfile, dann ein Build mit Instrumentierung. Webpack: kleines Node-Skript, das compiler-Hooks mit process.hrtime.bigint() um Phasen wie „seal“ und „emit“ wickelt und kumulierte Millisekunden schreibt. Vite: Plugin, das in closeBundle und nach optionaler Minification stoppt — wichtig ist, dass Sie Wall-Clock-ms je Phase speichern, nicht nur CPU-Profile.

Nach dem Lauf soll ein einziges JSON entstehen; Rohlogs bleiben optional unter raw/build.log. Validieren Sie mit jq empty build_metrics.json, bevor OpenClaw startet. So bleibt der Ablauf pro Git-SHA bitweise wiederholbar, solange Cache-Verzeichnisse dokumentiert und bei Bedarf geleert werden — siehe auch Cache-Optimierung für faire Vergleiche.

#!/usr/bin/env bash
set -euo pipefail
SHA="${GITHUB_SHA:-$(git rev-parse HEAD)}"
OUT=".openclaw/reports/${SHA}"
mkdir -p "$OUT"
export BUILD_METRICS_PATH="$OUT/build_metrics.json"
npm run build:instrumented   # ruft eure Webpack/Vite-Hooks auf
jq empty "$BUILD_METRICS_PATH"

Trennen Sie „Messung“ und „Summary“: erst valides JSON, dann OpenClaw — so scheitern defekte Builds schnell und geben keine halbfertigen PR-Kommentare ab.

Ein stabiler JSON-Vertrag reduziert Parser-Brüche zwischen Teams. Empfohlenes Minimum: schema (z. B. build_metrics/v1), gitSha, toolchain (vite|webpack|rspack), nodeVersion, totalMs, phases als Array von Objekten mit name, ms und optional cacheHit (boolean oder Trefferquote 0–1). Ergänzend: ciLabel (Runner-Name), coldStart (ob node_modules frisch war) und entries, wenn mehrere HTML-Entrypoints separat gemessen werden.

OpenClaw liest diese Felder deterministisch und projiziert sie in Markdown-Abschnitte: Übersicht (SHA, Gesamtzeit), Phasen-Tabelle, Cache-Hinweis. Keine Pfade mit Benutzernamen vom Remote Mac im JSON ablegen — relative Repo-Pfade oder Hash-IDs. Wenn Sie zusätzlich Bundle-Größen auswerten, verlinken Sie statt Duplikaten die Analyzer-Schwellen-Summary.

Performance-Regressionen sind relativ: laden Sie eine Baseline vom letzten grünen main-Build oder vom merge-base mit Ihrem Feature-Branch. Speichern Sie baselineMs und optional Phasen-Baseline in einer kleinen Datei oder holen Sie sie aus Ihrer Artefakt-Registry. Ein zweites JSON, build_gate.json, fasst das Ergebnis zusammen: level mit Werten pass, warn oder fail, reasons als kurze Strings (z. B. „totalMs +18 % gegenüber baseline“), deltas mit Phasennamen und Prozent.

Schwellen-Alarm: definieren Sie Team-weit z. B. +10 % warn, +25 % fail auf totalMs, plus harte Obergrenzen für Einzelphasen (Minify). CI kann bei fail den Job rot stellen, bei warn nur den OpenClaw-Kommentar posten — so bleiben harte Blocker und weiche Signale trennbar.

Übergeben Sie build_metrics.json und build_gate.json an OpenClaw (CLI oder HTTP-Gateway) und erzeugen Sie pr_build_perf_summary.md mit festen Überschriften: Fingerprint, Gesamt-Delta, Top-Phasen, Empfehlung (z. B. „Prüfen Sie Minify-Plugins“). Der Agent soll keine Secrets nach stdout oder in die Markdown-Datei schreiben.

OpenClaw-Gateway-Token (Minimalrechte): separater Bearer- oder mTLS-Client nur für Ihre OpenClaw-Instanz — nicht der GitHub-GITHUB_TOKEN. Rechte: ausschließlich POST auf den Summary-Endpunkt mit Größenlimit; kein Zugriff auf Repositories, keine Org-Administration. Kurze TTL oder regelmäßige Rotation; in CI als verschlüsseltes Secret; lokal im macOS-Schlüsselbund statt in Shell-History. So bleibt ein Leck des Gateway-Tokens von Git-Write-Rechten entkoppelt — im Gegensatz zu einem PAT mit breiten Repo-Rechten.

Für Git-Interaktionen (PR-Kommentar) verwenden Sie weiterhin einen eingeschränkten GitHub-Token nur mit pull_requests: write und contents: read auf ein Repository — orthogonal zum OpenClaw-Gateway.

Nach der Summary-Generierung kann die CI einen HMAC-signierten Webhook (Slack, Teams, eigenes Ingest) aufrufen oder gh pr comment nutzen. Der Body enthält nur den Markdown-Text und Metadaten wie PR-Nummer — keine Roh-JSON-Artefakte, wenn die Plattform Zeichenlimits hat. Setzen Sie einen Idempotency-Key aus pr-Nummer + gitSha oder einen HTML-Kommentar <!-- openclaw-build-perf:$SHA -->, damit erneute Läufe bestehende Kommentare aktualisieren statt Spam zu erzeugen — analog zur Bundle-Graph-Summary.

curl -sS -X POST "$BUILD_PERF_WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -H "X-Hub-Signature-256: sha256=$(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$WEBHOOK_SECRET" -binary | xxd -p -c 256)" \
  -d "$BODY"

Verbinden Sie optional denselben Workflow mit Branch-Protection: fail aus build_gate.json bricht den Job ab, während warn nur annotiert. So bleibt die Webhook-Schicht rein informativ und der Merge-Status folgt Ihrer Policy.

Monorepo: Messen Sie pro Workspace-Paket getrennte phases oder tragen Sie packageName im JSON, damit OpenClaw keine Zeiten verschiedener Apps summiert.

Parallelität: Wenn mehrere Builds gleichzeitig laufen, unterscheiden Sie Runs über ciRunId, um Baseline-Vergleiche nicht zu vermischen.

429 / Rate-Limits: Backoff und Warteschlange am Gateway; Fehler in status.txt neben dem Report loggen statt stillem Retry.