verify-site

name

verify-site

description

Проверяет сайт как живой пользователь через Playwright MCP: открывает страницу, скроллит до конца, кликает по каждой кнопке и ссылке, заполняет и отправляет форму, читает консоль на ошибки, проверяет плавность анимаций, проверяет мобильный вьюпорт (390x844), делает скриншоты на каждом шаге и составляет отчёт о багах в фиксированном формате. Найденные баги чинит и перепроверяет заново, максимум 3 круга. Используй когда просят «проверь сайт», «протестируй сайт как пользователь», «пройдись по сайту руками», «e2e проверка через Playwright», «убедись что всё работает перед публикацией», «QA сайта», «click through the site», «verify the website», «test this like a real user», «browser QA with Playwright MCP», «check the site end to end», а также после любой значимой правки фронтенда перед тем как показать результат пользователю или задеплоить. Triggers: verify-site, проверка сайта, тест сайта, e2e тест, QA прогон, browser testing.

Проверка сайта как живой человек (verify-site)

Цель — пройти сайт руками через Playwright MCP так, как это сделал бы реальный посетитель, и поймать баги, которые не видны по коду: сломанные клики, недоступные формы, ошибки в консоли, дёрганые анимации, проблемы на мобильном.

Используй инструменты Playwright MCP (в этом окружении они с префиксом mcp__playwright__…; если MCP называется иначе — используй эквивалентные): browser_navigate, browser_snapshot, browser_click, browser_fill_form, browser_take_screenshot, browser_console_messages, browser_resize, browser_press_key (для скролла клавишами), browser_evaluate (точечно, если нужно проверить состояние).

Работай кругами. Максимум 3 круга. Если после 3-го круга остаются баги — зафиксируй их в отчёте как открытые, не зацикливайся дальше без явного запроса пользователя.

Круг проверки (шаги 1-8 в каждом круге)

1. Открыть страницу

browser_navigate на целевой URL/локальный dev-сервер. Сразу browser_console_messages, чтобы поймать ошибки уже на загрузке.

2. Снять снапшот структуры

browser_snapshot — получить дерево доступности: список всех интерактивных элементов (ссылки, кнопки, поля форм), которые нужно будет обойти.

3. Проскроллить до конца

Пройди страницу сверху вниз (клавишей End/Page Down через browser_press_key, либо повторяющимся скроллом), с остановками на каждой смысловой секции. Делай browser_take_screenshot на 3-5 ключевых точках скролла (не на каждом пикселе).

4. Кликнуть каждую кнопку и ссылку

Пройдись по всем интерактивным элементам из снапшота (шаг 2):

• Кнопки, которые не открывают модалки/переходы и не выполняют навигацию — считать подозрительными, перепроверить browser_console_messages сразу после клика.
• Внешние ссылки — достаточно убедиться, что href не пустой/не # без обработчика (через снапшот/evaluate, не обязательно открывать каждую в новой вкладке).
• Якорные ссылки/табы/аккордеоны — кликнуть и убедиться, что состояние реально меняется (снапшот до/после).

5. Заполнить и отправить форму

Если на странице есть форма — browser_fill_form валидными тестовыми данными (имя, email вида [e-mail], телефон вида [phone] и т.п., без реальных персональных данных), затем отправить и проверить:

• Появилось ли ожидаемое состояние успеха (сообщение/редирект/дизейбл кнопки).
• Нет ли новых ошибок в консоли после сабмита.
• Проверь также пустую отправку и невалидные данные (например, email без @) — форма должна показывать валидацию, а не падать молча.

6. Проверить консоль

browser_console_messages за весь круг — любые error уровня фиксируются как баг. warning — фиксируются отдельным списком, не блокируют вердикт, но упоминаются в отчёте.

7. Проверить плавность анимаций

Формальных метрик FPS в базовом Playwright MCP нет, поэтому оцени эвристически:

• При скролле и открытии модалок/меню делай 2-3 скриншота подряд с небольшим интервалом в момент анимации — резкие «скачки» layout между кадрами (элемент прыгает, а не плавно движется) = баг.
• Проверь browser_console_messages на warning про layout thrashing/long tasks, если браузер их логирует.
• Если анимаций нет — так и отметь в отчёте, без вымышленных проблем.

8. Мобильный вьюпорт

browser_resize на 390×844. Повтори сокращённую версию шагов 3-6: скролл до конца, клики по ключевым CTA, проверка формы, консоль. Отдельно проверь:

• Не обрезан ли контент, нет ли горизонтального скролла.
• Достаточен ли размер тач-зон у кнопок (визуально по скриншоту).
• Не перекрывает ли фиксированная шапка/футер контент.

Если найден баг

1. Зафиксируй баг в отчёте (см. формат) сразу, со скриншотом-доказательством.
2. После завершения текущего круга — почини баг в коде (Edit/Write), не трогая то, что не сломано.
3. Начни следующий круг с шага 1 (полная переоценка, не только починенного места — правка могла что-то задеть).
4. Если баг не удаётся починить за отведённые 3 круга — оставь его в отчёте как открытый с пометкой и объяснением, что пробовал.

Формат отчёта (строго соблюдать)

## Отчёт verify-site

**Страница:** <URL/путь>
**Круг:** N из 3

### Чек-лист
- [x/•/✗] Навигация и скролл
- [x/•/✗] Кнопки и ссылки
- [x/•/✗] Форма (отправка + валидация)
- [x/•/✗] Консоль без ошибок
- [x/•/✗] Анимации без рывков
- [x/•/✗] Мобильный вьюпорт (390×844)

### Найденные баги

| # | Приоритет | Где | Что не так | Статус |
|---|---|---|---|---|
| 1 | P0/P1/P2 | шаг/секция | описание + ссылка на скриншот | исправлено / открыт |

### Скриншоты
- Десктоп, первый экран: <путь/ссылка>
- Десктоп, низ страницы: <путь/ссылка>
- Мобильный, первый экран: <путь/ссылка>
- <прочие ключевые точки>

### Итоговый вердикт
**ГОТОВ К ПУБЛИКАЦИИ** / **ЕСТЬ БЛОКЕРЫ (P0)** / **ЕСТЬ ЗАМЕЧАНИЯ, НЕ БЛОКИРУЮТ (P1/P2)**

Приоритеты: P0 — сайт сломан/недоступен/данные теряются (блокирует публикацию), P1 — заметно портит опыт, но не критично, P2 — мелкая полировка.

Если за 3 круга остались открытые P0 — итоговый вердикт всегда «ЕСТЬ БЛОКЕРЫ», даже если это последний круг.