2026 OpenClaw — фронтенд на практике:
удалённый Mac: агрегация времени сборки Vite/Webpack и сводка регрессии производительности в PR

Задайте на удалённом Mac фиксированный каталог, например .openclaw/reports/${GITHUB_SHA:-$(git rev-parse HEAD)}/, и добавьте его в .gitignore. Исполняемая цепочка начинается с одинаковой базы инструментов: та же minor-версия Node, что в CI, npm ci или pnpm install --frozen-lockfile, затем production-сборка с инструментированием. Webpack: небольшой Node-скрипт оборачивает хуки compiler и пишет накопленные миллисекунды по фазам вроде seal и emit. Vite: плагин с остановкой в closeBundle и при необходимости после минификации — важно сохранять wall-clock в мс по фазам, а не только CPU-профиль.

После прогона должен остаться один JSON; сырой лог — опционально в raw/build.log. Перед OpenClaw выполните jq empty build_metrics.json и ненулевой выход при ошибке. Так прогон по каждому SHA воспроизводим, если документировать каталоги кэша и при сравнении чистить их по политике — см. оптимизацию кэша.

#!/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
jq empty "$BUILD_METRICS_PATH"

Разделяйте «измерение» и «сводку»: сначала валидный JSON, потом OpenClaw — тогда битая сборка не публикует полуготовый комментарий в PR.

Стабильный JSON-контракт снижает поломки парсера между командами. Минимум: schema (например build_metrics/v1), gitSha, toolchain (vite|webpack|rspack), nodeVersion, totalMs, phases — массив объектов с name, ms и при необходимости cacheHit (bool или доля 0–1). Дополнительно: ciLabel (метка runner), coldStart (свежий ли node_modules), entries при нескольких точках входа.

OpenClaw детерминированно проецирует поля в Markdown: обзор (SHA, общее время), таблица фаз, подсказка по кэшу. Не кладите в JSON абсолютные пути с именем пользователя на remote Mac — только относительные пути репозитория или хэши. Объёмы бандла лучше не дублировать: используйте сводку по analyzer.

Регрессии производительности относительны: baseline берите с последнего зелёного main или с merge-base с feature-веткой. Сохраните baselineMs и при необходимости baseline по фазам. Второй файл, build_gate.json, фиксирует итог: level — pass, warn или fail, reasons — короткие строки (например «totalMs +18 % к baseline»), deltas — имя фазы и процент.

Пороговая сигнализация: команда договаривается, например, +10 % → warn, +25 % → fail для totalMs, плюс жёсткий потолок для отдельных фаз (minify). Добавьте минимальный абсолютный прирост в мс для общего времени, чтобы микродрейф не считался регрессией. При fail job в CI красный; при warn — зелёный, но уходит уведомление и сводка OpenClaw. Промах кэша помечайте отдельно, не смешивая с регрессией кода.

Передайте build_metrics.json и build_gate.json в OpenClaw (CLI или HTTP-шлюз) и сгенерируйте pr_build_perf_summary.md с фиксированными заголовками: отпечаток коммита, дельта по общему времени, топ фаз, рекомендация (например «проверьте плагины минификации»). Агент не должен писать секреты в stdout или в Markdown.

Токен шлюза OpenClaw (минимальные права): отдельный Bearer- или mTLS-клиент только для вашего экземпляра OpenClaw — не GITHUB_TOKEN. Разрешения: по сути POST на эндпоинт сводки с лимитом тела; без доступа к репозиториям и без админских прав в организации. Короткий TTL или регулярная ротация; в CI — зашифрованный secret; локально — связка ключей macOS, не история shell. Утечка шлюза не даёт права на запись в Git — в отличие от широкого PAT.

Для комментария в PR используйте отдельный ограниченный GitHub-токен: pull-requests: write, при необходимости contents: read для одного репозитория — ортогонально шлюзу OpenClaw.

После генерации сводки CI может вызвать подписанный HMAC webhook (Slack, Teams, свой ingest) или выполнить gh pr comment. В теле — Markdown и метаданные PR, без сырого JSON при лимитах платформы. Задайте Idempotency-Key из номер PR + gitSha или HTML-комментарий <!-- openclaw-build-perf:$SHA -->, чтобы повторные прогоны обновляли один комментарий — по аналогии с сводкой графа бандла.

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"

Свяжите workflow с branch protection: fail из build_gate.json роняет job, warn только аннотирует. Повторы при 429 — с backoff; ошибки пишите в status.txt рядом с отчётом.

Монорепозиторий: отдельные phases по пакетам или поле packageName, чтобы OpenClaw не суммировал разные приложения.

Параллельные прогоны: различайте запуски через ciRunId, чтобы baseline не смешивались.

Расхождение с CI: холодный старт, другой каталог кэша, троттлинг CPU — фиксируйте cacheHit, NODE_OPTIONS и тип runner; сравнивайте с baseline на том же классе машин.