OpenClaw на фронтенде в 2026 году:
Deploy Hook → смоук, мёртвые ссылки и сводка сборки на удалённом Mac

Сборка на Netlify доказывает, что код компилируется; пользователи через несколько минут всё равно видят ошибки маршрутизации, устаревший edge-кэш и баги только в WebKit/Safari. Deploy Hook — минимальный контракт платформы: «деплой завершился — реагируйте». Если передать этот сигнал на удалённый Mac с работой 7×24, вы получаете настоящие движки Safari, стабильные сессии и автоматизацию, которая не обрывается, когда кто-то закрыл крышку ноутбука.

OpenClaw удобен там, где один POSIX-хост оркестрирует Playwright, curl и небольшие утилиты на Node. Считайте хук постановкой задачи в очередь, а не приглашением выполнять сорок минут тестов внутри одного HTTP-запроса: быстро подтвердите приём, запустите долгую работу в фоне и пишите структурированные логи — дежурному проще сопоставить падения по netlify_deploy_id, чем открывать десять дашбордов.

После сборки Netlify может вызвать ваш Build hook методом POST. Запрос должен попадать в ingress под вашим контролем: шлюз OpenClaw, лёгкий Worker на периметре или nginx на Mac с TLS. Ingress проверяет общий секрет (X-Webhook-Secret или HMAC), выставляет OPENCLAW_RUN_ID и запускает, например, ~/runners/netlify-post-deploy.sh (или эквивалент на Node).

Runner определяет целевой URL — прод-домен или deploy preview через API Netlify с NETLIFY_AUTH_TOKEN и DEPLOY_ID. Дальше три фазы по порядку: (A) прогрев, (B) смоук и граф ссылок, (C) POST сводки. Каждая фаза дописывает строку NDJSON в .openclaw/reports/deploy_hook.ndjson, чтобы логи уходили в S3 или прикреплялись к CI без передачи секретов Netlify в GitHub Actions.

Положите скелет в репозиторий как scripts/netlify/openclaw-post-deploy.sh, сделайте исполняемым и направьте хук Netlify (или curl из GitHub Actions) на ingress, который запускает этот файл. Один и тот же сценарий годится для сухого прогона на Mac разработчика и для «боевого» прогона на арендованном удалённом Mac.

1. Контекст: export GIT_SHA="${COMMIT_REF:-$(git rev-parse HEAD)}", export NETLIFY_DEPLOY_ID="${DEPLOY_ID:-unknown}", export OPENCLAW_RUN_ID="$(uuidgen)"; DEPLOY_URL — из JSON тела хука или вывода Netlify CLI.
2. Прогрев с повторами: цикл curl -fsS -o /dev/null -w '%{http_code}' "$DEPLOY_URL/healthz" (или лёгкая страница) до 200 или дедлайна; пауза с экспоненциальным backoff с потолком ~30 с, чтобы не забивать edge при серии 429.
3. Смоук: npx playwright test tests/smoke --project=webkit --project=chromium против DEPLOY_URL; держите набор короче десяти минут, чтобы случайный синхронный вызов хука не упёрся в таймаут.
4. Мёртвые ссылки: обход внутренних якорей из /sitemap.xml или фиксированного списка маршрутов; фиксируйте url, final_status, redirect_chain, content_type. Этап падает, если обязательный маршрут отдаёт 404 или зацикленный редирект.
5. JSON сводки: объедините длительности Playwright и краулера в .openclaw/reports/build_summary.json с полями schema: "build_summary/v1", git_sha, netlify_deploy_id, smoke_ms, link_scan_ms, failed_cases[], exit_code.
6. Callback: POST JSON на webhook комментария PR или совместимый с корпоративным мессенджером endpoint с заголовками Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN и Idempotency-Key: ${GIT_SHA}:${NETLIFY_DEPLOY_ID}:summary, чтобы повторная доставка хука не спамила треды.

Для более глубоких UX-проверок до этой цепочки используйте материал по Lighthouse и ссылкам из вводного абзаца; сам post-deploy hook лучше держать узким: быстрые регрессии, которые заметят клиенты в первую очередь.

Каждая строка NDJSON должна содержать одинаковый набор ключей — и дашборды, и люди говорят на одном языке:

• ▸ts в ISO-8601, level, openclaw_run_id, git_sha, netlify_deploy_id, phase (warmup | smoke | links | callback).
• ▸attempt (с единицы), http_status или curl_exit, duration_ms, url (без токенов в query), error_class (dns, tls, timeout, assert).
• ▸При смоуке — playwright_project и путь к trace_path вместо вставки секретов в stdout.

Повторы: идемпотентные GET-прогревы имеет смысл повторять при 429, 502, 503 и обрыве соединения с джиттером и экспоненциальным backoff (например база 2 с, множитель 1,8, не более шести попыток). Мутирующие сценарии смоука не ретраить вслепую: перезапускайте набор только после смены deploy ID или подтверждённой инвалидации кэша. Числовые дельты длительности фиксируйте в сводке рядом с текстом отчёта, чтобы продакт видел регрессии времени и причину падения в одном сообщении.