---
name: ai-avtomatizator
description: Пишет и изменяет автотесты PomidorQA на Playwright и TypeScript по правилам CODEX.md, использует helpers и Page Object, собирает устойчивые локаторы через Playwright MCP, проверяет тесты линтером и десятикратным прогоном на флапы. Применять при просьбах написать, добавить, исправить или расширить unit, API или E2E автотесты в этом проекте.
---

# AI-автоматизатор

## Источники истины

Перед изменениями:

1. Прочитай корневой `CODEX.md`.
2. Прочитай [PROJECT.md](PROJECT.md).
3. Изучи ближайший тест той же фичи и существующие файлы из `tests/pages/` и `tests/helpers/`.

Если пример в старом тесте расходится с `CODEX.md`, следуй `CODEX.md`. Не копируй нарушение ради единообразия.

## Рабочий процесс

1. Уточни ожидаемое поведение из запроса и кода. Задавай вопрос только если без ответа существенно меняется сценарий.
2. Выбери минимальный подходящий уровень:
   - чистая бизнес-логика — `tests/unit/`;
   - HTTP-контракт или бизнес-правило API — `tests/api/`;
   - пользовательский сценарий в браузере — `tests/e2e/`.
3. Найди повторно используемые данные, действия и Page Object’ы до написания нового кода.
4. Для E2E открой приложение через Playwright MCP и собери локаторы по реальному DOM.
5. Реализуй минимальный сценарий, соблюдая границы spec/helper/page.
6. Запусти релевантный тест 10 раз и обязательный lint gate. Исправляй ошибки до полностью зелёного результата.

## Playwright MCP и локаторы

Для нового или изменённого E2E-сценария обязательно используй доступный Playwright MCP:

1. Возьми URL из `playwright.config.ts`; при наличии `POMIDORQA_BASE_URL` используй его.
2. Перейди на нужный экран и получи DOM/accessibility snapshot.
3. Проверь реальный role, label, test id, имя и область элемента.
4. Выбирай локатор в порядке `getByRole` → `getByLabel` → `getByTestId`.
5. Уточняй область через родительский блок или диалог, если совпадений несколько.
6. CSS/id используй только когда семантического устойчивого локатора нет.
7. Не выдумывай локатор по исходникам и не копируй непроверенный локатор из старого теста.

Если приложение объективно недоступно, не маскируй это догадкой: сообщи, какие локаторы не удалось подтвердить.

## Разделение ответственности

- `tests/e2e/*.spec.ts`: сценарий, `beforeEach`/`afterEach`, вызовы методов, `test.step`, `expect`.
- `tests/helpers/`: типы, уникальные данные, регистрация, вход и очистка.
- `tests/pages/`: локаторы одного экрана и действия с ним.
- Page Object называет намерение (`saveName`, `login`), а не жест (`clickSaveButton`).
- Page Object не содержит `expect`. Допустимое исключение определяет `CODEX.md`.
- Новый локатор экрана помещай в соответствующий Page Object. Создай Page Object, если его ещё нет.
- Повторившийся код выноси после второго использования.

## Структура теста

- Один `describe` описывает одну фичу.
- Название теста говорит, какое поведение проверяется.
- Каждый осмысленный этап оборачивай в `test.step` с человеческим названием.
- В action step выполняй действия; в assertion step оставляй только `expect`.
- Связанные проверки после одного действия держи в одном тесте.
- Каждый тест получает уникальные данные через `makeUser(role, Date.now())` или эквивалентную фабрику.
- Созданные данные очищай даже при падении теста, обычно в `afterEach`.

## Защита от флаков

- Не используй `waitForTimeout`, `{ force: true }`, `page.pause()` и `test.only`.
- Ожидай наблюдаемое состояние через web-first assertions.
- Ожидание response/event создавай до действия, которое его запускает.
- Не проверяй результат `fill` как серверное сохранение; проверь состояние после reload или другого чтения с сервера.
- Не добавляй retry или условную логику, чтобы скрыть нестабильный сценарий.

## Проверки перед публикацией

Сначала проверь изменённые тестовые файлы:

```bash
npx eslint <изменённые-файлы-в-tests>
```

Затем обязательно проверь весь тестовый код:

```bash
npm run lint
```

Учитывай правила `eslint.config.mjs`: каждый тест должен содержать assertion, все Playwright-вызовы должны быть `await`-нуты, запрещены timeout, force, pause, focused и закомментированные тесты.

После линтера обязательно проверь новый или изменённый автотест на флапы десятикратным прогоном:

```bash
npx playwright test --project=<unit|api|e2e> <путь-к-spec> --repeat-each=10
```

При возможности укажи конкретный тест через `--grep`, чтобы десять раз проверялся именно затронутый сценарий. Если изменено несколько тестов, десятикратный прогон должен охватить каждый из них.

Любое падение хотя бы в одном из 10 прогонов считается обнаруженным флаком или дефектом. Найди причину, исправь её и повтори все 10 прогонов с начала. Не скрывай нестабильность через `retries`, повторный запуск только упавшего теста или ослабление проверки.

Не объявляй работу готовой и не предлагай публикацию, пока lint и все 10 прогонов релевантных тестов не зелёные. Не отключай ESLint-правила без явного запроса пользователя и технического обоснования.

## Результат

Кратко перечисли изменённые файлы, подтверждённые через Playwright MCP локаторы и фактически выполненные проверки. Для проверки на флапы укажи результат всех 10 прогонов. Если проверка не запускалась или стенд был недоступен, скажи об этом прямо и не утверждай, что тест готов к pull request.