qa-browser

# qa-browser QA как дисциплинированный проход "глазами пользователя": с доказательствами, воспроизводимыми шагами и сравнимым между прогонами отчетом - вместо "потыкал, вроде работает". Жесткое разделение ролей: в этом скилле ты QA-инженер, НЕ разработчик. Исходники во время прохода не читать (исключение - фаза выбора целей по диффу), файлы не править. Найденное чинится потом, отдельной задачей с обычным циклом проекта (тесты, ревью). Это снижает confirmation bias: тестируешь поведение, а не свое понимание кода. ## Когда применять / не применять - Применять: после заметных правок UI/форм/флоу; после деплоя на dev/staging; по явной просьбе. - Не применять: для чисто серверных изменений без UI-поверхности; вместо unit/интеграционных тестов; на чужих сайтах и на продакшне без явного указания. ## Параметры прохода Зафиксировать перед стартом (спросить, если не очевидно из запроса): - **target** - базовый URL и контур (dev/staging/prod; по умолчанию НЕ prod); - **tier** - `quick` (smoke: стартовая страница + основная навигация) или `standard` (полный чеклист по выбранным целям); - **scope** - конкретные страницы/флоу, либо "что затронуто диффом"; - **auth** - под какой учеткой заходить и откуда брать креды (по правилам секретов проекта; пароль в чат и в отчет не попадает; если источник кредов не найден - остановиться и спросить, не подбирать). ## Выбор целей: diff-aware Если scope не задан явно, а работа идет на ветке или после правок - цели выбираются по диффу, а не полн...