QA

QA-верификация задачи

Единый QA-цикл: требования → факты → вердикт → регресс-тесты → гейт. Собран из лучших практик skill-каталогов (superpowers/TDD, verification-before-completion, webapp-testing, playwright-pro, vitest-unit-testing) + проектные засады из боевых сессий.

Два режима — определяются входом:

• Приёмка задачи: вход — ТЗ/тикет (+ ветка/стенд) → отчёт-вердикт по пунктам.
• Аудит чужого QA-отчёта («бред или не бред»): вход — отчёт → перепроверка каждого факта по коду и живому окружению; отчёт судить только по фактам, не по тону.

Что на входе ($ARGUMENTS)

• ТЗ: .docx (конвертировать: textutil -convert txt -output <scratchpad>/tz.txt "<file>"), .md, текст тикета или путь к QA-отчёту (.html — читать как есть).
• Ветка/коммит/MR задачи (по умолчанию — текущая ветка, git log по номеру таски).
• URL стенда (если есть) — иначе локальный рендер.

Шаги

1. Требования → чек-лист

Пронумеровать каждое требование ТЗ (п.1, п.2, …). Из ТЗ вытащить проверяемые факты: точные URL, тексты, количества (посчитать самому: страны/ссылки/пункты), placement («перед блоком X»), коды редиректов. Сверить с планом (.ai-factory/PLAN.md) и коммитами ветки (git show --stat), чтобы знать, что заявлено сделанным.

2. Статическая сверка (код — источник правды)

• Данные/константы: посчитать реальные количества скриптом (python/grep -c), не на глаз.
• Дифф с эталоном: если ТЗ ссылается на образец («как на /euro-cards/») — вычислить точную разницу множеств (что добавлено/потеряно), а не «похоже».
• Всё, чего нет в ТЗ, но есть в реализации (и наоборот) — в отдельный список вопросов.

3. SSR / HTTP (краулер не кликает и не ждёт JS)

Правило: для SEO-требований проверять серверный HTML (curl), НЕ DOM после гидрации.

curl -s <url> -o page.html
grep -c 'href="/target/"' page.html          # ссылка есть как <a href> в разметке?
curl -sI -o /dev/null -w '%{http_code} %{redirect_url}\n' <url>  # именно 301, не 302/307/308

Чек-лист: целевые ссылки в SSR HTML; статусы и коды редиректов; robots meta + X-Robots-Tag + robots.txt; sitemap (URL добавлены/удалены); canonical; заголовки h1-h3 там, где ТЗ их требует. Скрытый контент (hidden, CSS) в HTML — ОК для краулера; контент только в JSON-пейлоаде/после клика — НЕ ОК.

4. Живой рендер (гейт не ловит всё — например, отсутствие "use client")

Поднять свой сервер на отдельном порту (:3000 занят пользователем — не убивать!):

NEXT_DIST_DIR=.next-qa nohup pnpm exec next dev -p 3199 > <scratchpad>/dev.log 2>&1 &
# НЕ `pnpm run dev -- -p 3199` — «--» уходит аргументом next и ломает запуск

Через Playwright MCP: пройти интерактив из ТЗ (клики/табы/раскрытия), проверить что видима ровно одна панель/состояние, скриншоты блоков. Замер после клика — отдельным evaluate-вызовом (React обновляется асинхронно, «после» в том же evaluate = «до»).

Визуальная целостность: не полагаться на скриншоты со скроллом (sticky-хедер даёт артефакты) — числовой дифф getComputedStyle (font-size/weight/family/margins/цвет) нового кода против эталона (стенд со старым кодом / reference :4444 — там фейковый шрифт, сравнивать layout, не размеры текста).

Уборка после: kill <PID>; NEXT_DIST_DIR пачкает репо — git checkout -- next-env.d.ts tsconfig.json; удалить .next-qa, скриншоты из корня.

5. Регресс-тесты на каждый подтверждённый баг

На каждый FAIL — тест, который падает до фикса и зеленеет после (TDD-петля). Паттерны: Vitest + RTL, селектить по testid/ролям/семантике (css:false — module-классы в тест-DOM исчезают); для SSR-требований — тест на присутствие ссылок в разметке (container.querySelectorAll('a[href^=…]')), для скрытости — closest("[hidden]"). Именовать тесты по номеру бага/пункта ТЗ, чтобы отчёт ссылался на них.

6. Гейт и честный вердикт (verification-before-completion)

pnpm run check (или гейт проекта) целиком; при чужом WIP в дереве — коммитить точечным git add своих файлов, чужое не стейджить. Не писать «готово», пока: гейт зелёный И SSR-проверки пройдены И живой рендер проверен. Если что-то не прогнано — так и написать в отчёте («не проверено: …, нужно …»).

Выход

Markdown-отчёт (в чат; по запросу — файл/HTML):

1. Вердикт-таблица по пунктам ТЗ: п.N → PASS / PASS с замечанием / FAIL / QUESTION.
2. Дефекты BUG-NN с severity (major/minor/low), «Где / Суть / Почему важно / Шаги / Ожидаемо»; честно помечать «не регресс этой задачи», если баг старый.
3. Вопросы UNC-NN — расхождения ТЗ↔реализация, которые решает автор ТЗ/SEO, а не код. Не чинить их молча.
4. Не проверено — что и почему, с командой для ручной проверки.
5. Если чинили: список фиксов + регресс-тестов, результат гейта, что осталось.

Анти-паттерны

• Проверять SEO-требования по DOM после гидрации вместо curl серверного HTML.
• Верить «редирект работает» без кода ответа (301 ≠ 302/307/308).
• Считать количества «на глаз» вместо скрипта.
• Скриншот-диффы элементов со sticky-контентом вместо числового computed-styles диффа.
• Убивать чужой dev на :3000; оставлять .next-qa/tsconfig-мусор после себя.
• Объявлять «готово» с непрогнанным гейтом или непроверенным живым рендером.
• Чинить UNC-вопросы (расхождения с ТЗ) кодом без решения автора ТЗ.