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 после гидрации.** ```bash 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` занят пользователем — не убивать!): ```bash 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-вопросы (расхождения с ТЗ) кодом без решения автора ТЗ.