# ReTibe MCP — инструкция для Claude Code Вставь этот файл (или ссылку на него) в тред Claude Code, чтобы он подключился к платформе ReTibe и писал тебе автотесты. English version: `docs/CLAUDE_MCP_GUIDE.en.md`. Обе версии держатся в соответствии; при расхождении правилась сначала русская. --- ## 1. Подключение ```bash claude mcp add --transport http retibe https://retibe.com/mcp \ --header "Authorization: Bearer ВАШ_ТОКЕН" ``` Токен выпускается в профиле на https://retibe.com/profile → «API-токены». Показывается один раз, восстановить нельзя. Отзыв там же — действует мгновенно. **Две независимые инстанции.** Есть ещё `https://retibe.ru/mcp` — тот же код и тот же набор инструментов, но **отдельная база**: свои аккаунты, свои сценарии, своя квота. Токен от одной на другой не работает — вернётся `Invalid, revoked or expired`. Выпускай токен там, где лежат твои сценарии. **Вариант со своей машины (stdio).** Если репозиторий ReTibe у тебя локально, подключайся через stdio: сценарии, параметры и история берутся с платформы, а сами прогоны выполняются у тебя — быстро, бесплатно и без расхода месячной квоты (режим `composite`, он включается сам, как только задан `RETIBE_BASE_URL`). ```bash claude mcp add retibe \ --env RETIBE_BASE_URL=https://retibe.com \ --env RETIBE_TOKEN=rtb_... \ -- node /абсолютный/путь/к/TestBot/bin/retibe-mcp.js ``` Токен тот же самый, из профиля. Он имеет приоритет над `RETIBE_EMAIL` / `RETIBE_PASSWORD` / `RETIBE_COOKIE`: если задать их вместе с токеном, они будут проигнорированы, и сервер скажет об этом в stderr. Режим и способ авторизации видны в первой строке лога: `backend=composite (runs local, reads https://retibe.com auth=token)`. Проверка после подключения: попроси Claude вызвать `retibe_whoami`. Он должен вернуть твой email, план, остаток квот и `build.sha` — коммит, на котором собран отвечающий тебе образ (зачем это нужно — раздел 6). **Частота вызовов ограничена.** Публичный эндпоинт режет её до проверки токена: 60 вызовов в минуту на токен (пачкой до 30) и 120 в минуту на адрес (пачкой до 60). Отказ — HTTP 429 с заголовком `Retry-After` и кодом `-32004`; это «подожди столько-то секунд», а не «кончилась квота» (`-32003`) и не «токен отозван». Повтор в цикле без паузы только держит корзину пустой. **Всё, что токен записывает, записывается в журнал.** Каждый не-GET запрос, сделанный токеном, оставляет строку: время, метод, путь, код ответа, имя токена и идентификатор задетой сущности — сценария, расписания, кейса чек-листа, параметра, прогона. Тела запросов в журнал не попадают: шаги сценариев, значения параметров и секреты туда физически не доходят — журнал снимается до разбора тела. Работа через браузер под cookie строк не добавляет: там и так видно, кто это был. Журнал живёт 90 дней (на своей инсталляции — `API_AUDIT_RETENTION_DAYS`), читается инструментом `retibe_audit` (раздел 8). Чем авторизована сессия, видно в `retibe_whoami`: `authVia` — `api_token` или `session`. --- ## 2. Чем это отличается от Playwright MCP Важно понимать до начала, иначе ожидания разойдутся с реальностью. | | Playwright MCP | ReTibe MCP | |---|---|---| | Модель работы | водит браузер вживую | пишет сценарий, прогоняет, читает разбор | | Видит ли страницу между шагами | да | **нет** — но видит её ДО того, как написан сценарий: `retibe_inspect_page`, раздел 5 | | Что остаётся после сессии | ничего | сохранённый сценарий, отчёт, история прогонов | | Повторный прогон | заново объяснять | один вызов по id | | Где выполняется | локально | на платформе, в её браузерах | **Вывод: разведка больше не обязана быть чужой.** У ReTibe теперь есть обе её половины, и на платформе обе смотрят на страницу тем же окружением, тем же хранилищем параметров и с того же исходящего IP, с которых пойдёт прогон: - **`retibe_crawl`** — карта сайта: какие страницы вообще есть, на какой глубине, какой у них заголовок и сколько на каждой ссылок, форм, кнопок и полей. С этого начинают, когда дан домен, а не страница. - **`retibe_inspect_page`** — разметка ОДНОЙ страницы: заголовки, поля форм с их подписями, кнопки, ссылки, iframe'ы с готовым значением `data.frame` и по 1–2 кандидата в селекторы на элемент, каждый проверен на то, что указывает ровно на один элемент. Разница между ними принципиальная: **обход даёт счётчики, разведка страницы — селекторы**. «На /checkout две формы» — это повод открыть /checkout, а не то, что можно вставить в шаг. Playwright MCP по-прежнему хорош для интерактивного «покликай и посмотри, что будет». Но за селекторами для сценария ходить теперь надо не туда: страницу, которую увидит прогон, показывает прогонный браузер. ReTibe хорош для закрепления — «этот путь должен работать всегда, проверяй его при каждом релизе». Они не конкуренты. Рабочая связка: разведать `retibe_inspect_page`, закрепить в ReTibe, а Playwright'ом исследовать руками то, чего в сценарии ещё нет. --- ## 3. Как просить Работает хорошо: > Напиши сценарий ReTibe: открыть https://example.com, проверить что есть > заголовок, перейти на /pricing, убедиться что видна форма. Провалидируй, > прогони и покажи результат. > Посмотри https://shop.example.com/checkout через `retibe_inspect_page` и скажи, > какими селекторами адресовать поля карты. Угадывать не надо. > Прогон webtest-123 упал. Сравни его с последним зелёным и скажи, что изменилось. > Проверь мои сценарии на предмет проверок, которые ничего не проверяют. > Посмотри чек-лист «Релиз 2.4»: что там ещё руками? Возьми верхний кейс, > напиши сценарий и привяжи его к этому кейсу. > Поставь smoke-набор на каждое утро в 07:30 по Москве. Покажи, на какое время > платформа его поставила. > Что у меня запланировано на следующую неделю и что упало за прошлую? Работает плохо: > Потести сайт. Слишком расплывчато. Посмотреть страницу Claude теперь может сам (`retibe_crawl`, `retibe_inspect_page`), а вот чтó на ней важно — знаешь только ты. --- ## 4. Правильный порядок работы Скажи Claude следовать этому порядку — он заложен в инструменты: 1. **`retibe_env`** — какие есть окружения и ключи параметров 2. **`retibe_crawl`** — если дан домен, а не страница: карта сайта, чтобы выбрать, про чтó вообще писать сценарий (раздел 5) 3. **`retibe_inspect_page`** — посмотреть нужную страницу: заголовки, формы с их подписями, кнопки, ссылки, iframe'ы и кандидаты в селекторы, проверенные на уникальность. Стоит единицу отдельной дешёвой квоты `inspections`, а не `web_tests` (раздел 5) 4. **`retibe_actions`** — каталог действий и контракт каждого, которое собирается использовать 5. **`retibe_reference`** — сквозные механики (шаблоны, условия, фикстуры) 6. **`retibe_param`** — если сценарию нужны логин, пароль или базовый URL, завести их сейчас (раздел 19). Параметры вперёд, сценарий потом 7. написать сценарий 8. **`retibe_validate_scenario environment:'…'`** — до запуска браузера, занимает миллисекунды и не стоит ни единицы квоты 9. **`retibe_validate_scenario view:'storyboard'`** — «а какой из этих шагов вообще способен покраснеть?» 10. **`retibe_run_scenario`** → **`retibe_run_result`** Шаги 2–3 — это не роскошь, а самая дешёвая часть цикла. Придуманный селектор стоит минуту браузера и единицу `web_tests` за каждую попытку; разведка отвечает на тот же вопрос за единицу `inspections`, которых на порядок больше. Вставляй селекторы из ответа как есть. `retibe_inspect_page` по умолчанию показывает страницу целиком, но ответ обрезан бюджетом в 8 КБ: `counts` говорит, сколько элементов было на самом деле, а `truncated` — что именно выкинули, чтобы влезть. Нужна одна часть страницы — сузь её `selector:'form#checkout'`: это и дешевле по контексту, и точнее. Кандидаты при этом всё равно проверяются на уникальность по всему документу, а не по поддереву, так что селектор из суженной разведки остаётся верным в сценарии. Шаг 8 пропускать нельзя. Платформа **не валидирует сценарии** — она примет сломанный и будет его гонять. С аргументом `environment` валидатор делает ещё и предполётную сверку: каждый `{{params.*}}` из сценария проверяется по настоящему хранилищу этого окружения, и то, чего там нет, приезжает как `PARAM_KEY_MISSING`. Это важно потому, что ненайденный ключ **не роняет шаг**: резолвер оставляет плейсхолдер как есть, и в поле логина уезжает текст `{{params.auth.email}}`. Без аргумента сверки не будет, и ответ скажет об этом полем `unchecked`, а не промолчит — подробности в разделе 19. Браузер при этом всё равно не запускается и квота не тратится. Шаг 9 — это ответ на вопрос, которого список предупреждений не даёт. Сорок варнингов не говорят, заметит ли тест поломку сайта; раскадровка говорит, и занимает те же миллисекунды. Если в итоге написано «покраснеть не может ничто» — сценарий декоративный, и прогонять его бессмысленно. Если на аккаунте есть чек-листы, перед пунктом 7 полезен нулевой шаг — **`retibe_checklists`**: он отвечает на «что вообще автоматизировать», а после сохранения сценария **`retibe_checklist_item op:link`** привязывает кейс к нему. Привязка — обычная строка, которую платформа не проверяет; как она ломается, написано в разделе 10. Как назвать сценарий и сколько их вообще должно быть — раздел 15. Прочитай его **до** пункта 7: имя и верхнеуровневый `id` потом почти не поменять, потому что на них завязаны и история, и привязка к чек-листу. После `retibe_save_scenario` — допиши строку в `docs/TEST_COVERAGE.md`, карту покрытия проекта (раздел 18). В тот же заход, а не «потом»: тред, который придёт следующим, начнёт с этого файла. Сохранение обратимо, и на это можно опираться. Каждое сохранение, меняющее шаги, имя или описание, оставляет снимок: в ответе `retibe_save_scenario` приходит `revision`, а `retibe_scenarios {id:47, revisions:true}` показывает последние двадцать правок с диффом шагов у каждой. Откат — одна команда: `retibe_save_scenario {op:'revert', id:47, revision:4, confirm:true}`. Без `confirm` откат отказывается и показывает дифф, который собирался применить, так что посмотреть, что вернётся, ничего не стоит. Состояние, которое откат вытеснил, тоже становится ревизией — то есть откат откатывается тем же вызовом. Это не повод не проверять сценарий перед сохранением: ревизии хранят двадцать последних правок и ничего не знают о прогонах, чек-листах и `historyId`. `retibe_examples` и `retibe_docs` в этот порядок намеренно не входят — они нужны не всегда. Бери их, когда действие незнакомое и контракта из `retibe_actions` не хватает: `retibe_examples` даст рабочий сценарий целиком, `retibe_docs` — прозу по разделу. Насколько им верить — раздел 6. --- ## 5. Разведка: карта сайта и разметка страницы Самая дорогая ошибка в этом продукте — придуманный селектор. Агент пишет `#submit-button`, на странице `button.btn-primary`, прогон падает на первом шаге, и минута браузера плюс единица `web_tests` потрачены на опечатку. Два инструмента закрывают это до прогона. ### `retibe_crawl` — какие страницы вообще есть Отвечает на вопрос, который идёт первым, когда дан домен: на что вообще писать сценарий. Обходит сайт с указанного URL и возвращает карту — каждую дошедшую страницу, её глубину, заголовок и счётчики ссылок, форм, кнопок и полей. ``` retibe_crawl url:'https://shop.example.com' retibe_crawl url:'https://shop.example.com' max_pages:20 max_depth:2 retibe_crawl crawl_id:'…' ``` | Аргумент | Что делает | |---|---| | `url` | откуда начать. Обязателен, если не передан `crawl_id` | | `crawl_id` | дочитать обход, начатый предыдущим вызовом, вместо нового | | `max_pages` | сколько страниц посетить, 1–20, по умолчанию 10. Тариф может урезать — ответ говорит, сколько дали на самом деле | | `max_depth` | 0 — только стартовая страница, 1 — её ссылки, 2 — их ссылки. Только свой домен | | `wait_ms` | сколько ждать обход, 0–55000, по умолчанию 50000 | **Он возвращает счётчики, а не селекторы.** «На /checkout две формы и девять полей» — это повод открыть /checkout разведкой, а не то, что можно вставить в шаг. Ни одного проверенного адреса элемента здесь нет и быть не может: краулер считает, а не адресует. Страница — до тридцати секунд, поэтому инструмент ждёт `wait_ms` и, если не дождался, отдаёт `crawl_id`; второй вызов с ним дочитывает готовую карту. Страницы, которые не загрузились, приезжают отдельным списком `deadPages` — их не смешивают с пустыми. Страницы, опознанные как SPA, приходят **без** счётчиков (`—`, а не `0`): с них снимаются метрики производительности вместо разметки. Один обход на аккаунт одновременно; второй получает 409. ### `retibe_inspect_page` — что на странице и как это адресовать Открывает одну страницу в headless-браузере и возвращает компактный очерк: заголовки, формы с подписанными полями, кнопки, ссылки, iframe'ы (с готовым значением для `data.frame`) и у каждого элемента 1–2 кандидата в селекторы, каждый проверен на момент съёмки на уникальность (`querySelectorAll().length === 1`). Эти селекторы надо вставлять как есть. | Аргумент | Что делает | |---|---| | `url` | обязателен; может содержать `{{params.*}}` — на платформе они разрешаются | | `environment` | в каком окружении разрешать параметры | | `selector` | сузить очерк до поддерева, например `form#checkout` | | `maxElements` | потолок на каждый список, 1–100, по умолчанию 40 | Ответ ограничен 8 КБ: `counts` говорит, сколько элементов было на самом деле, `truncated` — что именно выкинули. `scopeNotFound: true` значит, что `selector` не нашёл ничего, — тогда пустые списки означают «никуда не смотрели», а не «на странице пусто». Кандидаты проверяются на уникальность по всему документу, а не по поддереву, так что селектор из суженной разведки остаётся верным в сценарии. Одна разведка на аккаунт одновременно; вторая получает `INSPECT_IN_FLIGHT` — ответ приходит не позже сорока секунд, так что это «подожди», а не «сломалось». ### Квота у разведки своя, и она дешевле Вызов на платформе списывает единицу счётчика `inspections`, а не `web_tests`: 60 в месяц на Free, 600 на Professional, безлимит на Corporate — на порядок больше, чем прогонов, именно чтобы агент никогда не экономил на «посмотреть». Остаток виден в `retibe_whoami` строкой `inspections: 3/60`. Списывается только после состоявшейся навигации: опечатка в URL, отказ по адресу или мёртвый DNS не стоят ничего. `retibe_crawl` квоту `inspections` не тратит — его режет тариф по числу страниц. ### Платформа против своей машины На платформе страница открывается тем же окружением, тем же хранилищем параметров и с того же исходящего IP, что и прогон. `retibe_inspect_page` работает и без платформы — локальный бэкенд откроет страницу браузером на твоей машине, — но это более слабое утверждение, и в ответе оно помечено `source: 'local'`: твоя сеть и твой IP, квоты нет вовсе, `{{params.*}}` не разрешаются (URL с шаблоном отвергается до запуска браузера), зато `localhost` разрешён и нужен Chromium на машине. `retibe_crawl` локального аналога **не имеет**. Что именно меняется в каждом из этих пунктов и почему в `composite`-режиме разведка всё равно идёт на платформу (`source: 'remote'`) — `retibe_docs section:'local-vs-platform-inspection-ru'`. ### Чего разведка не делает Селекторы проверены на уникальность **в момент съёмки**. Страница, которая рендерится по-разному от сессии к сессии, их сломает — поэтому предпочитай кандидатов с `id`, `data-testid` и `name` путям вида `nth-of-type`. Адреса внутренней сети платформа не открывает: URL, который резолвится в приватный диапазон, отвергается до запуска браузера — и так же на каждом редиректе, куда страница попыталась уйти. Что именно запрещено — в разделе 9. --- ## 6. Насколько этим знаниям можно верить У инструментов справки **разная природа и разная надёжность**. Это не придирка — от этого зависит, чему верить при расхождении. | Инструмент | Откуда берётся | Гарантия свежести | |---|---|---| | `retibe_actions` | извлечён из `switch` самого движка разбором AST | **высокая** — тест перечитывает движок на каждом прогоне и падает при расхождении | | имена полей `data.*`, `required`, алиасы | разбор AST движка: чтения `data.*` внутри каждого `case`, включая делегаты и типы их параметров | **высокая** — тест перечитывает движок на каждом прогоне и падает, если движок читает поле, которого нет в контракте | | описания полей `data.*`, ловушки, примеры | написаны руками против исходника движка | **средняя** — правятся руками; новое поле доезжает как «(undocumented — read by the engine, not yet described)», пока его не описали | | `retibe_reference` | заморожённый текст, вшит в сборку | **низкая** — не пересобирается ничем | | `retibe_docs`, `retibe_examples` | файлы `knowledge/` и `examples/`, лежат в образе | **средняя** — правятся руками, с движком не сверяются | | привязка чек-листа к сценарию | строка, которую кто-то когда-то ввёл руками | **никакая** — ни FK, ни триггера, ни сверки; ломается молча (раздел 10) | | `docs/TEST_COVERAGE.md` в репозитории | ведётся руками этим же тредом | **никакая** — ничто не сверяет; но это единственное место, где записано «чего нет и почему» (раздел 18) | | описания инструментов | написаны руками | **низкая** — с движком ничем не связаны | | промпты `/author`, `/debug`, `/harden` | написаны руками, но закрыты тестом | **средняя** — тест проверяет, что каждый упомянутый инструмент зарегистрирован на этом бэкенде, что ключевые шаги на месте и что текст правильно ветвится по бэкенду; качество формулировок не проверяет ничто | **Что это значит на практике.** Список действий — это надёжно. Если `retibe_actions` действие не вернул, его в движке нет: каталог машинно извлечён из диспетчера и закрыт тестом на дрейф. Придуманные действия (`web_fill`, `web_type`, `web_hover`) валидатор ловит. Список полей `data.*` — тоже надёжно, и по той же причине: он извлечён из тел `case` движка вместе с делегатами и типами их параметров. Если `retibe_actions` показал поле с типом «(undocumented — read by the engine, not yet described)» — движок его читает, а описания ещё нет: поле рабочее, смысл уточняй по движку. Гейт односторонний там, где движок отдаёт `data` целиком (`web_assert`, `api_request`): для таких действий список полей может быть неполным. Всё остальное — прозаические утверждения, которые могли отстать от кода (описания полей в том числе: с движком сверены их имена, но не их смысл). Веришь им до первого противоречия с поведением; при расхождении прав движок. **`retibe_docs` и `retibe_examples` на `retibe.com/mcp` работают** — начиная с `d1069cc`. До него образ собирался без каталогов `knowledge/` и `examples/`, и оба инструмента отвечали ошибкой на каждый вызов; теперь Dockerfile кладёт их в `/app`, откуда сервер и резолвит их (`repoRoot = RETIBE_REPO_ROOT ?? cwd`). Если всё-таки видишь `... is missing from this checkout` — эндпоинт поднят на образе старше этого коммита, и лечится это передеплоем, а не правкой сценария. **Публичный эндпоинт может отставать от репозитория — и теперь это видно.** Деплой ручной: `git pull` плюс пересборка контейнера, без CI/CD, и никакая проверка на границе не срабатывает. Но эндпоинт сообщает свою сборку: `retibe_whoami` отдаёт `build: { sha, version, startedAt }`, а `GET /health` — поле `build`. Там же `publicBase` — адрес, от которого строится каждая ссылка в ответах (отчёт, скриншоты, JUnit, Allure), и `platform` — адрес, по которому эндпоинт сам ходит в платформу; внутри деплоя это `http://app:3000`, и так и должно быть. Сравни сборку с тем, что в репозитории: git rev-parse --short=12 origin/main Совпало — поведение эндпоинта и есть поведение main, и расхождение с этим файлом надо чинить в коде. Не совпало — правка просто ещё не выкачена, и дебажить нечего. `build.sha: "dev"` означает образ, собранный без метки (локальный запуск или ручной `docker compose build` мимо deploy.sh); `build.version` — версия из package.json, `build.startedAt` — момент старта процесса: свежий sha при старом `startedAt` значит, что образ пересобрали, а контейнер не перезапустили. Ту же сборку видно ещё до первого вызова — в ответе `initialize` поле `serverInfo.version` имеет вид `1.0.0+`. --- ## 7. Главное, что нужно знать про этот движок Здесь причина, по которой валидатор вообще написан. Движок принимает почти что угодно, поэтому сломанный тест не падает — он **проходит зелёным, ничего не проверяя**. Клоду это сказано в описаниях инструментов, но полезно знать и тебе. **Проверки, которые не могут упасть.** `api_test`, `security`, `accessibility`, `seo_analysis`, `graphql_test`, `load_test` и ещё несколько записывают проблему в findings, а сам шаг остаётся `passed`. API вернул 500 — тест зелёный. Если шаг должен блокировать релиз, после него нужен настоящий ассерт. **`web_assert` умеет меньше, чем кажется.** Он проверяет видимость и вхождение подстроки — причём подстроку только через `data.contains` или его алиас `data.expectedText` (движок читает `data.contains ?? data.expectedText`). Поля `assertion` / `expected` / `attribute` / `text` / `value` **не читаются вообще** — шаг с ними пройдёт на любом видимом элементе с любым текстом. **У селекторов два движка, и от этого зависит синтаксис.** Одна и та же строка в `web_click` и в `web_wait` разбирается по-разному: | Путь | Какие поля по нему идут | `:contains('текст')` | Синтаксис Playwright (`:has-text()`, `text=`, `xpath=`, `role=`) | |---|---|---|---| | **A — собственный резолвер движка** (`findElementBySelector`) | `web_click` (`selector`, `buttonSelector`, `waitForSelector`), `web_click_submenu` (`submenuParentSelector`, `submenuSelector`, `waitForSelector`), `web_fill_form` (`formFields[].selector`, `formSubmitSelector`) | **работает**, но только в точной форме `тег:contains('текст в кавычках')`: кавычки обязательны, после закрывающей скобки ничего | работает — всё, что не `:contains()`, уходит в Playwright как есть | | **B — напрямую в Playwright** | всё остальное: `web_assert.selector`, `web_extract.selector`, `web_wait.waitForSelector`, `web_login.loginSelectors.*`, `web_fill_form.successSelector` и `errorMessageSelectors[]`, `webrtc_verify_stream.videoSelector`, `page_*`, `condition.selector`, `skipIf.condition.selector`, `data.frame` | **синтаксическая ошибка** — такого движка у Playwright нет, отвергается весь селектор целиком | работает | Путь A ещё и режет строку по запятым и пробует альтернативы по очереди — запятая ВНУТРИ `:has-text("a, b")` или `:is(a, b)` будет прочитана как отдельная альтернатива и сломает селектор. Внутри тела `use_fixture` пути A нет вовсе: фикстурный диспетчер кликает и заполняет голыми вызовами Playwright, так что там любой селектор — путь B, и `button:contains('Login')`, безупречный в сценарии, в фикстуре роняет шаг. Валидатор знает эту таблицу по полям и отвечает тремя кодами, и все три — **предупреждения**: они называют шаг, который сломается, но не запрещают ни сохранение, ни прогон — эти правила моложе сценариев, которые они судят, и сценарий, который отработал вчера, обязан отработать и сегодня. При авторинге зовите `retibe_validate_scenario strict:true` — там они снова блокируют. Три кода: `SELECTOR_UNSUPPORTED_PSEUDO` (`:contains()` на пути B), `SELECTOR_CONTAINS_BAD_SHAPE` (`:contains()` на пути A, но в форме, которую хелпер не переводит — такую альтернативу движок **выбрасывает, даже не попробовав**, и шаг падает «ничего не найдено» после полного таймаута) и `SELECTOR_JQUERY_PSEUDO` (`:eq()`, `:first`, `:input`, `:checkbox`, `:hidden` и ещё полтора десятка — это jQuery, а не CSS, их не переводит ни один путь). `:has()`, `:is()`, `:not()`, `:first-child`, `:checked`, а также добавленные Playwright `:visible`, `:has-text()`, `:text()`, `:nth-match()` — валидны, и валидатор про них молчит. Строки, которые не CSS (`xpath=…`, `//…`, `text=…`, `id=…`, `role=…`) и любая строка с `{{` не судятся вовсе. Те же коды приходят и из `web_evaluate`: валидатор читает в `data.script` строковые литералы, переданные в `querySelector`, `querySelectorAll`, `closest` и `matches`, и судит их по пути B — только жёстче, потому что между строкой и браузером там нет даже Playwright. `:contains()` и jQuery-псевдоклассы в скрипте он ловит; а вот `:has-text()`, `>> nth=` и `:nth-match()` там тоже не работают, но валидатор про них в скрипте молчит — держи это в голове сам. Переменная, шаблонная строка или конкатенация вместо литерала не судятся. Селекторы `page_method` не судятся вовсе: они лежат в базе page object'ов, а не в сценарии. **Отсутствие проверяется полем `data.absent: true`.** Оно ждёт у Playwright состояния `hidden`, а это **исчез из DOM ИЛИ есть, но не виден** (`display: none`, `visibility: hidden`, нулевой размер) — ровно «попап закрылся», «ошибка пропала». Так и задумано: модалки чаще прячут, чем удаляют, и ассерт, который ждёт именно удаления, краснел бы на каждом втором сайте. Шаг честно падает по `Timeout ms`, пока элемент всё ещё на экране, — сломай его нарочно и убедись. Два условия. Первое: строго булево `true` — `"true"`, `1` и `"yes"` оставляют обычную проверку видимости, то есть шаг начинает проверять ровно обратное тому, что написано; валидатор ловит это кодом `ASSERT_ABSENT_NOT_BOOLEAN`. Второе: вместе с `absent: true` текст **не** проверяется — движок выходит до сравнения, и `contains`/`expectedText` на таком шаге мертвы (`ASSERT_ABSENT_IGNORES_TEXT`). `visible: false` — это **не** отсутствие: ожидание всего лишь ослабляется до `state: "attached"`, элемент обязан остаться в DOM. Поле осталось для ``-элементов и скрытых узлов, которые должны быть на месте. ```json { "id": "popup-gone", "action": "web_assert", "data": { "selector": ".popup", "absent": true, "timeout": 5000 } } ``` **`web_evaluate` годится и как разведка.** Всё, что вернул скрипт, попадает не только в лог, но и в результат шага, а оттуда — в `extracted` дайджеста (раздел 9). Там же оказываются значения `web_extract`. `step.storeAs` по-прежнему **ничего не связывает** между шагами — предупреждение `STOREAS_DEAD` остаётся верным, — но теперь он хотя бы подписывает значение именем в `extracted`. Чтобы передать значение из шага в шаг, это всё ещё `data.storeResponseAs`. **`web_fill_form` проглатывает ошибки полей — но теперь перечитывает форму.** По умолчанию неудача с отдельным полем не роняет шаг: она уходит в `validationErrors`, а шаг остаётся `passed`. Сверх этого после заполнения **всех** полей движок перечитывает каждое и пишет в сообщение шага, что в форме реально лежит: `#card → 19 симв. | #month → ПУСТО`. Значения именно **описаны, а не выведены** — эта строка попадает в лог, в HTML-отчёт и в сохранённый результат, а в форме лежат номера карт, CVV и разрешённые `{{params.*}}`; если нужны сами значения, `revealValues: true` покажет их, кроме пароля. Поле, которому просили непустое значение, а оно пусто, значит страница его очистила или отвергла: при `validateForm: true` это роняет шаг и называет поле, без флага — предупреждение. Переформатирование провалом **не** считается, иначе номер карты падал бы всегда, а поле, которое не удалось прочитать уверенно, отмечается как непрочитанное и не роняет ничего. Чтение повторяет ретаргетинг Playwright, поэтому поле, адресованное через свой `