2026 OpenClaw — фронтенд на практике:
удалённый Mac: парсинг JSON axe-core и сводка для PR с обратной отдачей
Регрессии доступности дешевле ловить в CI, чем объяснять в чате. Ниже — воспроизводимая цепочка на удалённом Mac: axe-core пишет JSON, шлюз OpenClaw собирает pr_a11y_summary.md, пороги решают успех job, а текст уходит в комментарий к pull request через API — без URL веб-консолей, где нужна уже открытая сессия. Дополнительно: Lighthouse, ссылки и базовая линия a11y, визуальная регрессия → сводка в PR, Source Map и PR-сводка в той же дисциплине комментариев.
| Способ | Когда уместен | Нюансы JSON |
|---|---|---|
| Playwright / Puppeteer + axe | Несколько маршрутов, cookie превью | Файл на URL или объединённый массив; метка времени |
| Cypress, @axe-core/cypress | Зрелые сценарии компонентов и путей | Привязка к id теста для разбора инцидентов |
| @axe-core/cli по staging URL | Лёгкий гейт без оркестратора браузера | Таймауты страниц; аккуратные ретраи |
01 Способ запуска axe и JSON-вывод
axe-core — движок: в 2026 году устойчивый паттерн — запускать его там, где уже поднимается UI: шаги Playwright или Cypress с injectAxe и checkA11y, либо скрипт с @axe-core/cli по HTTPS-превью. На общем удалённом Mac закрепите версии Chromium/WebKit и Node рядом с образом CI, чтобы прогон вчера совпадал с прогоном сегодня.
Сохраняйте машиночитаемый JSON, а не скриншоты DevTools. Каталог вида .openclaw/reports/<git-sha>/a11y/: axe-raw.json или несколько raw_*.json, плюс meta.json с версией axe, строкой браузера и списком URL. Перед сканом стабилизируйте ленивую загрузку и анимации (waitForSelector, при необходимости фиксация часов), чтобы снизить расхождение с ручной проверкой в Safari на том же Mac.
Полный JSON не кладите в мессенджеры: в канал — только путь к артефакту или усечённая сводка; секреты превью не попадают в промпт агента. Job при нарушении политики должен завершаться с ошибкой, но артефакты всё равно загружайте — иначе OpenClaw не соберёт текст для ревьюеров.
02 Шаблон правил парсинга OpenClaw
Агент не должен парсить HTML страницы Git-хоста. Дайте ему чтение репозитория и каталога отчётов; в репозитории зафиксируйте текст правил: «прочитай нормализованный JSON; заполни pr_a11y_summary.md по разделам ниже». Источник истины — violations: группировка по id, для impact берите максимальный уровень в группе; у каждого правила не более пяти уникальных селекторов из nodes, рядом теги WCAG из tags.
Практичный порядок блоков: метаданные (коммит, браузер, количество URL), сводка по impact, топ правил по частоте, представительные узлы (укороченный HTML), команды перепроверки (тот же npm-скрипт или тег Playwright), освобождения от политики только с id тикета. Факты из JSON отделяйте от гипотетических «как починить». Парсинг с битой схемой — ненулевой код выхода, чтобы не смешивать пустую сводку с зелёным гейтом.
03 Поля сводки и пороги
Нормализованный промежуточный файл удобно строить с полями ruleId, impact, wcagRefs, helpUrl (только публичная документация), failureSummary, targetSelectors, url, fingerprint. Полный HTML страницы не храните; фрагменты усечь до пары килобайт, чтобы не тащить PII в PR. Пороги храните в Git рядом с workflow; при смене политики поднимайте schemaVersion в JSON, чтобы старые комментарии явно устаревали.
| Поле / метрика | В сводке | Пример порога |
|---|---|---|
critical |
Отдельный блок сверху | 0 — иначе блокировка merge |
serious |
Таблица и ключевые URL | 0 для релиза; или бюджет команды |
moderate |
Приложение или ссылка на тикет | Часто только учёт без падения job |
| Код выхода | Одна строка в подвале pr_a11y_summary.md |
Превышение порога — exit 1; ошибка парсера — exit 2 |
04 Комментарий у Git-провайдера: описательные шаги без URL «под залогиненного» пользователя
Опишите интеграцию для безопасности и сопровождения как цепочку REST или официального CLI плюс учётные данные с минимальным scope на один репозиторий — а не «откройте вкладку в браузере». Типовой порядок: из payload CI взять идентификатор pull/merge request; прочитать файл pr_a11y_summary.md; выполнить запрос создания или обновления комментария с телом Markdown. Токен выдавать через секрет-хранилище, в логах — без полного значения, только отпечаток или маска.
Для GitHub — fine-grained PAT или GitHub App с правом записи в pull requests одного репозитория; для GitLab — project access token с узким api. В тексте комментария не размещайте ссылки на внутренние дашборды и консоли, которые открываются только после SSO; для справки по правилам используйте стабильные публичные helpUrl из отчёта axe или открытые справочники WCAG. Если с Mac нельзя ходить в API напрямую, отправляйте Markdown на внутренний webhook, который уже держит секреты и пишет комментарий — граница доверия одна.
Идемпотентность: в начале тела комментария скрытый маркер с SHA сборки (HTML-комментарий), поиск существующего комментария перед созданием нового. 429 и 5xx: экспоненциальный backoff с джиттером, ограничение попыток; при флаке не дублируйте десятки сообщений в тред.
05 FAQ по ошибкам
Взрыв числа violations: отфильтруйте сторонние iframe, задайте allowlist правил или доменов; в сводке отдельная колонка «сторонний контент», чтобы не смешивать с кодом продукта.
Таймаут или пустой отчёт: проверьте редирект на страницу входа, DNS, VPN; убедитесь, что превью отдаёт тот же HTML, что и у разработчика на удалённом Mac.
Расхождение с Lighthouse: наборы метрик и правил различаются; зафиксируйте в README, что для релиза источником истины является axe, и синхронизируйте список URL с материалом про Lighthouse и преддеплойную проверку.
401/403 у API: ротация токена, явные permissions в workflow, allowlist исходящих IP для выделенного Mac.
Один и тот же путь: axe → JSON в .openclaw/reports/ → нормализация → OpenClaw → pr_a11y_summary.md → пороги CI → комментарий через API без ссылок на консоли с обязательным входом. Удалённый Mac выравнивает окружение с Safari/WebKit и длительными прогонами агента.
Главная, тарифы, покупка без обязательного входа, помощь и SSH/VNC. Ещё по автоматизации фронтенда: смоук-тесты на Mac, разбор логов E2E, все статьи блога.