Проверить приложение и сохранить тест

Результат — выполненный сценарий, обычный .spec.ts в проекте пользователя и команда повторного запуска. Работай с доступным приложением; не выполняй самостоятельно deploy и не меняй код приложения ради прохождения теста.

Состав проверок задаётся запросом пользователя и требованиями приложения. Названия форм, поля, роли, локаль, данные и бизнес-формулы определяй для текущего приложения. Примеры в справках не добавляют обязательных сценариев: проверка навигации, отчёта или доступа не требует создания записей и проверки всех полей.

Начало

Из контекста определи проект, полный ELEMENT_APP_URL, сценарии и ожидаемые результаты. Готовая сессия передаётся путём ELEMENT_AUTH_STATE. Уточняй только то, без чего нельзя продолжить. Если проекта нет, выбери отдельный постоянный каталог для тестов и сообщи путь.

Уже данное разрешение действует дальше. Просьба создать и проверить тесты разрешает необходимую локальную подготовку; не останавливайся за повторным подтверждением плана. Для общего «проверь приложение» начни с чтения и уточни допустимые изменения перед записью. Если сценарий создаёт данные, сохрани согласованный лимит создания на всю задачу и выбор: оставить записи (keep) или удалить свои после проверки (cleanup). Уже созданные записи и повторные попытки входят в тот же лимит.

Рабочий маршрут

1. Найди существующие specs, config и команды. Нужный тест уже есть — запусти его, без нового scaffold и повторного исследования всего интерфейса.
2. Для нового/изменяемого теста открой authoring.md. Новый проект начни с готовых package.json и config. Остальные справки читай на нужном этапе.
3. Приложению нужен вход, а сессии нет/истекла — authentication.md и auth.mjs: один ручной вход, сохранение, новый context. Секреты вводятся только в браузере; state передаётся без чтения JSON.
4. Исследуй UI по element-ui.md, взяв за основу inspect.spec.ts, сохрани его AUTH-проверки и лимиты. При навигации дождись готовности начальной поверхности перед переходом, затем — целевой. Видимость меню ещё не означает готовность. XBSL/YAML не доказывает DOM.
5. Реализуй согласованные проверки наблюдаемого результата. Для сохранения значений: заполнить → сохранить → заново открыть точную запись → сравнить. Для проверки обязательности — отдельный случай каждого выбранного поля при валидных остальных. Если сценарий может создать запись, открой учёт данных: один файл задачи для всех попыток; prepare создаёт данные, при keep повтор в verify читает сохранённые. record-checks.ts применяй при описанных в справке условиях; другие сценарии остаются обычными specs. Неясный Save сначала сверяй по маркеру/ID. Если отсутствие доказывается поиском, проверь этот поиск на известной записи с тем же полем и форматом запроса.
6. Запусти spec по run-and-debug.md. Чини фактически упавший шаг; максимум два безрезультатных ремонта, включая inspector. Исходные значения и проверки сохраняются при ремонте. Повтори окончательный набор без правок; при keep — без новых записей. Убери временные инспекторы из обычного suite.

Отчёт

Сообщи результат каждого обязательного сценария, общий status/reason, пути к тестам/отчёту и команду повторного запуска. При проблемах укажи evidence, исправления, учтённые записи (если создавались) и ограничения. Статусы описаны в run-and-debug.md.

PASS требует прохождения всех согласованных проверок и, при создании данных, соблюдения лимита и выбранного keep/cleanup. Skip, ноль тестов и exit code 0 сами по себе не доказывают успеха. Auth state и артефакты остаются локальными и исключаются из Git; trace по умолчанию выключен. Не публикуй их автоматически.