smirnovalex-qa Верификация валидности баг-репорта
Твоя задача — НЕ проверка оформления, а адверсариальная верификация самой проблемы. Исходи из презумпции, что репорт может быть галлюцинацией агента или ложным выводом на основе неполного контекста. Твоя цель — попытаться ОПРОВЕРГНУТЬ репорт, и только если опровергнуть не удалось — подтвердить его.
Входные данные
$ARGUMENTS — путь к файлу баг-репорта или сам текст репорта.
- Если аргумент похож на путь (
docs/bugs/**,*.md,*.txt) — прочитай файл. - Если это текст репорта, вставленный прямо в сообщение, — используй его как есть.
- Если аргумент пуст — возьми баг-репорт из последнего сообщения пользователя в диалоге; если и там его нет, спроси, какой репорт проверить (не выдумывай).
Порядок работы
Извлеки утверждения. Разбей репорт на атомарные фактические утверждения:
- что именно воспроизводится (шаги, входные данные, окружение);
- какое поведение наблюдается (actual);
- какое поведение ожидается (expected) и НА ЧЁМ основано это ожидание (спека, документация, код, здравый смысл автора репорта?);
- какая причина/локализация заявлена (если заявлена).
Проверь каждое утверждение независимо, по первоисточникам:
- найди в коде реальную реализацию описанного поведения — читай код, а не пересказ в репорте; упомянутые файлы/функции/эндпоинты/конфиги должны существовать и делать то, что заявлено;
- проверь, что "ожидаемое поведение" действительно ожидаемо: есть ли требование/спека/контракт, или автор репорта сам его придумал;
- проверь, не является ли поведение намеренным (feature, известное ограничение, осознанный trade-off — ищи комментарии, ADR, git log/blame, существующие тикеты и доки);
- проверь, не устарел ли репорт: возможно, проблема уже исправлена в текущей ветке.
Воспроизведи проблему. Если это возможно в текущем окружении — выполни шаги воспроизведения (запусти код, тест, запрос, скрипт) и зафиксируй фактический результат. Если воспроизвести напрямую нельзя — напиши минимальный тест/скрипт, изолирующий заявленное поведение, и прогони его. Если воспроизведение невозможно в принципе (нужен прод, внешний сервис, специфичные данные) — явно скажи это и оцени проблему только по коду, пометив вывод как косвенный.
Проверь выводы, а не только факты. Даже если наблюдаемое поведение реально, заявленная причина может быть неверной. Отдельно оцени: наблюдение (симптом) vs интерпретацию (диагноз) — они подтверждаются независимо.
Вердикт
Дай один из вердиктов с обоснованием:
- ПОДТВЕРЖДЁН — проблема воспроизведена / однозначно доказана кодом. Приложи доказательства: вывод воспроизведения, ссылки на код (file:line).
- ПОДТВЕРЖДЁН ЧАСТИЧНО — симптом реален, но причина/масштаб/ожидаемое поведение в репорте описаны неверно. Укажи, что именно скорректировать.
- НЕ ПОДТВЕРЖДЁН — проблема не воспроизводится или репорт основан на ложной посылке. Объясни, откуда взялся ложный вывод (какой контекст автор репорта не учёл).
- НЕДОСТАТОЧНО ДАННЫХ — перечисли конкретные вопросы/данные, без которых верификация невозможна (окружение, версия, входные данные, доступы).
Требования к ответу
- Каждый вывод — только со ссылкой на доказательство: код (file:line), вывод команды, результат теста. Утверждения без доказательств запрещены.
- Если уверенность не 100% — явно укажи степень уверенности и что осталось непроверенным.
- НЕ исправляй баг и не меняй код (кроме временных тестов/скриптов для воспроизведения — их удали после проверки). Инструменты редактирования файлов недоступны этому скиллу намеренно — это read-only аудит.
- Если репорт частично неверен — сформулируй уточнения/правки к репорту, чтобы он стал корректным.